On 03/01/2022 17:42, Mateusz Viste wrote:
> 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.

Unless it involves local accounting practices in rounding monetary amounts!

Meanwhile, float and double can represent monetary units up to about
1e38 or 1e308, but not to the nearest dollar or even cent when the sums
get big enough.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Monday, 3 January 2022 at 16:22:49 UTC, David Brown wrote:
>ted 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

>The point is that hyperinfaltion is not just

No, the point is that this is not the proper venue for your political/economic
views. Please stop.

On Monday, 3 January 2022 at 17:42:40 UTC, Mateusz Viste wrote:
> 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.
>
You can take the view that you are just a code monkey. So if the instructions
say store the date as two digits, you store the date as two digits, and let other
people worry what happens when the date rolls round to year 2000.

But many programmers don't work in that type of environment.

2022-01-03 at 11:09 -0800, Malcolm McLean wrote:
> But many programmers don't work in that type of environment.

You mean these programmers that code up a financial application that
looses dollars here and there if the sums' too big, instead of
failing with a clear error message? Yes, I know the type. I try to
avoid having them in my teams.

Mateusz

On Monday, 3 January 2022 at 19:32:12 UTC, Mateusz Viste wrote:
> 2022-01-03 at 11:09 -0800, Malcolm McLean wrote:
> > But many programmers don't work in that type of environment.
> You mean these programmers that code up a financial application that
> looses dollars here and there if the sums' too big, instead of
> failing with a clear error message? Yes, I know the type. I try to
> avoid having them in my teams.
>
I don't code programs that deal with amounts of money.

But I'd be extremely concerned about this. Basically you're taking the system
down if inflation creates a numeric overflow. That might be OK in some
situations, but for others, it could be a disaster. You buy a burger, and suddenly
all the tills go down because the day's takings have exceeded 63 bits. Not
a good look.

In article <P0HAJ.143568$7D4.141171@fx37.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On Monday, 3 January 2022 at 16:22:49 UTC, David Brown wrote:
>>ted 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
>
>>The point is that hyperinfaltion is not just
>
>No, the point is that this is not the proper venue for your political/economic
>views. Please stop.
>

Why does it hurt you so much to see Malcolm's posts here?
Why is it so important - why is your little psyche so damaged - that you
feel the need to comment?

The motto of Usenet is: If you don't like something, just ignore it.
Pretend it didn't happen. It's the only way to keep your sanity.

P.S. And, you're about to do a "I know what I am, but what are you?"
routine at me, can it. This is a legitimate inquiry. I really want to
know how you got to be so damaged.

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
[...]
>> I won't discuss politics here.
>>
> When hamburgers [more politics]

Malcolm, knock it off.

--
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 Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
> [...]
> >> I won't discuss politics here.
> >>
> > When hamburgers [more politics]
>
> Malcolm, knock it off.
>
Don't you see that that if you are discussing the representation of monetary
values, there are a few obvious things to consider? Whether they are real or
discrete is one. Another is range. What's the maximum value that we might
need to represent?

In article <8735m41lwy.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
>[...]
>>> I won't discuss politics here.
>>>
>> When hamburgers [more politics]
>
>Malcolm, knock it off.

Keith...

Why so butt-hurt?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/GodDelusion

In article <b2918a53-acd6-4c46-9b58-6ac578bc055cn@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
>> [...]
>> >> I won't discuss politics here.
>> >>
>> > When hamburgers [more politics]
>>
>> Malcolm, knock it off.
>>
>Don't you see that that if you are discussing the representation of monetary
>values, there are a few obvious things to consider? Whether they are real or
>discrete is one. Another is range. What's the maximum value that we might
>need to represent?

Malcolm, ...

You probably would have been fine - and the Not-Cs would have just ignored
you - if you just hadn't used the B-word (*) in your first post in the
sub-thread. Unfortunately, this is an error from which you cannot recover.

(*) Biden

--
12% of Americans think that Joan of Arc was Noah's wife.

On 03/01/2022 23:52, Malcolm McLean wrote:
> On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
>> [...]
>>>> I won't discuss politics here.
>>>>
>>> When hamburgers [more politics]
>>
>> Malcolm, knock it off.
>>
> Don't you see that that if you are discussing the representation of monetary
> values, there are a few obvious things to consider? Whether they are real or
> discrete is one. Another is range. What's the maximum value that we might
> need to represent?
>

