I have some calculations that can result in -Infini or -NAN. In the case of -Infini, a comparison using F< appears to handle the value correctly, treating it as the most negative value possible I expect.

In the case of -NAN, it also treats it as a very negative number, less than -85 anyway. This confuses me. This value arises when the input data is all zeros because the unit under test is not seeing a signal and measures zero for all readings. Because there is a log of a ratio, when that ratio is zero the log produces -Inifini. When all values are zero, the division is 0/0 resulting in -NAN, both before and after the log.

This is not a big problem. The -Infini case is actually the unit working correctly and the test passes. When all the data measured is zeros, there is a significant problem with the UUT and it is not so important this test fails. There are other tests using the same data that will also fail. I'd just like it to be consistent across the tests.

I suppose I could simply have it not report anything after the first failure which is a check on the amplitude at 1 kHz, a baseline test I suppose.

Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever? I tried a few tests...

1e0 0e0 f/ f. Infini ok
-1e0 0e0 f/ f. -Infini ok
0e0 0e0 f/ f. -NAN ok
+0e0 0e0 f/ f. -NAN ok
0e0 +0e0 f/ f. -NAN ok
+0e0 +0e0 f/ f. -NAN ok

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 28/05/2022 14:48, Rick C wrote:
> ...
> Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever? I tried a few tests...
>
> 1e0 0e0 f/ f. Infini ok
> -1e0 0e0 f/ f. -Infini ok
> 0e0 0e0 f/ f. -NAN ok
> +0e0 0e0 f/ f. -NAN ok
> 0e0 +0e0 f/ f. -NAN ok
> +0e0 +0e0 f/ f. -NAN ok

IEEE-754 doesn't recognize signed NAN (after all it's "Not-A-Number").
Printing NANs along with the sign bit is what many systems do, however.
As to why the negative bit was set for div-zero (a mathematically
undefined operation), one would have to ask Intel or Kahan. BTW it
would have been just as valid for the system to throw an error:

0e 0e f/ FLOAT_INVALID_OPERATION at 00489841 F/ +2

Rick C <gnuarm.deletethisbit@gmail.com> writes:
>I have some calculations that can result in -Infini or -NAN. In the case o=
>f -Infini, a comparison using F< appears to handle the value correctly, tre=
>ating it as the most negative value possible I expect. =20
>
>In the case of -NAN, it also treats it as a very negative number, less than=
> -85 anyway.

What makes you think so? NaNs are unordered wrt other FP values
(including NaNs), so you get:

0e 0e f/ fconstant nan ok
nan f. NaN ok
nan -85e f>= . 0 ok
nan -85e f< . 0 ok

The only comparison that produces true when you compare with a NaN is F<>:

nan nan f<> . -1 ok

>Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever?=

The sign of a NaN does not matter.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

gnuarm.del...@gmail.com schrieb am Samstag, 28. Mai 2022 um 06:48:49 UTC+2:
> I have some calculations that can result in -Infini or -NAN. In the case of -Infini, a comparison using F< appears to handle the value correctly, treating it as the most negative value possible I expect.
>
> In the case of -NAN, it also treats it as a very negative number, less than -85 anyway. This confuses me. This value arises when the input data is all zeros because the unit under test is not seeing a signal and measures zero for all readings. Because there is a log of a ratio, when that ratio is zero the log produces -Inifini. When all values are zero, the division is 0/0 resulting in -NAN, both before and after the log.
>
> This is not a big problem. The -Infini case is actually the unit working correctly and the test passes. When all the data measured is zeros, there is a significant problem with the UUT and it is not so important this test fails. There are other tests using the same data that will also fail. I'd just like it to be consistent across the tests.
>
> I suppose I could simply have it not report anything after the first failure which is a check on the amplitude at 1 kHz, a baseline test I suppose.
>
> Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever? I tried a few tests...
>
> 1e0 0e0 f/ f. Infini ok
> -1e0 0e0 f/ f. -Infini ok
> 0e0 0e0 f/ f. -NAN ok
> +0e0 0e0 f/ f. -NAN ok
> 0e0 +0e0 f/ f. -NAN ok
> +0e0 +0e0 f/ f. -NAN ok

The sign just reflects the meaningless sign bit of the binary representation range of NaNs.

Comparison between NaN and any floating-point value x (including NaN and ±∞)
NaN ≥ x NaN ≤ x NaN > x NaN < x NaN = x NaN ≠ x
False False False False False True

From these rules, x ≠ x or x = x can be used to test whether x is NaN or non-NaN.

BTW the Standard Forth test suite comprises a file ieee-arith-test.fs for fp operations with NaNs.

