On 2021-12-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>> On 2021-12-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> [...]
>>> But it can mean dealing with thousands of dollars to the exact cent --
>>> and if you get a result of $1234.565001 and round it to $1234.57, when
>>
>> You cannot get a result of $1234.565... by only additive and subtractive
>> transactions, such as recording expenses in a ledger whose
>> denomination is pennies!
>
> I didn't say otherwise.

No, you didn't; but so then that doesn't really speak to the issue of
should the base amounts be integers or floating-point.

An integer-based system can have fractional values come up and
has to deal with them.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-12-30, Bart <bc@freeuk.com> wrote:
> On 30/12/2021 00:34, Kaz Kylheku wrote:
>> On 2021-12-29, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 29/12/2021 22:37, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>> [...]
>>>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>>>> especially in a toy program or for personal use. (I've used it for
>>>>>> accounts within a small business.)
>>>>>
>>>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>>>>
>>>>> Using floating-point for money risks, at best, rare off-by-one errors,
>>>>> such as a computation yielding a result one cent off from the correct
>>>>> value. I believe that would be considered unacceptable in any
>>>>> real-world financial application.
>>>>
>>>> Real-world doesn't need to mean dealing with trillions of dollars to the
>>>> exact cent.
>>>
>>> Real-world still uses COBOL for these type of applications.
>>>
>>>>
>>>> Most businesses work with amounts far smaller. Then I believe the
>>>> precision of float64 is enough to emulate the needed rounding methods.
>>>
>>> Why bother with the error-prone "needed rounding methods". Use uint64_t
>>> and denominate in mills.
>>
>> This common intution is incorrect. Financial systems sometimews need to
>> calculate fractional amounts, like a 15.03% tax or whatever.
>>
>> And in those situations, you may be required to implement the required
>> rounding rules: what to do when some fractional result lands halfway
>> between two pennies: which one does it go to.
>>
>> You cannot get away from rounding issues just because you used an
>> integer representation for mills or penies.
>
> The problem isn't the recommended rounding method, it's repeatability.
>
> With floating point, an intermediate result might end in .4999999993 or
> in .5000000007. If the rule is that up to exactly 0.5 rounds down, and
> anything beyond rounds up, then it can go either way.

This is fairly straightforward, actually. Suppose we are workign with
dollars and cents, and have a $0.0049999993 or $0.005000000007 result.

We do not just look at the 4 or 5 digit we look at (at least) one more
digit, and round that off first:

$0.0049... -> $0.0050 -> $0.005

$0.0050... -> $0.0050 -> $0.005

Now that we have our mill (tenth of a cent) denomination rounded off
using conventional arithmetic rounding, we then look at the tenth of a
cent digit and round to the cent.

Here we can use a specific rounding rule like Banker's for instance, if
we are so inclined:

$0.005 -> $0.00 // digit before 5 is 0, which is even, so down

This could be done with character processing: format the floating point
number to a certain number of fixed digits after the decimal point, just
letting sprintf (or whatever function) doing its built-in rounding.
Then, using the resulting decimal, implement the exact pencil-and-paper
rounding method.

Or it can all be done with just floating-point calculations.

The key point is that both of the original numbers $0.0049999993 and
$0.005000000007 are understood to be floating-point approximations
representing precisely half a cent, and with a little care we can get
the rounding to work accordingly: we can get that half a cent value
first, and then implement the required rounding to the cent.

On 30/12/2021 21:04, Kaz Kylheku wrote:
> On 2021-12-30, Bart <bc@freeuk.com> wrote:
>> On 30/12/2021 00:34, Kaz Kylheku wrote:
>>> On 2021-12-29, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 29/12/2021 22:37, Keith Thompson wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>> [...]
>>>>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>>>>> especially in a toy program or for personal use. (I've used it for
>>>>>>> accounts within a small business.)
>>>>>>
>>>>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>>>>>
>>>>>> Using floating-point for money risks, at best, rare off-by-one errors,
>>>>>> such as a computation yielding a result one cent off from the correct
>>>>>> value. I believe that would be considered unacceptable in any
>>>>>> real-world financial application.
>>>>>
>>>>> Real-world doesn't need to mean dealing with trillions of dollars to the
>>>>> exact cent.
>>>>
>>>> Real-world still uses COBOL for these type of applications.
>>>>
>>>>>
>>>>> Most businesses work with amounts far smaller. Then I believe the
>>>>> precision of float64 is enough to emulate the needed rounding methods.
>>>>
>>>> Why bother with the error-prone "needed rounding methods". Use uint64_t
>>>> and denominate in mills.
>>>
>>> This common intution is incorrect. Financial systems sometimews need to
>>> calculate fractional amounts, like a 15.03% tax or whatever.
>>>
>>> And in those situations, you may be required to implement the required
>>> rounding rules: what to do when some fractional result lands halfway
>>> between two pennies: which one does it go to.
>>>
>>> You cannot get away from rounding issues just because you used an
>>> integer representation for mills or penies.
>>
>> The problem isn't the recommended rounding method, it's repeatability.
>>
>> With floating point, an intermediate result might end in .4999999993 or
>> in .5000000007. If the rule is that up to exactly 0.5 rounds down, and
>> anything beyond rounds up, then it can go either way.
>
> This is fairly straightforward, actually. Suppose we are workign with
> dollars and cents, and have a $0.0049999993 or $0.005000000007 result.
>
> We do not just look at the 4 or 5 digit we look at (at least) one more
> digit, and round that off first:
>
> $0.0049... -> $0.0050 -> $0.005
>
> $0.0050... -> $0.0050 -> $0.005
>
> Now that we have our mill (tenth of a cent) denomination rounded off
> using conventional arithmetic rounding, we then look at the tenth of a
> cent digit and round to the cent.

I think I thought of some similar idea at one time, but I never tested
it for real, and now I'm not so sure.

For example, if instead of 4999993 and 5000007, you have 4499993 and 4500007

Now it's not so clear whether that first digit ends up as 4 or 5.

