Floating point subtraction rounding error (NOT display error)

[Keflavich]

Hey, I have a bit of code that died on a domain error when doing an
arcsin, and apparently it's because floating point subtraction is
having problems. I know about the impossibility of storing floating
point numbers precisely, but I was under the impression that the
standard used for that last digit would prevent subtraction errors
from compounding.

Is there a simple solution to this problem, or do I need to run some
sort of check at every subtraction to make sure that my float does not
deviate? I'm not sure I know even how to do that.

A sample of the failure:
ipdb>1.0000000000000001 == 1
True
ipdb>R
0.69999999999999996
ipdb>R==.7
True
ipdb>y2
3.2999999999999998
ipdb>y2 == 3.3
True
ipdb>cirY-y2
0.70000000000000018
ipdb>cirY-y2 == .7
False

I was unable to find solutions when searching the web because all of
the hits I got were discussing display issues, which I'm not concerned
with.

Thanks,
Adam

[Aahz]

In article <93**********************************@s12g2000prg. googlegroups.com>,
Keflavich <ke*******@gmail.comwrote:

>
Hey, I have a bit of code that died on a domain error when doing an
arcsin, and apparently it's because floating point subtraction is
having problems. I know about the impossibility of storing floating
point numbers precisely, but I was under the impression that the
standard used for that last digit would prevent subtraction errors
from compounding.

Is there a simple solution to this problem, or do I need to run some
sort of check at every subtraction to make sure that my float does not
deviate? I'm not sure I know even how to do that.

Switch to Decimal module? Available in 2.4 and later.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith

[Steven D'Aprano]

On Thu, 13 Dec 2007 14:30:18 -0800, Keflavich wrote:

Hey, I have a bit of code that died on a domain error when doing an
arcsin, and apparently it's because floating point subtraction is having
problems.

I'm not convinced that your diagnosis is correct. Unless you're using
some weird, uncommon hardware, it's unlikely that a bug in the floating
point subtraction routines has escaped detection. (Unlikely, but not
impossible.) Can you tell us what values give you incorrect results?

I know about the impossibility of storing floating point
numbers precisely, but I was under the impression that the standard used
for that last digit would prevent subtraction errors from compounding.

What gave you that impression? Are you referring to guard digits?

Is there a simple solution to this problem, or do I need to run some
sort of check at every subtraction to make sure that my float does not
deviate? I'm not sure I know even how to do that.

I still don't quite understand your problem. If you think your float is
deviating from the correct value, that implies you know what the correct
value should be. How do you know what the correct value should be?

I should also mention that of course your answer will deviate, due to the
finite precision of floats.

A sample of the failure:
ipdb>1.0000000000000001 == 1
True
ipdb>R
0.69999999999999996
ipdb>R==.7
True
ipdb>y2
3.2999999999999998
ipdb>y2 == 3.3
True
ipdb>cirY-y2
0.70000000000000018

What's cirY? How do you know this is the incorrect value?

ipdb>cirY-y2 == .7
False

Obviously not. As you've already shown, the correct value is
0.70000000000000018, not 0.69999999999999996 (the closest floating point
value to 0.7).

I was unable to find solutions when searching the web because all of the
hits I got were discussing display issues, which I'm not concerned with.

Have you read this?
http://docs.sun.com/source/806-3568/ncg_goldberg.html


--
Steven.

[Paddy]

On Dec 14, 3:22 am, Keflavich <[e-mail]:

On Dec 13, 5:52 pm, Steven D'Aprano <st...@REMOVE-THIS-

cybersource.com.auwrote:

On Thu, 13 Dec 2007 14:30:18 -0800, Keflavich wrote:

Hey, I have a bit of code that died on a domain error when doing an
arcsin, and apparently it's because floating point subtraction is having
problems.

I've come to understand that
1. Floats are fuzzy around the edges.
2. Never do: "The difference between two floats is equal to..."
Do: "The difference between two floats is in the range ..."
But even 2 needs some serious thinking if the range of float values
being
compared is large.

Its unscientific, but floats need more respect.

- Paddy.

[Nikos Vergas]

Solved: used round(number,12) in this case for all of the operands of

my arcsines. Not pretty, but at least VIM made it easy...

You might have the same problem though:

>>round(1.000340100000325235000000235,13)

1.0003401000003

>>round(1.000340100000325235000000235,12)

1.0003401000000001

[Keflavich]

On Dec 14, 2:57 am, "Nikos Vergas" <[e-mail]:

Solved: used round(number,12) in this case for all of the operands of
my arcsines. Not pretty, but at least VIM made it easy...

You might have the same problem though:

>round(1.000340100000325235000000235,13)

1.0003401000003

>round(1.000340100000325235000000235,12)

1.0003401000000001

True, but I think that's actually the behavior I'm looking for: the
truncation in this case gives me a smaller number (I hope it's safe to
assume that 1.0003401000000001 < 1.0003401000003), which is exactly
what I want when I'm worried about subtractions giving me numbers very
slightly larger than 1.

Gabriel, Paddy, thanks for the overviews. Yes, floats deserve more
respect, or at least more caution.

I feel fairly certain, however, that floats are exactly what I want
for my purposes: I need moderately high precision and I'm not
concerned about the least-significant-bit errors except when they
violate function domains. I guess the overriding lesson is that every
float subtraction needs to be carefully thought through, which is a
disappointing loss of simplicity for me, but I'll deal with it.

Adam