On Thursday, January 26, 2023 at 5:27:41 PM UTC-5, Arne Vajhøj wrote:
> On 1/26/2023 9:32 AM, Arne Vajhøj wrote:
> > I do not think the exact same problem can be recreated in
> > Basic (as far as I can read the documentation then Basic
> > does not allow static initialization in map's).
> >
> > But to show something in Basic it is easy to do with
> > assignment:
> >
> > program p
> >
> > map (d) long lw1, long lw2
> >
> > external sub s1, s2
> >
> > lw1 = 1
> > lw2 = 2
> >
> > call s1
> > call s2
> >
> > print lw1, lw2
> >
> > end program
> > !
> > sub s1
> >
> > map (d) word w1, word w2, word w3, word w4
> >
> > w2 = 1
> > w4 = 2
> >
> > end sub
> > !
> > sub s2
> >
> > map (d) byte b1, byte b2, byte b3, byte b4, byte b5, byte b6, byte b7,
> > byte b8
> >
> > b4 = 1
> > b8 = 2
> >
> > end sub
> >
> > $ bas p
> > $ lin p
> > $ r p
> > 16842753 33685506
> The Fortran version with static initialization (using data statements!)
> and no calls:
>
> $ type p2x.for
> program p2
> integer*4 lw1,lw2
> common /d/lw1,lw2
> data lw1/1/,lw2/2/
> write(*,*) lw1,lw2
> end
> $ for p2x
> $ type s1.for
> subroutine s1
> integer*2 w1,w2,w3,w4
> common /d/w1,w2,w3,w4
> data w2/1/,w4/2/
> end
> $ for s1
> $ type s2.for
> subroutine s2
> integer*1 b1,b2,b3,b4,b5,b6,b7,b8
> common /d/b1,b2,b3,b4,b5,b6,b7,b8
> data b4/1/,b8/2/
> end
> $ for s2
> $ link p2x + s1 + s2
> $ run p2x
> 16842753 33685506
> $ link p2x + s2 + s1
> $ run p2x
> 65537 131074
>
> (tested on VMS Alpha)
>
> The order of the OBJ files in the link command change the output.
>
> Yuck.
>
> Arne
Correct. My example was a condensed version of the problem report.
The original was multiple modules. My example is the worst case scenario
(both in terms of what the compiler has to handle and in terms of my sense
of decency). The static initializations is what I didn't consider in the past.

For BASIC, the example of

map (d) long lw1, long lw2

probably would accidentally create 4 longwords due to how BASIC describes
it to GEM. I didn't take a full survey of all the frontends back at the initial G2L
design. Mostly focused on C & BLISS (to boot the OS) followed by Fortran
and COBOL (we knew that packed decimal and complex needed special
attention).

And yes, I think Dave asked earlier. All of the frontends (C++ is different)
continue to generate GEM CIL and GEM symbol table. Having each frontend
generate its own LLVM IR would be much more work and you run the risk
of introducing subtle differences. Having the single conversion in G2L
is much better. The LLVM interface (which is in C++ and would be hard to
code to from BLISS-based frontends without an extensive set of jacket
routines [yes, LLVM has a C-based interface but it not well supported])
isn't upward compatible. We had to make changes to the G2L code from
the version that interfaces to the LLVM used for the cross compilers and
the newer LLVM used for the native compilers. Only a single place to change
by having G2L.

On 2023-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/26/2023 12:05 PM, Single Stage to Orbit wrote:
>> On Thu, 2023-01-26 at 11:50 -0500, Dave Froble wrote:
>>>> I am of the opinion that direct testing for equality of floating
>>>> point numbers should be disallowed by every language and that
>>>> people should be forced to use an alternative where _they_ have to
>>>> specify the delta value that 2 numbers should be within before they
>>>> are considered to be equal.
>>>
>>> Well, "have to" or not, that is the only method that works ...
>>
>> Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..

You are still directly comparing two approximations and as Arne points
out, it's not the same thing as using a delta value

>
> VB.NET?
>
> IF Math.Round(x,2) = Math.Round(y,2) THEN
>
> and:
>
> IF Math.Abs(x - y) < 0.01 THEN
>
> are not fully equivalent.
>

This is the only method that is truly robust when you are comparing
approximations instead of exact values.

(This assumes Abs() in the above example is really a floating point Abs()
instead of an integer Abs()).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thu, 2023-01-26 at 13:38 -0500, Arne Vajhøj wrote:
> > Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..
>
> VB.NET?
>
> IF Math.Round(x,2) = Math.Round(y,2) THEN
>
> and:
>
> IF Math.Abs(x - y) < 0.01 THEN
>
> are not fully equivalent.

Of course they aren't. But it is good enough for our purposes.
--
Tactical Nuclear Kittens

On 1/27/2023 1:42 PM, Single Stage to Orbit wrote:
> On Thu, 2023-01-26 at 13:38 -0500, Arne Vajhøj wrote:
>>> Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..
>>
>> VB.NET?
>>
>> IF Math.Round(x,2) = Math.Round(y,2) THEN
>>
>> and:
>>
>> IF Math.Abs(x - y) < 0.01 THEN
>>
>> are not fully equivalent.
>
> Of course they aren't. But it is good enough for our purposes.

I am not saying that one is better than the other
just that for some cases the test results will be
different.

Arne

On 1/27/2023 1:44 PM, Simon Clubley wrote:
> On 2023-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/26/2023 12:05 PM, Single Stage to Orbit wrote:
>>> On Thu, 2023-01-26 at 11:50 -0500, Dave Froble wrote:
>>>>> I am of the opinion that direct testing for equality of floating
>>>>> point numbers should be disallowed by every language and that
>>>>> people should be forced to use an alternative where _they_ have to
>>>>> specify the delta value that 2 numbers should be within before they
>>>>> are considered to be equal.
>>>>
>>>> Well, "have to" or not, that is the only method that works ...
>>>
>>> Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..
>
> You are still directly comparing two approximations

..NET spec for Round guarantees the best approximation.

> and as Arne points
> out, it's not the same thing as using a delta value

Yep.

>> VB.NET?
>>
>> IF Math.Round(x,2) = Math.Round(y,2) THEN
>>
>> and:
>>
>> IF Math.Abs(x - y) < 0.01 THEN
>>
>> are not fully equivalent.
>
> This is the only method that is truly robust when you are comparing
> approximations instead of exact values.

I think the optimal method depends on the context. And even
with the last method there is the big question of what is the right
value for the epsilon - there is no magic right answer.

In some contexts the relative difference may be better than the
absolute difference:

IF Math.Abs(x / y - 1.0) < 0.001 THEN

> (This assumes Abs() in the above example is really a floating point Abs()
> instead of an integer Abs()).

..NET has 8 overloads of Abs:

Abs(double) -> double
Abs(decimal) -> decimal
Abs(double,int) -> double
Abs(decimal,int) -> decimal
Abs(double,roundingmode) -> double
Abs(decimal,roundingmode) -> decimal
Abs(double,int,roundingmode) -> double
Abs(decimal,int,roundingmode) -> decimal

Arne

> I am not saying that one is better than the other [...]

I am. A reasonable test for approximate equality looks for a "small"
(absolute) difference between two values. Expecting two extremely close
values to round to the same value is not reasonable. (That is, it
doesn't always happen.)

"Equal when rounded" might seem plausible at first glance, but (even)
a little thought would reveal that it's an inferior test (because it
gives goofy results for values close to a round-down/up decision value).

> I think the optimal method depends on the context. And even
> with the last method there is the big question of what is the right
> value for the epsilon - there is no magic right answer.

Choosing a good parameter for a good test is important, but choosing
a good parameter for a good test should not be confused with choosing
between a good test and a foolish test.

On 1/27/2023 7:45 PM, Arne Vajhøj wrote:
> In some contexts the relative difference may be better than the
> absolute difference:
>
> IF Math.Abs(x / y - 1.0) < 0.001 THEN

25 years ago I liked this one:

const double FP_SMALL = 0.000001;
const double FP_ABS_SMALL_1 = -FP_SMALL;
const double FP_ABS_SMALL_2 = FP_SMALL;
const double FP_REL_SMALL_1 = 1-FP_SMALL;
const double FP_REL_SMALL_2 = 1+FP_SMALL;

BOOL num_eq(double x1,double x2)
{ double d;
if((-1<x2)&&(x2<1)) {
d = x1 - x2;
return ((FP_ABS_SMALL_1<d)&&(d<FP_ABS_SMALL_2));
} else {
d = x1 / x2;
return ((FP_REL_SMALL_1<d)&&(d<FP_REL_SMALL_2));
}
}

Apparently I did not like space around operators back then.

Arne

On 1/28/2023 12:46 AM, Steven Schweda wrote:
>> I am not saying that one is better than the other [...]
>
> I am. A reasonable test for approximate equality looks for a "small"
> (absolute) difference between two values.

Absolute difference is sensitive to the scale
of the data.

Sometimes relative difference makes more sense.

> Expecting two extremely close
> values to round to the same value is not reasonable. (That is, it
> doesn't always happen.)
>
> "Equal when rounded" might seem plausible at first glance, but (even)
> a little thought would reveal that it's an inferior test (because it
> gives goofy results for values close to a round-down/up decision value).

Consider the case where the numbers represent money.

The difference between 2.494 dollar/euro and 2.496 dollar/euro
are less than 0.01 but ...

Arne

On 2023-01-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/28/2023 12:46 AM, Steven Schweda wrote:
>>> I am not saying that one is better than the other [...]
>>
>> I am. A reasonable test for approximate equality looks for a "small"
>> (absolute) difference between two values.
>
> Absolute difference is sensitive to the scale
> of the data.
>
> Sometimes relative difference makes more sense.
>
>> Expecting two extremely close
>> values to round to the same value is not reasonable. (That is, it
>> doesn't always happen.)
> >
>> "Equal when rounded" might seem plausible at first glance, but (even)
>> a little thought would reveal that it's an inferior test (because it
>> gives goofy results for values close to a round-down/up decision value).
>
> Consider the case where the numbers represent money.
>
> The difference between 2.494 dollar/euro and 2.496 dollar/euro
> are less than 0.01 but ...
>

Hmmm. Do you own a red stapler by any chance ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

> [...] a "small" (absolute) difference between two values. [...]

> Absolute difference is sensitive to the scale
> of the data.

_My_ "absolute" was in the sense of "absolute value", as in
Math.Abs(). Any dependence on the scale was built into '"small"', not
"absolute". Hence the quotation marks around '"small"'.

> Consider the case where the numbers represent money.

Who cares what the numbers represent? For example, if you round to
the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
but one rounds to 1, and the other to 2, so the lame test says that
they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
both round to 2, so the lame test says that they're "equal". Any test
which treats a difference of 0.00002 as significant, and a difference of
0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
of what the numbers might represent.

On 1/28/2023 3:01 PM, Steven Schweda wrote:
>> Consider the case where the numbers represent money.
>
> Who cares what the numbers represent? For example, if you round to
> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
> but one rounds to 1, and the other to 2, so the lame test says that
> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
> both round to 2, so the lame test says that they're "equal". Any test
> which treats a difference of 0.00002 as significant, and a difference of
> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
> of what the numbers might represent.

There are some specific rules for money usually about
always rounding 2 digits.

1494 dollars divided by 1000 = 1.494 get rounded to 1.49
diff 0.002 not equal
1496 dollars divided by 1000 = 1.496 get rounded to 1.50

1496 dollars divided by 1000 = 1.496 get rounded to 1.50
diff 0.008 equal
1504 dollars divided by 1000 = 1.504 get rounded to 1.50

Arne

PS: One should never use traditional binary based floating
point for storing money instead use some decimal based
type. But sometimes calculations switch to floating point
anyway.

On 1/28/2023 3:01 PM, Steven Schweda wrote:
>> [...] a "small" (absolute) difference between two values. [...]
>> Absolute difference is sensitive to the scale
>> of the data.
>
> _My_ "absolute" was in the sense of "absolute value", as in
> Math.Abs(). Any dependence on the scale was built into '"small"', not
> "absolute". Hence the quotation marks around '"small"'.

Yes.

But it can be difficult to determine upfront what a good value
for small it with absolute if one does not know the magnitude of
the numbers up front.

Relative difference is much more robust for that problem.

But relative difference has a problem with numbers
close to zero.

Arne

On 2023-01-28 23:35, Arne Vajhøj wrote:
> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>> Consider the case where the numbers represent money.
>>
>>     Who cares what the numbers represent?  For example, if you round to
>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>> but one rounds to 1, and the other to 2, so the lame test says that
>> they're "unequal".  And 1.50001 and 2.49999 differ by 0.99998, but they
>> both round to 2, so the lame test says that they're "equal".  Any test
>> which treats a difference of 0.00002 as significant, and a difference of
>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>> of what the numbers might represent.
>
> There are some specific rules for money usually about
> always rounding 2 digits.
>
> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>                               diff 0.002          not equal
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>                               diff 0.008            equal
> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
> Arne
>
> PS: One should never use traditional binary based floating
>     point for storing money instead use some decimal based
>     type. But sometimes calculations switch to floating point
>     anyway.

So by your own example, two values differing by 0.002 could be
considered not equal, but two values differing by 0.008 could be
considered equal. Don't you see that this leads to a very bad algorithm
for comparing for approximate equal?

More generally, 0.002 of difference might be considered equal or not
equal purely based on what the actual values are. For some, they will be
equal, and for some others not. The delta that is required for two
numbers to be considered unequal varies based on what the actual numbers
are.

At least in my book, that is a clear indication that it's a very bad method.

Johnny

> But it can be difficult to determine upfront what a good value
> for small it with absolute if one does not know the magnitude of
> the numbers up front.

The magnitude of the numbers might not matter as much as the number
of bits in the mantissa.

Everything's complicated, but a bad method (like, say, comparing
rounded values) is still a bad method. (I claim.)

