srange bug?

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)

edit retag close merge delete

Sort by ยป oldest newest most voted

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!

more

thank you for your detailed explanation! The exact ring is a good solution. I should have studied more the documentation of srange before asking!

( 2012-06-28 06:34:47 +0200 )edit
1

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.

( 2012-06-28 11:07:55 +0200 )edit

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).

more

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.

( 2012-06-28 06:27:00 +0200 )edit
more

thank you very much I will take a look of it. Its nice to have always something new and interesting to read :)

( 2012-07-06 09:36:01 +0200 )edit

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...

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

more