On 30/12/2021 17:16, Manfred wrote:
> On 12/30/2021 2:06 AM, Bart wrote:
>> On 30/12/2021 00:09, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> Real-world doesn't need to mean dealing with trillions of dollars to
>>>> the exact cent.
>>>
>>> But it can mean dealing with thousands of dollars to the exact cent --
>>> and if you get a result of $1234.565001 and round it to $1234.57, when
>>> the rules call for a result of $1234.56, that could be a serious
>>> problem.
>>
>> With floating point, that result could as easily be just under
>> 1234.565 as just over. If the requirements really are that binary
>> floating point must have exactly identical results, down to the least
>> significant bit, even for intermediates so that rounding will always
>> give the same results too, then that's what you have to do.
>
> Yes, and that's why standard floating point is not suitable for accurate
> accounting.
>
> IEEE 754 floating point types are designed for applications where its is
> OK to assume that all values are approximated, e.g. measurements of
> physical quantities. In this kind of environment the goal is to have
> lots of decimal digits and huge scale of representation, some
> predictable estimate of the propagation of rounding errors, and
> calculation efficiency.
> The price of not being able to represent exactly the value 1% (i.e.
> 0.01) is acceptable, even if this value is so common, as long as the
> goals above are achieved.
>
> The financial world has different requirements: they want exact results
> whenever possible, and rounding errors, when impossible to avoid, are
> thoroughly regulated.
> This is because balancing the books down to the exact cent is important
> to those guys.
> In order to achieve this, they are willing to pay some price in terms of
> representable numbers: the whole world uses monetary amounts quantified
> down to the cent (2 decimal digits). In a similar fashion, conversion
> ratios like currency exchange rates are conventionally expressed in a
> fixed amount of significant digits (I think it's 6 or 7 digits), and the
> same is likely to hold for interest rates as well. There's some upper
> limit to the largest monetary amount to handle (e.g. the global wealth),
> and so on.
> Finally, calculations need not be super fast: a monetary transaction
> involves much less computation than, say, modeling a magnetic field.
>
> All in all, it's no surprise that the financial world uses different
> data types than floating point, like e.g. the Decimal type.

Well, I have my own unlimited precision decimal floating point library.
But I would still think it a vast overkill for the mortgage calculation
exercise of the OP's.

It also doesn't magically solve all issues. You'd have problems with
exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p
or exactly 6/8d in old money), or doing any similar kind of division.

On 12/31/2021 3:20 AM, Bart wrote:
> On 30/12/2021 17:16, Manfred wrote:
>> On 12/30/2021 2:06 AM, Bart wrote:
>>> On 30/12/2021 00:09, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> Real-world doesn't need to mean dealing with trillions of dollars to
>>>>> the exact cent.
>>>>
>>>> But it can mean dealing with thousands of dollars to the exact cent --
>>>> and if you get a result of $1234.565001 and round it to $1234.57, when
>>>> the rules call for a result of $1234.56, that could be a serious
>>>> problem.
>>>
>>> With floating point, that result could as easily be just under
>>> 1234.565 as just over. If the requirements really are that binary
>>> floating point must have exactly identical results, down to the least
>>> significant bit, even for intermediates so that rounding will always
>>> give the same results too, then that's what you have to do.
>>
>> Yes, and that's why standard floating point is not suitable for
>> accurate accounting.
>>
>> IEEE 754 floating point types are designed for applications where its
>> is OK to assume that all values are approximated, e.g. measurements of
>> physical quantities. In this kind of environment the goal is to have
>> lots of decimal digits and huge scale of representation, some
>> predictable estimate of the propagation of rounding errors, and
>> calculation efficiency.
>> The price of not being able to represent exactly the value 1% (i.e.
>> 0.01) is acceptable, even if this value is so common, as long as the
>> goals above are achieved.
>>
>> The financial world has different requirements: they want exact
>> results whenever possible, and rounding errors, when impossible to
>> avoid, are thoroughly regulated.
>> This is because balancing the books down to the exact cent is
>> important to those guys.
>> In order to achieve this, they are willing to pay some price in terms
>> of representable numbers: the whole world uses monetary amounts
>> quantified down to the cent (2 decimal digits). In a similar fashion,
>> conversion ratios like currency exchange rates are conventionally
>> expressed in a fixed amount of significant digits (I think it's 6 or 7
>> digits), and the same is likely to hold for interest rates as well.
>> There's some upper limit to the largest monetary amount to handle
>> (e.g. the global wealth), and so on.
>> Finally, calculations need not be super fast: a monetary transaction
>> involves much less computation than, say, modeling a magnetic field.
>>
>> All in all, it's no surprise that the financial world uses different
>> data types than floating point, like e.g. the Decimal type.
>
> Well, I have my own unlimited precision decimal floating point library.
> But I would still think it a vast overkill for the mortgage calculation
> exercise of the OP's.

It's not really a matter of unlimited precision, see my remark above
about the amount of significant digits.

>
> It also doesn't magically solve all issues. You'd have problems with
> exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p
> or exactly 6/8d in old money), or doing any similar kind of division.

No finite arithmetic can solve these issues - whatever the base, you
will always have some divisor that yields an unrepresentable result.

But, as I said, the financial world has addressed this by limiting the
number of significant digits - decimal digits - in conversion factors. I
had this information, for international currency exchange rates, from
someone who used to make up his living writing financial software, and I
wouldn't be surprised at all if the same applied to other factors as
well, like interest rates.

I can understand that the difference between an interest rate of 1.03%
and 1.030000001% is negligible (the business manager may be perfectly
happy with a discrete choice between say 1.03% and 1.03001%), but
inexact books balancing is not, even (maybe especially) if it's about a
cent for a business worth billions.

On 12/31/2021 3:20 AM, Bart wrote:
....
> It also doesn't magically solve all issues. You'd have problems with
> exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p
> or exactly 6/8d in old money), or doing any similar kind of division.

The issue is not about accurately representing the results of all
possible divisions. It's about getting the legally mandated results.
Whenever money is involved, there's people trying to use every possible
trick to get more of it than they're actually entitled to. As a result,
regulatory agencies have gotten heavily involved in such issues,
specifying precisely how financial calculations should be performed.
I've heard from second-hand sources what kinds of requirements those
agencies have imposed, but I have not been able to locate any first-hand
sources. It hardly matters, because the detailed requirements vary from
one country to another, and even between different industries. However,
they all are based upon the same idea:

Every quantity you need to calculate must, in effect, be stored as an
integer with a scaling factor that is an integer power of 10, usually
negative. All calculations are performed as if using ordinary integer
arithmetic, with the appropriate scaling factor for the result. I say
"in effect", because on some platforms you can achieve the same result
by relying upon hardware support for decimal floating point.

The point is, if you don't use either scaled integers or decimal
floating point or something similar, you won't always round the results
of your calculation the same way as is required by the relevant
regulations. Even if it only happens rarely and only involves a tiny
amount of money, if the regulators find out they will come after you
because the fact that you calculated it incorrectly is taken as evidence
hinting that you were at least sloppy with your calculations, and at
worst, may have been trying to do something fraudulent.

