srange bug?

asked 2012-06-27 21:57:09 +0100

45 ●1 ●1 ●10

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 flag offensive close merge delete

add a comment

2

answered 2012-06-27 22:47:41 +0100

kcrisman
12242 ●42 ●136 ●255

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!

edit flag offensive delete link

Comments

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 ( 2012-06-28 06:34:47 +0100 )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.

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

add a comment

2

answered 2012-06-27 22:47:12 +0100

Jason Grout
3505 ●9 ●36 ●81

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

edit flag offensive delete link

Comments

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 ( 2012-06-28 06:27:00 +0100 )edit

add a comment

1

answered 2012-06-29 06:58:18 +0100