Re: Decimal: Formal review begins

From: Ivan Matek (libbooze_at_[hidden])
Date: 2025-01-23 14:42:52

On Tue, Jan 21, 2025 at 8:32 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> And here's another option

Implementations of _fast type without expensive decoding of implied bits
and our discussions about ABI made me wonder...  I know authors currently
want to only implement IEEE754 so this is not directly related to review of
current library, more of a
future potential developments discussion.

Do you think there could be a benefit from additional nonIEEE754 decimal
types?
Let's use decimal64 as example.
IEEE754 does plenty of clever tricks as implied digits to pack as much data
as possible in 64 bits.
If we want to go around the performance overhead of decoding that clever
encoding we must use more than 64 bits of data. This has size issues, and
as we discussed before potential function call overhead issues.
Now what if we flip the design restrictions?
So instead of asking:
How many bytes we need to represent decimal64 so that operations are fast?
we ask:
What is the largest precision/range of values we can put inside 64 bits
while making sure operations are fast?

Here we have tradeoff: are we gonna "steal" from exponent or mantissa so
design is not clear, but does not matter hugely for general discussion
here.
For interchange this format is bad because for example C# application will
not know how to decode invented format. Now you may say that nobody will
use this because it is nonstandard(afaik IEEE754 demands multiples of
32bits encoded as they prescribe).
I think people could be convinced if the speed benefits are there. Let me
elaborate my speculation: most of the time people do not pick decimal64
because they need max values/max precision that decimal64 offers.
They pick decimal64 because they need values/precision over what decimal32
offers. This is where decimal60(or whatever the name is) would fit in.