Live data from Hacker News

Floating point visually explained (2017)

fabiensanglard.net

41–50 of 58 posts

Re: Floating point visually explained (2017)

#41

As one who understands floats I really wish there was a better notation for literals, the best would be a floating literal in binary representation. For integers you can write 0x0B, 11, 0b1011 and have a very precise representation For floats you write 1e-1 or 0.1 and you get an ugly truncation. If it were possible to write something like 1eb-1 (for 0.5) and 1eb-2 (for 0.25)... people would be incentivate to use nice…

> better notation for literals [...] something like 1eb-1 (for 0.5) and 1eb-2 (for 0.25) There are floating point hex literals. These can be written as 0x1p-1 == 0.5 and 0x1p-2 == 0.25. You can use them in C/C++, Java, Julia, Swift, ..., but they are not supported everywhere. https://observablehq.com/@jrus/hexfloat

C++ hex floats are an interesting combination of 3 numeric bases in one!

the mantissa is written in base 16

the exponent is written in base 10

the exponent itself is a power of 2 (not of 16 or 2), so that's base 2

One can only wonder how that came to be. I think they chose base 10 for the exponent to allow using the 'f' suffix to denote float (as opposed to double)

Re: Floating point visually explained (2017)

#42

Earlier quoted context omitted.

> better notation for literals [...] something like 1eb-1 (for 0.5) and 1eb-2 (for 0.25) There are floating point hex literals. These can be written as 0x1p-1 == 0.5 and 0x1p-2 == 0.25. You can use them in C/C++, Java, Julia, Swift, ..., but they are not supported everywhere. https://observablehq.com/@jrus/hexfloat

Julia is missing 32 bit and 16 bit hex floats unfortunately.

You can just wrap the literal in a conversion function, eg Float32(0x1p52), which should get constant propagated at compile time.

Re: Floating point visually explained (2017)

#43
It probably differs a lot per person, and I usually do find graphical explanations of stuff easyer to graph. But that formula was way easyer to understand for me than the other explanation. Maybe it is related to the fact that I am pretty ok at math, but I got kinda bad dyslexia.

Re: Floating point visually explained (2017)

#44
post #37
post #19

Why is everyone complaining about people finding floats hard? Sure, scientific notation is easy to grasp, but you can't honestly tell me that it's trivial AFTER you consider rounding modes, subnormals, etc. Maybe if hardware had infinite precision like the real numbers nobody would be complaining ;) One thing I dislike in discussions about floats is this incessant focus on the binary representation. The representatio…

I think the binary representation is the essence of floating point numbers, and if you go beyond the "sometimes, the result is slightly wrong" stage, you have to understand it. And so far the explanation in the article is the best I found, not least because subnormal numbers appear naturally. There is a mathematical foundation behind it of course, but it is not easy for a programmer like me. I think it is better to t…

Sorry, I didn't mean to downplay the value of using concrete examples. I absolutely agree that everyone learns better from concrete settings, which is why my original comment fixed the parameters for people to play with. I was referring more to the discussions of how exponents are stored biased, the leading bit in the mantissa is implied = 1 (except for subnormals), and so on. All these are distracting features that can (and should) be covered once the reader has a strong intuition of the more fundamental aspects.

Re: Floating point visually explained (2017)

#46

Earlier quoted context omitted.

Julia is missing 32 bit and 16 bit hex floats unfortunately.

You can just wrap the literal in a conversion function, eg Float32(0x1p52), which should get constant propagated at compile time.

I know, it just isn't as nice to read.

Re: Floating point visually explained (2017)

#47

Earlier quoted context omitted.

It also explains why 0.1+0.2 is not 0.3. With binary IEEE-754 floats, none of those can be represented exactly[a]. With decimal IEEE-754 floats, it's possible, but the majority of hardware people interact with works on binary floats. [a]: Sure, if you `console.log(0.1)`, you'll get 0.1, but it's not possible to express it in binary exactly ; only after rounding. 0.5, however, is exactly representable.

Python 3.9.5 >>> 0.1.hex() '0x1.999999999999ap-4' >>> 0.2.hex() '0x1.999999999999ap-3' >>> (0.1 + 0.2).hex() '0x1.3333333333334p-2' >>> 0.3.hex() '0x1.3333333333333p-2'

But they are repeating. So, by definition, they are not exactly representable in a (binary) floating point system. Again, that’s why 0.1 + 0.2 is not 0.3 in binary floating point.

Re: Floating point visually explained (2017)

#49
The "default" formula as presented in the article seems… strange. Is this really how it's normally taught?

    (-1)^S * 1.M * 2^(E - 127)
This seems unnecessarily confusing. And 1.M isn't notation I've seen before. If we expand 1.M into 1 + M : 0
    (-1)^S * (1 + M) * 2^(E - 127)
    (-1)^S * 2^log_2(1 + M) * 2^(E - 127)
    
    let F := log_2(1 + M)
    0 
Since we know F is between 0 and 1, we can see that F controls where the number lands between 2^(E - 127) and 2^(E - 127 + 1) (ignoring the sign). It's the "offset".

Re: Floating point visually explained (2017)

#50
post #14

Earlier quoted context omitted.

that's called fixed point. there isn't hardware for it because it is cheap to make in software using integer math.

Some DSP chips had hardware for fixed point. I think it's a shame that C never added support for fixed point.

There was a draft and GCC supports it in stdfix.h. The downside is that the types have limited integer range since they're tailored for DSP applications where values are kept scaled between +/-1.0.
Post reply on HN