Re: Decimal: Formal review begins.

From: Peter Dimov (pdimov_at_[hidden])
Date: 2025-01-16 00:34:58

Matt Borland wrote:
> The name "decimal32" is occupied by the IEEE-754 compliant type. The
> naming scheme matches published standards and existing practice such as
> uint32_t vs uint_fast32_t. There's a clear statement of intent using the latter. I
> don't think people should pick decimal32 over decimal32_fast in the general
> case, but I also think it would be a bad idea to diverge from IEEE in our naming
> scheme.

Fair enough, N2849/TR 24733 do say that decimal32 occupies four octets.

(Although this gives significantly more guarantees in 24733 because you could
bit_cast the standard decimal32 to uint32_t and observe the IEEE representation,
whereas I don't think you can do that for this library's decimal32.)

However... even if we accept that the name decima32 belongs to the compact
version, shouldn't there at least be a way to implicitly convert decimal32 to
decimal32_fast? Shouldn't there be a way to (explicitly or implicitly) convert
decimal32_fast to decimal32? Or at minimum, assign decimal32_fast to
decimal32?

E.g.

void f( decimal32& x, decimal32& y )
{
    decimal32_fast x2 = x;
    decimal32_fast y2 = y;
    // do calculations here using decimal32_fast
    x = <some result of type decimal32_fast>;
    y = <some result of type decimal32_fast>;
}

Incidentally, the synopsis of decimal32_fast says

explicit constexpr operator decimal64() const noexcept;
explicit constexpr operator decimal128() const noexcept;

but this doesn't seem correct to me. It also doesn't seem to correspond
to what the source code says.

Furthermore, consider

void f( decimal32& x, decimal32& y )
{
    decimal32_fast z = x + y;
    decimal32_fast w = x - y;
    // do calculations here using decimal32_fast
    x = <some result of type decimal32_fast>;
    y = <some result of type decimal32_fast>;
}

These lines

    decimal32_fast z = x + y;
    decimal32_fast w = x - y;

still perform an unnecessary pack and unpack. Shouldn't we be worried
about that? Maybe a compiler can optimize this out, maybe it can't; I'll
need to put Decimal on Compiler Explorer somehow to check.

This can be avoided by making operator+(decimal32, decimal32) return
decimal32_fast. That's not unheard of because it's for instance what
operator+(short, short) does, but it is not what TR 24733 specifies.