←back to thread

Show HN: Floating point arithmetic types in C++ for any size and any base

(github.com)
67 points seg_fault | 2 comments | 18 Oct 24 17:42 UTC | HN request time: 0s | source

Since there is so much interest on HN in floats lately and their software implementations, I wanted to show mine. It has no use and is just for teaching me floats and C++. Give me your thoughts.
Show context
badmintonbaseba ◴[21 Oct 24 20:06 UTC] No.41907988[source]▶
Nice!

> TODO: (configurable) rounding support

What's the default rounding mode? Round to nearest even?

You might be interested in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33... too, which is a recent paper for introducing reproducible floating point to C++.

Very small floating point types can be handy for exhaustive testing of floating point function templates, especially ones that take multiple arguments. Walking over all floating point values for a small type often finds most if not all corner cases that can manifest with a floating point type of any size.

replies(1): >>41908252 #
seg_fault ◴[21 Oct 24 20:32 UTC] No.41908252[source]▶
Rounding: actually it just cuts off. I have not spent much time to think about how to specify and implement the different rounding modes. Maybe some day...

Thanks for the hint to the paper. I also faced these issues. Thus, I provided a constructor which accepts mantissa and exponent as values. Very handy for the unittests.

replies(1): >>41908733 #
1. badmintonbaseba ◴[21 Oct 24 21:32 UTC] No.41908733[source]▶
By cutting off do you mean that it correctly rounds towards zero? Maybe you can implement rounding to closest by just doing the calculation in a one digit wider mantissa with rounding to zero and observing the last digit, at least for an even base. It won't be rounding to even though, but for that a 2 digit wider mantissa is probably enough.

Rounding to nearest with an odd base doesn't seem to be as straightforwardly implementable from rounding to zero calculations at a higher precision.

replies(1): >>41908790 #
2. seg_fault ◴[21 Oct 24 21:38 UTC] No.41908790[source]▶
I remember that I tried that some time ago. Especially the multiplication was tough, but I can not recall where I gave up. When I find some time, I will pick it up again :)