| slovo | definícia |
interpreted
(encz) | interpreted,interpretovaný adj: Zdeněk Brož |
interpreted
(encz) | interpreted,tlumočil v: Zdeněk Brož |
Interpreted
(gcide) | Interpret \In*ter"pret\, v. t. [imp. & p. p. Interpreted; p.
pr. & vb. n. Interpreting.] [F. interpr[^e]ter, L.
interpretari, p. p. interpretatus, fr. interpres interpeter,
agent, negotiator; inter between + (prob.) the root of
pretium price. See Price.]
[1913 Webster]
1. To explain or tell the meaning of; to expound; to
translate orally into intelligible or familiar language or
terms; to decipher; to define; -- applied esp. to
language, but also to dreams, signs, conduct, mysteries,
etc.; as, to interpret the Hebrew language to an
Englishman; to interpret an Indian speech.
[1913 Webster]
Emmanuel, which being interpreted is, God with us.
--Matt. i. 23.
[1913 Webster]
And Pharaoh told them his dreams; but there was none
that could interpret them unto Pharaoh. --Gen. xli.
8.
[1913 Webster]
2. To apprehend and represent by means of art; to show by
illustrative representation; as, an actor interprets the
character of Hamlet; a musician interprets a sonata; an
artist interprets a landscape.
Syn: To translate; explain; solve; render; expound;
elucidate; decipher; unfold; unravel.
[1913 Webster] |
interpreted
(wn) | interpreted
adj 1: understood in a certain way; made sense of; "a word taken
literally"; "a smile taken as consent"; "an open door
interpreted as an invitation" [syn: interpreted,
taken] |
interpreted
(foldoc) | interpreter
interpreted
A program which executes other programs. This
is in contrast to a compiler which does not execute its
input program (the "source code") but translates it into
executable "machine code" (also called "object code")
which is output to a file for later execution. It may be
possible to execute the same source code either directly by an
interpreter or by compiling it and then executing the {machine
code} produced.
It takes longer to run a program under an interpreter than to
run the compiled code but it can take less time to interpret
it than the total required to compile and run it. This is
especially important when prototyping and testing code when an
edit-interpret-debug cycle can often be much shorter than an
edit-compile-run-debug cycle.
Interpreting code is slower than running the compiled code
because the interpreter must analyse each statement in the
program each time it is executed and then perform the desired
action whereas the compiled code just performs the action.
This run-time analysis is known as "interpretive overhead".
Access to variables is also slower in an interpreter because
the mapping of identifiers to storage locations must be done
repeatedly at run time rather than at compile time.
There are various compromises between the development speed
when using an interpreter and the execution speed when using a
compiler. Some systems (e.g. some Lisps) allow interpreted
and compiled code to call each other and to share variables.
This means that once a routine has been tested and debugged
under the interpreter it can be compiled and thus benefit from
faster execution while other routines are being developed.
Many interpreters do not execute the source code as it stands
but convert it into some more compact internal form. For
example, some BASIC interpreters replace keywords with
single byte tokens which can be used to index into a {jump
table}. An interpreter might well use the same {lexical
analyser} and parser as the compiler and then interpret the
resulting abstract syntax tree.
There is thus a spectrum of possibilities between interpreting
and compiling, depending on the amount of analysis performed
before the program is executed. For example Emacs Lisp is
compiled to "byte-code" which is a highly compressed and
optimised representation of the Lisp source but is not machine
code (and therefore not tied to any particular hardware).
This "compiled" code is then executed (interpreted) by a {byte
code interpreter} (itself written in C). The compiled code
in this case is machine code for a virtual machine which
is implemented not in hardware but in the byte-code
interpreter.
See also partial evaluation.
(1995-01-30)
|
| | podobné slovo | definícia |
interpreted
(encz) | interpreted,interpretovaný adj: Zdeněk Brožinterpreted,tlumočil v: Zdeněk Brož |
misinterpreted
(encz) | misinterpreted,nesprávně vyložený Zdeněk Brož |
uninterpreted
(encz) | uninterpreted,neinterpretovaný adj: Zdeněk Brožuninterpreted,nevyložený adj: Zdeněk Brožuninterpreted,nevysvětlený adj: Zdeněk Brož |
Uninterpreted
(gcide) | Uninterpreted \Uninterpreted\
See interpreted. |
interpreted
(wn) | interpreted
adj 1: understood in a certain way; made sense of; "a word taken
literally"; "a smile taken as consent"; "an open door
interpreted as an invitation" [syn: interpreted,
taken] |
interpreted
(foldoc) | interpreter
interpreted
A program which executes other programs. This
is in contrast to a compiler which does not execute its
input program (the "source code") but translates it into
executable "machine code" (also called "object code")
which is output to a file for later execution. It may be
possible to execute the same source code either directly by an
interpreter or by compiling it and then executing the {machine
code} produced.
It takes longer to run a program under an interpreter than to
run the compiled code but it can take less time to interpret
it than the total required to compile and run it. This is
especially important when prototyping and testing code when an
edit-interpret-debug cycle can often be much shorter than an
edit-compile-run-debug cycle.
Interpreting code is slower than running the compiled code
because the interpreter must analyse each statement in the
program each time it is executed and then perform the desired
action whereas the compiled code just performs the action.
This run-time analysis is known as "interpretive overhead".
Access to variables is also slower in an interpreter because
the mapping of identifiers to storage locations must be done
repeatedly at run time rather than at compile time.
There are various compromises between the development speed
when using an interpreter and the execution speed when using a
compiler. Some systems (e.g. some Lisps) allow interpreted
and compiled code to call each other and to share variables.
This means that once a routine has been tested and debugged
under the interpreter it can be compiled and thus benefit from
faster execution while other routines are being developed.
Many interpreters do not execute the source code as it stands
but convert it into some more compact internal form. For
example, some BASIC interpreters replace keywords with
single byte tokens which can be used to index into a {jump
table}. An interpreter might well use the same {lexical
analyser} and parser as the compiler and then interpret the
resulting abstract syntax tree.
There is thus a spectrum of possibilities between interpreting
and compiling, depending on the amount of analysis performed
before the program is executed. For example Emacs Lisp is
compiled to "byte-code" which is a highly compressed and
optimised representation of the Lisp source but is not machine
code (and therefore not tied to any particular hardware).
This "compiled" code is then executed (interpreted) by a {byte
code interpreter} (itself written in C). The compiled code
in this case is machine code for a virtual machine which
is implemented not in hardware but in the byte-code
interpreter.
See also partial evaluation.
(1995-01-30)
|
|