On Tuesday, 4 January 2022 at 17:18:36 UTC, Guillaume wrote:
> Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
> > 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
> >> will have been melted down for metal. So is 53 bits enough? I don't
> >> write programs that deal withh amounts of money, so I don't really
> >> know. However if I had to choose a C type, I'd probably go for
> >> integer representation of amounts in cents, using a double.
> >
> > A double is nice to represent not-100%-precise fractional units,
> > it really does not have its place in any kind of financial
> > program, esp. if the goal is storing cents anyway.
> Absolutely. Using FP for financial calculations is for people who don't
> know arithmetics. Maybe teaching some math (again) to CS students would
> help, here? :)
>
> At the very least, if you absolutely want to use FP for this, at least
> use decimal FP. Although it can still have precision issues due to its
> floating point nature, at least rounding will not yield gross errors.
>
> And if you're OK with using integers, but are afraid fixed-size ones (at
> least 64 bits) could be an unacceptable limit down the road, just use
> arbitrary precision arithmetic. And you don't need to hand-implement
> that, unless it's your thing. GNU GMP is great.
>
> One of the many problems with FP can be easily shown. Apart from the
> usual unability to represent some numbers exactly, they also have an
> inherent problem when, for instance, adding very small numbers to very
> large ones.
>
> Of course if all you do is writing "toy programs", use whatever. But
> somehow, if this is a student work, I would have a problem with calling
> student exercises "toy programs". That would certainly give them the
> wrong idea about how to do things properly. If they once used FP for
> financial operations, even on a small exercise, how can you know they
> won't do the same later on at work when having to write code dealing
> with financial calculations?
>
The central difficulty is that people have no problem with the idea
that an integer type should hold an amount in cents. But for some reason
they think that a floating point type must hold an amount in dollars.
Probably because an amount of 110 cents is always written as 1.10
dollars for the end-user.

Once you make that leap, you'll see that you can use floating point types to
represent integers.

On 04/01/2022 17:18, Guillaume wrote:
> Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
>>> will have been melted down for metal. So is 53 bits enough? I don't
>>> write programs that deal withh amounts of money, so I don't really
>>> know. However if I had to choose a C type, I'd probably go for
>>> integer representation of amounts in cents, using a double.
>>
>> A double is nice to represent not-100%-precise fractional units,
>> it really does not have its place in any kind of financial
>> program, esp. if the goal is storing cents anyway.
>
> Absolutely. Using FP for financial calculations is for people who don't
> know arithmetics. Maybe teaching some math (again) to CS students would
> help, here? :)
>
> At the very least, if you absolutely want to use FP for this, at least
> use decimal FP. Although it can still have precision issues due to its
> floating point nature, at least rounding will not yield gross errors.

64-bit floating point can represent values up to c. 10 trillion dollars
to the nearest cent. (I think the limit corresponds to the 2**52 bits of
precision.)

It won't be to the exact cent if printed to many decimals, but if you
know it is supposed to represent values that end in exactly 0.00 to
0.99, then it will display properly if converted to text and rounded to
2 decimals.

So it can be used to store such values. Calculating with it is a
different matter if you are actually working with that kind of magnitude
and actually need 1-cent accuracy and reproducability (which is going to
be virtually nobody).

> And if you're OK with using integers, but are afraid fixed-size ones (at
> least 64 bits) could be an unacceptable limit down the road, just use
> arbitrary precision arithmetic. And you don't need to hand-implement
> that, unless it's your thing. GNU GMP is great.

No, it isn't. It's a massive great dependency. If you really need to use
it, look for GMP-lite (a solution using one .h and one .c file).

However to me that would be a sign of someone who doesn't know what
they're doing and just throws unnecessary precision at the problem in
the hope it will magically fix any issues.

Remember, even /decimal/ arbitrary precision integer or floating point
could implemented using just float types, by always working within the
known limitations of that type. Similarly, you can just directly work
within the known limitations of ieee754.

> One of the many problems with FP can be easily shown. Apart from the
> usual unability to represent some numbers exactly, they also have an
> inherent problem when, for instance, adding very small numbers to very
> large ones.