You can discuss that without the politics. It is enough to note that
some countries have suffered hyperinflation so severe that 64-bit
integers would not be sufficient for currency, and leave it there. Let
those that are interested in the history (and that includes me) look it
up or discuss it elsewhere. Incorrect historical claims and wild
political conspiracy theories are of no use or interest here. Is it so
difficult for you to appreciate the difference?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
>> [...]
>> >> I won't discuss politics here.
>> >>
>> > When hamburgers [more politics]
>>
>> Malcolm, knock it off.
>>
> Don't you see that that if you are discussing the representation of monetary
> values, there are a few obvious things to consider? Whether they are real or
> discrete is one. Another is range. What's the maximum value that we might
> need to represent?

Of course I see that. And if you want to talk about how hyperinflation
and/or extremely large quantities might affect financial calculations.
If you assume an upper bound on a quantity, it's best to make that
assumption explicit.

It's your assertions that specific currently proposed policies will lead
to hyperinflation that are off-topic and annoying.

--
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 Monday, 3 January 2022 at 23:24:46 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
> >> [...]
> >> >> I won't discuss politics here.
> >> >>
> >> > When hamburgers [more politics]
> >>
> >> Malcolm, knock it off.
> >>
> > Don't you see that that if you are discussing the representation of monetary
> > values, there are a few obvious things to consider? Whether they are real or
> > discrete is one. Another is range. What's the maximum value that we might
> > need to represent?
> Of course I see that. And if you want to talk about how hyperinflation
> and/or extremely large quantities might affect financial calculations.
> If you assume an upper bound on a quantity, it's best to make that
> assumption explicit.
>
Maybe not. If we assume that a hamburger costs about a dollar in today's money,
in Weimar Germany the mark got up to 4 trillion to the dollar before being
abandoned. So clearly we need to plan for a burger costing at least 4 trillion
dollars. But how high could it go? Very hard to answer. But a double will handle
values of up to 10^308. It's hard to see even hyperinflation getting that high
before the monetary system totally collapses. So we're probably safe as far
as range is concerned with a double.
A double also has 53 bits of precision. that allows values of up to about 10^16
to be represented exactly. That's 10^14 is we store values in cents. So is that
enough? That's a much harder call. If you are dealing with hamburger joints,
then you can have quite a bit of inflation before you fail to be able to represent
as many hamburgers as you could reasonably sell. Then you start dropping
cents. But by the time you start dropping cents, the cent will be a notional unit
of currency. All the coins 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.
>
> It's your assertions that specific currently proposed policies will lead
> to hyperinflation that are off-topic and annoying.
>
As far as C programmers are concerned, the question is, is hyperinflation
something that happened in Weimar Germany back in the olden days,
and could never happen in the modern US. Or is it a real and present
danger. Is this something we should be thinking about?

If you ask some qualified people, I think you'll find that they are extremely
worried.

On Tuesday, 4 January 2022 at 01:43:46 UTC+2, Malcolm McLean wrote:
> On Monday, 3 January 2022 at 23:24:46 UTC, Keith Thompson wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > > On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
> > >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > >> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
> > >> [...]
> > >> >> I won't discuss politics here.
> > >> >>
> > >> > When hamburgers [more politics]
> > >>
> > >> Malcolm, knock it off.
> > >>
> > > Don't you see that that if you are discussing the representation of monetary
> > > values, there are a few obvious things to consider? Whether they are real or
> > > discrete is one. Another is range. What's the maximum value that we might
> > > need to represent?
> > Of course I see that. And if you want to talk about how hyperinflation
> > and/or extremely large quantities might affect financial calculations.
> > If you assume an upper bound on a quantity, it's best to make that
> > assumption explicit.
> >
> Maybe not. If we assume that a hamburger costs about a dollar in today's money,
> in Weimar Germany the mark got up to 4 trillion to the dollar before being
> abandoned. So clearly we need to plan for a burger costing at least 4 trillion
> dollars. But how high could it go? Very hard to answer. But a double will handle
> values of up to 10^308. It's hard to see even hyperinflation getting that high
> before the monetary system totally collapses. So we're probably safe as far
> as range is concerned with a double.
> A double also has 53 bits of precision. that allows values of up to about 10^16
> to be represented exactly. That's 10^14 is we store values in cents. So is that
> enough? That's a much harder call. If you are dealing with hamburger joints,
> then you can have quite a bit of inflation before you fail to be able to represent
> as many hamburgers as you could reasonably sell. Then you start dropping
> cents. But by the time you start dropping cents, the cent will be a notional unit
> of currency. All the coins 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.
> >
> > It's your assertions that specific currently proposed policies will lead
> > to hyperinflation that are off-topic and annoying.
> >
> As far as C programmers are concerned, the question is, is hyperinflation
> something that happened in Weimar Germany back in the olden days,
> and could never happen in the modern US. Or is it a real and present
> danger. Is this something we should be thinking about?
>
> If you ask some qualified people, I think you'll find that they are extremely
> worried.

