11–20 of 53 posts
Here's a C/C++ partial implementation of posits: https://github.com/libcg/bfp
https://github.com/Etaphase/FastSigmoids.jl
contains both a julia library and a C/C++ library. Posits are implemented as a C type and a C++ class where the type and class sizes correspond to the bitwidth.
The overall idea of choosing a number distribution that loses less precision for common operations and orders of magnitude is pretty compelling, though.
HN discussion from 2 years ago: https://news.ycombinator.com/item?id=9943589
HN discussion from 2 years ago: https://news.ycombinator.com/item?id=9943589
This is different from unums which it says so in the second line of the Abstract.
https://news.ycombinator.com/item?id=14013971
John Gustafson (the author) has an account
HN discussion from 2 years ago: https://news.ycombinator.com/item?id=9943589
What a strange claim. Outputting a NaN is easier than raising an interrupt, or could be done within an interrupt, and detecting a NaN input requires a handful of gates or less.
This is not to say that NaNs are a good or bad method, but they're definitely not expensive to implement.
> posits lack a separate ∞ and −∞ [...] “negative zero” is another defiance of mathematical logic that exists in IEEE floats.
I will note that the IEEE standard almost had a projective infinity mode, and x87 has that mode.
> floats are asymmetric and use those bit patterns for a vast and unused cornucopia of NaN values
If we want to ignore languages like javascript and lua, sure.
> There are no “NaN” (not-a-number) bit representations with posits; instead, the calculation is interrupted, and the interrupt handler can be set to report the error and its cause, or invoke a workaround and continue computing, but posits do not make the logical error of assigning a number to something that is, by definition, not a number. This simplifies the hardware considerably. What a strange claim. Outputting a…
These guys have never allreduced a timestep in a simulation where something can go aphysical.
I mean, sure, one can communicate aphysical conditions using out-of-band means. But it is so pretty when it just rides along for free as a NaN result.
Edit: I stand corrected having looked up authors. I still think having float effectively be Maybe[float] is a feature not a bug.
> There are no “NaN” (not-a-number) bit representations with posits; instead, the calculation is interrupted, and the interrupt handler can be set to report the error and its cause, or invoke a workaround and continue computing, but posits do not make the logical error of assigning a number to something that is, by definition, not a number. This simplifies the hardware considerably. What a strange claim. Outputting a…
I saw him explain that in float, there a too many bit representations that amount to "NaN". According to a Stack Overflow I found:
"IEEE 754 standard defines 16,777,214 32-bit floating point values as NaNs, or 0.4% of all possible values."
That's "expensive" in terms of losing bits of expressiveness that could have been used to represent actual numbers.
> There are no “NaN” (not-a-number) bit representations with posits; instead, the calculation is interrupted, and the interrupt handler can be set to report the error and its cause, or invoke a workaround and continue computing, but posits do not make the logical error of assigning a number to something that is, by definition, not a number. This simplifies the hardware considerably. What a strange claim. Outputting a…
Or is that exception hard to implement?