3 ms·

I’m a bit surprised that these two concepts are seen together. I’d of thought that financial math and data management would always be done with some level of a

I’m a bit surprised that these two concepts are seen together. I’d of thought that financial math and data management would always be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. Then again, 128 bits is plenty for microcents or whatever the minimim unit is. I’m guessing back in the day when things were 32 bit or less, there were entire financial database implementations that handled this abstraction?

dboreham 3y ago
Handled in hardware on some machines (e.g. VAX)
DamonHD 3y ago
If you actually want to do something useful and accurate and auditable and performant and space-efficient, because you have a lot of money values to bank with, you really don't want too much abstraction. My experiences in various bits of banking include where juniors ignore advice NOT to store currency in floating point values and then come whining that arithmetic is broken, and tech dudes in a lab deciding that every single FX flow in an investment bank should have 2MB of (unshared) calendar hidden inside its abstraction which made some individual trades too big to load even for powerful machines... Fixed point calcs in integers are good.
- Waterluvian 3y ago
  Floating point feels like an incredibly grokkable concept that was just not taught well for a long time. Maybe too mathematically (of course). Or maybe that was just my experience. I feel like any dev team should pick up a copy of this for on-boarding: https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-floats-work/ https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-f...
  - fidotron 3y ago
    Floating point being grokkable doesn’t make it any more suitable for this application. Floating point is inherently an approximation - your bank balance should not be an approximation.
    - DamonHD 3y ago
      More to the point binary fp absolutely is a bad approximation to, and does poor arithmetic on, common legal sub-1 decimal currency values, ie those that do not have an exact binary fp representation.
    - Spivak 3y ago
      > Floating point is inherently an approximation - your bank balance should not be an approximation. I think this is a perfect example of bad floating point teaching. Floating point is not an approximation in any sense. If the numerical result of your calculation is representable in floating point you will get an exact answer always. And for results that aren't representable you decide exactly what should be done about that. It's like saying integers are an approximation because 5/2 == 2.
      - deleted 3y ago
        [deleted]
      - dahfizz 3y ago
        In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX. A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them. Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.
        fidotron 3y ago
        TBF, be careful here. The IEEE floats can represent a subset of integers in their range exactly. For example, 64 bit floats can represent the range of 32 bit ints accurately (and more). That said, it is bizarre to claim that if the result can be represented you get the exact result, when the core problem is that the result cannot be represented because the representation is an approximation.
shortrounddev2 3y ago
> I’m guessing back in the day when things were 32 bit or less, there were entire financial database implementations that handled this abstraction? This issue is what COBOL was designed to solve. Fixed decimal point arithmetic in base 10
dahfizz 3y ago
> be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. This still doesn't do that, its just integer math. It doesn't matter how your CPU implements it, as long as `x = a + b` gives the correct value for x. You don't have to immediately reach for an abstraction layer when you hear the word "bits" ;)
- Waterluvian 3y ago
  But without a sufficient stratigraphy of abstractions, I can't ever dig down if I run into issues! ;)

dboreham 3y ago

Handled in hardware on some machines (e.g. VAX)

DamonHD 3y ago

If you actually want to do something useful and accurate and auditable and performant and space-efficient, because you have a lot of money values to bank with, you really don't want too much abstraction. My experiences in various bits of banking include where juniors ignore advice NOT to store currency in floating point values and then come whining that arithmetic is broken, and tech dudes in a lab deciding that every single FX flow in an investment bank should have 2MB of (unshared) calendar hidden inside its abstraction which made some individual trades too big to load even for powerful machines... Fixed point calcs in integers are good.

Waterluvian 3y ago
Floating point feels like an incredibly grokkable concept that was just not taught well for a long time. Maybe too mathematically (of course). Or maybe that was just my experience. I feel like any dev team should pick up a copy of this for on-boarding: https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-floats-work/ https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-f...
- fidotron 3y ago
  Floating point being grokkable doesn’t make it any more suitable for this application. Floating point is inherently an approximation - your bank balance should not be an approximation.
  - DamonHD 3y ago
    More to the point binary fp absolutely is a bad approximation to, and does poor arithmetic on, common legal sub-1 decimal currency values, ie those that do not have an exact binary fp representation.
  - Spivak 3y ago
    > Floating point is inherently an approximation - your bank balance should not be an approximation. I think this is a perfect example of bad floating point teaching. Floating point is not an approximation in any sense. If the numerical result of your calculation is representable in floating point you will get an exact answer always. And for results that aren't representable you decide exactly what should be done about that. It's like saying integers are an approximation because 5/2 == 2.
    - deleted 3y ago
      [deleted]
    - dahfizz 3y ago
      In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX. A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them. Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.
      - fidotron 3y ago
        TBF, be careful here. The IEEE floats can represent a subset of integers in their range exactly. For example, 64 bit floats can represent the range of 32 bit ints accurately (and more). That said, it is bizarre to claim that if the result can be represented you get the exact result, when the core problem is that the result cannot be represented because the representation is an approximation.

shortrounddev2 3y ago

> I’m guessing back in the day when things were 32 bit or less, there were entire financial database implementations that handled this abstraction? This issue is what COBOL was designed to solve. Fixed decimal point arithmetic in base 10

dahfizz 3y ago

> be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. This still doesn't do that, its just integer math. It doesn't matter how your CPU implements it, as long as `x = a + b` gives the correct value for x. You don't have to immediately reach for an abstraction layer when you hear the word "bits" ;)

Waterluvian 3y ago
But without a sufficient stratigraphy of abstractions, I can't ever dig down if I run into issues! ;)