4 ms·

One quick side story. Years ago, when I worked in automobile systems programming, some coworkers had to bring up a CAN bus data extraction system quickly (less

by w8rbt 11y ago

One quick side story. Years ago, when I worked in automobile systems programming, some coworkers had to bring up a CAN bus data extraction system quickly (less than a week) that worked with all of our programming tools. We used Java, C#, C, Python and C++ to capture, process and display the data to end users. To save time (due to the short schedule), they decided to store all numbers as 64 bit doubles. They reasoned that 64 bit doubles were big enough to hold any number that might come off the system controllers (some where intel, others motorola) and would simplify the design so that they could write it quickly. Some time later, we discovered an infrequent bug where occasionally, some of the CAN variables were correct, but at other times they failed sanity checks (way outside of the expected values for the specific sensor). Long story short, the issue turned-out to be that 64 bit double assumption. Sometimes there was enough space to store a large 64 bit int (if the int was 52 bits or less (IIRC)), at other times the int was too large to fit. The sign (+/-) and exponent take up 12 bits or so. The moral of the story is to use the right size (and sign) for each variable and don't assume that one size will fit all. We had to go back and correct all the bad values. That took awhile. In hindsight, they should have been given more time to design the system.

kabdib 11y ago
Floating point numbers are almost always a mistake. Classic howlers: "Well, we can represent almost all the values we care about." Until the day you can't. "We'll represent time with a double, with the fractional part being part of a day, and the day being an integer day number from when Somebody Famous Did Something." Until you realize that the 10AM meeting you want to put in your scheduler can't be exactly represented. "We'll put our account balances in there as floats because unlike everyone else who has done this, we know what we're doing." But you don't. And that noise you heard was a million accountants crying out in pain. You wouldn't represent a pointer as "some fraction of the amount of memory the machine has, from 0.0 to 0.9999", which is my usual retort when someone wants to smuggle a scalar or structural value in a float.
- roel_v 11y ago
  "Floating point numbers are almost always a mistake." This. The problem is that it's almost impossible to internalize this without having first-hand experience - experience which usually takes years to accumulate. By coincidence, over the last month I had to explain the problems with floating point numbers to non-technical people on two disjoint occasions, and failed miserably each time, because the technical details are too complicated and the examples too obscure. The 'store account balance in double, let's put the remainder on our own account' parable is the only example that sort of works but then they look at you blank-faced and say 'we're not a bank'. Just venting I guess. It's the simple things in mapping real-world things to bits that trip me up the most - why is it so hard to represent 'numbers' in computers? Why is it so hard to represent 'date' in computers? Why is it so hard to represent 'locations' in computers?
  - jbb555 11y ago
    I find it interesting that people don't realize that decimal notation has exactly the same issues as floating point. You can't store 1/10 of a £ in a binary floating point number exactly so don't use it for money. Well, you can't store 1/3 of a £ in a decimal number exactly either. The only difference is that people have got so used to decimal that we don't even notice the issue any more, and choose prices and have systems to work around the issue. It's so ingrained we don't even know we are doing it. So don't think that decimals are any better at storing money amounts than binary floating point, they are not. however all of the history and workarounds that we've been using for many years before computers for this issue also work if you store them in computers the same way. That's why you use decimals, it's because they replicate the representation issues we are used to already so we don't even notice they are there, it's not that they are fundementally better in any way.
    - roel_v 11y ago
      I think I disagree (depending on what you mean exactly). You say "That's why you use decimals, it's because they replicate the representation issues we are used to already so we don't even notice they are there, it's not that they are fundamentally better in any way." So decimals are better, because they allow us to represent money amounts in the exact same way we do in real life, which is what we're modeling in software. 1/10 = 0.1, an amount you want to be able to represent in a computer. 1/3 = 0.33..., an amount (when talking about money) you don't want to represent (when we're talking about maintaining balances). Unless you're saying "decimal as a concept is not philosophically or morally better than floating point", which is a position to which I suspect pretty much everybody subscribes.
- im3w1l 11y ago
  My understanding was that they used doubles as int52's, and the troubles they had came when that int52 overflowed and corrupted the exponent of the double. As opposed to the usual double problems.
userbinator 11y ago
To save time (due to the short schedule), they decided to store all numbers as 64 bit doubles. JavaScript influence?
- roel_v 11y ago
  On a team that writes a CAN bus interface? God I hope not...
  - yitchelle 11y ago
    Lucky for the drivers, it is not for the code that _goes_ in the car.
    - jmnicolas 11y ago
      If the Toyota debacle is any indication, the code that goes in the car is not pretty either.
- ygra 11y ago
  Could be Lua, too.
cpeterso 11y ago
A similar story about OCaml's garbage collector from https://twitter.com/mcclure111/status/637758978093547521 https://twitter.com/mcclure111/status/637758978093547521: So the GC stats package in #OCaml has a record of how many words have been allocated since startup and it's a float it has been explained to me OCaml GC recording bytes in floats is because float can store up to 2^52 integer but int only goes up to 2^30.
- danieldk 11y ago
  OCaml uses a tag bit to distinguish ints from pointers, so (unboxed) ints are only 31 bits: https://realworldocaml.org/v1/en/html/memory-representation-of-values.html https://realworldocaml.org/v1/en/html/memory-representation-... Floating point numbers are normally boxed (except for float arrays, float-only records, and some cases of local use).

by w8rbt 11y ago

kabdib 11y ago

Floating point numbers are almost always a mistake. Classic howlers: "Well, we can represent almost all the values we care about." Until the day you can't. "We'll represent time with a double, with the fractional part being part of a day, and the day being an integer day number from when Somebody Famous Did Something." Until you realize that the 10AM meeting you want to put in your scheduler can't be exactly represented. "We'll put our account balances in there as floats because unlike everyone else who has done this, we know what we're doing." But you don't. And that noise you heard was a million accountants crying out in pain. You wouldn't represent a pointer as "some fraction of the amount of memory the machine has, from 0.0 to 0.9999", which is my usual retort when someone wants to smuggle a scalar or structural value in a float.

roel_v 11y ago
"Floating point numbers are almost always a mistake." This. The problem is that it's almost impossible to internalize this without having first-hand experience - experience which usually takes years to accumulate. By coincidence, over the last month I had to explain the problems with floating point numbers to non-technical people on two disjoint occasions, and failed miserably each time, because the technical details are too complicated and the examples too obscure. The 'store account balance in double, let's put the remainder on our own account' parable is the only example that sort of works but then they look at you blank-faced and say 'we're not a bank'. Just venting I guess. It's the simple things in mapping real-world things to bits that trip me up the most - why is it so hard to represent 'numbers' in computers? Why is it so hard to represent 'date' in computers? Why is it so hard to represent 'locations' in computers?
- jbb555 11y ago
  I find it interesting that people don't realize that decimal notation has exactly the same issues as floating point. You can't store 1/10 of a £ in a binary floating point number exactly so don't use it for money. Well, you can't store 1/3 of a £ in a decimal number exactly either. The only difference is that people have got so used to decimal that we don't even notice the issue any more, and choose prices and have systems to work around the issue. It's so ingrained we don't even know we are doing it. So don't think that decimals are any better at storing money amounts than binary floating point, they are not. however all of the history and workarounds that we've been using for many years before computers for this issue also work if you store them in computers the same way. That's why you use decimals, it's because they replicate the representation issues we are used to already so we don't even notice they are there, it's not that they are fundementally better in any way.
  - roel_v 11y ago
    I think I disagree (depending on what you mean exactly). You say "That's why you use decimals, it's because they replicate the representation issues we are used to already so we don't even notice they are there, it's not that they are fundamentally better in any way." So decimals are better, because they allow us to represent money amounts in the exact same way we do in real life, which is what we're modeling in software. 1/10 = 0.1, an amount you want to be able to represent in a computer. 1/3 = 0.33..., an amount (when talking about money) you don't want to represent (when we're talking about maintaining balances). Unless you're saying "decimal as a concept is not philosophically or morally better than floating point", which is a position to which I suspect pretty much everybody subscribes.
im3w1l 11y ago
My understanding was that they used doubles as int52's, and the troubles they had came when that int52 overflowed and corrupted the exponent of the double. As opposed to the usual double problems.

userbinator 11y ago

To save time (due to the short schedule), they decided to store all numbers as 64 bit doubles. JavaScript influence?

roel_v 11y ago
On a team that writes a CAN bus interface? God I hope not...
- yitchelle 11y ago
  Lucky for the drivers, it is not for the code that _goes_ in the car.
  - jmnicolas 11y ago
    If the Toyota debacle is any indication, the code that goes in the car is not pretty either.
ygra 11y ago
Could be Lua, too.

cpeterso 11y ago

A similar story about OCaml's garbage collector from https://twitter.com/mcclure111/status/637758978093547521 https://twitter.com/mcclure111/status/637758978093547521: So the GC stats package in #OCaml has a record of how many words have been allocated since startup and it's a float it has been explained to me OCaml GC recording bytes in floats is because float can store up to 2^52 integer but int only goes up to 2^30.

danieldk 11y ago
OCaml uses a tag bit to distinguish ints from pointers, so (unboxed) ints are only 31 bits: https://realworldocaml.org/v1/en/html/memory-representation-of-values.html https://realworldocaml.org/v1/en/html/memory-representation-... Floating point numbers are normally boxed (except for float arrays, float-only records, and some cases of local use).