Can you give an example of a real-world financial calculation where that
could happen? I mean, other than adding $0.01 to $10,000,000,000,000.00
or so; just get real.

> Of course if all you do is writing "toy programs", use whatever. But
> somehow, if this is a student work, I would have a problem with calling
> student exercises "toy programs". That would certainly give them the
> wrong idea about how to do things properly. If they once used FP for
> financial operations, even on a small exercise, how can you know they
> won't do the same later on at work when having to write code dealing
> with financial calculations?

I've used floating point for financial work. The world didn't end that I
remember.

On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
> On 04/01/2022 17:18, Guillaume wrote:
> > Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
> >> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
> >>> will have been melted down for metal. So is 53 bits enough? I don't
> >>> write programs that deal withh amounts of money, so I don't really
> >>> know. However if I had to choose a C type, I'd probably go for
> >>> integer representation of amounts in cents, using a double.
> >>
> >> A double is nice to represent not-100%-precise fractional units,
> >> it really does not have its place in any kind of financial
> >> program, esp. if the goal is storing cents anyway.
> >
> > Absolutely. Using FP for financial calculations is for people who don't
> > know arithmetics. Maybe teaching some math (again) to CS students would
> > help, here? :)
> >
> > At the very least, if you absolutely want to use FP for this, at least
> > use decimal FP. Although it can still have precision issues due to its
> > floating point nature, at least rounding will not yield gross errors.
>
> 64-bit floating point can represent values up to c. 10 trillion dollars
> to the nearest cent. (I think the limit corresponds to the 2**52 bits of
> precision.)
>
53 bits. You get a "free" bit because the leading digit is always 1, except for
zero, which has a special representation.
>
> It won't be to the exact cent if printed to many decimals, but if you
> know it is supposed to represent values that end in exactly 0.00 to
> 0.99, then it will display properly if converted to text and rounded to
> 2 decimals.
>
> So it can be used to store such values. Calculating with it is a
> different matter if you are actually working with that kind of magnitude
> and actually need 1-cent accuracy and reproducability (which is going to
> be virtually nobody).
>
> > And if you're OK with using integers, but are afraid fixed-size ones (at
> > least 64 bits) could be an unacceptable limit down the road, just use
> > arbitrary precision arithmetic. And you don't need to hand-implement
> > that, unless it's your thing. GNU GMP is great.
>
> No, it isn't. It's a massive great dependency. If you really need to use
> it, look for GMP-lite (a solution using one .h and one .c file).
>
> However to me that would be a sign of someone who doesn't know what
> they're doing and just throws unnecessary precision at the problem in
> the hope it will magically fix any issues.
>
I checked a few real world financial implementations.
In Java, they have a class which can use either a 32-bit integer, a 64 bit integer,
or a "Big Decimal" as the underlying representation. The recommendation is
to use the Big Decimal. Presumably it will scale to arbitrarily values.

However Java isn't C. In C it's much harder to encapsulate an arbitrary-
sized number, pass it around, and perform calculations with it.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:

>> However to me that would be a sign of someone who doesn't know what=20
>> they're doing and just throws unnecessary precision at the problem in=20
>> the hope it will magically fix any issues.=20
>>=20
>I checked a few real world financial implementations.
>In Java, they have a class which can use either a 32-bit integer, a 64 bit =
>integer,
>or a "Big Decimal" as the underlying representation. The recommendation is
>to use the Big Decimal. Presumably it will scale to arbitrarily values.
>
>However Java isn't C. In C it's much harder to encapsulate an arbitrary-
>sized number, pass it around, and perform calculations with it.

Which is why they don't use C, and instead use COBOL and JAVA.

On Tuesday, 4 January 2022 at 19:00:57 UTC, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
> >> However to me that would be a sign of someone who doesn't know what=20
> >> they're doing and just throws unnecessary precision at the problem in=20
> >> the hope it will magically fix any issues.=20
> >>=20
> >I checked a few real world financial implementations.
> >In Java, they have a class which can use either a 32-bit integer, a 64 bit =
> >integer,
> >or a "Big Decimal" as the underlying representation. The recommendation is
> >to use the Big Decimal. Presumably it will scale to arbitrarily values.
> >
> >However Java isn't C. In C it's much harder to encapsulate an arbitrary-
> >sized number, pass it around, and perform calculations with it.
> Which is why they don't use C, and instead use COBOL and JAVA.
>
That's often the real answer. Use Cobol for programs dealing mainly
with amounts of money. That's its niche.
But sometimes you might need to use C. For instance in the software
controlling a till.

