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.
Any idea why the division of 0/0 gives a -NAN rather than +NAN or whatever?=
...
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
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.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.
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
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 testsusing 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
gnuarm.del...@gmail.com schrieb am Samstag, 28. Mai 2022 um 06:48:49 UTC+2: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.
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.
using the same data that will also fail. I'd just like it to be consistent across the tests.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
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 okThe sign just reflects the meaningless sign bit of the binary representation range of NaNs.
-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
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.
...
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 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.
... 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. ...
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.
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, similarFor a Forth system which supports IEEE 754 format numbers, I would use
to your other example.
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 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.
GCC does this via fpclassify(f) which is just a bit pattern matcher, similar to your other example.
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 areAt first, I didn't understand what you were saying. Then I went back to
non-standard words) correctly, you need isnan/FNAN? - or vice versa.
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, similarFor a Forth system which supports IEEE 754 format numbers, I would use
to your other example.
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.
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.
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.
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.
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?
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, >similarFor a Forth system which supports IEEE 754 format numbers, I would use
to your other example.
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.
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 >estimationF= is useful. A lot of iteration schemes end in detecting
for equality. IOW could you really trust an F= or F<> word to give a >correct answer?
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, >similarFor a Forth system which supports IEEE 754 format numbers, I would use
to your other example.
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 logarithmNaNs are useful to not have to inspect intermediate results.
of a negative number. For some applications this seems more useful than >throwing NaNs around.
Mostly the results are correct. At the end you discover a Nan,
and then you have to look closely.
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?
There is also good reason that some system use "signalling" NaNs to trigger >warnings or interrupts.
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.
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.
Are there Forth systems which support floating point numbers
but do not provide F= and F<> ?
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<>.
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.
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=?
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.
|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
dxforth <dxforth@gmail.com> writes:
But chose to provide it as hardware didn't? 'Negative zero' is only
meaningful if a system expressly supports it.
Negative zero is supported by essentially all floating point hardware
these days. But oh man, F~ is ugly. 0e and -0e have different
encodings (bit patterns) even though F= compares them as equal.
E.g. there doesn't seem much point having F~ do:
0e -0e 0e f~ . 0 ok
On that system 0e and -0e have the same bit pattern, so
if one couldn't print it out:
-0e f. 0. ok
should operate as you describe. On an IEEE system (most systems now),
-0e f. prints -0.
On an IEEE system (most systems now),
-0e f. prints -0.
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 :--)
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
dxforth <dxforth@gmail.com> writes:
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?
Pardon?
'Negative zero' is only
meaningful if a system expressly supports it.
Obviously.
E.g. there doesn't seem
much point having F~ do:
0e -0e 0e f~ . 0 ok
Period! But that's how it is specified.
if one couldn't print it out:
-0e f. 0. ok
How a negative zero should be printed is a different discussion.
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
Gforth prints (on AMD64, i.e., an IEEE 754 system):
-0e f. 0. ok
0e fnegate f. 0. ok
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
dxforth <dxforth@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
Gforth doesn't have FCOMP and I don't see it in forth-standard.org.
What is it supposed to do?
On Tuesday, July 19, 2022 at 11:57:07 AM UTC+2, dxforth wrote:
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
It is useful in numerical procedures. It makes quite a bit of difference
when handling an hyperbolic branch, see D.N. Williams' home pages.
Do you mean F~ ? Given F= and FSIGN that can pick the sign of zero,
then F~ and its restrictive spec on zero becomes redundant.
On Tuesday, July 19, 2022 at 11:57:07 AM UTC+2, dxforth wrote:
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
It is useful in numerical procedures. It makes quite a bit of difference
when handling an hyperbolic branch, see D.N. Williams' home pages.
-marcel--
In article <4e841f83-8b8f-47fc-bacb-069530d55b88n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
On Tuesday, July 19, 2022 at 11:57:07 AM UTC+2, dxforth wrote:
On 19/07/2022 18:18, Anton Ertl wrote:[..]
dxforth <dxf...@gmail.com> writes:
FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.
It is useful in numerical procedures. It makes quite a bit of difference >>when handling an hyperbolic branch, see D.N. Williams' home pages.
Unclear. "FCOMP seeing no difference between 0e and -0e".
Is that useful?
Or is FCOMP useful?
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Gforth prints (on AMD64, i.e., an IEEE 754 system):
-0e f. 0. ok
0e fnegate f. 0. ok
Both of those print -0. under gforth 0.73 in Debian 11 x64. It's
interesting if something changed.
On 19/07/2022 18:18, Anton Ertl wrote:
How a negative zero should be printed is a different discussion.
There's precedence for printing it differently to other numbers?
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Gforth prints (on AMD64, i.e., an IEEE 754 system):
-0e f. 0. ok
0e fnegate f. 0. ok
Both of those print -0. under gforth 0.73 in Debian 11 x64. It's
interesting if something changed.
dxforth <dxforth@gmail.com> writes:By precedence I mean convention. ANS has a convention for inputting
On 19/07/2022 18:18, Anton Ertl wrote:
How a negative zero should be printed is a different discussion.
There's precedence for printing it differently to other numbers?
Not sure what you mean with "precedence" here, but anyway, negative
zero should be printed differently from, e.g., 1.
Whether it should
be printed differently from positive zero is the question.
dxforth <dxf...@gmail.com> writes:
On 19/07/2022 18:18, Anton Ertl wrote:
How a negative zero should be printed is a different discussion.
There's precedence for printing it differently to other numbers?Not sure what you mean with "precedence" here, but anyway, negative
zero should be printed differently from, e.g., 1. Whether it should
be printed differently from positive zero is the question.
Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:[..]
How can this be qustioned??
Branch cuts are an important thing eg in the field of trigonometric and logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0. are important.
ans = -Inflog(-0)
ans = -Inflog(+0)
There's precedence for printing it differently to other numbers?Not sure what you mean with "precedence" here
Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:
dxforth <dxf...@gmail.com> writes:
On 19/07/2022 18:18, Anton Ertl wrote:Not sure what you mean with "precedence" here, but anyway, negative
How a negative zero should be printed is a different discussion.
There's precedence for printing it differently to other numbers?
zero should be printed differently from, e.g., 1. Whether it should
be printed differently from positive zero is the question.
How can this be qustioned??
Branch cuts are an important thing eg in the field of trigonometric and logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0. are important.
I see nothing in the definition of F. which permits a change of sign.
On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:[..]
How can this be qustioned??You had me worried for a moment but it isn't as simple as that :--)
Branch cuts are an important thing eg in the field of trigonometric and logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0. are important.
MATLAB:
ans = -Inflog(-0)
ans = -Inflog(+0)
Marcel Hendrix schrieb am Mittwoch, 20. Juli 2022 um 21:11:31 UTC+2:[..]
MATLAB:Everyone is free and happy to cook her own soup ;-)
ans = -Inflog(-0)
ans = -Inflog(+0)
Wolfram Alpha does:
log(0.0) or log(-0.0) --> undefined, whereas
log(0+0i) -> -inf, whereas
log(0.0+0.0i) -> undefined
On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:[..]
How can this be qustioned??
Branch cuts are an important thing eg in the field of trigonometric and
logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0. >> are important.
You had me worried for a moment but it isn't as simple as that :--)
MATLAB:
ans = -Inflog(-0)
ans = -Inflog(+0)
On 21/07/2022 05:11, Marcel Hendrix wrote:
On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:[..]
How can this be qustioned??
Branch cuts are an important thing eg in the field of trigonometric and
logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0. >> are important.
You had me worried for a moment but it isn't as simple as that :--)
MATLAB:VFX:
ans = -Inflog(-0)
ans = -Inflog(+0)
0e fln f. -NaN ok
DX-Forth:
0e fln f. -INF ok
As both use the same x87 instructions I'm guessing it's something
to do with NAN/INF decoding.
VFX:
0e fln f. -NaN ok
0e fln f.^
dxforth <dxforth@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.^
On Friday, July 22, 2022 at 4:38:04 AM UTC+2, dxforth wrote:
On 21/07/2022 05:11, Marcel Hendrix wrote:
On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote: >> >> Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:VFX:
[..]
How can this be qustioned??
Branch cuts are an important thing eg in the field of trigonometric and >> >> logarithmic functions, particularly in the complex plane.
+0e FDUP FLN f. f. -inf +0.
-0e FDUP FLN f. -nan -0.
The only thing that is undefined is the 'sign' of nan. The signs before 0.
are important.
You had me worried for a moment but it isn't as simple as that :--)
MATLAB:
ans = -Inflog(-0)
ans = -Inflog(+0)
0e fln f. -NaN ok
DX-Forth:
0e fln f. -INF ok
As both use the same x87 instructions I'm guessing it's something
to do with NAN/INF decoding.
Why Inf? What about this classic:
FORTH> +0e fdup fsin fswap f/ f. -NAN ok
FORTH> +0e fdup fcos fswap f/ f. +INF ok
FORTH> -0e fdup fcos fswap f/ f. -INF ok
FORTH> 0e fdup fcos fswap f/ f. +INF ok
dxforth <dxforth@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.^
On 22/07/2022 15:16, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOGStephen advises the fix will be in the next release.
0e fln f.^
dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
On 22/07/2022 15:16, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.
^
Stephen advises the fix will be in the next release.
IEEE 754 section 9.2.1 specifies clearly
".. log(±0) is −∞ and signals the divideByZero exception .."
Reference page 43 in
https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
On 7/30/22 07:22, minf...@arcor.de wrote:
dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
On 22/07/2022 15:16, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.
^
Stephen advises the fix will be in the next release.
IEEE 754 section 9.2.1 specifies clearly
".. log(±0) is −∞ and signals the divideByZero exception .."
Reference page 43 in https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdfThe divideByZero exception mask bit must be set in order for the fpu to signal the exception. It is not set by default.
In kForth-32/64,
\ Check ln(0)
0e f.
0 ok
0e fln f.
-inf ok
\ Check ln(-0)
-0e f.
-0 ok
-0e fln f.
-inf ok
In kForth-32, the FPU's exception mask bit for divideByZero may be set
as follows:
------
include ans-words
include strings
include modules
include syscalls
include mc
include asm-x86
include fpu-x86
cr
.( FLN of zero with default FPU exception mask ) cr
0e fln f. cr
.( Press a key to set the divideByZero FPU exception ) cr
key drop
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
0e fln f.
------
Output of the above code in kForth-32:
-------
$ kforth32
kForth-32 v 2.4.0 (Build: 2022-06-30)
Copyright (c) 1998--2022 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU Affero General Public License, v3.0 or later
Ready!
include fpu-signals-test
FLN of zero with default FPU exception mask
-inf
Press a key to set the divideByZero FPU exception
Floating point exception (core dumped)
$
------
We can, of course, trap the signal in kForth (see sigfpe.4th for an
example of how to trap a signal in kForth).
Krishna Myneni schrieb am Samstag, 30. Juli 2022 um 18:31:38 UTC+2:
On 7/30/22 07:22, minf...@arcor.de wrote:
dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:The divideByZero exception mask bit must be set in order for the fpu to
On 22/07/2022 15:16, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.
^
Stephen advises the fix will be in the next release.
IEEE 754 section 9.2.1 specifies clearly
".. log(±0) is −∞ and signals the divideByZero exception .."
Reference page 43 in
https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
signal the exception. It is not set by default.
In kForth-32/64,
\ Check ln(0)
0e f.
0 ok
0e fln f.
-inf ok
\ Check ln(-0)
-0e f.
-0 ok
-0e fln f.
-inf ok
In kForth-32, the FPU's exception mask bit for divideByZero may be set
as follows:
------
include ans-words
include strings
include modules
include syscalls
include mc
include asm-x86
include fpu-x86
cr
.( FLN of zero with default FPU exception mask ) cr
0e fln f. cr
.( Press a key to set the divideByZero FPU exception ) cr
key drop
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
0e fln f.
------
Output of the above code in kForth-32:
-------
$ kforth32
kForth-32 v 2.4.0 (Build: 2022-06-30)
Copyright (c) 1998--2022 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU Affero General Public License, v3.0 or later
Ready!
include fpu-signals-test
FLN of zero with default FPU exception mask
-inf
Press a key to set the divideByZero FPU exception
Floating point exception (core dumped)
$
------
We can, of course, trap the signal in kForth (see sigfpe.4th for an
example of how to trap a signal in kForth).
Well done!
BTW I was sometimes wondering about those strange exception codes
54 and 55 in table 9.1 of the standard document. They seem a half-cooked rudiment and practically useless.
On 7/30/22 07:22, minf...@arcor.de wrote:
dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
On 22/07/2022 15:16, Anton Ertl wrote:
dxforth <dxf...@gmail.com> writes:
VFX:
0e fln f. -NaN ok
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004
VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021
0e fln f. Invalid argument to FLN/FLOG
0e fln f.
^
Stephen advises the fix will be in the next release.
IEEE 754 section 9.2.1 specifies clearly
".. log(±0) is −∞ and signals the divideByZero exception .."
Reference page 43 in
https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
The divideByZero exception mask bit must be set in order for the fpu to signal the exception. It is not set by default.
In kForth-32/64,
\ Check ln(0)
0e f.
0 ok
0e fln f.
-inf ok
\ Check ln(-0)
-0e f.
-0 ok
-0e fln f.
-inf ok
In kForth-32, the FPU's exception mask bit for divideByZero may be set
as follows:
------
include ans-words
include strings
include modules
include syscalls
include mc
include asm-x86
include fpu-x86
cr
.( FLN of zero with default FPU exception mask ) cr
0e fln f. cr
.( Press a key to set the divideByZero FPU exception ) cr
key drop
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
is actually masking the divideByZero exception, rather than enabling it.
The program generates an exception for the odd reason that when I loaded
the strings.4th module, the fpu status register indicates an INVALID
error, caused by the following statement in strings.4th
0e 0e f/ fconstant NAN
used to define NAN for the word STRING>F .
On 7/30/22 23:02, Krishna Myneni wrote:...
0 unmaskFPUexceptions \ mask all exceptions...
On 7/30/22 11:31, Krishna Myneni wrote:,,,
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86...
is actually masking the divideByZero exception, rather than enabling it.
The program generates an exception for the odd reason that when I loaded
the strings.4th module, the fpu status register indicates an INVALID
error, caused by
Bottom line is the code I intended to enable an exception on the fpu...
divide by zero error is not correct, and only generates an exception due
to a leftover status error from somewhere else in the code. The word modifyFPUStateX86 may be faulty.
On 31/07/2022 14:02, Krishna Myneni wrote:
FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
is actually masking the divideByZero exception, rather than enabling it.
The program generates an exception for the odd reason that when I loaded
the strings.4th module, the fpu status register indicates an INVALID
error, caused by the following statement in strings.4th
0e 0e f/ fconstant NAN
used to define NAN for the word STRING>F .
The bit patterns for IEEE INF NAN are documented. Load them into PAD and F@
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:32:42 |
| Calls: | 6,712 |
| Files: | 12,243 |
| Messages: | 5,355,397 |