|
Re: Glitch in floor() function?
|
CChris
|
Jun 27, 2008 02:00 PDT
|
posted by: CChris <christian.cuvier at ?griculture.g?uv.fr>
Mike Wever wrote:
| |
Hi, all. I was trying to write a function to round a number and uncovered what
seems to be a glitch in the floor() function.
This code:
<eucode>
include get.e
procedure round(atom x, integer precision)
integer mult
mult = power(10, precision)
printf(1, "initial: %f\n", {x})
x *= mult
printf(1, "shifted right: %f\n", {x})
x += 0.5
printf(1, "plus rounding half: %f\n", {x})
x = floor(x)
printf(1, "floor: %f\n", {x})
x /= mult
printf(1, "shifted left: %f\n", {x})
end procedure
round(1.5,0)
puts(1, "\n")
round(1.05,1)
puts(1, "\n")
round(1.005,2)
puts(1, "\n")
round(1.0005,3)
if wait_key() then end if
</eucode>
produces these results:
initial: 1.500000
shifted right: 1.500000
plus rounding half: 2.000000
floor: 2.000000
shifted left: 2.000000
initial: 1.050000
shifted right: 10.500000
plus rounding half: 11.000000
floor: 11.000000
shifted left: 1.100000
initial: 1.005000
shifted right: 100.500000
plus rounding half: 101.000000
floor: 100.000000
shifted left: 1.000000
initial: 1.000500
shifted right: 1000.500000
plus rounding half: 1001.000000
floor: 1001.000000
shifted left: 1.001000
It seems that floor(101) gave a result of 100. Is this an error or am I
missing something?
|
Yes, the usual penny drop.
1.000500 is not exactly representable in FPU hardware. According to the precise sequence of operations you perform, this loss of acuracy shows up or doesn't.
If you were printing that "101" as sprint("%.16f",the_value), you'd see a number a very tiny amount below 101, like 100.99999999857412. floor() correct,y returns 100.
CChris
|
|
 |
|