1. It's a bug? Re: Strange problem
- Posted by Joel Crook <joel at MAIL.K-A.COM>
Mar 18, 2000
-
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
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
--=====================_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
>>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
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
-
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
-
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
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
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
-
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
-
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 ......
