4 ms·

Mentioning this b/c it was something that surprised me when I first heard it: Many python numerical libraries change how they internally represent certain data

Mentioning this b/c it was something that surprised me when I first heard it: Many python numerical libraries change how they internally represent certain data types and/or change internal algorithms from version to version. This means that running the exact same code on two different versions may give you slightly different results. In your side project this may not be a big deal but if you are working at, say, a hedge fund or a company that does long and complicated data processing pipelines then version upgrades with no unit testing can be "very bad".

atoav 2y ago
If you are working in a hedge fund you probably (hopefully?) know it isn't a good idea to represent monetary values using floats. And your numerics library should be checked for correctness on each commit, just in case.
- wesselbindt 2y ago
  Of course, but regardless, version bumps do sometimes affect the outcomes of pipelines. Unit tests are a good thing to have.
- samatman 2y ago
  This is a useful bit of conventional wisdom, but it helps to know when it is and isn't applicable. There is a huge amount of data analysis which uses numbers representing money as inputs where it's fine to use floating point, and financial entities routinely do so. For a transaction, interest payments, and that sort of thing, then yes, one needs a specific sort of fixed-point representation, and operations which round in whatever the legally-correct fashion is for the use case. Reductively, if you've turned money into numbers, and will turn the resulting numbers back into money, don't use floating point. If you're running a big calculation with lots of inputs to decide what stock to buy next, that's probably going to have floating-point monetary values in it, and there's nothing wrong with that. Hedge funds do a lot of the latter.
owlbite 2y ago
Unless the underlying code has been designed specifically for it (at the cost of some lost performance), it is a somewhat unreasonable expectation for high performance numerical code to always return the same result across version changes. Even running the same code on different machines, or the same machine with differently aligned data is likely to return different (but equally mathematically valid) results.
tomsmeding 2y ago
This happens not only in math libraries but even in compilers. An x64 processor has two ways (at least) to perform simple 64-bit floating-point operations: with SSE registers (using only one of the slots in the vecror), or with the older x87 instructions. The former work with 64-bit IEEE intermediates (`double`), the latter works with 80-bit extended precision intermediates (`long double`). In practice, these days compilers always use the former because they're widely available and are predictable. But if you tell a C compiler to not assume that SSE is available, it will use the x87 instructions. If you use the x87 instructions, whether an intermediate float value is stored in memory or in a register changes the outcome, because it's stored in memory truncated to 64 bits, but in the (x87) register it's the full 80 bits. If you rely on exact, reproducible floating-point results, you have more to worry about than just software versions.

atoav 2y ago

If you are working in a hedge fund you probably (hopefully?) know it isn't a good idea to represent monetary values using floats. And your numerics library should be checked for correctness on each commit, just in case.

wesselbindt 2y ago
Of course, but regardless, version bumps do sometimes affect the outcomes of pipelines. Unit tests are a good thing to have.
samatman 2y ago
This is a useful bit of conventional wisdom, but it helps to know when it is and isn't applicable. There is a huge amount of data analysis which uses numbers representing money as inputs where it's fine to use floating point, and financial entities routinely do so. For a transaction, interest payments, and that sort of thing, then yes, one needs a specific sort of fixed-point representation, and operations which round in whatever the legally-correct fashion is for the use case. Reductively, if you've turned money into numbers, and will turn the resulting numbers back into money, don't use floating point. If you're running a big calculation with lots of inputs to decide what stock to buy next, that's probably going to have floating-point monetary values in it, and there's nothing wrong with that. Hedge funds do a lot of the latter.

owlbite 2y ago

Unless the underlying code has been designed specifically for it (at the cost of some lost performance), it is a somewhat unreasonable expectation for high performance numerical code to always return the same result across version changes. Even running the same code on different machines, or the same machine with differently aligned data is likely to return different (but equally mathematically valid) results.

tomsmeding 2y ago

This happens not only in math libraries but even in compilers. An x64 processor has two ways (at least) to perform simple 64-bit floating-point operations: with SSE registers (using only one of the slots in the vecror), or with the older x87 instructions. The former work with 64-bit IEEE intermediates (`double`), the latter works with 80-bit extended precision intermediates (`long double`). In practice, these days compilers always use the former because they're widely available and are predictable. But if you tell a C compiler to not assume that SSE is available, it will use the x87 instructions. If you use the x87 instructions, whether an intermediate float value is stored in memory or in a register changes the outcome, because it's stored in memory truncated to 64 bits, but in the (x87) register it's the full 80 bits. If you rely on exact, reproducible floating-point results, you have more to worry about than just software versions.