Hi all,
I'm having a problem with a patch doing some very simple math. The problem is that float 0.1 represents as 0.0999985 in some cases. I know this has to do with floating-point representation but sometimes this lead to bigger errors. Is there any way to fix this ? Changing the width of the number box doesn't work. Thanks for any help and sorry if this has been discussed earlier.
Saludos
Mirko
That's a problem with floating point calculations on computers, unfortuantely. Hard to work around that.
.hc
On Feb 17, 2012, at 4:27 PM, Mirko Petrovich wrote:
Hi all,
I'm having a problem with a patch doing some very simple math. The problem is that float 0.1 represents as 0.0999985 in some cases. I know this has to do with floating-point representation but sometimes this lead to bigger errors. Is there any way to fix this ? Changing the width of the number box doesn't work. Thanks for any help and sorry if this has been discussed earlier.
Saludos
Mirko
<basic_subtraction.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
Le 2012-02-19 à 21:52:00, Hans-Christoph Steiner a écrit :
On Feb 17, 2012, at 4:27 PM, Mirko Petrovich wrote:
I'm having a problem with a patch doing some very simple math. The problem is that float 0.1 represents as 0.0999985 in some cases.
That's a problem with floating point calculations on computers, unfortuantely. Hard to work around that.
0.1 is usually represented as exactly 13421773/134217728 = 0.100000001490116... where 134217728 = pow(2,27)
For various reasons, the numerator can be a few units up or down : 13421772/134217728 = 0.0999999940395355... 13421769/134217728 = 0.0999999716877937... 13421776/134217728 = 0.1000000238418580...
As you can see, 0.0999985 is way off. You get that kind of value with a numerator around 13421571. That's 202 notches off !
If you sum together a lot of 0.001 values to make a 0.1, the error accumulates. It's more accurate to count using whole numbers, and divide the whole number each time.
It's sometimes important to cut down on accuracy for the benefit of efficiency, but doing audio on today's laptops, you will probably not encounter them. However, tablets and phones often have slow float calculators.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; Mirko Petrovich mirko.petrovich@gmail.com Sent: Sunday, February 19, 2012 10:12 PM Subject: Re: [PD] floating-point question
Le 2012-02-19 à 21:52:00, Hans-Christoph Steiner a écrit :
On Feb 17, 2012, at 4:27 PM, Mirko Petrovich wrote:
I'm having a problem with a patch doing some very simple math. The
problem is that float 0.1 represents as 0.0999985 in some cases.
That's a problem with floating point calculations on computers,
unfortuantely. Hard to work around that.
0.1 is usually represented as exactly 13421773/134217728 = 0.100000001490116... where 134217728 = pow(2,27)
For various reasons, the numerator can be a few units up or down : 13421772/134217728 = 0.0999999940395355... 13421769/134217728 = 0.0999999716877937... 13421776/134217728 = 0.1000000238418580...
As you can see, 0.0999985 is way off. You get that kind of value with a numerator around 13421571. That's 202 notches off !
If you sum together a lot of 0.001 values to make a 0.1, the error accumulates. It's more accurate to count using whole numbers, and divide the whole number each time.
With 64-bit floats does this problem practically go away (like getting an index into a large table)?
-Jonathan
It's sometimes important to cut down on accuracy for the benefit of efficiency, but doing audio on today's laptops, you will probably not encounter them. However, tablets and phones often have slow float calculators.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-19 à 19:42:00, Jonathan Wilkes a écrit :
With 64-bit floats does this problem practically go away (like getting an index into a large table)?
Depends on how practical you need it to be.
32-bit floats have 23 explicit bits of numerator, and an implicit high bit that is always one. This causes the numerators to always be whole numbers picked between 16777216 and 33554431.
64-bit floats have 52 explicit bits of numerator, and an implicit high bit. This means 29 doublings of precision. Every error is 536870912 times smaller.
For indexing into a table, it's very hard to do something wrong using float64. For other things, ... you can always find something more picky about precision of floats, but they can get really hard to find as you increase precision.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 20/02/12 04:42, Jonathan Wilkes wrote:
----- Original Message -----
From: Mathieu Bouchardmatju@artengine.ca To: Hans-Christoph Steinerhans@at.or.at Cc: pd-list@iem.at; Mirko Petrovichmirko.petrovich@gmail.com Sent: Sunday, February 19, 2012 10:12 PM Subject: Re: [PD] floating-point question
Le 2012-02-19 à 21:52:00, Hans-Christoph Steiner a écrit :
On Feb 17, 2012, at 4:27 PM, Mirko Petrovich wrote:
I'm having a problem with a patch doing some very simple math. The
problem is that float 0.1 represents as 0.0999985 in some cases.
That's a problem with floating point calculations on computers,
unfortuantely. Hard to work around that.
...
With 64-bit floats does this problem practically go away (like getting an index into a large table)?
Careful, though, if you convert it back to 32 or 16 bit. Especially if you are using expensive gear:
Le 2012-02-20 à 11:03:00, Lorenzo Sutton a écrit :
Careful, though, if you convert it back to 32 or 16 bit. Especially if you are using expensive gear: http://www.around.com/ariane.html
It's not just converting to lesser number of bits. I'd also think that they converted it to int16 (similar to the format of wav files). The float16 format didn't exist back then, and is still not supported by hardware outside of graphics cards of the 2000's.
Also, they got an overflow and not a lack of precision. Lack of precision doesn't matter when you get an overflow. Overflow also doesn't matter when the number is used for entirely the wrong thing.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Lorenzo Sutton -
Mathieu Bouchard -
Mirko Petrovich