Le 04/01/2022 à 20:15, Malcolm McLean a écrit :
> On Tuesday, 4 January 2022 at 19:00:57 UTC, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
>>>> However to me that would be a sign of someone who doesn't know what=20
>>>> they're doing and just throws unnecessary precision at the problem in=20
>>>> the hope it will magically fix any issues.=20
>>>> =20
>>> I checked a few real world financial implementations.
>>> In Java, they have a class which can use either a 32-bit integer, a 64 bit =
>>> integer,
>>> or a "Big Decimal" as the underlying representation. The recommendation is
>>> to use the Big Decimal. Presumably it will scale to arbitrarily values.
>>>
>>> However Java isn't C. In C it's much harder to encapsulate an arbitrary-
>>> sized number, pass it around, and perform calculations with it.
>> Which is why they don't use C, and instead use COBOL and JAVA.
>>
> That's often the real answer. Use Cobol for programs dealing mainly
> with amounts of money. That's its niche.
> But sometimes you might need to use C. For instance in the software
> controlling a till.

As I said, there's a whole lot of arbitrary-precision libraries for C,
Gnu GMP being a good, well known and stable one.

On 04/01/2022 18:52, Malcolm McLean wrote:
> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
>> On 04/01/2022 17:18, Guillaume wrote:
>>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
>>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
>>>>> will have been melted down for metal. So is 53 bits enough? I don't
>>>>> write programs that deal withh amounts of money, so I don't really
>>>>> know. However if I had to choose a C type, I'd probably go for
>>>>> integer representation of amounts in cents, using a double.
>>>>
>>>> A double is nice to represent not-100%-precise fractional units,
>>>> it really does not have its place in any kind of financial
>>>> program, esp. if the goal is storing cents anyway.
>>>
>>> Absolutely. Using FP for financial calculations is for people who don't
>>> know arithmetics. Maybe teaching some math (again) to CS students would
>>> help, here? :)
>>>
>>> At the very least, if you absolutely want to use FP for this, at least
>>> use decimal FP. Although it can still have precision issues due to its
>>> floating point nature, at least rounding will not yield gross errors.
>>
>> 64-bit floating point can represent values up to c. 10 trillion dollars
>> to the nearest cent. (I think the limit corresponds to the 2**52 bits of
>> precision.)
>>
> 53 bits. You get a "free" bit because the leading digit is always 1, except for
> zero, which has a special representation.

If the 53rd bit is always 1, then isn't the precision determined by the
other 52 bits?

So if a mantissa was only going to be 0b10 or 0b11, to me that's only
1-bit precision!

>> It won't be to the exact cent if printed to many decimals, but if you
>> know it is supposed to represent values that end in exactly 0.00 to
>> 0.99, then it will display properly if converted to text and rounded to
>> 2 decimals.
>>
>> So it can be used to store such values. Calculating with it is a
>> different matter if you are actually working with that kind of magnitude
>> and actually need 1-cent accuracy and reproducability (which is going to
>> be virtually nobody).
>>
>>> And if you're OK with using integers, but are afraid fixed-size ones (at
>>> least 64 bits) could be an unacceptable limit down the road, just use
>>> arbitrary precision arithmetic. And you don't need to hand-implement
>>> that, unless it's your thing. GNU GMP is great.
>>
>> No, it isn't. It's a massive great dependency. If you really need to use
>> it, look for GMP-lite (a solution using one .h and one .c file).
>>
>> However to me that would be a sign of someone who doesn't know what
>> they're doing and just throws unnecessary precision at the problem in
>> the hope it will magically fix any issues.
>>
> I checked a few real world financial implementations.
> In Java, they have a class which can use either a 32-bit integer, a 64 bit integer,
> or a "Big Decimal" as the underlying representation.

