5 ms·

That's quite a lot. The by far most important things for me: Floats guarantee at least 7, and doubles at least 15 significant decimal digits. That's regularly s

by s9w 6y ago

That's quite a lot. The by far most important things for me: Floats guarantee at least 7, and doubles at least 15 significant decimal digits. That's regularly surprisingly low to many devs.

deleted 6y ago
[deleted]
hnick 6y ago
The real problem I see mostly happen when arithmetic gets involved. Two simple and precise floats added or subtracted can get you something like 5.00000000001 if you aren't careful. A fairly innocuous perl snippet shows this: DB<1> $a+=0.1 for 1..10; print $a - 1 -1.11022302462516e-16 I ran into a bug like this on a website, I don't know what they were doing to the inputs but a simple 60.9 or similar turned into 60.9000000001 and tripped up the back-end service.
- slavik81 6y ago
  The problem is that they aren't precise floats. 0.1 has no finite representation in binary. It's an infinite repeating string of digits, like 1/3rd is in decimal. Thus, when you add a bunch of them together, the inherent error in rounding them off at some finite number of digits slowly adds up. The same is true of all multiples of 0.1, unless they're also a multiple of 0.5. Hence why your 60.9 is not actually 60.9. It was never exact to begin with.
  - hnick 6y ago
    Yes, that is true. But usually symptoms don't surface until errors accumulate which is why I found that web form interesting. 'Precise' was the wrong word. What I meant was the system reports back the exact entered value 0.1 (rather than what it has in memory, which is 0.100000001490116119384765625 according to https://www.h-schmidt.net/FloatConverter/IEEE754.html https://www.h-schmidt.net/FloatConverter/IEEE754.html). Most programs will do this fairly well. I confirmed javascript is entirely capable of storing and retrieving the number I entered, so I'm not entirely sure what they were doing to confuse it :) Must have been some secret maths.
  - DarkWiiPlayer 6y ago
    > 0.1 has no finite representation in binary. b1 / b1010 I don't see the problem. Did you mean to say it has no finite representation in the IEEE float format? > It was never exact to begin with. But the format sadly gets used in situations where people expect it to be reasonably accurate, where it isn't, because developers either underestimate the "reasonable" or overestimate the "accurate" part. It's just sad that most mainstream programming languages have no native accurate data type for rational numbers.
    - Gracana 6y ago
      > Did you mean to say it has no finite representation in the IEEE float format? Of course that's implied.
      - DarkWiiPlayer 6y ago
        It was a rhetoric question; I just wanted to point out that people blame these inaccuracies on "binary representations" when in reality it's just this one binary representation that's broken.
        deleted 6y ago
        [deleted]
    - account42 6y ago
      So are you saying that ⅓ has a finite presentation in decimal? Finite binary rationals ⊋ finite binary numbers.
      - DarkWiiPlayer 6y ago
        > So are you saying that ⅓ has a finite presentation in decimal? Yes: ⅓
    - slavik81 6y ago
      I meant in positional notation, but most people know that as "decimal notation". Unfortunately, that implies base 10, so I avoided the term. I gave both an example in binary and an example in decimal to clarify my imprecise terminology. I worry that by objecting only to the binary example, you may confuse people into thinking the two are different.
kstenerud 6y ago
It may seem low, but it's really not. At 6 significant digits, you'd have a margin of error of a thousandth of an inch when measuring a football field.
- 0xffff2 6y ago
  Counterpoint: At 6 significant digits you have a margin of error of thousandths of a millimeter when measuring degrees longitude near the prime meridian, but the error balloons to whole meters when measuring longitudes in Australia. I have a piece of software that I wrote ages ago where I looked at the max error in the US and concluded that 32bit floats were enough. This made sense since at the time I was reasonably confident that the tool would only be used with locations in the continental US and it simplified my architecture. Fast forward a few years and we ended up open sourcing the tool and people started using it all over the world. I'm still dealing with the fallout to this day. I'm dreading the day that the tool gets used in some inter-planetary context and I have to repeat all of the work to add support for 128 bit/arbitrary precision location data.
- T-hawk 6y ago
  Sure, that's low, depending on context. At 6 significant digits, a million-dollar bank account would have a margin of error of up to +/- 5 dollars. And if you add up a million of any item with 6 significant digits, that's enough for inaccuracy to propagate all the way into your first significant digit. (It would require systematic inaccuracy in one direction, but there are certainly data sets and contexts where that would happen.)
  - kstenerud 6y ago
    https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio https://dzone.com/articles/never-use-float-and-double-for-mo...