On 1/28/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-01-28 23:35, Arne Vajhøj wrote:
>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>> Consider the case where the numbers represent money.
>>>
>>>     Who cares what the numbers represent?  For example, if you round to
>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>> but one rounds to 1, and the other to 2, so the lame test says that
>>> they're "unequal".  And 1.50001 and 2.49999 differ by 0.99998, but they
>>> both round to 2, so the lame test says that they're "equal".  Any test
>>> which treats a difference of 0.00002 as significant, and a difference of
>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>> of what the numbers might represent.
>>
>> There are some specific rules for money usually about
>> always rounding 2 digits.
>>
>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>>                                diff 0.002          not equal
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>                                diff 0.008            equal
>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50

> So by your own example, two values differing by 0.002 could be
> considered not equal, but two values differing by 0.008 could be
> considered equal. Don't you see that this leads to a very bad algorithm
> for comparing for approximate equal?
>
> More generally, 0.002 of difference might be considered equal or not
> equal purely based on what the actual values are. For some, they will be
> equal, and for some others not. The delta that is required for two
> numbers to be considered unequal varies based on what the actual numbers
> are.
>
> At least in my book, that is a clear indication that it's a very bad
> method.

I am not sure that I get your point.

This is how rounding of money works.

Software that operate on money needs to implement
the rules.

