First time here? Check out the FAQ!

Ask Your Question
0

srange bug?

asked 12 years ago

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:

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)

Preview: (hide)

4 Answers

Sort by » oldest newest most voted
2

answered 12 years ago

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!

Preview: (hide)
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 gravatar imagekoukourikos ( 12 years ago )
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 gravatar imagekcrisman ( 12 years ago )
2

answered 12 years ago

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

Preview: (hide)
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 gravatar imagekoukourikos ( 12 years ago )
1

answered 12 years ago

Volker Braun gravatar image
Preview: (hide)
link

Comments

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 ( 12 years ago )
0

answered 12 years ago

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.

Preview: (hide)
link

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

Stats

Asked: 12 years ago

Seen: 713 times

Last updated: Jun 29 '12