Ask Your Question

srange bug?

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

koukourikos gravatar image

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:

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

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

4 Answers

Sort by ยป oldest newest most voted

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

kcrisman gravatar image

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

koukourikos gravatar imagekoukourikos ( 2012-06-28 06:34:47 +0200 )edit

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 gravatar imagekcrisman ( 2012-06-28 11:07:55 +0200 )edit

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

Jason Grout gravatar image

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

koukourikos gravatar imagekoukourikos ( 2012-06-28 06:27:00 +0200 )edit

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

Volker Braun gravatar image
edit flag offensive delete link more


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

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

answered 2012-06-28 14:26:13 +0200

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 @

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2012-06-27 21:57:09 +0200

Seen: 535 times

Last updated: Jun 29 '12