On 31/12/2021 23:13, James Kuyper wrote:
> On 12/31/2021 3:20 AM, Bart wrote:
> ...
>> It also doesn't magically solve all issues. You'd have problems with
>> exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p
>> or exactly 6/8d in old money), or doing any similar kind of division.
>
> The issue is not about accurately representing the results of all
> possible divisions. It's about getting the legally mandated results.
> Whenever money is involved, there's people trying to use every possible
> trick to get more of it than they're actually entitled to. As a result,
> regulatory agencies have gotten heavily involved in such issues,
> specifying precisely how financial calculations should be performed.
> I've heard from second-hand sources what kinds of requirements those
> agencies have imposed, but I have not been able to locate any first-hand
> sources. It hardly matters, because the detailed requirements vary from
> one country to another, and even between different industries. However,
> they all are based upon the same idea:
>
> Every quantity you need to calculate must, in effect, be stored as an
> integer with a scaling factor that is an integer power of 10, usually
> negative. All calculations are performed as if using ordinary integer
> arithmetic, with the appropriate scaling factor for the result. I say
> "in effect", because on some platforms you can achieve the same result
> by relying upon hardware support for decimal floating point.
>
> The point is, if you don't use either scaled integers or decimal
> floating point or something similar, you won't always round the results
> of your calculation the same way as is required by the relevant
> regulations. Even if it only happens rarely and only involves a tiny
> amount of money, if the regulators find out they will come after you
> because the fact that you calculated it incorrectly is taken as evidence
> hinting that you were at least sloppy with your calculations, and at
> worst, may have been trying to do something fraudulent.

Then the regulators should themselves provide a library that performs
arithmetic or other calculations according to their standards.

That's if someone is working on software where this is an actual necessity.

I'm just fed up with people always bringing this up on forums when some
quantity might involve money. Those advanced requirements are heavily
dependent on application areas, and little to do with basic programming,
especially when a language doesn't provide the special types (scaled
integers etc) that might be needed.

On Friday, December 31, 2021 at 6:59:28 PM UTC-5, Bart wrote:
> On 31/12/2021 23:13, James Kuyper wrote:
....
> > The point is, if you don't use either scaled integers or decimal
> > floating point or something similar, you won't always round the results
> > of your calculation the same way as is required by the relevant
> > regulations. Even if it only happens rarely and only involves a tiny
> > amount of money, if the regulators find out they will come after you
> > because the fact that you calculated it incorrectly is taken as evidence
> > hinting that you were at least sloppy with your calculations, and at
> > worst, may have been trying to do something fraudulent.
> Then the regulators should themselves provide a library that performs
> arithmetic or other calculations according to their standards.

That's not their responsibility. And there's a large body of existing
software that does exactly what's needed. It's mostly specialized accounting
software. If you're using commercial accounting software, it probably
conforms to the relevant requirements.

> That's if someone is working on software where this is an actual necessity.

Correct. Different financial calculations are subject to different regulations,
and in many cases the relevant regulations are lenient enough to allow
people to ignore these issues. However, that's generally not the case with
mortgages.

> I'm just fed up with people always bringing this up on forums when some
> quantity might involve money. Those advanced requirements are heavily
> dependent on application areas, and little to do with basic programming,
> especially when a language doesn't provide the special types (scaled
> integers etc) that might be needed.

If you feel that way, then you should be pleased to know that _decimal32,
_decimal64, and _decimal128 are being considered for inclusion in the next
version of the C standard. There were added precisely because of these
issues.

Mortgages are heavily regulated (at least in the US, and I presume also in
most first-world countries where mortgages are even permitted). Any
calculations like the ones the OP was performing should be disclaimed as
only estimates, unless they handle the rounding of the results in the manner
required by law.

Bart <bc@freeuk.com> writes:
> On 31/12/2021 23:13, James Kuyper wrote:
>> On 12/31/2021 3:20 AM, Bart wrote:
>> ...
>>> It also doesn't magically solve all issues. You'd have problems with
>>> exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p
>>> or exactly 6/8d in old money), or doing any similar kind of division.
>> The issue is not about accurately representing the results of all
>> possible divisions. It's about getting the legally mandated results.
>> Whenever money is involved, there's people trying to use every possible
>> trick to get more of it than they're actually entitled to. As a result,
>> regulatory agencies have gotten heavily involved in such issues,
>> specifying precisely how financial calculations should be performed.
>> I've heard from second-hand sources what kinds of requirements those
>> agencies have imposed, but I have not been able to locate any first-hand
>> sources. It hardly matters, because the detailed requirements vary from
>> one country to another, and even between different industries. However,
>> they all are based upon the same idea:
>> Every quantity you need to calculate must, in effect, be stored as
>> an
>> integer with a scaling factor that is an integer power of 10, usually
>> negative. All calculations are performed as if using ordinary integer
>> arithmetic, with the appropriate scaling factor for the result. I say
>> "in effect", because on some platforms you can achieve the same result
>> by relying upon hardware support for decimal floating point.
>> The point is, if you don't use either scaled integers or decimal
>> floating point or something similar, you won't always round the results
>> of your calculation the same way as is required by the relevant
>> regulations. Even if it only happens rarely and only involves a tiny
>> amount of money, if the regulators find out they will come after you
>> because the fact that you calculated it incorrectly is taken as evidence
>> hinting that you were at least sloppy with your calculations, and at
>> worst, may have been trying to do something fraudulent.
>
> Then the regulators should themselves provide a library that performs
> arithmetic or other calculations according to their standards.

Are you sure they don't? I'm not.

And if they don't -- is the ISO C committee obligated to provide a
conforming C implementation?

It's not my field and I don't know the details. Unlike you, I admit that.

> That's if someone is working on software where this is an actual necessity.
>
> I'm just fed up with people always bringing this up on forums when
> some quantity might involve money. Those advanced requirements are
> heavily dependent on application areas, and little to do with basic
> programming, especially when a language doesn't provide the special
> types (scaled integers etc) that might be needed.

As several of us have acknowledged, using floating-point for money is
probably fine for toy or introductory programs. It's not ok for any
application that interacts with financial regulations. And I'm fed up
with you whining when anyone points that out.

--
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 01/01/2022 00:35, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 31/12/2021 23:13, James Kuyper wrote:

>> Then the regulators should themselves provide a library that performs
>> arithmetic or other calculations according to their standards.
>
> Are you sure they don't? I'm not.

If they do then you use that and be done with it. But it's little to
with learning to program.

> And if they don't -- is the ISO C committee obligated to provide a
> conforming C implementation?
>
> It's not my field and I don't know the details. Unlike you, I admit that.
>
>> That's if someone is working on software where this is an actual necessity.
>>
>> I'm just fed up with people always bringing this up on forums when
>> some quantity might involve money. Those advanced requirements are
>> heavily dependent on application areas, and little to do with basic
>> programming, especially when a language doesn't provide the special
>> types (scaled integers etc) that might be needed.
>
> As several of us have acknowledged, using floating-point for money is
> probably fine for toy or introductory programs. It's not ok for any
> application that interacts with financial regulations. And I'm fed up
> with you whining when anyone points that out.

