Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164058 > unrolled thread
| Started by | Manu Raju <MR@invalid.invalid> |
|---|---|
| First post | 2021-12-25 01:00 +0000 |
| Last post | 2021-12-29 15:21 +0000 |
| Articles | 20 on this page of 113 — 19 participants |
Back to article view | Back to comp.lang.c
Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-25 01:00 +0000
Re: Can this program be improved? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-24 21:44 -0800
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2021-12-25 12:56 +0100
Re: Can this program be improved? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-25 11:13 -0800
Re: Can this program be improved? Manfred <noname@add.invalid> - 2021-12-25 23:50 +0100
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 18:52 +0000
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-26 19:22 +0000
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 21:30 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-26 22:02 +0000
Re: Can this program be improved? Richard Damon <Richard@Damon-Family.org> - 2021-12-26 18:24 -0500
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-27 00:47 +0000
Re: Can this program be improved? Guillaume <message@bottle.org> - 2021-12-29 17:52 +0100
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-29 17:49 +0000
Re: Can this program be improved? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-29 11:33 -0800
Re: Can this program be improved? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-29 22:45 -0500
Re: Can this program be improved? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-30 00:35 -0800
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2021-12-30 10:19 +0100
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-01 18:19 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-01 19:33 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-29 14:37 -0800
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-29 23:09 +0000
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2021-12-29 23:54 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-29 16:11 -0800
Re: Can this program be improved? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-30 00:34 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-30 12:49 +0000
Re: Can this program be improved? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-30 21:04 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-31 02:13 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-29 16:09 -0800
Re: Can this program be improved? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-30 00:59 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-29 17:48 -0800
Re: Can this program be improved? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-30 20:47 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-30 01:06 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-30 04:48 -0800
Re: Can this program be improved? Manfred <noname@add.invalid> - 2021-12-30 18:16 +0100
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-31 02:20 +0000
Re: Can this program be improved? Manfred <noname@add.invalid> - 2021-12-31 18:25 +0100
Re: Can this program be improved? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-31 18:13 -0500
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-31 23:59 +0000
Re: Can this program be improved? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-31 16:20 -0800
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-31 16:35 -0800
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-01 00:53 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-31 20:22 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-31 22:04 -0800
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-01 14:59 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-02 17:22 -0800
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-02 20:49 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 03:09 -0800
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2022-01-03 16:22 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-03 14:42 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 14:52 -0800
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-03 22:58 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 04:27 -0800
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-04 13:39 +0000
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2022-01-04 00:18 +0100
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-03 15:24 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 15:43 -0800
Re: Can this program be improved? Öö Tiib <ootiib@hot.ee> - 2022-01-03 21:19 -0800
Re: Can this program be improved? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-04 09:23 +0100
Re: Can this program be improved? Guillaume <message@bottle.org> - 2022-01-04 18:18 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 10:35 -0800
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-04 14:07 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 15:11 -0800
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-04 15:47 -0800
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 18:30 -0800
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2022-01-04 23:46 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-04 18:41 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 10:52 -0800
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2022-01-04 19:00 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 11:15 -0800
Re: Can this program be improved? Guillaume <message@bottle.org> - 2022-01-04 21:57 +0100
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-04 21:02 +0000
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2022-01-04 21:38 +0000
Re: Can this program be improved? Manfred <noname@add.invalid> - 2022-01-04 23:01 +0100
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2022-01-04 09:31 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 01:30 -0800
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2022-01-04 14:55 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-04 06:21 -0800
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2022-01-04 16:49 +0100
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-04 15:56 +0000
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-04 15:03 +0000
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-03 22:54 +0000
Re: Can this program be improved? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-03 09:22 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 03:30 -0800
Re: Can this program be improved? David Brown <david.brown@hesbynett.no> - 2022-01-03 17:22 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 08:48 -0800
Re: Can this program be improved? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-03 18:42 +0100
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-03 17:59 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 11:09 -0800
Re: Can this program be improved? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-03 20:32 +0100
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-03 11:58 -0800
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2022-01-03 18:13 +0000
Re: Can this program be improved? gazelle@shell.xmission.com (Kenny McCormack) - 2022-01-03 20:05 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2022-01-01 16:53 +0000
Re: Can this program be improved? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-30 00:29 +0000
Re: Can this program be improved? Bart <bc@freeuk.com> - 2021-12-25 12:47 +0000
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 18:56 +0000
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-25 17:38 +0000
Re: Can this program be improved? Öö Tiib <ootiib@hot.ee> - 2021-12-25 10:58 -0800
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-25 19:16 +0000
Re: Can this program be improved? Öö Tiib <ootiib@hot.ee> - 2021-12-25 11:25 -0800
Re: Can this program be improved? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-25 15:01 -0800
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-25 23:09 +0000
Re: Can this program be improved? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-25 20:56 -0800
Re: Can this program be improved? scott@slp53.sl.home (Scott Lurndal) - 2021-12-25 19:30 +0000
Re: Can this program be improved? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-25 15:50 -0800
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 19:02 +0000
Re: Can this program be improved? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-25 11:53 -0800
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 19:00 +0000
Re: Can this program be improved? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-25 11:22 -0800
Re: Can this program be improved? Manu Raju <MR@invalid.invalid> - 2021-12-26 19:01 +0000
Re: Can this program be improved? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-25 13:27 -0800
Re: Can this program be improved? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-25 16:06 -0800
Re: Can this program be improved? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-29 15:21 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-04 14:07 -0800 |
| Message-ID | <87tuejyx2z.fsf@nosuchdomain.example.com> |
| In reply to | #164277 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The central difficulty is that people have no problem with the idea
> that an integer type should hold an amount in cents. But for some reason
> they think that a floating point type must hold an amount in dollars.
> Probably because an amount of 110 cents is always written as 1.10
> dollars for the end-user.
>
> Once you make that leap, you'll see that you can use floating point types to
> represent integers.
Or -- now hear me out -- you can use integers to represent integers.
The central difficulty is that there are rules that regulate how
financial calculations must be done. I don't know what those rules are,
but I speculate that floating-point, even if used to represent cents,
does not satisfy those rules. For anything more complicated than
addition and subtraction, there will be rounding errors that have to be
resolved *correctly*. Now if IEEE 754 floating-point happens to meet
the regulatory requirements, then that's what you should use, but I
don't think that's the case.
Doing all this stuff correctly is a solved problem. I doubt that anyone
here happens to know the details; as far as I know none of the regulars
work in finance. We're all speculating.
If someone has a reference to the actual rules used by banks and other
financial institutions, it would be interesting to see that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 15:11 -0800 |
| Message-ID | <1393d15f-e5ba-4ff2-977c-0618f457e0ebn@googlegroups.com> |
| In reply to | #164289 |
On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > [...] > > The central difficulty is that people have no problem with the idea > > that an integer type should hold an amount in cents. But for some reason > > they think that a floating point type must hold an amount in dollars. > > Probably because an amount of 110 cents is always written as 1.10 > > dollars for the end-user. > > > > Once you make that leap, you'll see that you can use floating point types to > > represent integers. > > Or -- now hear me out -- you can use integers to represent integers. > Yes, but a floating point type degrades gracefully as values get very large. Hyperinflation. The bit that you snipped because you were so upset by the sly little dig at a current politician that you couldn't see the point that was being made. Integers don't. They work perfectly until overflow occurs. Then you get nonsense results, or a crash if you are lucky / careful. > > The central difficulty is that there are rules that regulate how > financial calculations must be done. I don't know what those rules are, > but I speculate that floating-point, even if used to represent cents, > does not satisfy those rules. For anything more complicated than > addition and subtraction, there will be rounding errors that have to be > resolved *correctly*. Now if IEEE 754 floating-point happens to meet > the regulatory requirements, then that's what you should use, but I > don't think that's the case. > I've never written a real program to deal with amounts of money either. But I'd be surprised if a legislature mandated a particular C language type to hold monetary values. They might describe the required behaviour of the system. That might well be satisfied by a system with 53 bits of precision storing numbers in cents. If 53 bits are not enough, then going to long double would probably satisfy the legislators. > > Doing all this stuff correctly is a solved problem. I doubt that anyone > here happens to know the details; as far as I know none of the regulars > work in finance. We're all speculating. > I'm not sure it is. No-one here except me has posted any details of real systems. So we've no way of knowing whether hyperinflation has been properly considered or not. It would be interesting to get someone who has worked on financial information systems in Zimbabwe, for instance, to hear what they did. > > If someone has a reference to the actual rules used by banks and other > financial institutions, it would be interesting to see that. > Agreed. None of us have any real world experience.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-04 15:47 -0800 |
| Message-ID | <87lezvysf8.fsf@nosuchdomain.example.com> |
| In reply to | #164292 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>> > The central difficulty is that people have no problem with the idea
>> > that an integer type should hold an amount in cents. But for some reason
>> > they think that a floating point type must hold an amount in dollars.
>> > Probably because an amount of 110 cents is always written as 1.10
>> > dollars for the end-user.
>> >
>> > Once you make that leap, you'll see that you can use floating point types to
>> > represent integers.
>>
>> Or -- now hear me out -- you can use integers to represent integers.
>>
> Yes, but a floating point type degrades gracefully as values get very large.
You're assuming that degradation is acceptable if it's "graceful".
If you know something about the actual regulations that implies that,
by all means share it.
My speculation is that regulations require specific results to be
accurate to the cent regardless of the magnitude of the quantities being
used, and that hyperinflation would not be accepted as an excuse for
off-by-one errors. If for whatever reason we started having to deal
with quantities that don't fit in 64 bits, for example, perhaps some
software would have to be updated -- or perhaps it can already handle
such cases.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 18:30 -0800 |
| Message-ID | <b2c5f152-ce0c-4b5b-829b-3581c2223b10n@googlegroups.com> |
| In reply to | #164294 |
On Tuesday, 4 January 2022 at 23:47:49 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Tuesday, 4 January 2022 at 22:07:12 UTC, Keith Thompson wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> [...] > >> > The central difficulty is that people have no problem with the idea > >> > that an integer type should hold an amount in cents. But for some reason > >> > they think that a floating point type must hold an amount in dollars. > >> > Probably because an amount of 110 cents is always written as 1.10 > >> > dollars for the end-user. > >> > > >> > Once you make that leap, you'll see that you can use floating point types to > >> > represent integers. > >> > >> Or -- now hear me out -- you can use integers to represent integers. > >> > > Yes, but a floating point type degrades gracefully as values get very large. > You're assuming that degradation is acceptable if it's "graceful". > If you know something about the actual regulations that implies that, > by all means share it. > I'm assumignthat a graceful degradation is better than a sudden catastrophic failure. As youu say, that doesn't necessarily hold. Sometimes no results are better than slightly wrong results. > > My speculation is that regulations require specific results to be > accurate to the cent regardless of the magnitude of the quantities being > used, and that hyperinflation would not be accepted as an excuse for > off-by-one errors. If for whatever reason we started having to deal > with quantities that don't fit in 64 bits, for example, perhaps some > software would have to be updated -- or perhaps it can already handle > such cases. > Well let's look at what happened in Weimar Germany. A mark got up to 4 trilion dollars. So if say that a hamburger is worth a dollar, a hamburger in Hamburg in 1923 would have cost 4 trillion marks, or 400 trillion pfennigs. If the Germans had been using 64 bit computers those days, you could sell about 10,000 hamburgers, by my calculations, before the system fell over. But if you look at the graph of the mark versus the dollar, whilst inflation was severe, you didn't get into really startling figures until mid 1923. For along time, it would have looked as though 64 bits were perfectly adequate. The situation would have suddenly come on the developers. By this time the Germans were starving and there were riots in the streets. There would have been even worse riots if the transaction processing system had fallen over. Would the bank have made the situation even worse by kicking up a fuss over a few pfennigs? I wasn't there, I can't answer that question. Where you've got that sort of social phenomenon you don't always get a sane reaction. But by all means argue that 53 bit or even 64 bit mantissa floating point isn't enough and you need arbitrary-sized integers. That's a defensible position. "Malcolm is an idiot becuase he mentioned the current political situation" is not.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-04 23:46 +0000 |
| Message-ID | <T%4BJ.104424$Gco3.46927@fx01.iad> |
| In reply to | #164289 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >[...] >> The central difficulty is that people have no problem with the idea >> that an integer type should hold an amount in cents. But for some reason >> they think that a floating point type must hold an amount in dollars. >> Probably because an amount of 110 cents is always written as 1.10 >> dollars for the end-user. >> >> Once you make that leap, you'll see that you can use floating point types to >> represent integers. > >Or -- now hear me out -- you can use integers to represent integers. > >The central difficulty is that there are rules that regulate how >financial calculations must be done. I don't know what those rules are, >but I speculate that floating-point, even if used to represent cents, >does not satisfy those rules. For anything more complicated than >addition and subtraction, there will be rounding errors that have to be >resolved *correctly*. Now if IEEE 754 floating-point happens to meet >the regulatory requirements, then that's what you should use, but I >don't think that's the case. Anecdotally, the first generation Burroughs B3500 BCD machine (1966) had 100 digit signed and unsigned integer arithmetic operations (that could be performed on either 4-bit digits or 8-bit zoned-digits) and had a floating point (real) unit with 2 digit signed exponent and 100 digit signed mantissa. The machine was heavily sold into banks, insurance companies and other finance industry customers. In the second generation B4700 the real number (floating point) support was completely removed because no customer used it. Note this was by definition decimal floating point. > >Doing all this stuff correctly is a solved problem. I doubt that anyone >here happens to know the details; as far as I know none of the regulars >work in finance. We're all speculating. We had benchmarks derived from customer code for the B3500 & successors in the MCP group, but those have long been lost to history, bit-rot and thrown out boxes of 9-track and 18-track tapes from Iron Mountain, sadly.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-01-04 18:41 +0000 |
| Message-ID | <sr24c4$i02$1@dont-email.me> |
| In reply to | #164275 |
On 04/01/2022 17:18, Guillaume wrote: > Le 04/01/2022 à 09:23, Mateusz Viste a écrit : >> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: >>> will have been melted down for metal. So is 53 bits enough? I don't >>> write programs that deal withh amounts of money, so I don't really >>> know. However if I had to choose a C type, I'd probably go for >>> integer representation of amounts in cents, using a double. >> >> A double is nice to represent not-100%-precise fractional units, >> it really does not have its place in any kind of financial >> program, esp. if the goal is storing cents anyway. > > Absolutely. Using FP for financial calculations is for people who don't > know arithmetics. Maybe teaching some math (again) to CS students would > help, here? :) > > At the very least, if you absolutely want to use FP for this, at least > use decimal FP. Although it can still have precision issues due to its > floating point nature, at least rounding will not yield gross errors. 64-bit floating point can represent values up to c. 10 trillion dollars to the nearest cent. (I think the limit corresponds to the 2**52 bits of precision.) It won't be to the exact cent if printed to many decimals, but if you know it is supposed to represent values that end in exactly 0.00 to 0.99, then it will display properly if converted to text and rounded to 2 decimals. So it can be used to store such values. Calculating with it is a different matter if you are actually working with that kind of magnitude and actually need 1-cent accuracy and reproducability (which is going to be virtually nobody). > And if you're OK with using integers, but are afraid fixed-size ones (at > least 64 bits) could be an unacceptable limit down the road, just use > arbitrary precision arithmetic. And you don't need to hand-implement > that, unless it's your thing. GNU GMP is great. No, it isn't. It's a massive great dependency. If you really need to use it, look for GMP-lite (a solution using one .h and one .c file). However to me that would be a sign of someone who doesn't know what they're doing and just throws unnecessary precision at the problem in the hope it will magically fix any issues. Remember, even /decimal/ arbitrary precision integer or floating point could implemented using just float types, by always working within the known limitations of that type. Similarly, you can just directly work within the known limitations of ieee754. > One of the many problems with FP can be easily shown. Apart from the > usual unability to represent some numbers exactly, they also have an > inherent problem when, for instance, adding very small numbers to very > large ones. Can you give an example of a real-world financial calculation where that could happen? I mean, other than adding $0.01 to $10,000,000,000,000.00 or so; just get real. > Of course if all you do is writing "toy programs", use whatever. But > somehow, if this is a student work, I would have a problem with calling > student exercises "toy programs". That would certainly give them the > wrong idea about how to do things properly. If they once used FP for > financial operations, even on a small exercise, how can you know they > won't do the same later on at work when having to write code dealing > with financial calculations? I've used floating point for financial work. The world didn't end that I remember.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 10:52 -0800 |
| Message-ID | <6d78fbba-8bde-4bf4-9f90-40e59bcd61a3n@googlegroups.com> |
| In reply to | #164279 |
On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: > On 04/01/2022 17:18, Guillaume wrote: > > Le 04/01/2022 à 09:23, Mateusz Viste a écrit : > >> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: > >>> will have been melted down for metal. So is 53 bits enough? I don't > >>> write programs that deal withh amounts of money, so I don't really > >>> know. However if I had to choose a C type, I'd probably go for > >>> integer representation of amounts in cents, using a double. > >> > >> A double is nice to represent not-100%-precise fractional units, > >> it really does not have its place in any kind of financial > >> program, esp. if the goal is storing cents anyway. > > > > Absolutely. Using FP for financial calculations is for people who don't > > know arithmetics. Maybe teaching some math (again) to CS students would > > help, here? :) > > > > At the very least, if you absolutely want to use FP for this, at least > > use decimal FP. Although it can still have precision issues due to its > > floating point nature, at least rounding will not yield gross errors. > > 64-bit floating point can represent values up to c. 10 trillion dollars > to the nearest cent. (I think the limit corresponds to the 2**52 bits of > precision.) > 53 bits. You get a "free" bit because the leading digit is always 1, except for zero, which has a special representation. > > It won't be to the exact cent if printed to many decimals, but if you > know it is supposed to represent values that end in exactly 0.00 to > 0.99, then it will display properly if converted to text and rounded to > 2 decimals. > > So it can be used to store such values. Calculating with it is a > different matter if you are actually working with that kind of magnitude > and actually need 1-cent accuracy and reproducability (which is going to > be virtually nobody). > > > And if you're OK with using integers, but are afraid fixed-size ones (at > > least 64 bits) could be an unacceptable limit down the road, just use > > arbitrary precision arithmetic. And you don't need to hand-implement > > that, unless it's your thing. GNU GMP is great. > > No, it isn't. It's a massive great dependency. If you really need to use > it, look for GMP-lite (a solution using one .h and one .c file). > > However to me that would be a sign of someone who doesn't know what > they're doing and just throws unnecessary precision at the problem in > the hope it will magically fix any issues. > I checked a few real world financial implementations. In Java, they have a class which can use either a 32-bit integer, a 64 bit integer, or a "Big Decimal" as the underlying representation. The recommendation is to use the Big Decimal. Presumably it will scale to arbitrarily values. However Java isn't C. In C it's much harder to encapsulate an arbitrary- sized number, pass it around, and perform calculations with it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-04 19:00 +0000 |
| Message-ID | <yP0BJ.177520$VS2.44235@fx44.iad> |
| In reply to | #164280 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: >> However to me that would be a sign of someone who doesn't know what=20 >> they're doing and just throws unnecessary precision at the problem in=20 >> the hope it will magically fix any issues.=20 >>=20 >I checked a few real world financial implementations. >In Java, they have a class which can use either a 32-bit integer, a 64 bit = >integer, >or a "Big Decimal" as the underlying representation. The recommendation is >to use the Big Decimal. Presumably it will scale to arbitrarily values. > >However Java isn't C. In C it's much harder to encapsulate an arbitrary- >sized number, pass it around, and perform calculations with it. Which is why they don't use C, and instead use COBOL and JAVA.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 11:15 -0800 |
| Message-ID | <c79b4c6a-2170-4664-b788-5ceab80b1b37n@googlegroups.com> |
| In reply to | #164281 |
On Tuesday, 4 January 2022 at 19:00:57 UTC, Scott Lurndal wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > >On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: > >> However to me that would be a sign of someone who doesn't know what=20 > >> they're doing and just throws unnecessary precision at the problem in=20 > >> the hope it will magically fix any issues.=20 > >>=20 > >I checked a few real world financial implementations. > >In Java, they have a class which can use either a 32-bit integer, a 64 bit = > >integer, > >or a "Big Decimal" as the underlying representation. The recommendation is > >to use the Big Decimal. Presumably it will scale to arbitrarily values. > > > >However Java isn't C. In C it's much harder to encapsulate an arbitrary- > >sized number, pass it around, and perform calculations with it. > Which is why they don't use C, and instead use COBOL and JAVA. > That's often the real answer. Use Cobol for programs dealing mainly with amounts of money. That's its niche. But sometimes you might need to use C. For instance in the software controlling a till.
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2022-01-04 21:57 +0100 |
| Message-ID | <sr2cb9$1c5s$1@gioia.aioe.org> |
| In reply to | #164282 |
Le 04/01/2022 à 20:15, Malcolm McLean a écrit : > On Tuesday, 4 January 2022 at 19:00:57 UTC, Scott Lurndal wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: >>>> However to me that would be a sign of someone who doesn't know what=20 >>>> they're doing and just throws unnecessary precision at the problem in=20 >>>> the hope it will magically fix any issues.=20 >>>> =20 >>> I checked a few real world financial implementations. >>> In Java, they have a class which can use either a 32-bit integer, a 64 bit = >>> integer, >>> or a "Big Decimal" as the underlying representation. The recommendation is >>> to use the Big Decimal. Presumably it will scale to arbitrarily values. >>> >>> However Java isn't C. In C it's much harder to encapsulate an arbitrary- >>> sized number, pass it around, and perform calculations with it. >> Which is why they don't use C, and instead use COBOL and JAVA. >> > That's often the real answer. Use Cobol for programs dealing mainly > with amounts of money. That's its niche. > But sometimes you might need to use C. For instance in the software > controlling a till. As I said, there's a whole lot of arbitrary-precision libraries for C, Gnu GMP being a good, well known and stable one.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-01-04 21:02 +0000 |
| Message-ID | <sr2ckp$co8$1@dont-email.me> |
| In reply to | #164280 |
On 04/01/2022 18:52, Malcolm McLean wrote: > On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: >> On 04/01/2022 17:18, Guillaume wrote: >>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit : >>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: >>>>> will have been melted down for metal. So is 53 bits enough? I don't >>>>> write programs that deal withh amounts of money, so I don't really >>>>> know. However if I had to choose a C type, I'd probably go for >>>>> integer representation of amounts in cents, using a double. >>>> >>>> A double is nice to represent not-100%-precise fractional units, >>>> it really does not have its place in any kind of financial >>>> program, esp. if the goal is storing cents anyway. >>> >>> Absolutely. Using FP for financial calculations is for people who don't >>> know arithmetics. Maybe teaching some math (again) to CS students would >>> help, here? :) >>> >>> At the very least, if you absolutely want to use FP for this, at least >>> use decimal FP. Although it can still have precision issues due to its >>> floating point nature, at least rounding will not yield gross errors. >> >> 64-bit floating point can represent values up to c. 10 trillion dollars >> to the nearest cent. (I think the limit corresponds to the 2**52 bits of >> precision.) >> > 53 bits. You get a "free" bit because the leading digit is always 1, except for > zero, which has a special representation. If the 53rd bit is always 1, then isn't the precision determined by the other 52 bits? So if a mantissa was only going to be 0b10 or 0b11, to me that's only 1-bit precision! >> It won't be to the exact cent if printed to many decimals, but if you >> know it is supposed to represent values that end in exactly 0.00 to >> 0.99, then it will display properly if converted to text and rounded to >> 2 decimals. >> >> So it can be used to store such values. Calculating with it is a >> different matter if you are actually working with that kind of magnitude >> and actually need 1-cent accuracy and reproducability (which is going to >> be virtually nobody). >> >>> And if you're OK with using integers, but are afraid fixed-size ones (at >>> least 64 bits) could be an unacceptable limit down the road, just use >>> arbitrary precision arithmetic. And you don't need to hand-implement >>> that, unless it's your thing. GNU GMP is great. >> >> No, it isn't. It's a massive great dependency. If you really need to use >> it, look for GMP-lite (a solution using one .h and one .c file). >> >> However to me that would be a sign of someone who doesn't know what >> they're doing and just throws unnecessary precision at the problem in >> the hope it will magically fix any issues. >> > I checked a few real world financial implementations. > In Java, they have a class which can use either a 32-bit integer, a 64 bit integer, > or a "Big Decimal" as the underlying representation. 32 bits doesn't sound much but it will represent up to £21m to the exact penny. So fine for storage up to such limits, but you'd need a bigger type to do anything beyond adding and subtracting. > The recommendation is > to use the Big Decimal. Presumably it will scale to arbitrarily values. Say you have an amount of exactly EC$100.00 (a currency I've worked with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I believe this is the official exchange rate). The result is US$36.8066546431594832345688100408..., it goes on forever. To the nearest US cent, it'll be US$36.81, but it's approximate. You'd get that result with Big Decimal, float64, or float32. Big decimal hasn't helped here.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-04 21:38 +0000 |
| Message-ID | <j73BJ.272817$IW4.135808@fx48.iad> |
| In reply to | #164286 |
Bart <bc@freeuk.com> writes: >On 04/01/2022 18:52, Malcolm McLean wrote: >> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: >>> On 04/01/2022 17:18, Guillaume wrote: >>>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit : >>>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: >>>>>> will have been melted down for metal. So is 53 bits enough? I don't >>>>>> write programs that deal withh amounts of money, so I don't really >>>>>> know. However if I had to choose a C type, I'd probably go for >>>>>> integer representation of amounts in cents, using a double. >>>>> >>>>> A double is nice to represent not-100%-precise fractional units, >>>>> it really does not have its place in any kind of financial >>>>> program, esp. if the goal is storing cents anyway. >>>> >>>> Absolutely. Using FP for financial calculations is for people who don't >>>> know arithmetics. Maybe teaching some math (again) to CS students would >>>> help, here? :) >>>> >>>> At the very least, if you absolutely want to use FP for this, at least >>>> use decimal FP. Although it can still have precision issues due to its >>>> floating point nature, at least rounding will not yield gross errors. >>> >>> 64-bit floating point can represent values up to c. 10 trillion dollars >>> to the nearest cent. (I think the limit corresponds to the 2**52 bits of >>> precision.) >>> >> 53 bits. You get a "free" bit because the leading digit is always 1, except for >> zero, which has a special representation. > >If the 53rd bit is always 1, then isn't the precision determined by the >other 52 bits? > >So if a mantissa was only going to be 0b10 or 0b11, to me that's only >1-bit precision! > >>> It won't be to the exact cent if printed to many decimals, but if you >>> know it is supposed to represent values that end in exactly 0.00 to >>> 0.99, then it will display properly if converted to text and rounded to >>> 2 decimals. >>> >>> So it can be used to store such values. Calculating with it is a >>> different matter if you are actually working with that kind of magnitude >>> and actually need 1-cent accuracy and reproducability (which is going to >>> be virtually nobody). >>> >>>> And if you're OK with using integers, but are afraid fixed-size ones (at >>>> least 64 bits) could be an unacceptable limit down the road, just use >>>> arbitrary precision arithmetic. And you don't need to hand-implement >>>> that, unless it's your thing. GNU GMP is great. >>> >>> No, it isn't. It's a massive great dependency. If you really need to use >>> it, look for GMP-lite (a solution using one .h and one .c file). >>> >>> However to me that would be a sign of someone who doesn't know what >>> they're doing and just throws unnecessary precision at the problem in >>> the hope it will magically fix any issues. >>> >> I checked a few real world financial implementations. >> In Java, they have a class which can use either a 32-bit integer, a 64 bit integer, >> or a "Big Decimal" as the underlying representation. > >32 bits doesn't sound much but it will represent up to £21m to the exact >penny. So fine for storage up to such limits, but you'd need a bigger >type to do anything beyond adding and subtracting. > >> The recommendation is >> to use the Big Decimal. Presumably it will scale to arbitrarily values. > >Say you have an amount of exactly EC$100.00 (a currency I've worked >with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I >believe this is the official exchange rate). > >The result is US$36.8066546431594832345688100408..., it goes on forever. > >To the nearest US cent, it'll be US$36.81, but it's approximate. You'd >get that result with Big Decimal, float64, or float32. Big decimal >hasn't helped here. > $ printf "%u\n" $(( 1000000000 / 27169 )) 36806 Round the LSD and insert a decimal point.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-01-04 23:01 +0100 |
| Message-ID | <sr2g4l$13n1$1@gioia.aioe.org> |
| In reply to | #164286 |
On 1/4/2022 10:02 PM, Bart wrote: > On 04/01/2022 18:52, Malcolm McLean wrote: >> On Tuesday, 4 January 2022 at 18:41:20 UTC, Bart wrote: >>> On 04/01/2022 17:18, Guillaume wrote: >>>> Le 04/01/2022 à 09:23, Mateusz Viste a écrit : >>>>> 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: >>>>>> will have been melted down for metal. So is 53 bits enough? I don't >>>>>> write programs that deal withh amounts of money, so I don't really >>>>>> know. However if I had to choose a C type, I'd probably go for >>>>>> integer representation of amounts in cents, using a double. >>>>> >>>>> A double is nice to represent not-100%-precise fractional units, >>>>> it really does not have its place in any kind of financial >>>>> program, esp. if the goal is storing cents anyway. >>>> >>>> Absolutely. Using FP for financial calculations is for people who don't >>>> know arithmetics. Maybe teaching some math (again) to CS students would >>>> help, here? :) >>>> >>>> At the very least, if you absolutely want to use FP for this, at least >>>> use decimal FP. Although it can still have precision issues due to its >>>> floating point nature, at least rounding will not yield gross errors. >>> >>> 64-bit floating point can represent values up to c. 10 trillion dollars >>> to the nearest cent. (I think the limit corresponds to the 2**52 bits of >>> precision.) >>> >> 53 bits. You get a "free" bit because the leading digit is always 1, >> except for >> zero, which has a special representation. > > If the 53rd bit is always 1, then isn't the precision determined by the > other 52 bits? No, it's 53 bits of precision, or, in other words, 53 significant binary digits. The extra 1 bit is the result of proper choice of the exponent representation. However, it is not as if this extra bit came out of some magic, it has a price and it is called subnormal numbers (or denormals). > > So if a mantissa was only going to be 0b10 or 0b11, to me that's only > 1-bit precision! No, it's not about choosing an arbitrary prefix, it is the result of 2 facts: - any leading zeros can be converted into proper exponent adjustment, up to the limit given by the size of the exponent. - in binary arithmetic the first nonzero digit is always 1 :) > >>> It won't be to the exact cent if printed to many decimals, but if you >>> know it is supposed to represent values that end in exactly 0.00 to >>> 0.99, then it will display properly if converted to text and rounded to >>> 2 decimals. >>> >>> So it can be used to store such values. Calculating with it is a >>> different matter if you are actually working with that kind of magnitude >>> and actually need 1-cent accuracy and reproducability (which is going to >>> be virtually nobody). >>> >>>> And if you're OK with using integers, but are afraid fixed-size ones >>>> (at >>>> least 64 bits) could be an unacceptable limit down the road, just use >>>> arbitrary precision arithmetic. And you don't need to hand-implement >>>> that, unless it's your thing. GNU GMP is great. >>> >>> No, it isn't. It's a massive great dependency. If you really need to use >>> it, look for GMP-lite (a solution using one .h and one .c file). >>> >>> However to me that would be a sign of someone who doesn't know what >>> they're doing and just throws unnecessary precision at the problem in >>> the hope it will magically fix any issues. >>> >> I checked a few real world financial implementations. >> In Java, they have a class which can use either a 32-bit integer, a 64 >> bit integer, >> or a "Big Decimal" as the underlying representation. > > 32 bits doesn't sound much but it will represent up to £21m to the exact > penny. So fine for storage up to such limits, but you'd need a bigger > type to do anything beyond adding and subtracting. > >> The recommendation is >> to use the Big Decimal. Presumably it will scale to arbitrarily values. > > Say you have an amount of exactly EC$100.00 (a currency I've worked > with). You want to convert it to US$ at a rate of 1 US$ = $2.7169 EC$ (I > believe this is the official exchange rate). > > The result is US$36.8066546431594832345688100408..., it goes on forever. > > To the nearest US cent, it'll be US$36.81, but it's approximate. You'd > get that result with Big Decimal, float64, or float32. Big decimal > hasn't helped here. > Rounding errors smaller than a cent in the final result are obviously OK - they can't be helped, and such fractional difference couldn't be paid for anyway :) But the problem is that if you use naive FP arithmetic you may end up with errors in the final result that are larger than a cent (sometimes much larger), which is not OK.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-04 09:31 +0100 |
| Message-ID | <sr10lv$i2t$1@dont-email.me> |
| In reply to | #164256 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 01:30 -0800 |
| Message-ID | <2a287c23-ad75-45e8-befc-a8fdcdf19853n@googlegroups.com> |
| In reply to | #164261 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-04 14:55 +0100 |
| Message-ID | <sr1jk6$j9s$1@dont-email.me> |
| In reply to | #164263 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 06:21 -0800 |
| Message-ID | <423486e6-52bf-46ec-81c8-38d9b778903fn@googlegroups.com> |
| In reply to | #164267 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-04 16:49 +0100 |
| Message-ID | <sr1qat$60c$1@dont-email.me> |
| In reply to | #164268 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-01-04 15:56 +0000 |
| Message-ID | <sr1qob$2ndji$1@news.xmission.com> |
| In reply to | #164271 |
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
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-01-04 15:03 +0000 |
| Message-ID | <sr1nkf$2nc7j$1@news.xmission.com> |
| In reply to | #164263 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web