Same reason that good rounding supports different
rounding mode: UP (round .5 up), EVEN (round .5 to
even) etc.. Different places has different rules and
the software need to implement those.

Arne

On 1/28/2023 5:35 PM, Arne Vajhøj wrote:
> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>> Consider the case where the numbers represent money.
>>
>> Who cares what the numbers represent? For example, if you round to
>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>> but one rounds to 1, and the other to 2, so the lame test says that
>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>> both round to 2, so the lame test says that they're "equal". Any test
>> which treats a difference of 0.00002 as significant, and a difference of
>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>> of what the numbers might represent.
>
> There are some specific rules for money usually about
> always rounding 2 digits.
>
> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
> diff 0.002 not equal
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
> diff 0.008 equal
> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
> Arne
>
> PS: One should never use traditional binary based floating
> point for storing money instead use some decimal based
> type. But sometimes calculations switch to floating point
> anyway.

For maybe 45 years I've used FP (D-float) for monetary transactions and storage.
Never any problems. The secret is understanding what one is doing.

It is not always simple. Consider products with cost and prices using thousands
and even ten thousands, ie; .001 or .0001. Think of things such as golf tees,
sold by the bag, or rather large quantities. The final calculations will be
less than $.01 off, but that is acceptable. Now, sales analysis, where perhaps
millions of items are considered, can get off a bit. Usually acceptable. But,
rounding will cause some small discrepancies.

