
Beyond Floating Point: Next-Generation Computer Arithmetic [pdf] - wyldfire
http://web.stanford.edu/class/ee380/Abstracts/170201-slides.pdf
======
McKayDavis
I didn't dive too deep into the bit-wise implementation details, but overall
this looks very promising.

The first big issue I would have with Posits is the lack of a Not-a-Number
(NaN) representation (as indicated on slide 16).

NaN values have the property of making any calculation they are used in also
result in in a NaN.

I've found this property of NaNs to be invaluable in many contexts, especially
as a no-data value regular data.

For example, this is useful when using bllinear filtering of floating point
textures on a GPU -- any time a NaN texel is encountered, the entire fragment
is discarded. In this manner, NaN values can be used to mask out a region
without introducing a separate texture lookup.

I also love the simple, albeit obtuse, check for NaN:

    
    
      // Don't remove this if! It's checking if value is a NaN
      if (value != value) {
         // value is NaN...
      }

~~~
sounds
The accuracy and dynamic range comparison plots seem to say there are some
"NaN" conditions, with the note that it aborts the calculation.

It might be worth digging into the bit representation to find out exactly what
happens, for instance, when you multiply 0 * infinity. That was a case that
supposedly outputs NaN.

------
dwenzek
This sounds really promising: simpler, superior accuracy, more robust
operations.

Here is an implementation:
[https://github.com/libcg/bfp](https://github.com/libcg/bfp)

------
celias
The Great Debate @ARITH23: John Gustafson and William Kahan
[https://www.youtube.com/watch?v=LZAeZBVAzVw&feature=youtu.be](https://www.youtube.com/watch?v=LZAeZBVAzVw&feature=youtu.be)
Audio quality is not great but there are links to slides from Gustafson and
Kahan

------
olliej
So this may be dumb, but as far as I can tell this is comparing a 64bit double
to a different data type that uses many more bits -- the example
implementation uses an additional 9 bytes (ignoring padding/alignment etc). Of
course that has better precision - it has literally more than doubled the size
of the representation. I am on phone (so actual code review will take time),
but I'm not convinced that you can get rid of those extra bits.

That said the absence of -0 is actually a problem for some math - you need it
for some operations to come out correctly given that you are using a finitely
bound representation.

I'd love to see a clearer paper comparing precision, etc with equal size
constraints.