On Saturday, May 28, 2022 at 3:17:20 PM UTC-4, minf...@arcor.de wrote:
> gnuarm.del...@gmail.com schrieb am Samstag, 28. Mai 2022 um 06:48:49 UTC+2:
> > I have some calculations that can result in -Infini or -NAN. In the case of -Infini, a comparison using F< appears to handle the value correctly, treating it as the most negative value possible I expect.
> >
> > In the case of -NAN, it also treats it as a very negative number, less than -85 anyway. This confuses me. This value arises when the input data is all zeros because the unit under test is not seeing a signal and measures zero for all readings. Because there is a log of a ratio, when that ratio is zero the log produces -Inifini. When all values are zero, the division is 0/0 resulting in -NAN, both before and after the log.
> >
> > This is not a big problem. The -Infini case is actually the unit working correctly and the test passes. When all the data measured is zeros, there is a significant problem with the UUT and it is not so important this test fails. There are other tests using the same data that will also fail. I'd just like it to be consistent across the tests.
> >
> > I suppose I could simply have it not report anything after the first failure which is a check on the amplitude at 1 kHz, a baseline test I suppose..
> >
> > Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever? I tried a few tests...
> >
> > 1e0 0e0 f/ f. Infini ok
> > -1e0 0e0 f/ f. -Infini ok
> > 0e0 0e0 f/ f. -NAN ok
> > +0e0 0e0 f/ f. -NAN ok
> > 0e0 +0e0 f/ f. -NAN ok
> > +0e0 +0e0 f/ f. -NAN ok
> The sign just reflects the meaningless sign bit of the binary representation range of NaNs.
>
> Comparison between NaN and any floating-point value x (including NaN and ±∞)
> NaN ≥ x NaN ≤ x NaN > x NaN < x NaN = x NaN ≠ x
> False False False False False True
>
> From these rules, x ≠ x or x = x can be used to test whether x is NaN or non-NaN.
>
> BTW the Standard Forth test suite comprises a file ieee-arith-test.fs for fp operations with NaNs.

In the end, I found that Win32Forth defines how the various operators handle NaNs. So I reversed the sense of the test so a NaN in the inputs would cause a test failure.

Thanks for the info.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On 5/28/22 14:17, minf...@arcor.de wrote:

> ...
> Comparison between NaN and any floating-point value x (including NaN and ±∞)
> NaN ≥ x NaN ≤ x NaN > x NaN < x NaN = x NaN ≠ x
> False False False False False True
>
> From these rules, x ≠ x or x = x can be used to test whether x is NaN or non-NaN.
>
> BTW the Standard Forth test suite comprises a file ieee-arith-test.fs for fp operations with NaNs.

The ieee-arith-test.fs tests do not contain comparsion tests with NaN --
at least the version which is bundled with kForth does not contain any
comparison tests.

To my chagrin, I discovered yesterday that kForth-64/32 does not conform
to the IEEE 754 rules for comparison of floating point values with NaN.
I found this out the long way, after a recent calculation I was doing
caused memory corruption because an unexpected NaN comparison caused the
program to branch in a different path than would have been taken had the
tests conformed to the ones listed above (although other problems would
have ensued as a result of the correct behavior). Debugging this problem
revealed the following non-conforming result:

0e 0e f/ fconstant NaN
ok
0e NaN f> . \ this test should return False
-1 ok

Within my calculation, the failure occurred when the program used the
FSL module, gaussj, to solve 2x2 matrix equations, of the form

/ a b \ / x1 \ / e \
| | | | = | |
\ c d / \ x2 / \ f /

where a--f are computed from prior calculations, and GAUSSJ is used to
solve for x1 and x2. Hundreds of such matrix equations were being
generated and solved by the program, and, unexpectedly, the calculations
for a--f occasionally generated a NaN. Although there was a determinant
test to check for a singular matrix before passing the data to GAUSSJ,
it failed to show anything peculiar.

