On Tue, Jan 21, 2025 at 8:32 PM Peter Dimov via Boost
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.