1. integer() function unexpected behavior
- Posted by Tone Škoda <tskoda at email.si> Jan 31, 2005
- 593 views
?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
- Posted by cklester <cklester at yahoo.com> Jan 31, 2005
- 571 views
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
- Posted by Verne Tice <fredfarkle at highstream.net> Jan 31, 2005
- 554 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Jan 31, 2005
- 559 views
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
- Posted by Tone Škoda <tskoda at email.si> Jan 31, 2005
- 575 views
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
- Posted by CoJaBo <CoJaBo_EUforum_Address at CJBN.net> Jan 31, 2005
- 566 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Jan 31, 2005
- 561 views
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
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jan 31, 2005
- 571 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 31, 2005
- 569 views
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
- 567 views
- 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