For the case of a NaN occurring in the 2x2 matrix, GAUSSJ would tell me
that it couldn't find a solution, but it also stored data outside the
bounds of some housekeeping arrays, leading to memory corruption.
Interestingly, if the NaN comparison had conformed to IEEE 754 rules, it
appears that the memory corruption would not have occurred (although I
haven't tested this sufficiently yet), but the algorithm would not have
generated an error telling me that it could not solve the equation.
GAUSSJ was likely not written to consider what would happen if a NaN
existed within the matrix.

--
Krishna

Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 14:00:11 UTC+2:
> On 5/28/22 14:17, minf...@arcor.de wrote:
>
> > ...
> > Comparison between NaN and any floating-point value x (including NaN and ±∞)
> > NaN ≥ x NaN ≤ x NaN > x NaN < x NaN = x NaN ≠ x
> > False False False False False True
> >
> > From these rules, x ≠ x or x = x can be used to test whether x is NaN or non-NaN.
> >
> > BTW the Standard Forth test suite comprises a file ieee-arith-test.fs for fp operations with NaNs.
> The ieee-arith-test.fs tests do not contain comparsion tests with NaN --
> at least the version which is bundled with kForth does not contain any
> comparison tests.
>
> To my chagrin, I discovered yesterday that kForth-64/32 does not conform
> to the IEEE 754 rules for comparison of floating point values with NaN.
> I found this out the long way, after a recent calculation I was doing
> caused memory corruption because an unexpected NaN comparison caused the
> program to branch in a different path than would have been taken had the
> tests conformed to the ones listed above (although other problems would
> have ensued as a result of the correct behavior). Debugging this problem
> revealed the following non-conforming result:
>
> 0e 0e f/ fconstant NaN
> ok
> 0e NaN f> . \ this test should return False
> -1 ok
>
> Within my calculation, the failure occurred when the program used the
> FSL module, gaussj, to solve 2x2 matrix equations, of the form
>
> / a b \ / x1 \ / e \
> | | | | = | |
> \ c d / \ x2 / \ f /
>
> where a--f are computed from prior calculations, and GAUSSJ is used to
> solve for x1 and x2. Hundreds of such matrix equations were being
> generated and solved by the program, and, unexpectedly, the calculations
> for a--f occasionally generated a NaN. Although there was a determinant
> test to check for a singular matrix before passing the data to GAUSSJ,
> it failed to show anything peculiar.
>
> For the case of a NaN occurring in the 2x2 matrix, GAUSSJ would tell me
> that it couldn't find a solution, but it also stored data outside the
> bounds of some housekeeping arrays, leading to memory corruption.
> Interestingly, if the NaN comparison had conformed to IEEE 754 rules, it
> appears that the memory corruption would not have occurred (although I
> haven't tested this sufficiently yet), but the algorithm would not have
> generated an error telling me that it could not solve the equation.
> GAUSSJ was likely not written to consider what would happen if a NaN
> existed within the matrix.
>

This made me wonder (again):
0e NaN f> . \ this test should return False
-1 ok

In IEEE754 encoding, NaN means an unordered bit pattern range.
Comparing a bit pattern range with number zero should be as looney as
comparing a kitchen knife with fog.

But unfortunately IEEE754 specified logical results for such comparisons.
https://en.wikipedia.org/wiki/NaN

IMO a historical kludge, because for integer numbers there are no reserved
bits to designate invalidity. Therefore I guess the IEEE754 people settled for
"false or true" after comparions regardless of how these might be encoded.

Interestingly modern industrial control system often add control or quality bits
to integer numbers eg AD converter outputs. Ada can do similar things.

There is also good reason that some system use "signalling" NaNs to trigger
warnings or interrupts. Other NaN ranges can be used for NaN-boxing
eg to implement dynamic typing.

But standard Forth does not specifiy such things. IIRC there was just a short
notice in the appendix to REPRESENT.

Given this, what should be the outcome of: 0e NaN f> ?

C at least offers an isnan(x) macro to avoid such traps. IMO a Forth
system dealing with fp-numbers should offer a similar word.

On 7/14/22 08:03, minf...@arcor.de wrote:

>> ... Debugging this problem
>> revealed the following non-conforming result:
>>
>> 0e 0e f/ fconstant NaN
>> ok
>> 0e NaN f> . \ this test should return False
>> -1 ok
>> ...

>
> This made me wonder (again):
> 0e NaN f> . \ this test should return False
> -1 ok
>
> In IEEE754 encoding, NaN means an unordered bit pattern range.
> Comparing a bit pattern range with number zero should be as looney as
> comparing a kitchen knife with fog. ...
>

When making a comparison such as the above, between two different types
of information, a FALSE result seems more sensible than TRUE. In any
case, specifying the behavior in these cases is necessary in order to
analyze the flow of a program.

> C at least offers an isnan(x) macro to avoid such traps. IMO a Forth
> system dealing with fp-numbers should offer a similar word.

If the Forth system's F<> and F= conforms to IEEE 754, then it's easy to
define FNAN?

: FNAN? ( F: x -- ) ( -- flag) FDUP F<> ;

or

: FNAN? ( F: x -- ) ( -- flag) FDUP F= INVERT ;

These defs work in Gforth, when x is NaN.

Alternately, for double precision IEEE 754 numbers, the following
definitions should work on any ANS Forth system:

fvariable temp
BASE @
HEX

: FEXPONENT ( r -- u )
temp df! [ temp cell+ ] literal @ 14 rshift 7FF and ;

: FFRACTION ( r -- ud )
temp df! temp @ [ temp cell+ ] literal @ 000FFFFF and ;

: FNAN? ( r -- nan? )
fdup FEXPONENT 7FF = >r FFRACTION D0= invert r> and ;

BASE !

Have a look at

https://github.com/mynenik/kForth-32/blob/master/forth-src/ieee-754.4th

--
Krishna

Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
> On 7/14/22 08:03, minf...@arcor.de wrote:
>
> >> ... Debugging this problem
> >> revealed the following non-conforming result:
> >>
> >> 0e 0e f/ fconstant NaN
> >> ok
> >> 0e NaN f> . \ this test should return False
> >> -1 ok
> >> ...
> >
> > This made me wonder (again):
> > 0e NaN f> . \ this test should return False
> > -1 ok
> >
> > In IEEE754 encoding, NaN means an unordered bit pattern range.
> > Comparing a bit pattern range with number zero should be as looney as
> > comparing a kitchen knife with fog. ...
> >
>
> When making a comparison such as the above, between two different types
> of information, a FALSE result seems more sensible than TRUE. In any
> case, specifying the behavior in these cases is necessary in order to
> analyze the flow of a program.
> > C at least offers an isnan(x) macro to avoid such traps. IMO a Forth
> > system dealing with fp-numbers should offer a similar word.

> If the Forth system's F<> and F= conforms to IEEE 754, then it's easy to
> define FNAN?
>
> : FNAN? ( F: x -- ) ( -- flag) FDUP F<> ;
>
> or
>
> : FNAN? ( F: x -- ) ( -- flag) FDUP F= INVERT ;
>
> These defs work in Gforth, when x is NaN.

Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
non-standard words) correctly, you need isnan/FNAN? - or vice versa.

GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
to your other example.

On 7/14/22 10:35, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
....
> Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
> non-standard words) correctly, you need isnan/FNAN? - or vice versa.
>

