1. integer() function unexpected behavior
?integer(1.0)
shows 1, but i think it should 0.
and integer(1) should show 1, same as now.
2. Re: integer() function unexpected behavior
Tone Škoda wrote:
>
> ?integer(1.0)
>
> shows 1, but i think it should 0.
>
> and integer(1) should show 1, same as now.
Is it converting the value to an integer instead of testing the value? What
happens with 2.3, 5.0, etc...?
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
3. Re: integer() function unexpected behavior
Tone Škoda wrote:
>
> ?integer(1.0)
>
> shows 1, but i think it should 0.
>
> and integer(1) should show 1, same as now.
>
If you check the documentation for the integer(x) function, you will see an
example
if integer(x/y) then
-- something about x being an exact multiple of y
This implies that the purpose of integer(x) is to test:
x has no fractional portion and
x is in the range for a valid Euphoria integer (30-bit)
This latter implication (valid integer) is similar to the tests for
atom and sequence.
Verne Tice
4. Re: integer() function unexpected behavior
Tone Škoda wrote:
>
> ?integer(1.0)
>
> shows 1, but i think it should 0.
>
> and integer(1) should show 1, same as now.
The integer() function determines if the value supplied can be (or is)
stored as an integer, and not whether or not the value has a decimal
compoment.
For example ...
atom x
x = 10.0000000000000001
? integer(x)
>> displays 1
x = 999999999999
? integer(x)
>> displays 0
--
Derek Parnell
Melbourne, Australia
5. Re: integer() function unexpected behavior
Derek Parnell wrote:
> The integer() function determines if the value supplied can be (or is)
> stored as an integer, and not whether or not the value has a decimal
> compoment.
but shouldn't 1.0 be stored as atom? i think i read that once in some
optimization tips.
well, i'm doing another autoresizer and i wanted to use 1.0 to mean 100% and 1
to mean 1 pixel.
remainder(num, 1) insead of integer() could or should be used to test if number
has any fractional portion.
6. Re: integer() function unexpected behavior
Tone Škoda wrote:
>
> ?integer(1.0)
>
> shows 1, but i think it should 0.
>
> and integer(1) should show 1, same as now.
That is what should be expected. Also, what causes
this strange case? If it can't be fixed it should at
least be documented:
include get.e
constant a={
.78,
.9,
9.7,
0.9,
9.4
}
atom b
for o=1 to length(a) do
b=a[o]*100
printf(1,"Printed as %%d: %d. As %%f: %f. Integer?: %d\n",{b,b,integer(b)})
end for
integer c
c=.78*100
?wait_key()
Prints:
Printed as %d: 77. As %f: 78.000000. Integer?: 0
Printed as %d: 90. As %f: 90.000000. Integer?: 1
Printed as %d: 969. As %f: 970.000000. Integer?: 0
Printed as %d: 90. As %f: 90.000000. Integer?: 1
Printed as %d: 940. As %f: 940.000000. Integer?: 1
C:\ProgramDev\int.exw:19
type_check failure, c is 78
--> see ex.err
CoJaBo
"If two trains leave Boston heading in opposite directions, one
going 80MPH the other going 90MPH, how long will it be until
ANYONE CARES!!!" -- Me
[1010] << Supposed to be a computer
QWERTY
Laptop
Athlon 64 3700+ 2.4Ghz, 2GB RAM, 100GB HDD,
NVIDIA GeForce4 440 Go 64M Video card,
1920x1200 Resolution LCD
7. Re: integer() function unexpected behavior
Tone Škoda wrote:
>
> Derek Parnell wrote:
>
> > The integer() function determines if the value supplied can be (or is)
> > stored as an integer, and not whether or not the value has a decimal
> > compoment.
>
> but shouldn't 1.0 be stored as atom? i think i read that once in some
> optimization
> tips.
I understand your concern, but as I said, integer() reports if a number *CAN*
be stored as an integer. Not if it is an integer or an atom? You cannot use
integer() to determine if a literal (or any value) is actually an floating
point number or an integer.
> well, i'm doing another autoresizer and i wanted to use 1.0 to mean 100% and 1
> to mean
> 1 pixel.
This is exactly where I found out about this too. That's why in win32lib you
can only specify percentage locations from 0 to 99.9999999 .
As a workaround, you could just assume that any value above 0.999999 is
trying to be 100%.
> remainder(num, 1) insead of integer() could or should be used to test if
> number has
> any fractional portion.
Not so. If you use either then literal 1.0 or 1 the remainder is still zero.
The workaround I finally accepted for win32lib is using a string ...
createForm("Window, at=(50%, 24), size=(25%, 33%)")
The thing to remember in Euphoria is that integer and atom are just
*storage* options for numbers. The 'atom' just means that a larger number
of numbers can be stored and thus allowing 'integer' to be optimised for
performance. This means that if you have a literal or an atom variable,
and its current value *can* be stored as an integer, then it *is* stored
as an integer.
Thus 1 and 1.0 can both possibly be stored as an integer so therefore
Euphoria actually stores them that way. Most of the time this is a good
feature, unless you need to distinguish between the two.
--
Derek Parnell
Melbourne, Australia
8. Re: integer() function unexpected behavior
Tone Skoda wrote:
> ?integer(1.0)
>
> shows 1, but i think it should 0.
>
> and integer(1) should show 1, same as now.
And what should integer(6/3) show then?
Is 6/3 = 2 or is 6/3 = 2.0 ? 
As Derek wrote, you probably should use a string: "1.0".
Regards,
Juergen
9. Re: integer() function unexpected behavior
On Sun, 30 Jan 2005 20:00:27 -0800, CoJaBo <guest at RapidEuphoria.com>
wrote:
>Tone =8Akoda wrote:
>>
>> ?integer(1.0)=20
>>
>> shows 1, but i think it should 0.
>>
>> and integer(1) should show 1, same as now.
>
>That is what should be expected. Also, what causes
>this strange case? If it can't be fixed it should at
>least be documented:
Logically, I'd agree, but there is a huge amount of optimisation based
on this, not to mention legacy code. FWIW, I think that
<integer>=value/2
should _need_ to be written as
<integer>=floor(value/2)
but that's a different story.
<snip>
>Printed as %d: 77. As %f: 78.000000. Integer?: 0
>Printed as %d: 90. As %f: 90.000000. Integer?: 1
>Printed as %d: 969. As %f: 970.000000. Integer?: 0
>Printed as %d: 90. As %f: 90.000000. Integer?: 1
>Printed as %d: 940. As %f: 940.000000. Integer?: 1
>
>C:\ProgramDev\int.exw:19
>type_check failure, c is 78
>--> see ex.err
This is because the /physical hardware/ don't store decimal fractions
exactly, but as an approximation, in binary (base 2) exponent format.
Thus 0.78*100 is not 78 really, but 77.999999999999997 or
78.000000000000015. It has very little to do with the RDS product
(which is software!), and trace/ex.err showing all f.p values to 15 or
more significant places would quickly become rather tiresome.
You need to get round this with floor(), abs(), and <1e6 or somesuch.
Or indeed <integer>=floor(value*100+0.5).
Regards,
Pete
10. Re: integer() function unexpected behavior
- Posted by CoJaBo <CoJaBo_EUforum_Address at CJBN.net>
Jan 31, 2005
-
Last edited Feb 01, 2005
Pete Lomax wrote:
>
> On Sun, 30 Jan 2005 20:00:27 -0800, CoJaBo <guest at RapidEuphoria.com>
> wrote:
>
> >Tone =8Akoda wrote:
> >>
> >> ?integer(1.0)=20
> >>
> >> shows 1, but i think it should 0.
> >>
> >> and integer(1) should show 1, same as now.
> >
> >That is what should be expected. Also, what causes
> >this strange case? If it can't be fixed it should at
> >least be documented:
> Logically, I'd agree, but there is a huge amount of optimisation based
> on this, not to mention legacy code. FWIW, I think that
>
> <integer>=value/2
>
> should _need_ to be written as
>
> <integer>=floor(value/2)
>
> but that's a different story.
That is what should be documented.
>
> <snip>
> >Printed as %d: 77. As %f: 78.000000. Integer?: 0
> >Printed as %d: 90. As %f: 90.000000. Integer?: 1
> >Printed as %d: 969. As %f: 970.000000. Integer?: 0
> >Printed as %d: 90. As %f: 90.000000. Integer?: 1
> >Printed as %d: 940. As %f: 940.000000. Integer?: 1
> >
> >C:\ProgramDev\int.exw:19
> >type_check failure, c is 78
> >--> see ex.err
> This is because the /physical hardware/ don't store decimal fractions
> exactly, but as an approximation, in binary (base 2) exponent format.
> Thus 0.78*100 is not 78 really, but 77.999999999999997 or
> 78.000000000000015. It has very little to do with the RDS product
> (which is software!), and trace/ex.err showing all f.p values to 15 or
> more significant places would quickly become rather tiresome.
I thought so.
>
> You need to get round this with floor(), abs(), and <1e6 or somesuch.
> Or indeed <integer>=floor(value*100+0.5).
>
> Regards,
> Pete
>
>
CoJaBo
"If two trains leave Boston heading in opposite directions, one
going 80MPH the other going 90MPH, how long will it be until
ANYONE CARES!!!" -- Me
[1010] << Supposed to be a computer
QWERTY
Laptop
Athlon 64 3700+ 2.4Ghz, 2GB RAM, 100GB HDD,
NVIDIA GeForce4 440 Go 64M Video card,
1920x1200 Resolution LCD