32 bits doesn't sound much but it will represent up to £21m to the exact
penny. So fine for storage up to such limits, but you'd need a bigger
type to do anything beyond adding and subtracting.

> The recommendation is
> to use the Big Decimal. Presumably it will scale to arbitrarily values.

Say you have an amount of exactly EC$100.00 (a currency I've worked
with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I
believe this is the official exchange rate).

The result is US$36.8066546431594832345688100408..., it goes on forever.

To the nearest US cent, it'll be US$36.81, but it's approximate. You'd
get that result with Big Decimal, float64, or float32. Big decimal
hasn't helped here.

Bart <bc@freeuk.com> writes:
>On 04/01/2022 18:52, Malcolm McLean wrote:
>> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
>>> On 04/01/2022 17:18, Guillaume wrote:
>>>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
>>>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
>>>>>> will have been melted down for metal. So is 53 bits enough? I don't
>>>>>> write programs that deal withh amounts of money, so I don't really
>>>>>> know. However if I had to choose a C type, I'd probably go for
>>>>>> integer representation of amounts in cents, using a double.
>>>>>
>>>>> A double is nice to represent not-100%-precise fractional units,
>>>>> it really does not have its place in any kind of financial
>>>>> program, esp. if the goal is storing cents anyway.
>>>>
>>>> Absolutely. Using FP for financial calculations is for people who don't
>>>> know arithmetics. Maybe teaching some math (again) to CS students would
>>>> help, here? :)
>>>>
>>>> At the very least, if you absolutely want to use FP for this, at least
>>>> use decimal FP. Although it can still have precision issues due to its
>>>> floating point nature, at least rounding will not yield gross errors.
>>>
>>> 64-bit floating point can represent values up to c. 10 trillion dollars
>>> to the nearest cent. (I think the limit corresponds to the 2**52 bits of
>>> precision.)
>>>
>> 53 bits. You get a "free" bit because the leading digit is always 1, except for
>> zero, which has a special representation.
>
>If the 53rd bit is always 1, then isn't the precision determined by the
>other 52 bits?
>
>So if a mantissa was only going to be 0b10 or 0b11, to me that's only
>1-bit precision!
>
>>> It won't be to the exact cent if printed to many decimals, but if you
>>> know it is supposed to represent values that end in exactly 0.00 to
>>> 0.99, then it will display properly if converted to text and rounded to
>>> 2 decimals.
>>>
>>> So it can be used to store such values. Calculating with it is a
>>> different matter if you are actually working with that kind of magnitude
>>> and actually need 1-cent accuracy and reproducability (which is going to
>>> be virtually nobody).
>>>
>>>> And if you're OK with using integers, but are afraid fixed-size ones (at
>>>> least 64 bits) could be an unacceptable limit down the road, just use
>>>> arbitrary precision arithmetic. And you don't need to hand-implement
>>>> that, unless it's your thing. GNU GMP is great.
>>>
>>> No, it isn't. It's a massive great dependency. If you really need to use
>>> it, look for GMP-lite (a solution using one .h and one .c file).
>>>
>>> However to me that would be a sign of someone who doesn't know what
>>> they're doing and just throws unnecessary precision at the problem in
>>> the hope it will magically fix any issues.
>>>
>> I checked a few real world financial implementations.
>> In Java, they have a class which can use either a 32-bit integer, a 64 bit integer,
>> or a "Big Decimal" as the underlying representation.
>
>32 bits doesn't sound much but it will represent up to £21m to the exact
>penny. So fine for storage up to such limits, but you'd need a bigger
>type to do anything beyond adding and subtracting.
>
>> The recommendation is
>> to use the Big Decimal. Presumably it will scale to arbitrarily values.
>
>Say you have an amount of exactly EC$100.00 (a currency I've worked
>with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I
>believe this is the official exchange rate).
>
>The result is US$36.8066546431594832345688100408..., it goes on forever.
>
>To the nearest US cent, it'll be US$36.81, but it's approximate. You'd
>get that result with Big Decimal, float64, or float32. Big decimal
>hasn't helped here.
>

$ printf "%u\n" $(( 1000000000 / 27169 ))
36806