In every successful project where I've participated several things about its
data and functionality were illogical. Properties of records were misplaced,
not belonging to that record, having inadequate value ranges, duplicated
but not synchronized in other records, some crucial information was missing
and had to be figured by strange heuristics and so on. Modules did things
that these were not supposed to do or left things not done these were
supposed to do. Often such issues were known and cursed at but left
there and sometimes even some new such weirdness were added.

It is not because engineers participating deserved to be called code monkeys.
Infallible people are available nowhere. So perfect is worst enemy of good.
Who tries to make perfect things with usual fallible people right away
gets nothing done. Meanwhile software that is made good enough for
subset of its purposes will be used and improved over time. So it brings
profit right now.

One day part of that profit can be invested back to inevitable huge work
of replacing the Euros in it to German Goldens or whatever and it will be
done. Who can predict if there will be need for it and when and what will
it cost? It will be stuck in inability to proceed:
<https://en.wikipedia.org/wiki/Analysis_paralysis> No profit.

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.

A probably sane approach could be not to store the numbers at
all, but rely entirely on the database engine for handling and storing
them, while the C program would only process strings. The rationale
here would be that if the database cannot store the numbers properly,
then you are screwed anyway. Also, you could upgrade/fix the database
in the future without having to touch the program.
PostgreSQL has a nice "numeric" type that could be well suited for the
job at hand.

Alternatively, use uint64_t or _uint128_t if you really have to crunch
the numbers yourself. These types are proper integers that have well
defined boundaries and are easy to manipulate.

In any case, introducing doubles in such system will lead to entirely
new classes of problems, since even doing seemingly trivial math with
doubles can easily become a man-hour consuming trap.

> As far as C programmers are concerned, the question is, is
> hyperinflation something that happened in Weimar Germany back in the
> olden days, and could never happen in the modern US.

Again, not something that "C programmers" should be concerned with.
Unless you mean some kind of indie programmer that is at the same time
a financial expert, businessman and salesman, ie. a one-man-do-it-all
startup guy. But this guy won't have time for drafting apocalyptic
scenarios in his program, he will have to deliver something basic yet
efficient and appealing and sell it quickly if he wants to survive. Any
other scenario will include specifications written by someone that
knows what he's doing, ie. a domain expert.

Mateusz

On 04/01/2022 00:43, Malcolm McLean wrote:
> On Monday, 3 January 2022 at 23:24:46 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
>>>> [...]
>>>>>> I won't discuss politics here.
>>>>>>
>>>>> When hamburgers [more politics]
>>>>
>>>> Malcolm, knock it off.
>>>>
>>> Don't you see that that if you are discussing the representation of monetary
>>> values, there are a few obvious things to consider? Whether they are real or
>>> discrete is one. Another is range. What's the maximum value that we might
>>> need to represent?
>> Of course I see that. And if you want to talk about how hyperinflation
>> and/or extremely large quantities might affect financial calculations.
>> If you assume an upper bound on a quantity, it's best to make that
>> assumption explicit.
>>
> Maybe not. If we assume that a hamburger costs about a dollar in today's money,
> in Weimar Germany the mark got up to 4 trillion to the dollar before being
> abandoned. So clearly we need to plan for a burger costing at least 4 trillion
> dollars. But how high could it go? Very hard to answer. But a double will handle
> values of up to 10^308. It's hard to see even hyperinflation getting that high
> before the monetary system totally collapses. So we're probably safe as far
> as range is concerned with a double.
> A double also has 53 bits of precision. that allows values of up to about 10^16
> to be represented exactly. That's 10^14 is we store values in cents. So is that
> enough? That's a much harder call. If you are dealing with hamburger joints,
> then you can have quite a bit of inflation before you fail to be able to represent
> as many hamburgers as you could reasonably sell. Then you start dropping
> cents. But by the time you start dropping cents, the cent will be a notional unit
> of currency. All the coins 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.