At first, I didn't understand what you were saying. Then I went back to
look at the Forth-94 an Forth-2012 standards. It never occurred to me
that F= and F<> are nonstandard words. I'm not sure what the rationale
for this is. Even if there was a concern that the behavior of these
words depend on the particular floating point number implementation,
i.e. something other than IEEE 754, they can still be standardized with
caveats. Are there Forth systems which support floating point numbers
but do not provide F= and F<> ?

> GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
> to your other example.

For a Forth system which supports IEEE 754 format numbers, I would use
FNAN? as a primitive which must be used to define F= and F<>. If a Forth
system does not use a NaN supporting format, then obviously FNAN? is not
needed.

--
Krishna

Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 18:17:26 UTC+2:
> On 7/14/22 10:35, minf...@arcor.de wrote:
> > Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
> ...
> > Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
> > non-standard words) correctly, you need isnan/FNAN? - or vice versa.
> >
> At first, I didn't understand what you were saying. Then I went back to
> look at the Forth-94 an Forth-2012 standards. It never occurred to me
> that F= and F<> are nonstandard words. I'm not sure what the rationale
> for this is. Even if there was a concern that the behavior of these
> words depend on the particular floating point number implementation,
> i.e. something other than IEEE 754, they can still be standardized with
> caveats. Are there Forth systems which support floating point numbers
> but do not provide F= and F<> ?

As you certainly know, finite bit-encoded fp-numbers are more often than not
only (poor) approximations. That's why F~ is there, like an engineer's estimation
for equality. IOW could you really trust an F= or F<> word to give a correct answer?

> > GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
> > to your other example.
> For a Forth system which supports IEEE 754 format numbers, I would use
> FNAN? as a primitive which must be used to define F= and F<>. If a Forth
> system does not use a NaN supporting format, then obviously FNAN? is not
> needed.

That would mean throwing exceptions like for division by zero or for logarithm
of a negative number. For some applications this seems more useful than
throwing NaNs around.

On 7/14/22 11:43, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 18:17:26 UTC+2:
>> On 7/14/22 10:35, minf...@arcor.de wrote:
>>> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
>> ...
>>> Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
>>> non-standard words) correctly, you need isnan/FNAN? - or vice versa.
>>>
>> At first, I didn't understand what you were saying. Then I went back to
>> look at the Forth-94 an Forth-2012 standards. It never occurred to me
>> that F= and F<> are nonstandard words. I'm not sure what the rationale
>> for this is. Even if there was a concern that the behavior of these
>> words depend on the particular floating point number implementation,
>> i.e. something other than IEEE 754, they can still be standardized with
>> caveats. Are there Forth systems which support floating point numbers
>> but do not provide F= and F<> ?
>
> As you certainly know, finite bit-encoded fp-numbers are more often than not
> only (poor) approximations. That's why F~ is there, like an engineer's estimation
> for equality. IOW could you really trust an F= or F<> word to give a correct answer?
>