- s9w 6y ago
  You are also not able to represent your yearly salary to the cent. At least if you're American haha

by s9w 6y ago

That's quite a lot. The by far most important things for me: Floats guarantee at least 7, and doubles at least 15 significant decimal digits. That's regularly surprisingly low to many devs.

deleted 6y ago

[deleted]

hnick 6y ago

The real problem I see mostly happen when arithmetic gets involved. Two simple and precise floats added or subtracted can get you something like 5.00000000001 if you aren't careful. A fairly innocuous perl snippet shows this: DB<1> $a+=0.1 for 1..10; print $a - 1 -1.11022302462516e-16 I ran into a bug like this on a website, I don't know what they were doing to the inputs but a simple 60.9 or similar turned into 60.9000000001 and tripped up the back-end service.

slavik81 6y ago
The problem is that they aren't precise floats. 0.1 has no finite representation in binary. It's an infinite repeating string of digits, like 1/3rd is in decimal. Thus, when you add a bunch of them together, the inherent error in rounding them off at some finite number of digits slowly adds up. The same is true of all multiples of 0.1, unless they're also a multiple of 0.5. Hence why your 60.9 is not actually 60.9. It was never exact to begin with.
- hnick 6y ago
  Yes, that is true. But usually symptoms don't surface until errors accumulate which is why I found that web form interesting. 'Precise' was the wrong word. What I meant was the system reports back the exact entered value 0.1 (rather than what it has in memory, which is 0.100000001490116119384765625 according to https://www.h-schmidt.net/FloatConverter/IEEE754.html https://www.h-schmidt.net/FloatConverter/IEEE754.html). Most programs will do this fairly well. I confirmed javascript is entirely capable of storing and retrieving the number I entered, so I'm not entirely sure what they were doing to confuse it :) Must have been some secret maths.
- DarkWiiPlayer 6y ago
  > 0.1 has no finite representation in binary. b1 / b1010 I don't see the problem. Did you mean to say it has no finite representation in the IEEE float format? > It was never exact to begin with. But the format sadly gets used in situations where people expect it to be reasonably accurate, where it isn't, because developers either underestimate the "reasonable" or overestimate the "accurate" part. It's just sad that most mainstream programming languages have no native accurate data type for rational numbers.
  - Gracana 6y ago
    > Did you mean to say it has no finite representation in the IEEE float format? Of course that's implied.
    - DarkWiiPlayer 6y ago
      It was a rhetoric question; I just wanted to point out that people blame these inaccuracies on "binary representations" when in reality it's just this one binary representation that's broken.
      - deleted 6y ago
        [deleted]
  - account42 6y ago
    So are you saying that ⅓ has a finite presentation in decimal? Finite binary rationals ⊋ finite binary numbers.
    - DarkWiiPlayer 6y ago
      > So are you saying that ⅓ has a finite presentation in decimal? Yes: ⅓
  - slavik81 6y ago
    I meant in positional notation, but most people know that as "decimal notation". Unfortunately, that implies base 10, so I avoided the term. I gave both an example in binary and an example in decimal to clarify my imprecise terminology. I worry that by objecting only to the binary example, you may confuse people into thinking the two are different.

kstenerud 6y ago

It may seem low, but it's really not. At 6 significant digits, you'd have a margin of error of a thousandth of an inch when measuring a football field.

0xffff2 6y ago
Counterpoint: At 6 significant digits you have a margin of error of thousandths of a millimeter when measuring degrees longitude near the prime meridian, but the error balloons to whole meters when measuring longitudes in Australia. I have a piece of software that I wrote ages ago where I looked at the max error in the US and concluded that 32bit floats were enough. This made sense since at the time I was reasonably confident that the tool would only be used with locations in the continental US and it simplified my architecture. Fast forward a few years and we ended up open sourcing the tool and people started using it all over the world. I'm still dealing with the fallout to this day. I'm dreading the day that the tool gets used in some inter-planetary context and I have to repeat all of the work to add support for 128 bit/arbitrary precision location data.
T-hawk 6y ago
Sure, that's low, depending on context. At 6 significant digits, a million-dollar bank account would have a margin of error of up to +/- 5 dollars. And if you add up a million of any item with 6 significant digits, that's enough for inaccuracy to propagate all the way into your first significant digit. (It would require systematic inaccuracy in one direction, but there are certainly data sets and contexts where that would happen.)
- kstenerud 6y ago
  https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio https://dzone.com/articles/never-use-float-and-double-for-mo...
s9w 6y ago
You are also not able to represent your yearly salary to the cent. At least if you're American haha