I'm sure that many other industries have their own standards and their
own requirements when it comes to numbers representing values relevant
to their fields.

But no, it's always the ones representing money!

As a matter of interest (no pun!), if you were writing some program in
C, to do say stock reports on sales in your shop (so it's not exactly a
toy, and you're not a beginner), what type would you use for those
monetary amounts?

Say the info is input from CSV file for example.

Bart <bc@freeuk.com> writes:
> On 01/01/2022 00:35, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/12/2021 23:13, James Kuyper wrote:
>
>>> Then the regulators should themselves provide a library that performs
>>> arithmetic or other calculations according to their standards.
>> Are you sure they don't? I'm not.
>
> If they do then you use that and be done with it. But it's little to
> with learning to program.
>
>> And if they don't -- is the ISO C committee obligated to provide a
>> conforming C implementation?
>> It's not my field and I don't know the details. Unlike you, I admit
>> that.
>>
>>> That's if someone is working on software where this is an actual necessity.
>>>
>>> I'm just fed up with people always bringing this up on forums when
>>> some quantity might involve money. Those advanced requirements are
>>> heavily dependent on application areas, and little to do with basic
>>> programming, especially when a language doesn't provide the special
>>> types (scaled integers etc) that might be needed.
>> As several of us have acknowledged, using floating-point for money
>> is
>> probably fine for toy or introductory programs. It's not ok for any
>> application that interacts with financial regulations. And I'm fed up
>> with you whining when anyone points that out.
>
> I'm sure that many other industries have their own standards and their
> own requirements when it comes to numbers representing values relevant
> to their fields.
>
> But no, it's always the ones representing money!

That seems to be what comes up most often here.

Somebody asks about what's probably a student-level program that deals
with money. Somebody else mentions that there are rules in place that
have to be followed if you're dealing with money in a professional
context. I think that's a good thing to be aware of even if you don't
have to deal with all the issues directly.

It's an example, one among many, of an area where the inexactness of
floating-point calculations can cause problems -- and that's something
that most programmers need to be aware of.

And then you tell us you're "fed up" with it being mentioned. Too bad.

> As a matter of interest (no pun!), if you were writing some program in
> C, to do say stock reports on sales in your shop (so it's not exactly
> a toy, and you're not a beginner), what type would you use for those
> monetary amounts?
>
> Say the info is input from CSV file for example.

I don't know. If all I have to worry about is adding and subtracting
quantities that are always whole numbers of cents, I'd probably use a
sufficiently wide integer type with a scale factor of 100. If I had to
deal with computations that can yield fractional cents, I'd find out
what the detailed requirements are, and ask what libraries are available
to help implement those requirements.

--
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 Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> > On 01/01/2022 00:35, Keith Thompson wrote:
> >> Bart <b...@freeuk.com> writes:
> >>> On 31/12/2021 23:13, James Kuyper wrote:
> >
> >>> Then the regulators should themselves provide a library that performs
> >>> arithmetic or other calculations according to their standards.
> >> Are you sure they don't? I'm not.
> >
> > If they do then you use that and be done with it. But it's little to
> > with learning to program.
> >
> >> And if they don't -- is the ISO C committee obligated to provide a
> >> conforming C implementation?
> >> It's not my field and I don't know the details. Unlike you, I admit
> >> that.
> >>
> >>> That's if someone is working on software where this is an actual necessity.
> >>>
> >>> I'm just fed up with people always bringing this up on forums when
> >>> some quantity might involve money. Those advanced requirements are
> >>> heavily dependent on application areas, and little to do with basic
> >>> programming, especially when a language doesn't provide the special
> >>> types (scaled integers etc) that might be needed.
> >> As several of us have acknowledged, using floating-point for money
> >> is
> >> probably fine for toy or introductory programs. It's not ok for any
> >> application that interacts with financial regulations. And I'm fed up
> >> with you whining when anyone points that out.
> >
> > I'm sure that many other industries have their own standards and their
> > own requirements when it comes to numbers representing values relevant
> > to their fields.
> >
> > But no, it's always the ones representing money!
> That seems to be what comes up most often here.
>
> Somebody asks about what's probably a student-level program that deals
> with money. Somebody else mentions that there are rules in place that
> have to be followed if you're dealing with money in a professional
> context. I think that's a good thing to be aware of even if you don't
> have to deal with all the issues directly.
>
> It's an example, one among many, of an area where the inexactness of
> floating-point calculations can cause problems -- and that's something
> that most programmers need to be aware of.
>
> And then you tell us you're "fed up" with it being mentioned. Too bad.
> > As a matter of interest (no pun!), if you were writing some program in
> > C, to do say stock reports on sales in your shop (so it's not exactly
> > a toy, and you're not a beginner), what type would you use for those
> > monetary amounts?
> >
> > Say the info is input from CSV file for example.
> I don't know. If all I have to worry about is adding and subtracting
> quantities that are always whole numbers of cents, I'd probably use a
> sufficiently wide integer type with a scale factor of 100. If I had to
> deal with computations that can yield fractional cents, I'd find out
> what the detailed requirements are, and ask what libraries are available
> to help implement those requirements.
>
Why not use a double, and represent the amount in cents? That gives you
53 bits. However if Biden's stimulus package goes through and the USA
experiences hyperinflation, then the program will scale to sausages
costing quadrillions of dollars - people won't worry about small errors
in the cents under such circumstances. And if you need to represent a
fractional number of cents, you can still do that, admittedly with some
issues, but without knowing the exact rules and circumstances under
which fractions of cents can be created, it's impossible to get away from
those issues.

On 01/01/2022 04:22, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/01/2022 00:35, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 31/12/2021 23:13, James Kuyper wrote:
>>
>>>> Then the regulators should themselves provide a library that performs
>>>> arithmetic or other calculations according to their standards.
>>> Are you sure they don't? I'm not.
>>
>> If they do then you use that and be done with it. But it's little to
>> with learning to program.
>>
>>> And if they don't -- is the ISO C committee obligated to provide a
>>> conforming C implementation?
>>> It's not my field and I don't know the details. Unlike you, I admit
>>> that.
>>>
>>>> That's if someone is working on software where this is an actual necessity.
>>>>
>>>> I'm just fed up with people always bringing this up on forums when
>>>> some quantity might involve money. Those advanced requirements are
>>>> heavily dependent on application areas, and little to do with basic
>>>> programming, especially when a language doesn't provide the special
>>>> types (scaled integers etc) that might be needed.
>>> As several of us have acknowledged, using floating-point for money
>>> is
>>> probably fine for toy or introductory programs. It's not ok for any
>>> application that interacts with financial regulations. And I'm fed up
>>> with you whining when anyone points that out.
>>
>> I'm sure that many other industries have their own standards and their
>> own requirements when it comes to numbers representing values relevant
>> to their fields.
>>
>> But no, it's always the ones representing money!
>
> That seems to be what comes up most often here.
>
> Somebody asks about what's probably a student-level program that deals
> with money. Somebody else mentions that there are rules in place that
> have to be followed if you're dealing with money in a professional
> context. I think that's a good thing to be aware of even if you don't
> have to deal with all the issues directly.
>
> It's an example, one among many, of an area where the inexactness of
> floating-point calculations can cause problems -- and that's something
> that most programmers need to be aware of.
>
> And then you tell us you're "fed up" with it being mentioned. Too bad.

No, I'm fed up with it being a deal-breaker. OK, here it was one point
many, but still, AT specifically said:

'Stop using "regular" floating point types for representing monetary
quantities. They are not good for that purpose.'

I probably do most such calculations on my Casio; that doesn't have a
special type either.

>> As a matter of interest (no pun!), if you were writing some program in
>> C, to do say stock reports on sales in your shop (so it's not exactly
>> a toy, and you're not a beginner), what type would you use for those
>> monetary amounts?
>>
>> Say the info is input from CSV file for example.
>
> I don't know. If all I have to worry about is adding and subtracting
> quantities that are always whole numbers of cents, I'd probably use a
> sufficiently wide integer type with a scale factor of 100. If I had to
> deal with computations that can yield fractional cents, I'd find out
> what the detailed requirements are, and ask what libraries are available
> to help implement those requirements.

It's for your personal use to help in managing your shop. No officialdom
is involved.

Yes, you'd probably use doubles representing dollar amounts (not cents),
display results to 2 decimals, and perhaps round intermediate results to
two decimals.

On 29/12/2021 19:33, Andrey Tarasevich wrote:
> On 12/29/2021 9:49 AM, Bart wrote:

>> 2) Nothing wrong with using 'float' when it's appropropriate. Many
>> libraries eg. OpenGL make extensive use of float.
>
> That's just emphasizes my the point. The main purpose of "small" types,
> like `float`, `short`, char as plain integer, bit-fields etc. is to save
> memory in quantitatively massive data structures.
>
> That's exactly what OpenGL is intended to work with: massive amounts of
> geometric data. That's why it opts for `float` Everything else is just a
> consequence of that.

It has to give acceptable results. Presumably float's accuracy is
sufficient for that. Using less memory, and being somewhat faster, are
bonuses.

>> and in one place for quick reference.
>
> Piling up all variable declarations in one place makes for much slower
> reference: first, one has has to find the pile, then one has to sift
> through the pile.
>
> Local declarations are always instantly visible,

That's the problem! If trying to appreciate the algorithm, the types and
attributes of the variables are secondary.

Also, the type is only applied to the first occurence. You see
'interest' being used on a subsequent; what type is it? You glance at
the top of the function - it's not there! You have to scan backwards
from where you are until you encounter a matching declaration.

But then, if 'interest' /was/ declared at the top, now you are wasting
type doing that scan.

(This is a simple program. Have a look at something like the amalgmated
source file of sqlite3.c, where they really take your style on board.

You also have to contend with names with appear identical but have
subtle differences, or the same name declared more than once in the same
function. If you miss the first declaration on that backwards scan, you
may end up at the wrong one.

Look at the two declarations of pKeyInfo in this extract:

if( pPart || pOrderBy ){
int nPart = (pPart ? pPart->nExpr : 0);
int addrGoto = 0;
int addrJump = 0;
int nPeer = (pOrderBy ? pOrderBy->nExpr : 0);

if( pPart ){
int regNewPart = reg + pMWin->nBufferCol;
KeyInfo *pKeyInfo = sqlite3KeyInfoFromExprList(pParse, pPart, 0, 0);
addr = sqlite3VdbeAddOp3(v, OP_Compare, regNewPart,
pMWin->regPart,nPart);
sqlite3VdbeAppendP4(v, (void*)pKeyInfo, P4_KEYINFO);
addrJump = sqlite3VdbeAddOp3(v, OP_Jump, addr+2, 0, addr+2);
VdbeCoverageEqNe(v);
windowAggFinal(pParse, pMWin, 1);
if( pOrderBy ){
addrGoto = sqlite3VdbeAddOp0(v, OP_Goto);
}
}

if( pOrderBy ){
int regNewPeer = reg + pMWin->nBufferCol + nPart;
int regPeer = pMWin->regPart + nPart;

if( addrJump ) sqlite3VdbeJumpHere(v, addrJump);
if( pMWin->eType==TK_RANGE ){
KeyInfo *pKeyInfo = sqlite3KeyInfoFromExprList(pParse,
pOrderBy, 0, 0);
addr = sqlite3VdbeAddOp3(v, OP_Compare, regNewPeer, regPeer,
nPeer);
sqlite3VdbeAppendP4(v, (void*)pKeyInfo, P4_KEYINFO);
addrJump = sqlite3VdbeAddOp3(v, OP_Jump, addr+2, 0, addr+2);
VdbeCoverage(v);
}else{
addrJump = 0;
}
windowAggFinal(pParse, pMWin, pMWin->eStart==TK_CURRENT);
if( addrGoto ) sqlite3VdbeJumpHere(v, addrGoto);
}

Note that I've helped you by isolating the lines with both declarations,
but some functions are considerably longer, such as one of 750 lines
with 3 versions of "pPk".

Yet another delight is a 7000-line function, which uses names such as
"pcx" and "pCx" (with different types), or "pVtab" (of type sqlite_vtab)
and "pVTab" (of type VTABLE!).

All the 300+ locals in this function are listed below. Not all identical
names have the same type (eg. 'len' exists as 'long' and also 'int').

If all were listed at the top, there would necessarily be fewer as you
couldn't have duplicates (some will be labels), but if sorted like this
must surely be easier to find than scanning 7000 lines of dense code.

----------------------------------------------

(Sorry the types are not in proper C syntax. Names with void types are
labels.)

abort_due_to_error void
abort_due_to_interrupt void
aEQb [6]const uchar
affinity schar
aFlag [2]const ushort
aGTb [6]const uchar
alreadyExists int
aLTb [6]const uchar
aMem ref struct sqlite3_value
and_logic [9]const uchar
aOffset ref uint
aOp ref struct VdbeOp
apArg ref ref struct sqlite3_value
apArg ref ref struct sqlite3_value
aPermute ref int
aRes [3]int
arithmetic_result_is_null void
aRoot ref int
aZero [16]uchar
azType [4]const ref const schar
bIntint schar
bRev int
c int
c int
check_for_interrupt void
cnt int
cnt int
compare_op void
Compiling sqlite3.c to sqlite3.exe
db ref struct sqlite3
desiredAutoCommit int
encoding uchar
eNew int
eOld int
eqOnly int
exists int
file_format int
flags ushort
flags1 ushort
flags3 ushort
fp_math void
i int
i int
i int
i int
i int
i int
i int
i int
i int
i int
iA llong
iA llong
iAddr uint
iB llong
iB llong
iCompare int
iCookie int
iDb int
iDb int
iDb int
iDb int
idx int
ii int
ii int
iKey llong
iKey ullong
iMeta int
iMeta int
iMoved int
initData struct (ref struct sqlite3 db,ref ref
schar pzErrMsg,int iDb,int rc,uint mInitFlags)
iPrior uint
iQuery int
iRollback int
iSavepoint int
iSet int
isLegacy int
isNotInt int
isSchemaChange int
isTransaction int
isWriteLock uchar
j int
jump_to_p2 void
jump_to_p2_and_check_for_interrupt void
len int
len uint
n int
n int
n int
n int
n int
n uint
nArg int
nArg int
nByte int
nByte llong
nByte llong
nChange int
nData ullong
nEntry llong
nErr int
newMax uint
next_tail void
nField int
nField int
nField int
nHdr int
nKeyCol int
nMem int
nName int
no_mem void
nProgressLimit uint
nRoot int
nullFlag ushort
nVarint int
nVmStep uint
nZero llong
oc int
offset64 ullong
On line: 140
op uchar
op_column_corrupt void
op_column_out void
op_column_read_header void
open_cursor_set_hints void
opflags int
or_logic [9]const uchar
origFlags ushort
p ref struct Vdbe
p1 int
p1 int
p1 int
p1 int
p2 int
p2 int
p2 int
p2 int
pArgc ref struct sqlite3_value
pBt ref struct Btree
pBt ref struct Btree
pBt ref struct Btree
pBt ref struct Btree
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pC ref struct VdbeCursor
pCaller ref struct VdbeOp
pcDest int
pColl ref struct CollSeq
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCrsr ref struct BtCursor
pCtx ref struct sqlite3_context
pCtx ref struct sqlite3_context
pCtx ref struct sqlite3_context
pCtx ref struct sqlite3_context
pCur ref struct VdbeCursor
pCur ref struct VdbeCursor
pCur ref struct VdbeCursor
pCur ref struct VdbeCursor
pCur ref struct VdbeCursor
pcx int
pCx ref struct VdbeCursor
pCx ref struct VdbeCursor
pCx ref struct VdbeCursor
pCx ref struct VdbeCursor
pData ref struct sqlite3_value
pData0 ref struct sqlite3_value
pDb ref struct Db
pDb ref struct Db
pDb ref struct Db
pDest ref struct sqlite3_value
pDest ref struct sqlite3_value
pEnd ref struct sqlite3_value
pFrame ref struct VdbeFrame
pFrame ref struct VdbeFrame
pFrame ref struct VdbeFrame
pFrame ref struct VdbeFrame
pFrame ref struct VdbeFrame
pFree ref struct UnpackedRecord
pgno int
pgno int
pIdxKey ref struct UnpackedRecord
pIn ref struct sqlite3_value
pIn1 ref struct sqlite3_value
pIn2 ref struct sqlite3_value
pIn3 ref struct sqlite3_value
pKey ref struct sqlite3_value
pKeyInfo ref struct KeyInfo
pKeyInfo ref struct KeyInfo
pKeyInfo ref struct KeyInfo
pLast ref struct sqlite3_value
pMem ref struct sqlite3_value
pMem ref struct sqlite3_value
pMem ref struct sqlite3_value
pMem ref struct sqlite3_value
pMem ref struct sqlite3_value
pMem ref struct sqlite3_value
pModule ref struct sqlite3_module
pModule ref struct sqlite3_module
pModule ref struct sqlite3_module
pModule ref struct sqlite3_module
pModule ref struct sqlite3_module
pModule ref struct sqlite3_module
pName ref struct sqlite3_value
pnErr ref struct sqlite3_value
pNew ref struct Savepoint
pOp ref struct VdbeOp
pOrig ref struct VdbeCursor
pOut ref struct sqlite3_value
pPager ref struct Pager
pProgram ref struct SubProgram
pQuery ref struct sqlite3_value
pRec ref struct sqlite3_value
pReg ref struct sqlite3_value
pRt ref struct sqlite3_value
pSavepoint ref struct Savepoint
pTab ref struct Table
pTab ref struct Table
pTabCur ref struct VdbeCursor
pTmp ref struct Savepoint
pVar ref struct sqlite3_value
pVCur ref struct sqlite3_vtab_cursor
pVCur ref struct sqlite3_vtab_cursor
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVtab ref struct sqlite3_vtab
pVTab ref struct VTable
pX ref struct Btree
pX ref struct sqlite3_value
r struct (ref struct KeyInfo pKeyInfo,ref
struct sqlite3_value aMem,ushort nField,schar default_rc,uchar
errCode,schar r1,schar r2,uchar eqSeen)
r struct (ref struct KeyInfo pKeyInfo,ref
struct sqlite3_value aMem,ushort nField,schar default_rc,uchar
errCode,schar r1,schar r2,uchar eqSeen)
r struct (ref struct KeyInfo pKeyInfo,ref
struct sqlite3_value aMem,ushort nField,schar default_rc,uchar
errCode,schar r1,schar r2,uchar eqSeen)
r struct (ref struct KeyInfo pKeyInfo,ref
struct sqlite3_value aMem,ushort nField,schar default_rc,uchar
errCode,schar r1,schar r2,uchar eqSeen)
rA double
rB double
rc int
res int
res int
res int
res int
res int
res int
res int
res int
res int
res int
res int
res int
res int
res2 int
resetSchemaOnFault uchar
rowid llong
rowid llong
sContext struct (ref struct sqlite3_value pOut,ref
struct FuncDef pFunc,ref struct sqlite3_value pMem,ref struct Vdbe
pVdbe,int iOp,int isError,uchar skipFlag,uchar argc,[1]ref struct
sqlite3_value argv)
seek_not_found void
seekResult int
serial_type uint
sMem struct (union MemValue u,ushort
flags,uchar enc,uchar eSubtype,int n,ref schar z,ref schar zMalloc,int
szMalloc,uint uTemp,ref struct sqlite3 db,ref proc(ref void)void xDel)
sMem struct (union MemValue u,ushort
flags,uchar enc,uchar eSubtype,int n,ref schar z,ref schar zMalloc,int
szMalloc,uint uTemp,ref struct sqlite3 db,ref proc(ref void)void xDel)
sz llong
t ref void
t uint
takeJump int
too_big void
type1 ushort
type2 ushort
uA ullong
v llong
v llong
v1 int
v2 int
val llong
vdbe_return void
vfsFlags const int
vtabOnConflict uchar
wrFlag int
x llong
x ref proc(ref void,ref const schar)void
x struct (ref const void pKey,llong
nKey,ref const void pData,ref struct sqlite3_value aMem,ushort nMem,int
nData,int nZero)
x struct (ref const void pKey,llong
nKey,ref const void pData,ref struct sqlite3_value aMem,ushort nMem,int
nData,int nZero)
z ref const schar
z ref schar
z ref schar
z ref schar
zAffinity ref const schar
zAffinity ref schar
zData ref const uchar
zDb ref const schar
zDb ref const schar
zEndHdr ref const uchar
zFilename ref const schar
zHdr ref const uchar
zMaster ref const schar
zName ref schar
zNewRecord ref uchar
zSql ref schar
zTab ref const schar
zTrace ref schar

On 01/01/2022 18:19, Bart wrote:
> On 29/12/2021 19:33, Andrey Tarasevich wrote:

>> Local declarations are always instantly visible,

[Summary of local variables from a giant sqlite3.c function]

> nByte                          int
> nByte                          llong
> nByte                          llong

Don't get caught out!

> nField                         int
> nField                         int
> nField                         int

> p1                             int
> p1                             int
> p1                             int
> p1                             int

> pBt                            ref struct Btree
> pBt                            ref struct Btree
> pBt                            ref struct Btree
> pBt                            ref struct Btree

> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor
> pC                             ref struct VdbeCursor

> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor
> pCrsr                          ref struct BtCursor

> pFrame                         ref struct VdbeFrame
> pFrame                         ref struct VdbeFrame
> pFrame                         ref struct VdbeFrame
> pFrame                         ref struct VdbeFrame
> pFrame                         ref struct VdbeFrame

> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res                            int
> res2                           int

The above sets of identical names highlight other problems with local
declarations. Take the 24 versions of 'pC', with struct VdbeFrame*;
suppose the type needed to change; now you have to change 24 versions of it.

But, you won't know there are 24 versions; you will need to hunt them
down. Maybe some of the 24 are unrelated in use, and need to stay the
same type. But the function has mixed them all up in the same way that
all instances of a literal '1200' can be mixed up in a program.

> x                              llong
> x                              ref proc(ref void,ref const schar)void
> x                              struct (ref const void pKey,llong

I haven't analysed how these names relate to each within the block
structure. But suppose the x's are in nested blocks, and one declaration
is missed out. That one may be shadowing an outer 'x' - of the wrong
type. With luck, its used will cause a type error, but if not...

> nKey,ref const void pData,ref struct sqlite3_value aMem,ushort nMem,int
> nData,int nZero)
> x                              struct (ref const void pKey,llong
> nKey,ref const void pData,ref struct sqlite3_value aMem,ushort nMem,int
> nData,int nZero)

> z                              ref const schar
> z                              ref schar
> z                              ref schar
> z                              ref schar

.... or it ends up with a version that has a missing 'const'. Even when
they're all the same type, you could end writing or reading into the
wrong variable.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
[...]
>> I don't know. If all I have to worry about is adding and subtracting
>> quantities that are always whole numbers of cents, I'd probably use a
>> sufficiently wide integer type with a scale factor of 100. If I had to
>> deal with computations that can yield fractional cents, I'd find out
>> what the detailed requirements are, and ask what libraries are available
>> to help implement those requirements.
>>
> Why not use a double, and represent the amount in cents? That gives you
> 53 bits.

Why? long long gives you 63 bits. When floating-point gives you inexact
results, it does so silently. What advantage does double give you over
long long?

[politics deleted]
> And if you need to represent a
> fractional number of cents, you can still do that, admittedly with some
> issues, but without knowing the exact rules and circumstances under
> which fractions of cents can be created, it's impossible to get away from
> those issues.

Which is why you need to follow the relevant rules, which means you need
to find out what they are before you start writing code.

--
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 Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
> [...]
> >> I don't know. If all I have to worry about is adding and subtracting
> >> quantities that are always whole numbers of cents, I'd probably use a
> >> sufficiently wide integer type with a scale factor of 100. If I had to
> >> deal with computations that can yield fractional cents, I'd find out
> >> what the detailed requirements are, and ask what libraries are available
> >> to help implement those requirements.
> >>
> > Why not use a double, and represent the amount in cents? That gives you
> > 53 bits.
> Why? long long gives you 63 bits. When floating-point gives you inexact
> results, it does so silently. What advantage does double give you over
> long long?
>
> [politics deleted]
>
You've deleted the reason. Which is inherently political.
Some crazy politican decides to do what is called "monetary financing",
basically printing money rather than collecting taxes. Result, runaway
inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can
no longer cope (for a decent-sized burger joint). Floating point however
degrades gracefully until you hit figures so high that even hyperinflation
is unlikely to reach them.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
>> [...]
>> >> I don't know. If all I have to worry about is adding and subtracting
>> >> quantities that are always whole numbers of cents, I'd probably use a
>> >> sufficiently wide integer type with a scale factor of 100. If I had to
>> >> deal with computations that can yield fractional cents, I'd find out
>> >> what the detailed requirements are, and ask what libraries are available
>> >> to help implement those requirements.
>> >>
>> > Why not use a double, and represent the amount in cents? That gives you
>> > 53 bits.
>> Why? long long gives you 63 bits. When floating-point gives you inexact
>> results, it does so silently. What advantage does double give you over
>> long long?
>>
>> [politics deleted]
>>
> You've deleted the reason. Which is inherently political.
> Some crazy politican decides to do what is called "monetary financing",
> basically printing money rather than collecting taxes. Result, runaway
> inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can
> no longer cope (for a decent-sized burger joint). Floating point however
> degrades gracefully until you hit figures so high that even hyperinflation
> is unlikely to reach them.

If you're operating under regulations that say that "degrading
gracefully" is acceptable, you can use floating-point.

I won't discuss politics here.

--
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 */

2022-01-02 at 17:22 -0800, Malcolm McLean wrote:
> Result, runaway inflation, and a hamburger costs 4 quadrillion
> dollars. 63 bits can no longer cope (for a decent-sized burger
> joint). Floating point however degrades gracefully until you hit
> figures so high that even hyperinflation is unlikely to reach them.

The scenario that you describe is nothing that we haven't seen already.
The solution is to reevaluate the currency. We (Poles) did it in 1995
with a ratio of 1000:1, ie. 1000 old złotys (1000 PLZ) became one new
złoty (1 PLN). The French did something similar in 1960, where 100 old
francs became 1 new franc.

Shortly said, this is not a technical problem, and even if it was, then
it is not up to the programmer to decide if degrading currency is
acceptable or not, national banks issue strict regulations about how
things should be done in such occasion. In other words, bringing the
subject up in a technical group does not make any sense.

Mateusz

On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
> >> [...]
> >> >> I don't know. If all I have to worry about is adding and subtracting
> >> >> quantities that are always whole numbers of cents, I'd probably use a
> >> >> sufficiently wide integer type with a scale factor of 100. If I had to
> >> >> deal with computations that can yield fractional cents, I'd find out
> >> >> what the detailed requirements are, and ask what libraries are available
> >> >> to help implement those requirements.
> >> >>
> >> > Why not use a double, and represent the amount in cents? That gives you
> >> > 53 bits.
> >> Why? long long gives you 63 bits. When floating-point gives you inexact
> >> results, it does so silently. What advantage does double give you over
> >> long long?
> >>
> >> [politics deleted]
> >>
> > You've deleted the reason. Which is inherently political.
> > Some crazy politican decides to do what is called "monetary financing",
> > basically printing money rather than collecting taxes. Result, runaway
> > inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can
> > no longer cope (for a decent-sized burger joint). Floating point however
> > degrades gracefully until you hit figures so high that even hyperinflation
> > is unlikely to reach them.
> If you're operating under regulations that say that "degrading
> gracefully" is acceptable, you can use floating-point.
>
> I won't discuss politics here.
>
When hamburgers cost 4 quadrillion dollars, it's likely that everyone has more
to worry about than financial software rounding errors of a few cents.
However at least the system still works after a fashion. Systems using fixed
point will fall over, compounding the social chaos.

On Monday, 3 January 2022 at 08:22:46 UTC, Mateusz Viste wrote:
> 2022-01-02 at 17:22 -0800, Malcolm McLean wrote:
> > Result, runaway inflation, and a hamburger costs 4 quadrillion
> > dollars. 63 bits can no longer cope (for a decent-sized burger
> > joint). Floating point however degrades gracefully until you hit
> > figures so high that even hyperinflation is unlikely to reach them.
> The scenario that you describe is nothing that we haven't seen already.
> The solution is to reevaluate the currency. We (Poles) did it in 1995
> with a ratio of 1000:1, ie. 1000 old złotys (1000 PLZ) became one new
> złoty (1 PLN). The French did something similar in 1960, where 100 old
> francs became 1 new franc.
>
> Shortly said, this is not a technical problem, and even if it was, then
> it is not up to the programmer to decide if degrading currency is
> acceptable or not, national banks issue strict regulations about how
> things should be done in such occasion. In other words, bringing the
> subject up in a technical group does not make any sense.
>
It happened it Weimar Germany. 4 trillion marks to the dollar. But that was
before computerisation. We haven't had hyperinflation in an advanced major
economy since, but there's a real risk of it now with current policies being
pursued in the United States.
The authorities might issue strict instructions on what is to be done as
fixed point system fail to cope and the electronic accounting and transaction
clearing system starts to fall over. But it will make Y2K look like a trivial problem.

Much better to have a system that works after a fashion without needing to
be re-programmed.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

>When hamburgers cost 4 quadrillion dollars,

Leave out of this group the absurdist political rhetoric, please.

On 03/01/2022 12:30, Malcolm McLean wrote:
> On Monday, 3 January 2022 at 08:22:46 UTC, Mateusz Viste wrote:
>> 2022-01-02 at 17:22 -0800, Malcolm McLean wrote:
>>> Result, runaway inflation, and a hamburger costs 4 quadrillion
>>> dollars. 63 bits can no longer cope (for a decent-sized burger
>>> joint). Floating point however degrades gracefully until you hit
>>> figures so high that even hyperinflation is unlikely to reach them.
>> The scenario that you describe is nothing that we haven't seen already.
>> The solution is to reevaluate the currency. We (Poles) did it in 1995
>> with a ratio of 1000:1, ie. 1000 old złotys (1000 PLZ) became one new
>> złoty (1 PLN). The French did something similar in 1960, where 100 old
>> francs became 1 new franc.
>>
>> Shortly said, this is not a technical problem, and even if it was, then
>> it is not up to the programmer to decide if degrading currency is
>> acceptable or not, national banks issue strict regulations about how
>> things should be done in such occasion. In other words, bringing the
>> subject up in a technical group does not make any sense.
>>
> It happened it Weimar Germany. 4 trillion marks to the dollar. But that was
> before computerisation. We haven't had hyperinflation in an advanced major

It is one thing to bring up real-world historical examples of when large
numbers were needed to hold currency values - it shows that small ranged
types may not be sufficient (although I hope most people here are
sufficiently well-educated to know that hyperinflation has occurred).

But please drop the politics. If you want to discuss fiscal policy in
some country, I am sure there are newsgroups suited to that. But unless
some politician is trying to influence the C programming language, it is
off-topic here.

On Monday, 3 January 2022 at 16:22:49 UTC, David Brown wrote:
> On 03/01/2022 12:30, Malcolm McLean wrote:
>
> > It happened it Weimar Germany. 4 trillion marks to the dollar. But that was
> > before computerisation. We haven't had hyperinflation in an advanced major
> It is one thing to bring up real-world historical examples of when large
> numbers were needed to hold currency values - it shows that small ranged
> types may not be sufficient (although I hope most people here are
> sufficiently well-educated to know that hyperinflation has occurred).
>
> But please drop the politics. If you want to discuss fiscal policy in
> some country, I am sure there are newsgroups suited to that. But unless
> some politician is trying to influence the C programming language, it is
> off-topic here.
>
The point is that hyperinfaltion is not just some remote theoretical possibility.
It could easily happen, given current policy. So programmers need to be
aware of this possibility and be prepared for it.
I'm not saying it will definitely happen, and I'm not saying that there are no
arguments for destroying the currency and resetting. That would be moving
from programming to politics.
What I am saying is that progammer need to be prepared for what the politicans
may decide.

2022-01-03 at 08:48 -0800, Malcolm McLean wrote:
> The point is that hyperinfaltion is not just some remote theoretical
> possibility. It could easily happen, given current policy. So
> programmers need to be aware of this possibility and be prepared for
> it.

I believe you are very much mistaken. Programmers need not to worry
about life, they only need to fullfill project requirements. THESE may
or may not take into account real-life scenarios like the one you keep
mentioning. Drafting project requirements is not a subject that matches
this group's activity.

Mateusz