Looking through my code, and the FSL code, F= is used in algorithms for
checking exactly representable values, e.g. small integers, which are
needed for the computations, and, together with F<>, also used heavily
in testing floating point arithmetic. A particularly good example is
paranoia.4th:

https://github.com/mynenik/kForth-64/blob/master/forth-src/system-test/paranoia.4th

>>> GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
>>> to your other example.
>> For a Forth system which supports IEEE 754 format numbers, I would use
>> FNAN? as a primitive which must be used to define F= and F<>. If a Forth
>> system does not use a NaN supporting format, then obviously FNAN? is not
>> needed.
>
> That would mean throwing exceptions like for division by zero or for logarithm
> of a negative number. For some applications this seems more useful than
> throwing NaNs around.

As you've already pointed out, signalling NaNs are available in IEEE 754
for generating exceptions.

--
Krishna

On 14/07/2022 23:03, minf...@arcor.de wrote:
>
> In IEEE754 encoding, NaN means an unordered bit pattern range.
> Comparing a bit pattern range with number zero should be as looney as
> comparing a kitchen knife with fog.

Would you say the same about INF ? When logic fails and a result
is needed, convention steps in.

On 15/07/2022 02:17, Krishna Myneni wrote:
> On 7/14/22 10:35, minf...@arcor.de wrote:
>> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
> ...
>> Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
>> non-standard words) correctly, you need isnan/FNAN? - or vice versa.
>>
>
> At first, I didn't understand what you were saying. Then I went back to
> look at the Forth-94 an Forth-2012 standards. It never occurred to me
> that F= and F<> are nonstandard words. I'm not sure what the rationale
> for this is. Even if there was a concern that the behavior of these
> words depend on the particular floating point number implementation,
> i.e. something other than IEEE 754, they can still be standardized with
> caveats. Are there Forth systems which support floating point numbers
> but do not provide F= and F<> ?
>
>> GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
>> to your other example.
>
> For a Forth system which supports IEEE 754 format numbers, I would use
> FNAN? as a primitive which must be used to define F= and F<>. If a Forth
> system does not use a NaN supporting format, then obviously FNAN? is not
> needed.

Never heard of fpclassify but created something similar:

\ implementation for 80387 double-precision - software stack
\ 1=Unsupp 2=NAN 5=norm 6=INF 65=zero 66=Empty 69=denorm
code FCLASS ( r -- x )
addr fsp ) di mov qword 0 [di] fld fxam ax fstsw
st(0) fstp $45 # ah and $04 # ah cmp 1 $ jnz
\ test memory copy for subnormal
$0FFE # 1 floats 2- [di] test 1 $ jnz $40 # ah or 1 $:
ah inc ( make non-zero) bx bx sub ah bl mov
1 floats # addr fsp ) add bx push next
end-code

2 constant FP-NAN
5 constant FP-NORMAL
6 constant FP-INFINITE
65 constant FP-ZERO
69 constant FP-SUBNORMAL

\ test for non-number incl. INF (used by REPRESENT)
: nan? ( r -- +n|0 )
fclass
fp-normal of 0 end
fp-subnormal of 0 end
fp-zero of 0 end ;

Krishna Myneni schrieb am Freitag, 15. Juli 2022 um 00:21:13 UTC+2:
> On 7/14/22 11:43, minf...@arcor.de wrote:
> > Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 18:17:26 UTC+2:
> >> On 7/14/22 10:35, minf...@arcor.de wrote:
> >>> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
> >> ...
> >>> Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
> >>> non-standard words) correctly, you need isnan/FNAN? - or vice versa.
> >>>
> >> At first, I didn't understand what you were saying. Then I went back to
> >> look at the Forth-94 an Forth-2012 standards. It never occurred to me
> >> that F= and F<> are nonstandard words. I'm not sure what the rationale
> >> for this is. Even if there was a concern that the behavior of these
> >> words depend on the particular floating point number implementation,
> >> i.e. something other than IEEE 754, they can still be standardized with
> >> caveats. Are there Forth systems which support floating point numbers
> >> but do not provide F= and F<> ?
> >
> > As you certainly know, finite bit-encoded fp-numbers are more often than not
> > only (poor) approximations. That's why F~ is there, like an engineer's estimation
> > for equality. IOW could you really trust an F= or F<> word to give a correct answer?
> >
> Looking through my code, and the FSL code, F= is used in algorithms for
> checking exactly representable values, e.g. small integers, which are
> needed for the computations, and, together with F<>, also used heavily
> in testing floating point arithmetic.