If you are writing a simple example or test program, use whatever type
suits. If you are writing a single-purpose or single-user program, use
whatever type suits. These would be integer types if you want to store
integer cents (or pennies, or whatever), or doubles if you want to make
it easy to do interest rate calculations. This will be fine to tell you
the values involved - and the real legal tracking of money will be done
by banks and accountants using software that follows the required rules.

If you are writing a serious program, you find the rules for the
jurisdictions that are relevant. You don't make guesses based on vague
memories of school-time history classes or think "cents is good enough".
In some places, the rules involved are much more demanding - I know
that for some currencies, you need to track six digits after the decimal
point.

>>
>> It's your assertions that specific currently proposed policies will lead
>> to hyperinflation that are off-topic and annoying.
>>
> As far as C programmers are concerned, the question is, is hyperinflation
> something that happened in Weimar Germany back in the olden days,
> and could never happen in the modern US. Or is it a real and present
> danger. Is this something we should be thinking about?
>

No, it is not something you need to think about as a C programmer. You
write the code you need - and for an example program like the OP's, it
doesn't need any connection to reality. On the other hand, if you want
to write serious financial software, you follow the rules required - you
don't invent them.

> If you ask some qualified people, I think you'll find that they are extremely
> worried.
>

Could modern economies spiral into hyperinflation? Of course it is
possible. We've seen it before, worse and more recently than the Weimar
Republic. If you want to learn about and discuss this, find an
appropriate place to do so rather than mixing limited historical points
with paranoid conspiracy theories in a programming group. Or perhaps
find a qualified person and ask them, to put your mind at ease. Just be
sure to look for that qualified person in an appropriate place - not
comp.lang.c, and not some Facebook post by your Auntie's neighbour's
friend whose dad is a janitor in a bank so he should know.

On Tuesday, 4 January 2022 at 08:32:11 UTC, David Brown wrote:
> On 04/01/2022 00:43, Malcolm McLean wrote:
>
> > As far as C programmers are concerned, the question is, is hyperinflation
> > something that happened in Weimar Germany back in the olden days,
> > and could never happen in the modern US. Or is it a real and present
> > danger. Is this something we should be thinking about?
> >
> No, it is not something you need to think about as a C programmer. You
> write the code you need - and for an example program like the OP's, it
> doesn't need any connection to reality. On the other hand, if you want
> to write serious financial software, you follow the rules required - you
> don't invent them.
>
So you are also thinking like a code monkey. A code monkey is not a "bad
programmer". It's a model of development in which the programmer is as
far as possible de-skilled. So if the instructions say "store the date as
two digits", he is meant to store the date as two digits. It's not his job to
raise the question of what happens when we roll over to year 2000 with
his superiors. He's just the coder.
> > If you ask some qualified people, I think you'll find that they are extremely
> > worried.
> >
> Could modern economies spiral into hyperinflation? Of course it is
> possible. We've seen it before, worse and more recently than the Weimar
> Republic. If you want to learn about and discuss this, find an
> appropriate place to do so rather than mixing limited historical points
> with paranoid conspiracy theories in a programming group. Or perhaps
> find a qualified person and ask them, to put your mind at ease. Just be
> sure to look for that qualified person in an appropriate place - not
> comp.lang.c, and not some Facebook post by your Auntie's neighbour's
> friend whose dad is a janitor in a bank so he should know.
>
A conspiracy theory alleges that there is some secret plot to, in this
case, hyperinflate the currency. You don't have to believe that. Policy
that is a matter of public record is enough. We've seen hyperinflation in
places like Zimbabwe and Venuzuela, but not in an advanced, major
Western economy since Weimar. The partial exception is Israel in the
1980s, but it didn't have a hard currency at the time in the 1980s
(I believe). However that is going too far off topic.

On Monday, 3 January 2022 at 22:58:43 UTC, Kenny McCormack wrote:
> In article <b2918a53-acd6-4c46...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >On Monday, 3 January 2022 at 22:42:32 UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> > On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote:
> >> [...]
> >> >> I won't discuss politics here.
> >> >>
> >> > When hamburgers [more politics]
> >>
> >> Malcolm, knock it off.
> >>
> >Don't you see that that if you are discussing the representation of monetary
> >values, there are a few obvious things to consider? Whether they are real or
> >discrete is one. Another is range. What's the maximum value that we might
> >need to represent?
> Malcolm, ...
>
> You probably would have been fine - and the Not-Cs would have just ignored
> you - if you just hadn't used the B-word (*) in your first post in the
> sub-thread. Unfortunately, this is an error from which you cannot recover.
>
> (*) Biden
>
The poor man. Imagine mention of your name causing such angst.