Round the LSD and insert a decimal point.

On 1/4/2022 10:02 PM, Bart wrote:
> On 04/01/2022 18:52, Malcolm McLean wrote:
>> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote:
>>> On 04/01/2022 17:18, Guillaume wrote:
>>>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit :
>>>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote:
>>>>>> will have been melted down for metal. So is 53 bits enough? I don't
>>>>>> write programs that deal withh amounts of money, so I don't really
>>>>>> know. However if I had to choose a C type, I'd probably go for
>>>>>> integer representation of amounts in cents, using a double.
>>>>>
>>>>> A double is nice to represent not-100%-precise fractional units,
>>>>> it really does not have its place in any kind of financial
>>>>> program, esp. if the goal is storing cents anyway.
>>>>
>>>> Absolutely. Using FP for financial calculations is for people who don't
>>>> know arithmetics. Maybe teaching some math (again) to CS students would
>>>> help, here? :)
>>>>
>>>> At the very least, if you absolutely want to use FP for this, at least
>>>> use decimal FP. Although it can still have precision issues due to its
>>>> floating point nature, at least rounding will not yield gross errors.
>>>
>>> 64-bit floating point can represent values up to c. 10 trillion dollars
>>> to the nearest cent. (I think the limit corresponds to the 2**52 bits of
>>> precision.)
>>>
>> 53 bits. You get a "free" bit because the leading digit is always 1,
>> except for
>> zero, which has a special representation.
>
> If the 53rd bit is always 1, then isn't the precision determined by the
> other 52 bits?

No, it's 53 bits of precision, or, in other words, 53 significant binary
digits.
The extra 1 bit is the result of proper choice of the exponent
representation.
However, it is not as if this extra bit came out of some magic, it has a
price and it is called subnormal numbers (or denormals).

>
> So if a mantissa was only going to be 0b10 or 0b11, to me that's only
> 1-bit precision!

No, it's not about choosing an arbitrary prefix, it is the result of 2
facts:
- any leading zeros can be converted into proper exponent adjustment, up
to the limit given by the size of the exponent.
- in binary arithmetic the first nonzero digit is always 1 :)

>
>>> It won't be to the exact cent if printed to many decimals, but if you
>>> know it is supposed to represent values that end in exactly 0.00 to
>>> 0.99, then it will display properly if converted to text and rounded to
>>> 2 decimals.
>>>
>>> So it can be used to store such values. Calculating with it is a
>>> different matter if you are actually working with that kind of magnitude
>>> and actually need 1-cent accuracy and reproducability (which is going to
>>> be virtually nobody).
>>>
>>>> And if you're OK with using integers, but are afraid fixed-size ones
>>>> (at
>>>> least 64 bits) could be an unacceptable limit down the road, just use
>>>> arbitrary precision arithmetic. And you don't need to hand-implement
>>>> that, unless it's your thing. GNU GMP is great.
>>>
>>> No, it isn't. It's a massive great dependency. If you really need to use
>>> it, look for GMP-lite (a solution using one .h and one .c file).
>>>
>>> However to me that would be a sign of someone who doesn't know what
>>> they're doing and just throws unnecessary precision at the problem in
>>> the hope it will magically fix any issues.
>>>
>> I checked a few real world financial implementations.
>> In Java, they have a class which can use either a 32-bit integer, a 64
>> bit integer,
>> or a "Big Decimal" as the underlying representation.
>
> 32 bits doesn't sound much but it will represent up to £21m to the exact
> penny. So fine for storage up to such limits, but you'd need a bigger
> type to do anything beyond adding and subtracting.
>
>> The recommendation is
>> to use the Big Decimal. Presumably it will scale to arbitrarily values.
>
> Say you have an amount of exactly EC$100.00 (a currency I've worked
> with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I
> believe this is the official exchange rate).
>
> The result is US$36.8066546431594832345688100408..., it goes on forever.
>
> To the nearest US cent, it'll be US$36.81, but it's approximate. You'd
> get that result with Big Decimal, float64, or float32. Big decimal
> hasn't helped here.
>

