You'd still have to check for overflow, I imagine.
And there are other gotchas, for instance it seems natural to assume that NonZeroF32 * NonZeroF32 can return a NonZeroF32, but 1e-25 * 1e-25 = 0 because of underflow.
816 karma · joined July 27, 2024
And there are other gotchas, for instance it seems natural to assume that NonZeroF32 * NonZeroF32 can return a NonZeroF32, but 1e-25 * 1e-25 = 0 because of underflow.
```
impl Add for NonZeroF32 { ... }
impl Add<f32> for NonZeroF32 { ... }
impl Add<NonZeroF32> for f32 { ... }
```
What type would it return though?
They come from Lapack, the standard linear algebra foundation library, which is written in Fortran 77. That library was first written in 1992, when the Fortran 90 standard was still new and not supported everywhere, so they stuck with the earlier version. Lapack has become the standard library for dense non-parallel linear algebra; it is still maintained and updated, but the basic math algorithms haven't changed much, so there was no need to replace it entirely. Today there are also processor-specific libraries like MKL or Apple Accelerate, but they still all follow the same Lapack API.
When Fortran-77 was standardized, they decided to keep function names at most 6 letter long, to "ensure portability". I.e., they wanted to support certain compilers and architectures that were already considered old in 1977.
TL;DR: if you can't read easily those flame graphs today, it's because of backward compatibility with certain mainframes that probably date back to the late 1960s.
These students had already received an acceptance letter, so possibly they already turned down other positions based on that letter.
The requirement is called "dynamic linking" (the 2FA code must be tied to the specific transaction) and the relevant regulation is PSD2.