4 ms·

Anytime you're doing a lot of floating-point math, the imprecision can bite you in non-intuitive ways. But you can mitigate that by fixing the order of operatio

by macksd 6y ago

Anytime you're doing a lot of floating-point math, the imprecision can bite you in non-intuitive ways. But you can mitigate that by fixing the order of operations to minimize error. I suppose one other specific example of a similar concept would be that when training deep learning models models you're doing a ton of matrix multiplication and tweaking the weights constantly. Especially when using lower-precision numbers, you can hit issues where your coefficient gets too close to 0, and the next thing you know it IS 0, and everything it gets multiplied by also comes out to 0, which messes everything up. So you have to avoid getting too close to 0: https://pytorch.org/docs/stable/amp.html#gradient-scaling https://pytorch.org/docs/stable/amp.html#gradient-scaling.

omginternets 6y ago
Gotcha, thanks. This is actually exactly the piece of information that was missing!
- fuzzfactor 6y ago
  Careful numerical analysis can also be very worthwhile with integer math as well.
  - omginternets 6y ago
    When does that come up?
    - fuzzfactor 6y ago
      Can happen more seriously than with floating point since the dynamic range of integer math is relatively much more limited for the same bit depth. This can be especially bad with division followed by inherent truncation. The inability to represent very big values as well as very small values might need to be worked around. I needed to overcome this back in 1982 (before 16-bit portable PC's, and PC's were not yet popular at all) to do equivalent calculations on an 8-bit TRS-80 in 0.5K of BASIC program memory, to what was officially developed by 1980 in many pages of 32-bit FORTRAN. The algorithms had been well established for decades but always implemented using the equivalent of trig tables until the mainframe was capable of substituting (or even automatically printing the official tables!) after 1980. One volume of the published tables was bigger and weighed more than the TRS-80 portable. Ended up using something like the 21st century Gustafson approach for my little problem back then, now he is a mathematician pursuing a brilliant more universal solution. By 1982 it didn't bother me that my integer algorithms were dramatically different than the official floating-point FORTRAN. I had gotten accustomed to morphing fundamental equations by computerizing much less onerous tables where the simple near-linear equation was useless because the published tables contained official rounding errors from the original slide-rule calculations. To match the official calculations that time, the convergence of manual and automatic rounding errors took major precedence over the underlying equation which actually was defined by physical properties.

by macksd 6y ago

omginternets 6y ago

Gotcha, thanks. This is actually exactly the piece of information that was missing!

fuzzfactor 6y ago
Careful numerical analysis can also be very worthwhile with integer math as well.
- omginternets 6y ago
  When does that come up?
  - fuzzfactor 6y ago
    Can happen more seriously than with floating point since the dynamic range of integer math is relatively much more limited for the same bit depth. This can be especially bad with division followed by inherent truncation. The inability to represent very big values as well as very small values might need to be worked around. I needed to overcome this back in 1982 (before 16-bit portable PC's, and PC's were not yet popular at all) to do equivalent calculations on an 8-bit TRS-80 in 0.5K of BASIC program memory, to what was officially developed by 1980 in many pages of 32-bit FORTRAN. The algorithms had been well established for decades but always implemented using the equivalent of trig tables until the mainframe was capable of substituting (or even automatically printing the official tables!) after 1980. One volume of the published tables was bigger and weighed more than the TRS-80 portable. Ended up using something like the 21st century Gustafson approach for my little problem back then, now he is a mathematician pursuing a brilliant more universal solution. By 1982 it didn't bother me that my integer algorithms were dramatically different than the official floating-point FORTRAN. I had gotten accustomed to morphing fundamental equations by computerizing much less onerous tables where the simple near-linear equation was useless because the published tables contained official rounding errors from the original slide-rule calculations. To match the official calculations that time, the convergence of manual and automatic rounding errors took major precedence over the underlying equation which actually was defined by physical properties.