A double fp-number has a mantissa width of 54 bits. So even bigger integers
can be represented lossless. IIRC IEEE 754 requires that arithmetic operations
and comparisons within this integer range must be 100% correct.

+0e and -0e must compare to true of course.

A probably nonsensical 32 bit Forth without an integer data stack
could do everything in fp-math.

In article <55fa52eb-dcc3-42c9-b5db-c4318bfa1d29n@googlegroups.com>,
<SNIP>
>As you certainly know, finite bit-encoded fp-numbers are more often than not
>only (poor) approximations. That's why F~ is there, like an engineer's
>estimation
>for equality. IOW could you really trust an F= or F<> word to give a
>correct answer?

F= is useful. A lot of iteration schemes end in detecting
floating numbers are equal. F.i. bisection guarantees that you
end up in the confidence interval of a zero crossing.
ciforth supports F= . It is an oversight of the committee.
Why do you think the Intel fp processor supports it?

>
>Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 18:17:26 UTC+2:
>> > GCC does this via fpclassify(f) which is just a bit pattern matcher,
>similar
>> > to your other example.
>> For a Forth system which supports IEEE 754 format numbers, I would use
>> FNAN? as a primitive which must be used to define F= and F<>. If a Forth
>> system does not use a NaN supporting format, then obviously FNAN? is not
>> needed.
>
>That would mean throwing exceptions like for division by zero or for logarithm
>of a negative number. For some applications this seems more useful than
>throwing NaNs around.

NaNs are useful to not have to inspect intermediate results.
Mostly the results are correct. At the end you discover a Nan,
and then you have to look closely.
A modern processor generate one floating point result per clock,
but that can only work if the processor works on different fp
instructions in a pipeline.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

none albert schrieb am Freitag, 15. Juli 2022 um 14:07:03 UTC+2:
> In article <55fa52eb-dcc3-42c9...@googlegroups.com>,
> <SNIP>
> >As you certainly know, finite bit-encoded fp-numbers are more often than not
> >only (poor) approximations. That's why F~ is there, like an engineer's
> >estimation
> >for equality. IOW could you really trust an F= or F<> word to give a
> >correct answer?
> F= is useful. A lot of iteration schemes end in detecting
> floating numbers are equal. F.i. bisection guarantees that you
> end up in the confidence interval of a zero crossing.
> ciforth supports F= . It is an oversight of the committee.
> Why do you think the Intel fp processor supports it?

Do you have to set up a confidence interval eg declare an epsilon for F=?
Otherwise it would just check for equal bits that must not even differ in
the LSB which cannot always be guaranteed I fear.

> >Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 18:17:26 UTC+2:
> >> > GCC does this via fpclassify(f) which is just a bit pattern matcher,
> >similar
> >> > to your other example.
> >> For a Forth system which supports IEEE 754 format numbers, I would use
> >> FNAN? as a primitive which must be used to define F= and F<>. If a Forth
> >> system does not use a NaN supporting format, then obviously FNAN? is not
> >> needed.
> >
> >That would mean throwing exceptions like for division by zero or for logarithm
> >of a negative number. For some applications this seems more useful than
> >throwing NaNs around.
> NaNs are useful to not have to inspect intermediate results.
> Mostly the results are correct. At the end you discover a Nan,
> and then you have to look closely.

I understand that this economizes on checking intermediate results.
But I don't know whether it is ensured that eg log(-1.) throws a signalling
instead of a quiet NaN. If yes throwing an exception would probably be even faster
than hand-checking result.

On 15/07/2022 22:06, albert wrote:
> In article <55fa52eb-dcc3-42c9-b5db-c4318bfa1d29n@googlegroups.com>,
> <SNIP>
>>As you certainly know, finite bit-encoded fp-numbers are more often than not
>>only (poor) approximations. That's why F~ is there, like an engineer's
>>estimation
>>for equality. IOW could you really trust an F= or F<> word to give a
>>correct answer?
>
> F= is useful. A lot of iteration schemes end in detecting
> floating numbers are equal. F.i. bisection guarantees that you
> end up in the confidence interval of a zero crossing.
> ciforth supports F= . It is an oversight of the committee.
> Why do you think the Intel fp processor supports it?

More avoidance than oversight, IMO. Here's what the preceding FVG
(Forth Vendors Group) FP Standard had to say about F= :

"The logical operators will regard two real numbers as equal
if they differ only by a small amount. This "fuzz factor"
is related to the magnitude of the real numbers and is
implementation dependent."

F= r1 r2 --- f
True if floating point number r1 is equal to floating
point number r2. The real numbers are removed from the
floating point stack, and the flag is left on top of the
Forth parameter stack.

"minf...@arcor.de" <minforth@arcor.de> writes:
>There is also good reason that some system use "signalling" NaNs to trigger
>warnings or interrupts.