Yes, I can understand situations where D-float just won't do the job.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/28/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-01-28 23:35, Arne Vajhøj wrote:
>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>> Consider the case where the numbers represent money.
>>>
>>> Who cares what the numbers represent? For example, if you round to
>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>> but one rounds to 1, and the other to 2, so the lame test says that
>>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>>> both round to 2, so the lame test says that they're "equal". Any test
>>> which treats a difference of 0.00002 as significant, and a difference of
>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>> of what the numbers might represent.
>>
>> There are some specific rules for money usually about
>> always rounding 2 digits.
>>
>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>> diff 0.002 not equal
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>> diff 0.008 equal
>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>>
>> Arne
>>
>> PS: One should never use traditional binary based floating
>> point for storing money instead use some decimal based
>> type. But sometimes calculations switch to floating point
>> anyway.
>
> So by your own example, two values differing by 0.002 could be considered not
> equal, but two values differing by 0.008 could be considered equal. Don't you
> see that this leads to a very bad algorithm for comparing for approximate equal?
>
> More generally, 0.002 of difference might be considered equal or not equal
> purely based on what the actual values are. For some, they will be equal, and
> for some others not. The delta that is required for two numbers to be considered
> unequal varies based on what the actual numbers are.
>
> At least in my book, that is a clear indication that it's a very bad method.
>
> Johnny

