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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-01-01 00:53 +0000 |
| Message-ID | <sqo8mt$cmr$1@dont-email.me> |
| In reply to | #164186 |
On 01/01/2022 00:35, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 31/12/2021 23:13, James Kuyper wrote: >> Then the regulators should themselves provide a library that performs >> arithmetic or other calculations according to their standards. > > Are you sure they don't? I'm not. If they do then you use that and be done with it. But it's little to with learning to program. > And if they don't -- is the ISO C committee obligated to provide a > conforming C implementation? > > It's not my field and I don't know the details. Unlike you, I admit that. > >> That's if someone is working on software where this is an actual necessity. >> >> I'm just fed up with people always bringing this up on forums when >> some quantity might involve money. Those advanced requirements are >> heavily dependent on application areas, and little to do with basic >> programming, especially when a language doesn't provide the special >> types (scaled integers etc) that might be needed. > > As several of us have acknowledged, using floating-point for money is > probably fine for toy or introductory programs. It's not ok for any > application that interacts with financial regulations. And I'm fed up > with you whining when anyone points that out. I'm sure that many other industries have their own standards and their own requirements when it comes to numbers representing values relevant to their fields. But no, it's always the ones representing money! As a matter of interest (no pun!), if you were writing some program in C, to do say stock reports on sales in your shop (so it's not exactly a toy, and you're not a beginner), what type would you use for those monetary amounts? Say the info is input from CSV file for example.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-12-31 20:22 -0800 |
| Message-ID | <87r19s13w2.fsf@nosuchdomain.example.com> |
| In reply to | #164188 |
Bart <bc@freeuk.com> writes:
> On 01/01/2022 00:35, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/12/2021 23:13, James Kuyper wrote:
>
>>> Then the regulators should themselves provide a library that performs
>>> arithmetic or other calculations according to their standards.
>> Are you sure they don't? I'm not.
>
> If they do then you use that and be done with it. But it's little to
> with learning to program.
>
>> And if they don't -- is the ISO C committee obligated to provide a
>> conforming C implementation?
>> It's not my field and I don't know the details. Unlike you, I admit
>> that.
>>
>>> That's if someone is working on software where this is an actual necessity.
>>>
>>> I'm just fed up with people always bringing this up on forums when
>>> some quantity might involve money. Those advanced requirements are
>>> heavily dependent on application areas, and little to do with basic
>>> programming, especially when a language doesn't provide the special
>>> types (scaled integers etc) that might be needed.
>> As several of us have acknowledged, using floating-point for money
>> is
>> probably fine for toy or introductory programs. It's not ok for any
>> application that interacts with financial regulations. And I'm fed up
>> with you whining when anyone points that out.
>
> I'm sure that many other industries have their own standards and their
> own requirements when it comes to numbers representing values relevant
> to their fields.
>
> But no, it's always the ones representing money!
That seems to be what comes up most often here.
Somebody asks about what's probably a student-level program that deals
with money. Somebody else mentions that there are rules in place that
have to be followed if you're dealing with money in a professional
context. I think that's a good thing to be aware of even if you don't
have to deal with all the issues directly.
It's an example, one among many, of an area where the inexactness of
floating-point calculations can cause problems -- and that's something
that most programmers need to be aware of.
And then you tell us you're "fed up" with it being mentioned. Too bad.
> As a matter of interest (no pun!), if you were writing some program in
> C, to do say stock reports on sales in your shop (so it's not exactly
> a toy, and you're not a beginner), what type would you use for those
> monetary amounts?
>
> Say the info is input from CSV file for example.
I don't know. If all I have to worry about is adding and subtracting
quantities that are always whole numbers of cents, I'd probably use a
sufficiently wide integer type with a scale factor of 100. If I had to
deal with computations that can yield fractional cents, I'd find out
what the detailed requirements are, and ask what libraries are available
to help implement those requirements.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-12-31 22:04 -0800 |
| Message-ID | <9cca58b2-8310-45bb-98ac-4b71dc267a90n@googlegroups.com> |
| In reply to | #164192 |
On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote: > Bart <b...@freeuk.com> writes: > > On 01/01/2022 00:35, Keith Thompson wrote: > >> Bart <b...@freeuk.com> writes: > >>> On 31/12/2021 23:13, James Kuyper wrote: > > > >>> Then the regulators should themselves provide a library that performs > >>> arithmetic or other calculations according to their standards. > >> Are you sure they don't? I'm not. > > > > If they do then you use that and be done with it. But it's little to > > with learning to program. > > > >> And if they don't -- is the ISO C committee obligated to provide a > >> conforming C implementation? > >> It's not my field and I don't know the details. Unlike you, I admit > >> that. > >> > >>> That's if someone is working on software where this is an actual necessity. > >>> > >>> I'm just fed up with people always bringing this up on forums when > >>> some quantity might involve money. Those advanced requirements are > >>> heavily dependent on application areas, and little to do with basic > >>> programming, especially when a language doesn't provide the special > >>> types (scaled integers etc) that might be needed. > >> As several of us have acknowledged, using floating-point for money > >> is > >> probably fine for toy or introductory programs. It's not ok for any > >> application that interacts with financial regulations. And I'm fed up > >> with you whining when anyone points that out. > > > > I'm sure that many other industries have their own standards and their > > own requirements when it comes to numbers representing values relevant > > to their fields. > > > > But no, it's always the ones representing money! > That seems to be what comes up most often here. > > Somebody asks about what's probably a student-level program that deals > with money. Somebody else mentions that there are rules in place that > have to be followed if you're dealing with money in a professional > context. I think that's a good thing to be aware of even if you don't > have to deal with all the issues directly. > > It's an example, one among many, of an area where the inexactness of > floating-point calculations can cause problems -- and that's something > that most programmers need to be aware of. > > And then you tell us you're "fed up" with it being mentioned. Too bad. > > As a matter of interest (no pun!), if you were writing some program in > > C, to do say stock reports on sales in your shop (so it's not exactly > > a toy, and you're not a beginner), what type would you use for those > > monetary amounts? > > > > Say the info is input from CSV file for example. > I don't know. If all I have to worry about is adding and subtracting > quantities that are always whole numbers of cents, I'd probably use a > sufficiently wide integer type with a scale factor of 100. If I had to > deal with computations that can yield fractional cents, I'd find out > what the detailed requirements are, and ask what libraries are available > to help implement those requirements. > Why not use a double, and represent the amount in cents? That gives you 53 bits. However if Biden's stimulus package goes through and the USA experiences hyperinflation, then the program will scale to sausages costing quadrillions of dollars - people won't worry about small errors in the cents under such circumstances. And if you need to represent a fractional number of cents, you can still do that, admittedly with some issues, but without knowing the exact rules and circumstances under which fractions of cents can be created, it's impossible to get away from those issues.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-01 14:59 -0800 |
| Message-ID | <87k0fj12r3.fsf@nosuchdomain.example.com> |
| In reply to | #164193 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
[...]
>> I don't know. If all I have to worry about is adding and subtracting
>> quantities that are always whole numbers of cents, I'd probably use a
>> sufficiently wide integer type with a scale factor of 100. If I had to
>> deal with computations that can yield fractional cents, I'd find out
>> what the detailed requirements are, and ask what libraries are available
>> to help implement those requirements.
>>
> Why not use a double, and represent the amount in cents? That gives you
> 53 bits.
Why? long long gives you 63 bits. When floating-point gives you inexact
results, it does so silently. What advantage does double give you over
long long?
[politics deleted]
> And if you need to represent a
> fractional number of cents, you can still do that, admittedly with some
> issues, but without knowing the exact rules and circumstances under
> which fractions of cents can be created, it's impossible to get away from
> those issues.
Which is why you need to follow the relevant rules, which means you need
to find out what they are before you start writing code.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-02 17:22 -0800 |
| Message-ID | <0858a55c-fdd7-4aa8-9c56-0ec3b04840f4n@googlegroups.com> |
| In reply to | #164208 |
On Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote: > [...] > >> I don't know. If all I have to worry about is adding and subtracting > >> quantities that are always whole numbers of cents, I'd probably use a > >> sufficiently wide integer type with a scale factor of 100. If I had to > >> deal with computations that can yield fractional cents, I'd find out > >> what the detailed requirements are, and ask what libraries are available > >> to help implement those requirements. > >> > > Why not use a double, and represent the amount in cents? That gives you > > 53 bits. > Why? long long gives you 63 bits. When floating-point gives you inexact > results, it does so silently. What advantage does double give you over > long long? > > [politics deleted] > You've deleted the reason. Which is inherently political. Some crazy politican decides to do what is called "monetary financing", basically printing money rather than collecting taxes. Result, runaway inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can no longer cope (for a decent-sized burger joint). Floating point however degrades gracefully until you hit figures so high that even hyperinflation is unlikely to reach them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-02 20:49 -0800 |
| Message-ID | <87bl0t1l05.fsf@nosuchdomain.example.com> |
| In reply to | #164228 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote:
>> [...]
>> >> I don't know. If all I have to worry about is adding and subtracting
>> >> quantities that are always whole numbers of cents, I'd probably use a
>> >> sufficiently wide integer type with a scale factor of 100. If I had to
>> >> deal with computations that can yield fractional cents, I'd find out
>> >> what the detailed requirements are, and ask what libraries are available
>> >> to help implement those requirements.
>> >>
>> > Why not use a double, and represent the amount in cents? That gives you
>> > 53 bits.
>> Why? long long gives you 63 bits. When floating-point gives you inexact
>> results, it does so silently. What advantage does double give you over
>> long long?
>>
>> [politics deleted]
>>
> You've deleted the reason. Which is inherently political.
> Some crazy politican decides to do what is called "monetary financing",
> basically printing money rather than collecting taxes. Result, runaway
> inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can
> no longer cope (for a decent-sized burger joint). Floating point however
> degrades gracefully until you hit figures so high that even hyperinflation
> is unlikely to reach them.
If you're operating under regulations that say that "degrading
gracefully" is acceptable, you can use floating-point.
I won't discuss politics here.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-03 03:09 -0800 |
| Message-ID | <f96e4ea3-3c52-4869-99c6-c0806621b40cn@googlegroups.com> |
| In reply to | #164229 |
On Monday, 3 January 2022 at 04:49:56 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Saturday, 1 January 2022 at 22:59:43 UTC, Keith Thompson wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > On Saturday, 1 January 2022 at 04:22:50 UTC, Keith Thompson wrote: > >> [...] > >> >> I don't know. If all I have to worry about is adding and subtracting > >> >> quantities that are always whole numbers of cents, I'd probably use a > >> >> sufficiently wide integer type with a scale factor of 100. If I had to > >> >> deal with computations that can yield fractional cents, I'd find out > >> >> what the detailed requirements are, and ask what libraries are available > >> >> to help implement those requirements. > >> >> > >> > Why not use a double, and represent the amount in cents? That gives you > >> > 53 bits. > >> Why? long long gives you 63 bits. When floating-point gives you inexact > >> results, it does so silently. What advantage does double give you over > >> long long? > >> > >> [politics deleted] > >> > > You've deleted the reason. Which is inherently political. > > Some crazy politican decides to do what is called "monetary financing", > > basically printing money rather than collecting taxes. Result, runaway > > inflation, and a hamburger costs 4 quadrillion dollars. 63 bits can > > no longer cope (for a decent-sized burger joint). Floating point however > > degrades gracefully until you hit figures so high that even hyperinflation > > is unlikely to reach them. > If you're operating under regulations that say that "degrading > gracefully" is acceptable, you can use floating-point. > > I won't discuss politics here. > When hamburgers cost 4 quadrillion dollars, it's likely that everyone has more to worry about than financial software rounding errors of a few cents. However at least the system still works after a fashion. Systems using fixed point will fall over, compounding the social chaos.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-03 16:22 +0000 |
| Message-ID | <epFAJ.89625$L_2.75848@fx04.iad> |
| In reply to | #164232 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >When hamburgers cost 4 quadrillion dollars, Leave out of this group the absurdist political rhetoric, please.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-03 14:42 -0800 |
| Message-ID | <8735m41lwy.fsf@nosuchdomain.example.com> |
| In reply to | #164232 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-03 14:52 -0800 |
| Message-ID | <b2918a53-acd6-4c46-9b58-6ac578bc055cn@googlegroups.com> |
| In reply to | #164250 |
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?
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-01-03 22:58 +0000 |
| Message-ID | <sqvv2q$2mftp$2@news.xmission.com> |
| In reply to | #164251 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 04:27 -0800 |
| Message-ID | <9f5ceaf1-e9b6-4c0c-82c8-bfd437049565n@googlegroups.com> |
| In reply to | #164253 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-01-04 13:39 +0000 |
| Message-ID | <sr1ime$2na2l$1@news.xmission.com> |
| In reply to | #164265 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-04 00:18 +0100 |
| Message-ID | <sr007f$9oh$1@dont-email.me> |
| In reply to | #164251 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-03 15:24 -0800 |
| Message-ID | <87y23wz9l9.fsf@nosuchdomain.example.com> |
| In reply to | #164251 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-03 15:43 -0800 |
| Message-ID | <ff338dd2-a4fe-4b06-8b4a-e3622b666c9en@googlegroups.com> |
| In reply to | #164255 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-01-03 21:19 -0800 |
| Message-ID | <e147a8dd-97fe-445b-86f2-fe23a9a10642n@googlegroups.com> |
| In reply to | #164256 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-04 09:23 +0100 |
| Message-ID | <sr1058$1thv$1@gioia.aioe.org> |
| In reply to | #164256 |
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
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2022-01-04 18:18 +0100 |
| Message-ID | <sr1vgu$u1j$1@gioia.aioe.org> |
| In reply to | #164260 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-01-04 10:35 -0800 |
| Message-ID | <5700fe69-acd6-4700-8b40-e48ad349fe33n@googlegroups.com> |
| In reply to | #164275 |
On Tuesday, 4 January 2022 at 17:18:36 UTC, Guillaume wrote: > Le 04/01/2022 à 09:23, Mateusz Viste a écrit : > > 2022-01-03 at 15:43 -0800, Malcolm McLean wrote: > >> will have been melted down for metal. So is 53 bits enough? I don't > >> write programs that deal withh amounts of money, so I don't really > >> know. However if I had to choose a C type, I'd probably go for > >> integer representation of amounts in cents, using a double. > > > > A double is nice to represent not-100%-precise fractional units, > > it really does not have its place in any kind of financial > > program, esp. if the goal is storing cents anyway. > Absolutely. Using FP for financial calculations is for people who don't > know arithmetics. Maybe teaching some math (again) to CS students would > help, here? :) > > At the very least, if you absolutely want to use FP for this, at least > use decimal FP. Although it can still have precision issues due to its > floating point nature, at least rounding will not yield gross errors. > > And if you're OK with using integers, but are afraid fixed-size ones (at > least 64 bits) could be an unacceptable limit down the road, just use > arbitrary precision arithmetic. And you don't need to hand-implement > that, unless it's your thing. GNU GMP is great. > > One of the many problems with FP can be easily shown. Apart from the > usual unability to represent some numbers exactly, they also have an > inherent problem when, for instance, adding very small numbers to very > large ones. > > Of course if all you do is writing "toy programs", use whatever. But > somehow, if this is a student work, I would have a problem with calling > student exercises "toy programs". That would certainly give them the > wrong idea about how to do things properly. If they once used FP for > financial operations, even on a small exercise, how can you know they > won't do the same later on at work when having to write code dealing > with financial calculations? > The central difficulty is that people have no problem with the idea that an integer type should hold an amount in cents. But for some reason they think that a floating point type must hold an amount in dollars. Probably because an amount of 110 cents is always written as 1.10 dollars for the end-user. Once you make that leap, you'll see that you can use floating point types to represent integers.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web