23 ms·

Beyond Floating Point: Next-Generation Computer Arithmetic [pdf]

25 points by wyldfire 10y ago

dwenzek 10y ago
This sounds really promising: simpler, superior accuracy, more robust operations. Here is an implementation: https://github.com/libcg/bfp https://github.com/libcg/bfp
McKayDavis 10y ago
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 10y ago
  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.
celias 10y ago
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 10y ago
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.

25 points by wyldfire 10y ago

This sounds really promising: simpler, superior accuracy, more robust operations. Here is an implementation: https://github.com/libcg/bfp https://github.com/libcg/bfp

McKayDavis 10y ago

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 10y ago
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.

celias 10y ago

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 10y ago

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.