My rule of thumb, when working with US$, is that any difference greater than
..001 is not equal.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/28/2023 7:25 PM, Arne Vajhøj wrote:
> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>> Consider the case where the numbers represent money.
>>>>
>>>> Who cares what the numbers represent? For example, if you round to
>>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>>> but one rounds to 1, and the other to 2, so the lame test says that
>>>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>>>> both round to 2, so the lame test says that they're "equal". Any test
>>>> which treats a difference of 0.00002 as significant, and a difference of
>>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>>> of what the numbers might represent.
>>>
>>> There are some specific rules for money usually about
>>> always rounding 2 digits.
>>>
>>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>>> diff 0.002 not equal
>>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>>
>>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>> diff 0.008 equal
>>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
>> So by your own example, two values differing by 0.002 could be considered not
>> equal, but two values differing by 0.008 could be considered equal. Don't you
>> see that this leads to a very bad algorithm for comparing for approximate equal?
>>
>> More generally, 0.002 of difference might be considered equal or not equal
>> purely based on what the actual values are. For some, they will be equal, and
>> for some others not. The delta that is required for two numbers to be
>> considered unequal varies based on what the actual numbers are.
>>
>> At least in my book, that is a clear indication that it's a very bad method.
>
> I am not sure that I get your point.
>
> This is how rounding of money works.
>
> Software that operate on money needs to implement
> the rules.
>
> Same reason that good rounding supports different
> rounding mode: UP (round .5 up), EVEN (round .5 to
> even) etc.. Different places has different rules and
> the software need to implement those.
>
> Arne