Rounding errors smaller than a cent in the final result are obviously OK
- they can't be helped, and such fractional difference couldn't be paid
for anyway :)
But the problem is that if you use naive FP arithmetic you may end up
with errors in the final result that are larger than a cent (sometimes
much larger), which is not OK.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The central difficulty is that people have no problem with the idea
> that an integer type should hold an amount in cents. But for some reason
> they think that a floating point type must hold an amount in dollars.
> Probably because an amount of 110 cents is always written as 1.10
> dollars for the end-user.
>
> Once you make that leap, you'll see that you can use floating point types to
> represent integers.

Or -- now hear me out -- you can use integers to represent integers.

The central difficulty is that there are rules that regulate how
financial calculations must be done. I don't know what those rules are,
but I speculate that floating-point, even if used to represent cents,
does not satisfy those rules. For anything more complicated than
addition and subtraction, there will be rounding errors that have to be
resolved *correctly*. Now if IEEE 754 floating-point happens to meet
the regulatory requirements, then that's what you should use, but I
don't think that's the case.

Doing all this stuff correctly is a solved problem. I doubt that anyone
here happens to know the details; as far as I know none of the regulars
work in finance. We're all speculating.

If someone has a reference to the actual rules used by banks and other
financial institutions, it would be interesting to see that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > The central difficulty is that people have no problem with the idea
> > that an integer type should hold an amount in cents. But for some reason
> > they think that a floating point type must hold an amount in dollars.
> > Probably because an amount of 110 cents is always written as 1.10
> > dollars for the end-user.
> >
> > Once you make that leap, you'll see that you can use floating point types to
> > represent integers.
>
> Or -- now hear me out -- you can use integers to represent integers.
>
Yes, but a floating point type degrades gracefully as values get very large.
Hyperinflation. The bit that you snipped because you were so upset by
the sly little dig at a current politician that you couldn't see the point
that was being made.
Integers don't. They work perfectly until overflow occurs. Then you get nonsense
results, or a crash if you are lucky / careful.
>
> The central difficulty is that there are rules that regulate how
> financial calculations must be done. I don't know what those rules are,
> but I speculate that floating-point, even if used to represent cents,
> does not satisfy those rules. For anything more complicated than
> addition and subtraction, there will be rounding errors that have to be
> resolved *correctly*. Now if IEEE 754 floating-point happens to meet
> the regulatory requirements, then that's what you should use, but I
> don't think that's the case.
>
I've never written a real program to deal with amounts of money either.
But I'd be surprised if a legislature mandated a particular C language type
to hold monetary values. They might describe the required behaviour of
the system. That might well be satisfied by a system with 53 bits of
precision storing numbers in cents. If 53 bits are not enough, then going
to long double would probably satisfy the legislators.
>
> Doing all this stuff correctly is a solved problem. I doubt that anyone
> here happens to know the details; as far as I know none of the regulars
> work in finance. We're all speculating.
>
I'm not sure it is. No-one here except me has posted any details of real
systems. So we've no way of knowing whether hyperinflation has been
properly considered or not. It would be interesting to get someone who
has worked on financial information systems in Zimbabwe, for instance,
to hear what they did.
>
> If someone has a reference to the actual rules used by banks and other
> financial institutions, it would be interesting to see that.
>
Agreed. None of us have any real world experience.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>[...]
>> The central difficulty is that people have no problem with the idea
>> that an integer type should hold an amount in cents. But for some reason
>> they think that a floating point type must hold an amount in dollars.
>> Probably because an amount of 110 cents is always written as 1.10
>> dollars for the end-user.
>>
>> Once you make that leap, you'll see that you can use floating point types to
>> represent integers.
>
>Or -- now hear me out -- you can use integers to represent integers.
>
>The central difficulty is that there are rules that regulate how
>financial calculations must be done. I don't know what those rules are,
>but I speculate that floating-point, even if used to represent cents,
>does not satisfy those rules. For anything more complicated than
>addition and subtraction, there will be rounding errors that have to be
>resolved *correctly*. Now if IEEE 754 floating-point happens to meet
>the regulatory requirements, then that's what you should use, but I
>don't think that's the case.

