Show HN: Floating point arithmetic types in C++ for any size and any base | Hacker News Reader

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

github.com

79 pointsseg_fault41 comments

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.

Open articleView on HN

Consider dropping the specializations for the type traits, given that it's undefined behavior:

https://en.cppreference.com/w/cpp/types/is_fundamental

https://en.cppreference.com/w/cpp/types/is_floating_point

https://en.cppreference.com/w/cpp/types/is_arithmetic

https://en.cppreference.com/w/cpp/types/is_scalar

https://en.cppreference.com/w/cpp/types/is_object

Why is std::is_object even specialized here? Isn't it always true regardless?

I don't get what you mean. I thought they specify how the type can be used?

The cppreference page says:

> If the program adds specializations for std::is_fundamental or std::is_fundamental_v, the behavior is undefined.

This is an oversimplification. The actual rule is https://eel.is/c++draft/library#namespace.std-2 .

> the specialization meets the standard library requirements for the original template.

For is_fundamental<YourClassType> it means that is_fundamental<YourClassType>::value must be false, as YourClassType is not a fundamental type, as defined in https://eel.is/c++draft/basic.fundamental#17 .

Some traits are just not designed to be customization points.

Technically, you're not supposed to add your own specialisations to the `std` namespace

In general this isn’t true (i guess it is in this specific context). For example I believe it’s totally expected to specialize std hash

I’ve also done this with hash… though given the footguns scattered about, I wouldn’t be surprised if it broke the spec.

That is a completely intended way to use std::hash, along with a few other functions like std::tuple_size and std::tuple_element.

For "any size" I was kind of expecting arbitrary sized mantissa/exponent, can be useful for emulating weird DACs, for example, 12-bit mantissa and 3-bit exponent[1].

[1] https://ajxs.me/blog/Yamaha_DX7_Technical_Analysis.html

Actually you can specify the numeric limits of the mantissa and the exponent. They can be specified as template arguments[0]. So you could do:

      Float<uint8_t, // type of the mantissa
            uint8_t, // type of the exponent
            0,       // lowest possible value of the mantissa
            4095,    // highest possible value of the mantissa
            0,       // lowest possible value of the exponent
            7>       // highest possible value of the exponent

The Float then simulates an unsigned 12bit mantissa and a 3bit exponent. Sure it still takes 16 bytes. But you could create a union with bitfields where you shrink that even further.

[0] https://github.com/clemensmanert/fas/blob/58f9effbe6c13ab334...

Can you go in the other direction? Higher exponent and mantissa than regular float/double?

Sure.

    Float<int64_t, int64_t>

Gives you a signed Mantissa with 64 bit and a signed Exponent with 64bit. Since there are numeric limits for int64_t available, Float knows the max and the min value.

You could get even bigger ranges for Float by implementing your own big integer type.

Possibly could be combined with C23's _BitInt(N) for the template arguments? I think it's available in clang as a C++ extension.

edit: or I guess you could have your own Tmantissa and Texponent types as custom classes that correctly model _BitInt(N), they don't seem to be required to be builtin integral types.

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.

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.

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.

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 :)

How does this compare to Boost.Multiprecision, which works well with Boost.Math?

https://www.boost.org/doc/libs/1_86_0/libs/multiprecision/do...

My type is a bit simpler. But I think the approach is the same. After all, boost's type has much more math functions implemented. I don't have exp, sqrt...

No LICENSE. Have you thought about adding one?

Somebody wants to use it? :D I thought about something like where people can use it but have to make changed public. I am just curious, what should be changed. But I dont think there is actually a real world use case.

Sounds like you prefer copyleft licenses. I suggest MPL-2.0 or some variety of (L)GPL as they are the most well-known ones.

Here is an example of the other end of the spectrum that I've used a couple of times: very simple fixpoints.

https://github.com/codr7/claes/blob/main/src/claes/f64.hpp

> std::numeric_limits<fas::Float<std::int16_t, std::int8_t>>::MAX()

Surely you mean ::max()?

> is_fundamental<int16_t, int16_t>::value et al.

Besides the undefined behavior issue mentioned by others, none of these are syntactially correct.

> #include "fas/stream.hpp>

Ok then...

> The Stl's std::numeric_limits is required the limits of the specified types for mantissa and exponent.

Missing a word? Also, the STL [0] does not have std::numeric_limits, perhaps you mean the C++ standard library (or stdlib for short).

[0] https://en.wikipedia.org/wiki/Standard_Template_Library

Waiting for someone to implement a mandelbrot zoom with that (:

Have nothing to say other than - neat!

Thank you :)

Isn't this in libgmp already?

https://gmplib.org/

GMP doesn't do arbitrary exponents.

Indeed, thanks.

Slight correction, while the exponent is indeed fixed, it is larger than a f32/f64 exponent: https://gmplib.org/manual/Floating_002dpoint-Functions

However, this is not exposed in all GMP wrappers.

If I understand this correctly GMP has a flexible mantissa with no limitations during runtime.

In fas you have to specify the sizes (of mantissa and exponent) during compile time. So the size of this type is fixed. Thus, there is no heap involved.

It's copyrighted so I should not even look at it, and therefore not comment on it.

All creative works are copyrighted by default in the U.S. and any countries adhering to the Berne convention, unless copyrights are explicitly waived (which is not always an option). This is true regardless of what copyright notices exist, so by that standard you shouldn’t look at or comment on anything. ;) But, it’s legal to look at something copyrighted, you just can’t copy & distribute it. Just curious, did you mean that it lacks an open source license and you only look at open source, or was this just a joke that went sideways, or something else?

It's copyrighted, but nothing stops you from looking at it. It's akin to looking a t a mural painted at someone's house. You can also comment as long as you don't post snippets of the code (except for when fair use is applicable).

Legally yes, but in reality not. In most companies or projects legal tells me not to look at it all, esp. the FSF. I can look at the API, but not the implementation.

That's why it's called https://en.wikipedia.org/wiki/Clean-room_design.

I suppose you do not read books or watch movies either

Removed it.

You should put the copyright notice back and (optionally) add a license. Removing the notice from your code changes nothing, that does not waive or remove your copyright. You still have the copyrights to your code by default, and you should. Don’t react to silly comments on the internet by feeding them.

If you really don’t want the copyrights, you can use the CC0 license from Creative Commons. That would allow people to use your code any way they want with no restrictions (which means they are legally allowed to use it commercially, remove the author notice, re-license modified versions, redistribute the code, etc.). However, you do not need to waive your copyrights entirely in order to license your code as open source. You can choose between a variety of licensing terms, while still being very open and liberal about sharing. Try the Creative Commons license chooser https://chooser-beta.creativecommons.org/. Or look through open source licenses. Standardized SPDX IDs are gaining popularity since it helps with some automation workflows. https://opensource.org/licenses https://spdx.org/licenses/

Since you left the author note, maybe you would like an attribution license like one of these popular choices (both available with SPDX IDs): https://opensource.org/license/bsd-3-clause https://creativecommons.org/licenses/by-sa/4.0/

If you don’t add a license, then your code remains under strict copyright and people are not legally allowed to use it in their own projects, regardless of whether you have a copyright notice in the comments. Leaving out the copyright notice might be confusing, especially given this thread. The recommended practice is to include both the copyright notice and the license in comments or a license file.

And yet...

The API looks fine, well

Reply on news.ycombinator.com