Comment by mgaunard
4 years ago
I don't understand how M * 2^E (modulo small representation details) is difficult to grasp. Then you have decimal types as M * 10^E.
It's certainly much clearer than the windowing and bucketing in this article.
4 years ago
I don't understand how M * 2^E (modulo small representation details) is difficult to grasp. Then you have decimal types as M * 10^E.
It's certainly much clearer than the windowing and bucketing in this article.
His approach works well for me. I don't retain arbitrary facts. At least part of this is a fear that if I don't properly understand its dynamics I will misapply it, better to discard it.
The windowing explanation shows me a path from the intent of the designer through to the implementation (the algorithm). Now I can retain that knowledge.
> I don't retain arbitrary facts.
I still fail to understand what is arbitrary in scientific notation. The designers almost certainly didn't think in terms of windows when creating the data types, they probably thought about the mantissa and exponent the way it's usually explained, and maybe about information density (entropy per bit) when comparing with other possibilities.
Anyway, if it helps, great. Different explanations are always welcome. But this one is post-fact.
> I still fail to understand what is arbitrary in scientific notation
I used the word arbitrary, but did not say that scientific notation was arbitrary.
I will try to explain another way. The equation is an assertion. For me, it does not plainly follow from the underlying problem. Once the author has introduced the windowing approach, the equation follows easily for me.
> almost certainly [..] they probably [..] Different explanations are always welcome. But this one is post-fact.
By your own words, it is not clear that it is. It is clear that you doubt that the author of the system was thinking in terms of windows and buckets.
Ahem, exponential forms go back to Archimedes, and no design (or intent thereof) assumed windows or offsets in FP. It’s just a fixed-precision floating-point notation, no more no less. The problem persists with decimal tax calculations like $11111.11 x 12% == $1333.33|32, where 0.0032 is lost in a monetary form. It also persists with on-paper calculations because there may be no room for all the digits that your algorithm produces (think x/7) and you have to choose your final acceptable precision.
At least part of this is a fear that if I don't properly understand its dynamics I will misapply it
The explanation that you like can’t save from it either. It’s not something you think through and just write the correct code. Quick exercise with the “new” knowledge you’ve got: you have an array of a million floats, add them up correctly:
I think windowing and bucketing are a useful conceptual model for understanding the precision of the encoding space. I understand how FP values work in practice but this article really hits the nail on it's head when explaining the less tangible aspects of FP encoding.