Anecdotally, the first generation Burroughs B3500 BCD machine (1966) had
100 digit signed and unsigned integer arithmetic operations
(that could be performed on either 4-bit digits or 8-bit zoned-digits)
and had a floating point (real) unit with 2 digit signed exponent and
100 digit signed mantissa.

The machine was heavily sold into banks, insurance companies and other
finance industry customers.

In the second generation B4700 the real number (floating point) support was
completely removed because no customer used it. Note this was by
definition decimal floating point.

>
>Doing all this stuff correctly is a solved problem. I doubt that anyone
>here happens to know the details; as far as I know none of the regulars
>work in finance. We're all speculating.

We had benchmarks derived from customer code for the B3500 & successors in the MCP group,
but those have long been lost to history, bit-rot and thrown out boxes
of 9-track and 18-track tapes from Iron Mountain, sadly.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>> > The central difficulty is that people have no problem with the idea
>> > that an integer type should hold an amount in cents. But for some reason
>> > they think that a floating point type must hold an amount in dollars.
>> > Probably because an amount of 110 cents is always written as 1.10
>> > dollars for the end-user.
>> >
>> > Once you make that leap, you'll see that you can use floating point types to
>> > represent integers.
>>
>> Or -- now hear me out -- you can use integers to represent integers.
>>
> Yes, but a floating point type degrades gracefully as values get very large.

You're assuming that degradation is acceptable if it's "graceful".
If you know something about the actual regulations that implies that,
by all means share it.

My speculation is that regulations require specific results to be
accurate to the cent regardless of the magnitude of the quantities being
used, and that hyperinflation would not be accepted as an excuse for
off-by-one errors. If for whatever reason we started having to deal
with quantities that don't fit in 64 bits, for example, perhaps some
software would have to be updated -- or perhaps it can already handle
such cases.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Tuesday, 4 January 2022 at 23:47:49 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> [...]
> >> > The central difficulty is that people have no problem with the idea
> >> > that an integer type should hold an amount in cents. But for some reason
> >> > they think that a floating point type must hold an amount in dollars.
> >> > Probably because an amount of 110 cents is always written as 1.10
> >> > dollars for the end-user.
> >> >
> >> > Once you make that leap, you'll see that you can use floating point types to
> >> > represent integers.
> >>
> >> Or -- now hear me out -- you can use integers to represent integers.
> >>
> > Yes, but a floating point type degrades gracefully as values get very large.
> You're assuming that degradation is acceptable if it's "graceful".
> If you know something about the actual regulations that implies that,
> by all means share it.
>
I'm assumignthat a graceful degradation is better than a sudden catastrophic
failure. As youu say, that doesn't necessarily hold. Sometimes no results
are better than slightly wrong results.
>
> My speculation is that regulations require specific results to be
> accurate to the cent regardless of the magnitude of the quantities being
> used, and that hyperinflation would not be accepted as an excuse for
> off-by-one errors. If for whatever reason we started having to deal
> with quantities that don't fit in 64 bits, for example, perhaps some
> software would have to be updated -- or perhaps it can already handle
> such cases.
>
Well let's look at what happened in Weimar Germany. A mark got up
to 4 trilion dollars. So if say that a hamburger is worth a dollar, a
hamburger in Hamburg in 1923 would have cost 4 trillion marks, or
400 trillion pfennigs. If the Germans had been using 64 bit computers
those days, you could sell about 10,000 hamburgers, by my calculations,
before the system fell over.
But if you look at the graph of the mark versus the dollar, whilst inflation
was severe, you didn't get into really startling figures until mid 1923.
For along time, it would have looked as though 64 bits were perfectly
adequate. The situation would have suddenly come on the developers.
By this time the Germans were starving and there were riots in the streets.

There would have been even worse riots if the transaction processing
system had fallen over. Would the bank have made the situation even
worse by kicking up a fuss over a few pfennigs? I wasn't there, I can't
answer that question. Where you've got that sort of social phenomenon
you don't always get a sane reaction.

But by all means argue that 53 bit or even 64 bit mantissa floating point
isn't enough and you need arbitrary-sized integers. That's a defensible
position. "Malcolm is an idiot becuase he mentioned the current
political situation" is not.