One might think that they do that, but at least in the default
configuration of the FPU it does not:

\ AMD64-specific:
$7fc00000 pad ! pad sf@ fconstant qnan ok
$7fa00000 pad ! pad sf@ fconstant snan ok
qnan ok f:1
snan ok f:2
0e f+ ok f:2
snan 0e f< ok 1 f:2
qnan 0e f+ ok 1 f:3
.. 0 ok f:3
f. NaN ok f:2
f. NaN ok f:1
f. NaN ok

>Given this, what should be the outcome of: 0e NaN f> ?

There is no Forth-standard guarantees outcome, but one would expect
that F> is the > operation of IEEE 754, and for that the outcome is
false, i.e., 0 in standard Forth.

>C at least offers an isnan(x) macro to avoid such traps. IMO a Forth
>system dealing with fp-numbers should offer a similar word.

In Gforth you do FDUP F<>

There has been an attempt at an IEEE 754 proposal for Forth
standardization, but I have not heard of that for several years.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

"minf...@arcor.de" <minforth@arcor.de> writes:
>Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
>non-standard words) correctly, you need isnan/FNAN? - or vice versa.

I would expect that an implementation of F= and F<> just invokes the
corresponding CPU instructions without special-casing NaNs. And
indeed:

\ Gforth
see f=
Code f=
5623F8D636C2: mov $00[r13],r8
5623F8D636C6: xor r8d,r8d
5623F8D636C9: sub r13,$08
5623F8D636CD: mov edx,$0
5623F8D636D2: movsd xmm0,$08[r12]
5623F8D636D9: mov rax,r12
5623F8D636DC: lea r12,$10[r12]
5623F8D636E1: ucomisd xmm0,xmm15
5623F8D636E6: movsd xmm15,$10[rax]
5623F8D636EC: setnp r8lb
5623F8D636F0: cmovnz r8,rdx
5623F8D636F4: add r15,$08
5623F8D636F8: neg r8
5623F8D636FB: mov rcx,-$08[r15]
5623F8D636FF: jmp ecx
end-code

\ lxf
see f=
8691334 88DE3C4 29 88DE3AB 25 prim F=

88DE3C4 DFE9 fucomip ST(1)
88DE3C6 DDD8 fstp ST(0)
88DE3C8 0F9BC0 setnp al
88DE3CB 0FBEC0 movsx eax , al
88DE3CE 0F94C1 sete cl
88DE3D1 0FBEC9 movsx ecx , cl
88DE3D4 21C8 and eax , ecx
88DE3D6 F7D8 neg eax
88DE3D8 895DFC mov [ebp-4h] , ebx
88DE3DB 8BD8 mov ebx , eax
88DE3DD 8D6DFC lea ebp , [ebp-4h]
88DE3E0 C3 ret near

