1. It's a bug? Re: Strange problem
- Posted by Joel Crook <joel at MAIL.K-A.COM> Mar 18, 2000
- 458 views
- Last edited Mar 19, 2000
--=====================_481794395==_.ALT At 11:50 PM 03/18/2000 -0500, you wrote: >Everett Williams wrote: > >Sometimes I am a little slow, but I do finally get there. In a case where the >system truncates rather than rounds, the normal solution is to add .5 >except in this case where we are not sure that the conversion is always >less than the original decimal number. Given the answer to that question is >yes, then adding .5 solves the problem. Only a lot of very exacting testing or >an answer from RDS will solve the question for sure. > >Everett L.(Rett) Williams >rett at gvtc.com I modified his code a little bit and found something interesting: include misc.e global constant POSITION = 4, LEFT = 4.1, TOP = 4.2, DEMINSIONS = 5, WIDTH = 5.1, HEIGHT = 5.2, objects = { {1,0,{},{ 0, 0},{639,479}, 1,1,1}, {1,0,{},{10,10},{459,459},-1,1,1} } global function Get (integer obj, atom att) atom b integer a b=att - floor (att) b=b*10 a=floor(b) ? att ? b ? a return objects [obj] [att] end function object view view = 2 constant vp = {Get (view,WIDTH),Get (view, HEIGHT)} ? ({Get(view,LEFT), Get(view,TOP)}) -- -- the following numbers are returned: 5.1 -- this is att 1 -- this is b 0 <----- This is the result of a= floor(b) Notice ----This "should be" 1 --- I think this is a bug 5.2 2 2 <----- the second number is ok 4.1 1 0 <----- Notice ----again floor (b) fails 4.2 2 2<----- the fourth number is ok I'd say Lewis found a bug in the Euphoria code. Joel H. Crook Manager, Information Services Certified Novell Administrator Microsoft Certified Professional, OS Specialist Kellogg & Andelson Accountancy Corp. 14724 Ventura Blvd. 2nd Floor Sherman Oaks, CA 91403 (818) 971-5100 --=====================_481794395==_.ALT <html> At 11:50 PM 03/18/2000 -0500, you wrote:<br> >Everett Williams wrote:<br> ><br> >Sometimes I am a little slow, but I do finally get there. In a case where the<br> >system truncates rather than rounds, the normal solution is to add .5<br> >except in this case where we are not sure that the conversion is always<br> >less than the original decimal number. Given the answer to that question is<br> >yes, then adding .5 solves the problem. Only a lot of very exacting testing or<br> >an answer from RDS will solve the question for sure.<br> ><br> >Everett L.(Rett) Williams<br> >rett at gvtc.com<br> <br> <br> I modified his code a little bit and found something interesting:<br> <br> <br> include misc.e<br> <br> global constant<br> POSITION = 4,<br> LEFT = 4.1,<br> TOP = 4.2,<br> DEMINSIONS = 5,<br> WIDTH = 5.1,<br> HEIGHT = 5.2,<br> objects = {<br> {1,0,{},{ 0, 0},{639,479}, 1,1,1},<br> {1,0,{},{10,10},{459,459},-1,1,1}<br> <br> }<br> <br> global function Get (integer obj, atom att) <dl> <dd>atom b <dd>integer a <dd>b=att - floor (att) <dd>b=b*10 <dd>a=floor(b) <dd>? att <dd>? b <dd>? a <dd>return objects [obj] [att]<br> <br> </dl>end function<br> <br> object view<br> view = 2<br> <br> <br> constant vp = {Get (view,WIDTH),Get (view, HEIGHT)}<br> ? ({Get(view,LEFT), Get(view,TOP)})<br> --<br> <br> -- the following numbers are returned:<br> <br> 5.1 <x-tab> </x-tab>-- this is att<br> 1<x-tab> </x-tab>-- this is b <br> 0 <----- This is the result of a= floor(b) Notice ----This "should be" 1 --- I think this is a bug<br> 5.2<br> 2<br> 2 <----- the second number is ok<br> 4.1<br> 1<br> 0 <----- Notice ----again floor (b) fails<br> 4.2<br> 2<br> 2<----- the fourth number is ok<br> <br> I'd say Lewis found a bug in the Euphoria code.<br> <br> <br> Joel H. Crook<br> <br> Manager, Information Services<br> <font size=1>Certified Novell Administrator<br> Microsoft Certified Professional, OS Specialist<br> <br> </font><b>Kellogg & Andelson Accountancy Corp.<br> </b><font size=1>14724 Ventura Blvd. 2nd Floor<br> Sherman Oaks, CA 91403<br> (818) 971-5100<br> </font></html> --=====================_481794395==_.ALT--
2. Re: It's a bug? Re: Strange problem
- Posted by Irv Mullins <irv at ELLIJAY.COM> Mar 19, 2000
- 449 views
On Sun, 19 Mar 2000, Joel Crook wrote: > > I'd say Lewis found a bug in the Euphoria code. > Yes, it is a bug, but not in the floor() function. When you create a constant, or pass a value: for example, Get(4.1), it actually passes a number "close" to 4.1. See the test code below, which produces these results: att: 4.09999999999999964473 b: (att-floor(att) * 10) 0.99999999999999644729 a: (floor(b)) 0.00000000000000000000 att: 5.09999999999999964473 b: (att-floor(att) * 10) 0.99999999999999644729 a: (floor(b)) 0.00000000000000000000 Therefore, floor() is doing what it is supposed to do, round off to a whole number less than or equal to the value passed. The problem is in how to pass exactly the value you want to pass. -- test code: procedure Get ( atom att) atom b integer a b=att - floor (att) b=b*10 a=floor(b) printf(1,"att: %2.20f\n",att) printf(1,"b: (att-floor(att) * 10) %2.20f\n",b) printf(1,"a: (floor(b)) %2.20f\n",a) end procedure Get(4.1) Get(5.1) Regards, Irv
3. Re: It's a bug? Re: Strange problem
- Posted by Joel Crook <joel at MAIL.K-A.COM> Mar 19, 2000
- 435 views
--=====================_1550049==_.ALT At 09:38 AM 03/19/2000 -0500, you wrote: >On Sun, 19 Mar 2000, Joel Crook wrote: >> >> I'd say Lewis found a bug in the Euphoria code. >> >Yes, it is a bug, but not in the floor() function. >When you create a constant, or pass a value: >for example, Get(4.1), it actually passes a number >"close" to 4.1. See the test code below, which >produces these results: > >att: 4.09999999999999964473 >b: (att-floor(att) * 10) 0.99999999999999644729 >a: (floor(b)) 0.00000000000000000000 >att: 5.09999999999999964473 >b: (att-floor(att) * 10) 0.99999999999999644729 >a: (floor(b)) 0.00000000000000000000 That explains why, as I was puttering with the code last night, if I made "att" slightly larger-- say 4.11 that the conversion worked... >Therefore, floor() is doing what it is supposed to do, >round off to a whole number less than or equal to the >value passed. The problem is in how to pass exactly the >value you want to pass. <SNIP!> >Regards, >Irv Thanks Irv for the lesson on floats in Euphoria. I'll have to try this in TP7 and see what it does.. Thanks again, Joel Joel H. Crook "When the code works perfectly, the program is obsolete." -- "The Gosple According to St. Murphy" --=====================_1550049==_.ALT <html><div>At 09:38 AM 03/19/2000 -0500, you wrote:</div> <div>>On Sun, 19 Mar 2000, Joel Crook wrote:</div> <div>>></div> <div>>> I'd say Lewis found a bug in the Euphoria code.</div> <div>>></div> <div>>Yes, it is a bug, but not in the floor() function.</div> <div>>When you create a constant, or pass a value:</div> <div>>for example, Get(4.1), it actually passes a number</div> <div>>"close" to 4.1. See the test code below, which</div> <div>>produces these results:</div> <div>></div> <div>>att: 4.09999999999999964473</div> <div>>b: (att-floor(att) * 10) 0.99999999999999644729</div> <div>>a: (floor(b)) 0.00000000000000000000</div> <div>>att: 5.09999999999999964473</div> <div>>b: (att-floor(att) * 10) 0.99999999999999644729</div> <div>>a: (floor(b)) 0.00000000000000000000</div> <br> <div>That explains why, as I was puttering with the code last night, </div> <div>if I made "att" slightly larger-- say 4.11 that the conversion worked...</div> <br> <br> <div>>Therefore, floor() is doing what it is supposed to do,</div> <div>>round off to a whole number less than or equal to the</div> <div>>value passed. The problem is in how to pass exactly the</div> <div>>value you want to pass.</div> <div><SNIP!></div> <div>>Regards,</div> <div>>Irv</div> <br> <div>Thanks Irv for the lesson on floats in Euphoria.</div> <br> <div> I'll have to try this in TP7 and see what it does..</div> <br> <div>Thanks again,</div> <br> <div>Joel</div> <br> Joel H. Crook<br> <br> "<b><i>When the code works perfectly, the program is obsolete</b></i>."<br> <div align="right"> -- "The Gosple According to St. Murphy"</html> --=====================_1550049==_.ALT--
4. Re: It's a bug? Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 19, 2000
- 427 views
>>att: 4.09999999999999964473 >>b: (att-floor(att) * 10) 0.99999999999999644729 >>a: (floor(b)) 0.00000000000000000000 >>att: 5.09999999999999964473 >>b: (att-floor(att) * 10) 0.99999999999999644729 >>a: (floor(b)) 0.00000000000000000000 > >That explains why, as I was puttering with the code last night, >if I made "att" slightly larger-- say 4.11 that the conversion worked... > Irv, According to the book, we only get 16 places of accuracy from a 64 bit float. Your float routine is printing 20 places. It looks to me as if you could add something small way past any point of concern depending on the equation, such as 0.00000000001 and the equation would work. I'm still interested in those last 4 places. Where are they being manufactured from? Twenty places is approximately the capacity of an 8 byte binary integer. A 64 bit float has overhead for the exponent. Also, the number is not accurate to 16 places, but 14. Curiouser and curiouser said "Alice". The thing that matters is how to know when it is going to be a 32 bit or a 64 bit float and how to get rounding routines to work to the accuracy that is wanted for any particular mathematical situation. Everett L.(Rett) Williams rett at gvtc.com
5. Re: It's a bug? Re: Strange problem
- Posted by Jiri Babor <J.Babor at GNS.CRI.NZ> Mar 20, 2000
- 417 views
Guys, I have heard this one so many times I am getting a bit curious too: what is exactly your problem that requires higher precision than to about 16 decimal places? Even Bill Gate$' fabulous wealth can be expressed quite accurately, to the last cent in fact, using just 16 digits. That's plenty astronomical to me! jiri
6. Re: It's a bug? Re: Strange problem
- Posted by Irv Mullins <irv at ELLIJAY.COM> Mar 19, 2000
- 426 views
- Last edited Mar 20, 2000
On Sun, 19 Mar 2000, you wrote: > Guys, > > I have heard this one so many times I am getting a bit curious too: > what is exactly your problem that requires higher precision than to > about 16 decimal places? Even Bill Gate$' fabulous wealth can be > expressed quite accurately, to the last cent in fact, using just 16 > digits. That's plenty astronomical to me! jiri Well, Jiri, The origin of this problem was with code that failed at one decimal place. It was exactly the kind of thing you might run into doing graphics, where a coordinate is computed via division. It can be patched by adding .00001 or similar small value to the number(s) passed - messy but effective. Regards, Irv
7. Re: It's a bug? Re: Strange problem
- Posted by Kat <gertie at ZEBRA.NET> Mar 19, 2000
- 438 views
- Last edited Mar 20, 2000
----- Original Message ----- From: "Jiri Babor" <J.Babor at GNS.CRI.NZ> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Sunday, March 19, 2000 5:16 PM Subject: Re: It's a bug? Re: Strange problem > Guys, > > I have heard this one so many times I am getting a bit curious too: > what is exactly your problem that requires higher precision than to > about 16 decimal places? Even Bill Gate$' fabulous wealth can be > expressed quite accurately, to the last cent in fact, using just 16 > digits. That's plenty astronomical to me! jiri But when i measure plant cell nuclii radius in parsecs, 16 digits isn't enough. In fact, only string math will be accurate enough, since you can use as many digits as you wish, 16^16 if you wish. Sounds like a math library is needed. <shrug> Kat
8. Re: It's a bug? Re: Strange problem
- Posted by Jiri Babor <J.Babor at GNS.CRI.NZ> Mar 20, 2000
- 438 views
Kat wrote: >> I have heard this one so many times I am getting a bit curious too: >> what is exactly your problem that requires higher precision than to >> about 16 decimal places? Even Bill Gate$' fabulous wealth can be >> expressed quite accurately, to the last cent in fact, using just 16 >> digits. That's plenty astronomical to me! jiri > >But when i measure plant cell nuclii radius in parsecs, 16 digits isn't >enough. In fact, only string math will be accurate enough, since you can use >as many digits as you wish, 16^16 if you wish. Sounds like a math library is >needed. >shrug > >Kat What's your point? Advocacy of silly units? I thought it was *you* who moaned about the wasteful manner of string storage in Euphoria just recently. (Btw, I happen to agree with you on that one. In fact I would go to the extreme of asking Rob to discard his dogmatic blinkers and give us fast, fixed size element arrays, directly mappable to memory. 1, 2, 4, 8 and 16 byte elements would suit me fine.) Tossing a kat among the pidgeons... jiri
9. Re: It's a bug? Re: Strange problem
- Posted by Jiri Babor <J.Babor at GNS.CRI.NZ> Mar 20, 2000
- 423 views
Irv wrote: >> Guys, >> >> I have heard this one so many times I am getting a bit curious too: >> what is exactly your problem that requires higher precision than to >> about 16 decimal places? Even Bill Gate$' fabulous wealth can be >> expressed quite accurately, to the last cent in fact, using just 16 >> digits. That's plenty astronomical to me! jiri > >Well, Jiri, > >The origin of this problem was with code that failed at one decimal place. >It was exactly the kind of thing you might run into doing graphics, where >a coordinate is computed via division. It can be patched by adding .00001 >or similar small value to the number(s) passed - messy but effective. > >Regards, >Irv Well, Irv, Thank you very much for your graphics lecture, but you failed to answer my question again. jiri
10. Re: It's a bug? Re: Strange problem
- Posted by Irv Mullins <irv at ELLIJAY.COM> Mar 19, 2000
- 432 views
- Last edited Mar 20, 2000
On Sun, 19 Mar 2000, you wrote: > > > >The origin of this problem was with code that failed at one decimal place. > >It was exactly the kind of thing you might run into doing graphics, where > >a coordinate is computed via division. It can be patched by adding .00001 > >or similar small value to the number(s) passed - messy but effective. > > > >Regards, > >Irv > > Well, Irv, > > Thank you very much for your graphics lecture, but you failed to answer my > question again. jiri No, you failed to understand my answer. (Hint: read the first line "it failed at one (1) decimal place.) Maybe we don't need precision beyond 16 decimal places, but we need better than 1. Irv
11. Re: It's a bug? Re: Strange problem
- Posted by Kat <gertie at ZEBRA.NET> Mar 19, 2000
- 434 views
- Last edited Mar 20, 2000
----- Original Message ----- From: "Jiri Babor" <J.Babor at GNS.CRI.NZ> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Sunday, March 19, 2000 7:33 PM Subject: Re: It's a bug? Re: Strange problem > Kat wrote: > > >> I have heard this one so many times I am getting a bit curious too: > >> what is exactly your problem that requires higher precision than to > >> about 16 decimal places? Even Bill Gate$' fabulous wealth can be > >> expressed quite accurately, to the last cent in fact, using just 16 > >> digits. That's plenty astronomical to me! jiri > > > >But when i measure plant cell nuclii radius in parsecs, 16 digits isn't > >enough. In fact, only string math will be accurate enough, since you can use > >as many digits as you wish, 16^16 if you wish. Sounds like a math library is > >needed. > >shrug > > > >Kat > > What's your point? Advocacy of silly units? I thought it was *you* who > moaned about the wasteful manner of string storage in Euphoria just > recently. (Btw, I happen to agree with you on that one. In fact I > would go to the extreme of asking Rob to discard his dogmatic blinkers > and give us fast, fixed size element arrays, directly mappable to > memory. 1, 2, 4, 8 and 16 byte elements would suit me fine.) I'm not going to guess what units people are using, i am pointing out that you can't guess either, or foresee what the next person will need. You mentioned (economics) money, i mentioned (astronomy) parsecs, someone else may be figureing out (physics) strong force/weak force interaction from within an atom to across the universe. Why limit the number of digits that can be dealt with in a math problem? You automatically close off Eu from some domains when you do. Besides the accuracy issue. String math isn't going to eat a lot of memory, 32bits per digit is all. Maybe it will eat a lot of memory if you have a lot of numbers to munch on. What it will consume a lot of is time, since there is no conversion to binary, none of the math hardware can be used, it's all case or if_then digit-by-digit comparisons and lots of recursion. > Tossing a kat among the pidgeons... jiri /me growls at the flapping dinner ......