Re: Decimal: Formal review begins.

From: Peter Dimov (pdimov_at_[hidden])
Date: 2025-01-15 19:39:49

Joaquín M López Muñoz wrote:
> > No dia 15 de jan. de 2025, Ã s 10:34, John Maddock via Boost
> <boost_at_[hidden]> escreveu:
> >
> > The review of the proposed Decimal Number library by Matt Borland and
> Chris Kormanyos begins today and runs until 22nd Jan.
> >
> > You will find documentation here:
> https://cppalliance.org/decimal/decimal.html
> 
> A small typo I spotted: s/convince header/convenience header

Some quick comments from me as well:

"The final number constructed is in the form (sign || coeff < 0 ? -1 : 1) x abs(coeff) x 10^exp."

This doesn't make much sense formatting-wise; the
"(sign || coeff < 0 ? -1 : 1) x abs(coeff) x 10^exp" part should
be formatted differently and not mix code and ad-hoc 'x'
multiplication notations.

namespace boost {
namespace decimal {

// Paragraph numbers are from ISO/IEC DTR 24733

// 3.2.2.1 construct/copy/destroy
constexpr decimal32() noexcept = default;

This doesn't compile. "class decimal32 {" is missing.

The default "decimal32" name is occupied by the storage-optimized
form and not by the operation-optimized form. I don't think this is
the right decision. The storage-optimized form should only exist in
memory, and everything else should use the operation-optimized
form.

E.g. if we have (illustrative)

decimal32 f( decimal32 a, decimal32 b )
{
    return a+b;
}

decimal32 g( decimal32 a, decimal32 b )
{
    return a*b;
}

int main()
{
    decimal32 a, b, c, d, e;
    e = f( g(a, b), g(c, d) );
}

this currently would do a few unnecessary packs and unpacks.

But if f/g take and return the operation-optimized form, these
unnecessary pack+unpack operations are avoided.

That is, if "decimal32" is the operation-optimized form, and we
have e.g. "decimal32bid" for the BID encoded form, main would
be

int main()
{
    decimal32bid a, b, c, d, e;
    e = f( g(a, b), f(c, d) );
}

So the actual storage ("at rest") is still the same, but operations
are more efficient.

Note that in this case decimal32bid has no operations, only
conversions from and to decimal32. The actual arithmetic is
always performed over the operation-optimized form.