\ iForth
FORTH> see f=
Flags:
$10139AE0 : F= 488BC04883ED088F4500 H.@H.m..E.
$10139AEA f2poprev, 41DB6D10D9C941DB6D004D8D A[m.YIA[m.M.
6D20 m
$10139AF8 fcompp DED9 ^Y
$10139AFA fnstsw ax DFE0 _`
$10139AFC and rax, $00004400 d#
4881E000440000 H.`.D..
$10139B03 xor rax, $00004000 d#
4881F000400000 H.p.@..
$10139B0A sete al 0F94C0 ..@
$10139B0D movzx rbx, al 480FB6D8 H.6X
$10139B11 neg rbx 48F7DB Hw[
$10139B14 push rbx 53 S
$10139B15 ; 488B45004883C508FFE0 H.E.H.E..`

And here's an example of the pitfalls of FP numbers:

VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021

see f=
F=
( 004C4550 E8EBFBFFFF ) CALL 004C4140 F-
( 004C4555 E836FFFFFF ) CALL 004C4490 F0=
( 004C455A C3 ) RET/NEXT
( 11 bytes, 3 instructions )

Let's see how well this works:

1e 0e f/ fdup f= . \ 0 ok
SSE Exception 0000:1F85

By contrast:

gforth: 1e 0e f/ fdup f= . \ -1 ok
iForth: 1e 0e f/ fdup f= . \ -1 ok
lxf: 1e 0e f/ fdup f= . \ -1 ok

>GCC does this via fpclassify(f) which is just a bit pattern matcher, similar
>to your other example.

The code shown for Gforth comes out of gcc. No bit pattern matching
going on here.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 7/14/22 10:35, minf...@arcor.de wrote:
>> Krishna Myneni schrieb am Donnerstag, 14. Juli 2022 um 16:01:31 UTC+2:
>...
>> Isn't it a bit of a hen-and-egg problem? To implement F=/F<> (which are
>> non-standard words) correctly, you need isnan/FNAN? - or vice versa.
>>
>
>At first, I didn't understand what you were saying. Then I went back to
>look at the Forth-94 an Forth-2012 standards. It never occurred to me
>that F= and F<> are nonstandard words. I'm not sure what the rationale
>for this is.

|A.12.6.2.1640 F~
| |This provides the three types of "floating point equality" in common
|use — "close" in absolute terms, exact equality as represented, and
|"relatively close".

Except that 0e F~ is explicitly specified such that positive and
negative zero are unequal, which is not a common meaning of FP
equality these days (and probably not in 1994, either). So 0= F~ is
more expensive to implement and also does something different from F=.

My guess is that they did not provide F= and F<> because they are
occasionally used wrongly by naive programmers.

>Are there Forth systems which support floating point numbers
>but do not provide F= and F<> ?

Candidate for standardization?

>For a Forth system which supports IEEE 754 format numbers, I would use
>FNAN? as a primitive which must be used to define F= and F<>.

Why?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

albert@cherry.(none) (albert) writes:
>In article <55fa52eb-dcc3-42c9-b5db-c4318bfa1d29n@googlegroups.com>,
><SNIP>
>>As you certainly know, finite bit-encoded fp-numbers are more often than not
>>only (poor) approximations. That's why F~ is there, like an engineer's
>>estimation
>>for equality. IOW could you really trust an F= or F<> word to give a
>>correct answer?
>
>F= is useful. A lot of iteration schemes end in detecting
>floating numbers are equal.

Iterative approximation algorithms are an example where using F= is
dangerous: You can have cases where the algorithm eventually jitters
between two values, and an algorithm that terminates when the value no
longer changes according to F= does not terminate. Better use
approximate equality.

>It is an oversight of the committee.

Unlikely.

>Why do you think the Intel fp processor supports it?

Because it's easier to implement in hardware than F~ABS and F~REL.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

"minf...@arcor.de" <minforth@arcor.de> writes:
>Do you have to set up a confidence interval eg declare an epsilon for F=?

Not in any F= I am aware of.

>I understand that this economizes on checking intermediate results.
>But I don't know whether it is ensured that eg log(-1.) throws a signalling
>instead of a quiet NaN. If yes throwing an exception would probably be even faster
>than hand-checking result.

AFAIK the typical use for signaling NaNs is uninitialized data. But
at least in Gforth there is no difference in behaviour between
signaling and quiet NaNs; none of them causes a Forth exception when
performing an operation.

I think the idea behind these default settings of the FPU is that if
you get one NaN result in, say a 1000x1000 matrix, you still want the
999,999 other results rather than just an exception.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

On Monday, July 18, 2022 at 6:27:54 PM UTC+2, Anton Ertl wrote:
> AFAIK the typical use for signaling NaNs is uninitialized data. But
> at least in Gforth there is no difference in behaviour between
> signaling and quiet NaNs; none of them causes a Forth exception when
> performing an operation.

#10000 VALUE #times 0e FVALUE a 0e FVALUE b
: testoverhead CR TIMER-RESET #times 0 ?DO a b F/ FDROP LOOP .ELAPSED ;
: BENCH ( u -- ) TO #times
1e TO a 1e TO b testoverhead ." ( 1 / 1 ) "
0e TO a 1e TO b testoverhead ." ( 0 / 1 ) "
0e TO b testoverhead ." ( 0 / 0 ) " ;
FORTH> #1000000000 BENCH
1.697 seconds elapsed. ( 1 / 1 )
1.698 seconds elapsed. ( 0 / 1 )
1.697 seconds elapsed. ( 0 / 0 ) ok

I'm not sure other languages allow such a low overhead.
Calculations in SPICE / C can be awfully slow when
NaNs are generated.
> I think the idea behind these default settings of the FPU is that if
> you get one NaN result in, say a 1000x1000 matrix, you still want the
> 999,999 other results rather than just an exception.

You mean 999,000 results, of course :--)

-marcel

On 19/07/2022 01:48, Anton Ertl wrote:
>
> |A.12.6.2.1640 F~
> |
> |This provides the three types of "floating point equality" in common
> |use — "close" in absolute terms, exact equality as represented, and
> |"relatively close".
>
> Except that 0e F~ is explicitly specified such that positive and
> negative zero are unequal, which is not a common meaning of FP
> equality these days (and probably not in 1994, either).

But chose to provide it as hardware didn't? 'Negative zero' is only
meaningful if a system expressly supports it. E.g. there doesn't seem
much point having F~ do:

0e -0e 0e f~ . 0 ok

if one couldn't print it out:

-0e f. 0. ok