OpenEuphoria

Re: modified reverse

• Posted by Robert Craig <rds at RapidEuphoria.com> Aug 07, 2001
• 492 views

rforno writes:
> Rob, I do not understand. floor(anything) should 
> always be an integer. 

floor(1e12) produces a 
"mathematical integer" but does not
produce a 31-bit "Euphoria integer".

> It seems that x being an 
> integer does not matter.

In order to generate fast C code, 
the Euphoria To C Translator tries to determine
at translation time whether an expression must always
produce a 31-bit "Euphoria integer". 

In a for-loop,

    for i = start to limit by increment do ...

the translator will output much better C code
if it can "prove" to itself that start, limit, and increment
are always going to be 31-bit integers, whenever
this loop is started. This is easy when
they are all variables that have been declared as
"integer". It gets harder when you have expressions
involving function calls etc. The interpreter will also
speed up very slightly when things are clearly integers.

If x is a 31-bit Euphoria integer then floor(x/2)+1
will always be a Euphoria integer, but the translator
currently won't recognize this pattern. It does recognize
simpler patterns, for instance it assumes that built-in
functions, such as length(), getc(), peek(atom), ... etc.
always return a Euphoria integer.
Note that, in general, x+1 can't even be assumed 
to produce a Euphoria integer, but a statement like:

  x = x + 1

can be done using an integer calculation because
you have declared the target, x, to be an integer. The translator
assumes that your code contains no type errors or other errors 
that the interpreter can catch. It will assume that for-loop
start, limit, and increment values are at least atoms, if not integers.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com