srange bug?

 0 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) asked Jun 27 '12 koukourikos 45 ● 6

 2 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! posted Jun 27 '12 kcrisman 6639 ● 13 ● 66 ● 150 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)1It 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)
 2 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). 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)
 1 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)
 0 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. posted Jun 28 '12 trayres 1

[hide preview]