Re: Another Boost.Decimal Review

From: Matt Borland (matt_at_[hidden])
Date: 2025-01-23 16:23:25

On Thursday, January 23rd, 2025 at 11:10 AM, Jeff Garland <azswdude_at_[hidden]> wrote:

> 

> 

> On Thu, Jan 23, 2025 at 8:53 AM Matt Borland <matt_at_[hidden]> wrote:
> 

> > 

> > > Standardization:
> > >
> > 

> > 

> > We would certainly appreciate your help with standardization. Since C23 added decimal types I don't know why C++ would not have them.
> 

> 

> I expect c++26 will be standardized on top of C23 so will inherit those types. But of course having a native C++ type that does c++ things is different from _Decimal32 C code. I'll contact you offline on standardizing.

Sounds good.

> 

> 

> > > C23 and _Decimal*
> > >
> > 

> > > Should this library consider being a layer over C23 types where that's
> > > possible? GCC supports them at least in a limited fashion.
> > >
> > 

> > > https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html
> > >
> > 

> > 

> > It would be easier to add a wrapper over those than the Intel lib because they already come with GCC.
> 

> 

> Yes -- noting that the current gcc implementation doesn't implement any of the cmath functions.

We can add "accessors" that decode the bits like we do for unpacking our types. Once we have those mechanisms in place its a quick jump to plugging into all of our standard library.

> 

> 

> 

> > 

> > > > Does the API match with current best practices?
> > >
> > 

> > > Construction:
> > >
> > 

> > > template <typename T, typename T2>constexpr decimal32(T coeff, T2 exp,
> > >
> > 

> > > bool sign = false) noexcept;
> > >
> > 

> > > Is the sign flag helpful here? It seems simpler to just handle a negative
> > > coefficient -- like it already does. When I look at it there's already
> > > cognitive dissidence in my brain about if the sign flag overrides or
> > > inverts the coefficient sign. The N2849 api doesn't have this flag.
> > >
> > 

> > 

> > I think a couple people have mentioned confusion over this so it's likely in everyone's best interest to remove.
> 

> 

> 

> Excellent.
> 

> 

> > > Conversions:
> > >
> > 

> > > I'd like to see the library pull back on convertibility.
> > >
> > 

> > > long double ld{1.23456789234567};
> > > decimal32 d(ld); // what happens -- round, truncate, doesn't compile?
> > >
> > 

> > > The best answer is doesn't compile. There's been significant work in the
> > > standard now to define floating point rank and limit conversions with the
> > > extended floating point types. Specifically:
> > >
> > 

> > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#rank
> > >
> > 

> > 

> > That's not a terrible idea. We made them explicit and added notes in the docs that it may not do what you expect it to do. It's probably best to just remove that particular foot gun.
> 

> 

> Yep, there's too many of them for sure.
> 

> 

> > > Literals
> > >
> > 

> > > constexpr auto operator "" _DF(const char* str) -> decimal32constexpr
> > >
> > 

> > > auto operator "" _df(const char* str) -> decimal32
> > >
> > 

> > >
> > 

> > > Why not _d32, _d64, _d128? _df makes me think fast, not 32.
> > >
> > 

> > 

> > The current ones match the TR and what GCC has been doing with the _DecimalXX types.
> 

> 

> hmm, ugh right.
> 

> 

> > We will be switching a bunch of things to tables after Peter Turcan and other brought it up.
> > 

> > > In the using the library section I'd like to see some:
> > > - examples of using it it math
> > > - examples of the behavior of NAN/inf values
> > > - conversions from other types like float expanded
> > >
> > 

> > 

> > On the math one there are a couple examples with math (including binding with Boost.Math). The others we can add.
> 

> 

> Example .cpp files are good -- but in a *tutorial like form* in the docs is better.
> 

> Jeff