Perhaps you mean .005 ???

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/28/2023 6:36 PM, Steven Schweda wrote:
>> But it can be difficult to determine upfront what a good value
>> for small it with absolute if one does not know the magnitude of
>> the numbers up front.
>
> The magnitude of the numbers might not matter as much as the number
> of bits in the mantissa.
>
> Everything's complicated, but a bad method (like, say, comparing
> rounded values) is still a bad method. (I claim.)
>

And you'd be 100% correct. It is the amount of the difference that matters.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

>On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>> Consider the case where the numbers represent money.
>>>>
>>>> Who cares what the numbers represent? For example, if you round to

One of the absolute FIRST things that I was told about floating point
variables in my first programming class was to NEVER use them to represent
money.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/28/2023 8:16 PM, Dave Froble wrote:
> On 1/28/2023 5:35 PM, Arne Vajhøj wrote:
>> PS: One should never use traditional binary based floating
>>     point for storing money instead use some decimal based
>>     type. But sometimes calculations switch to floating point
>>     anyway.
>
> For maybe 45 years I've used FP (D-float) for monetary transactions and
> storage.  Never any problems.  The secret is understanding what one is
> doing.
>
> It is not always simple.  Consider products with cost and prices using
> thousands and even ten thousands, ie; .001 or .0001.  Think of things
> such as golf tees, sold by the bag, or rather large quantities.  The
> final calculations will be less than $.01 off, but that is acceptable.
> Now, sales analysis, where perhaps millions of items are considered, can
> get off a bit.  Usually acceptable.  But, rounding will cause some small
> discrepancies.

I find it hard to see why one would bother with the risks
of using floating point if a decimal type is available.

VMS Basic has a decimal type.

So has Cobol and most of the post-1990 languages.

The C crowd are missing out.

Arne

On 1/28/2023 8:19 PM, Dave Froble wrote:
> On 1/28/2023 7:25 PM, Arne Vajhøj wrote:
>> Same reason that good rounding supports different
>> rounding mode: UP (round .5 up), EVEN (round .5 to
>> even) etc.. Different places has different rules and
>> the software need to implement those.
>
> Perhaps you mean .005 ???

With 2 decimals then yes.

Arne

On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>> Consider the case where the numbers represent money.
>>>>>
>>>>> Who cares what the numbers represent? For example, if you round to
>
> One of the absolute FIRST things that I was told about floating point
> variables in my first programming class was to NEVER use them to represent
> money.

It is known to be problematic.

But there are 3 cases where it happens anyway:
- the developer does not care
- the language used does not have a decimal type and
integers with implied decimal is considered to
cumbersome
- decimal is actually used in general, but certain
calculations temporarily move over in floating
point (like some interest calculations)

Arne

On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>> Consider the case where the numbers represent money.
>>>>>
>>>>> Who cares what the numbers represent? For example, if you round to
>
> One of the absolute FIRST things that I was told about floating point
> variables in my first programming class was to NEVER use them to represent
> money.
> --scott
>

What if you didn't have a choice?

RSTS/E V04b

Signed word integers
Strings
Single and double D-float

That's all there was ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/28/2023 10:39 PM, Dave Froble wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>
> What if you didn't have a choice?
>
> RSTS/E V04b
>
> Signed word integers
> Strings
> Single and double D-float
>
> That's all there was ...

There is always integers and implied decimal.

Not fun though.

And one need an integer with enough bits ...

Could PDP-11 do 32 bit integers?

Arne