In article <9f5ceaf1-e9b6-4c0c-82c8-bfd437049565n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>The poor man. Imagine mention of his name causing such angst.

You're talking about poor Keith, right?

Yes, Keith has his, shall we say, issues...

--

Prayer has no place in the public schools, just like facts
have no place in organized religion.
-- Superintendent Chalmers

On 04/01/2022 10:30, Malcolm McLean wrote:

There is a wise saying - when you are in a hole, stop digging. You are
giving bad advice, justifying it with outlandish and unrealistic
political gibberish and your own misunderstandings of what people do in
the world of software development.

If you were employed as a programmer and asked to develop software that
complied with the fiscal laws of a country, but decided to implement it
in a different way because of your fairyland political ideas, you'd be
out of a job.

If that's the way /you/ want to live, that's up to you. But please stop
suggesting such attitudes to others that might be new to the programming
world and misunderstand your postings as good advice.

> However that is going too far off topic.
>

So let that be an end of this thread, now that you have pulled it so far
away from anything related to C, to the OP's questions, or to any
on-topic diversions that came out of the thread.

On Tuesday, 4 January 2022 at 13:55:29 UTC, David Brown wrote:
> On 04/01/2022 10:30, Malcolm McLean wrote:
>
> There is a wise saying - when you are in a hole, stop digging. You are
> giving bad advice, justifying it with outlandish and unrealistic
> political gibberish and your own misunderstandings of what people do in
> the world of software development.
>
> If you were employed as a programmer and asked to develop software that
> complied with the fiscal laws of a country, but decided to implement it
> in a different way because of your fairyland political ideas, you'd be
> out of a job.
>
The code monkey asks what the instructions are, and follows them. That's
because he's a low level person with limited responsibilities.
The software engineer looks at the instructions, and asks if they will
fulfil the requirement of the project, or if there is some problem with them.
In this case, whether the representation he has been asked to use for
monetary values will cope with hyperinflation.
What action he then takes depends on the status of the instructions, who
issued them, if there is a standard procedure for raising defect reports,
and, crucially, whether he believes that the scenario in which the instructions
will fail is a likely one and of importance to the project, or very far-fetched.

Engineering requires intelligence.
>
> If that's the way /you/ want to live, that's up to you. But please stop
> suggesting such attitudes to others that might be new to the programming
> world and misunderstand your postings as good advice.
>
Some people are happy with your model of development. It does have something
to be said for it. But it's not a professional attitude.
>
> > However that is going too far off topic.
> >
> So let that be an end of this thread, now that you have pulled it so far
> away from anything related to C, to the OP's questions, or to any
> on-topic diversions that came out of the thread.
>
I've kept very closely related to C at all times. Most useful programs deal with
things in the outside world. So if you are writing a C program which isn't
something that is purely computational, you need to discuss that thing.
In this case we are discussing money and how to represent it.

Keith leapt on the "B word" for his own reasons.

In article <2a287c23-ad75-45e8-befc-a8fdcdf19853n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>A conspiracy theory alleges that there is some secret plot to, in this
>case, hyperinflate the currency. You don't have to believe that. Policy
>that is a matter of public record is enough. We've seen hyperinflation in
>places like Zimbabwe and Venuzuela, but not in an advanced, major Western
>economy since Weimar. The partial exception is Israel in the 1980s, but
>it didn't have a hard currency at the time in the 1980s (I believe).
>However that is going too far off topic.

In the 21st century, the term "conspiracy theory" has lost all meaning -
not that it really had any in the first place.

In the 21st century, it just means "Any political idea that I don't like".

That is the sense in which the other idiot (the one to whom you were
responding) meant it.

--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.

On 04/01/2022 15:21, Malcolm McLean wrote:

<snip>

You've moved beyond off-topic posts into bad excuses and poorly-veiled
insults. Please leave it. If you feel there is something worth
discussing, my email address is valid.

In article <sr1qat$60c$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 04/01/2022 15:21, Malcolm McLean wrote:
>
><snip>
>
>You've moved beyond off-topic posts into bad excuses and poorly-veiled
>insults. Please leave it. If you feel there is something worth
>discussing, my email address is valid.

Why you so butt-hurt by this?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Mandela

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?