srange bug?

Question

Lets say that we want a list of the numbers 0,0.001,0.002 ... 2 if we use srange after some values we have rounding errors:

srange(0,2,0.001)
... 1.13799999999999, 1.13899999999999, 1.13999999999999, 1.14099999999999, 1.14199999999999...

why? Is this a bug? A quick solution is to use numpy:

import numpy as np
p=np.arange(0,2,0.001);p

array([  0.00000000e+00,   1.00000000e-03,   2.00000000e-03, ...,
         1.99700000e+00,   1.99800000e+00,   1.99900000e+00])

but the question remains... why srange doesn't work correctly?

(tested on Sage 5.0.1 & 5.0 & 4.7.2)

Accepted Answer

Or e.g.

sage: srange(0,1,.0001)[-10:]
[0.998999999999906, 0.999099999999906, 0.999199999999906, 0.999299999999906, 0.999399999999906, 0.999499999999906, 0.999599999999906, 0.999699999999906, 0.999799999999906, 0.999899999999906]

The point is that these are well within tolerance for 53-bit precision. The numpy stuff is just tricking you with its rounding or something.

sage: R = RealField(100)
sage: srange(R(0),R(1),R(.0001))[-10:]
[0.99900000000000000000000000170, 0.99910000000000000000000000170, 0.99920000000000000000000000170, 0.99930000000000000000000000170, 0.99940000000000000000000000170, 0.99950000000000000000000000170, 0.99960000000000000000000000170, 0.99970000000000000000000000170, 0.99980000000000000000000000170, 0.99990000000000000000000000170]

I'm sure that someone who understands machine numbers better can say why it's these particular numbers, but that's pretty much the story, I believe. Is there any particular reason why 1.14199999999999 would be worse than 1.14200000000000? If so, then you should use an exact ring (see the documentation for srange and do something like

sage: srange(0,1,1/1000)[-10:]
[99/100, 991/1000, 124/125, 993/1000, 497/500, 199/200, 249/250, 997/1000, 499/500, 999/1000]

Good luck!

thank you for your detailed explanation! The exact ring is a good solution. I should have studied more the documentation of srange before asking!
koukourikos (Jun 28 '12)
It takes a while to get used to the difference between real number and Real numbers. It's a little annoying for people like me with no programming background, but I guess it's better in the long run to actually understand how computers work... which I need to tell my students more often.
kcrisman (Jun 28 '12)

Answer 2

i like this answer (click again to cancel)

2

i dont like this answer (click again to cancel)

This is a problem with floating point arithmetic. Even numpy doesn't do things exactly; it's only a question of magnitude of error. To get it exactly, use exact numbers: srange(0,2,1/1000).

link

posted Jun 27 '12

Jason Grout
3185 ● 7 ● 27 ● 71

thank you , I always thought that floating point problems occur only when we use number with a lot of non-zero digits in their decimal part but it seams that this is not true.

thank you for your suggestion it is even more simpler than using numpy.

koukourikos (Jun 28 '12)

Answer 3

1	See also what every computer scientist should know about floating point arithmetic link posted Jun 29 '12 Volker Braun 2238 ● 5 ● 22 ● 52 thank you very much I will take a look of it. Its nice to have always something new and interesting to read :) koukourikos (Jul 06 '12)

Answer 4

If SRANGE is performing repeated additions to get these values, then this precision issue is related to the way SAGE handles real number addition.

From Sage Reference Manual @ http://www.sagemath.org/doc/reference/sage/misc/misc.html

Does anyone have a good reference on this issue for SAGE? If I find one I'll update this post.

srange bug?

4 Answers:

Your answer

Question tools

Tags:

Stats:

Related questions