"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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/07/2022 15:26, Paul Rubin wrote:

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.

Expected though not mandated. There's something re-assuring about not
seeing -0.0 in a table of values. Ideally a system that supports negative- zero should be able to turn it off. When it's off, I'd expect 0e -0e 0e f~
to return a true result.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Rubin <no.email@nospam.invalid> writes:

On an IEEE system (most systems now),
-0e f. prints -0.

Gforth prints (on AMD64, i.e., an IEEE 754 system):

-0e f. 0. ok
0e fnegate f. 0. ok

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <mhx@iae.nl> writes:

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.

Gforth implements FP operations by just performing the appropriate C
code and also sees uniform results for this benchmark. I see two possibilities:

* The operations you perform involving NaNs that are slow are
something other than 0/0.

* The actual latency is indeed slower for, e.g., 0/0, but since you
FDROP the result, you don't measure the latency, only the
throughput. In your SPICE work, you actually also measure the
latency.

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 :--)

No, 1 element out of 1,000,000 is a NaN, so there are 999,999 non-NaN
elements left.

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/07/2022 18:18, Anton Ertl wrote:

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?

FCOMP sees no difference between 0e -0e. Most likely because
mathematics doesn't.

'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.

With no explanation as to why. If anything it makes F~ less useful.

if one couldn't print it out:

-0e f. 0. ok

How a negative zero should be printed is a different discussion.

There's precedence for printing it differently to other numbers?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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? Computer floating point arithmetic doesn't
work like the mathematical reals: for example, FP arithmetic doesn't
follow the associative law, there are rounding errors, etc. So there
are good reasons for having negative 0.

W. Kahan (main designer of IEEE 754) has many articles and diatribes
about FP arithmetic on his web site,
https://people.eecs.berkeley.edu/~wkahan/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/07/2022 22:05, Paul Rubin wrote:

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?

Intel FPU instructions FCOM/FCOMP/FCOMPP--Compare Real

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/07/2022 22:03, Marcel Hendrix 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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, July 19, 2022 at 4:34:31 PM UTC+2, dxforth wrote:
[..]

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.

I did not comment on F~ but its use is indeed limited (see below).
F= is far more important.

Searching for: F~
D:\dfwforth\examples\dictaat\hbeb\lampmodels.frt(127): wanted 1e-3 F~ IF I (set-temperature) UNLOOP EXIT ENDIF
D:\dfwforth\examples\DOMI\domiapi.frt(441): S~ curl -o "json.txt" -D "response.txt" -F~
D:\dfwforth\examples\nrc\chapter2_Linear_Algebraic_Equations\apps\llc.frt(730): <VO> FSQR Rl F/ PWANTED -0.01e F~ ;
D:\dfwforth\examples\numeric\division.frt(34): 1e-17 F~ ?LEAVE D:\dfwforth\examples\numeric\tpf.frt(206): wy wsize F~ D:\dfwforth\examples\numeric\tpf.frt(207): wx wsize F~ AND ; PRIVATE D:\dfwforth\examples\numeric\tpfgr.frt(190): wy wsize F~ D:\dfwforth\examples\numeric\tpfgr.frt(191): wx wsize F~ AND ; PRIVATE D:\dfwforth\examples\paranoia\paranoia.frt(326): 0E F~ ; D:\dfwforth\examples\pl1\pl1b.frt(121): s" 0e F~ " evaluate ; immediate D:\dfwforth\examples\pl1\pl1b.frt(124): s" 0e F~ INVERT " evaluate ; immediate D:\dfwforth\examples\SPICE\Mag_Tool\readmag.frt(536): chk? IF varname EVALUATE ( F: rnew rold -- ) FOVER -0.01e F~
D:\dfwforth\examples\SPICE\old_ispice\ispice.frt(1251): STEPVAR3 STV3_end 1e-15 F~
D:\dfwforth\examples\SPICE\old_ispice\ispice.frt(1252): STEPVAR2 STV2_end 1e-15 F~ AND
D:\dfwforth\examples\SPICE\old_ispice\ispice.frt(1253): STEPVAR1 STV1_end 1e-15 F~ AND ; PRIVATE
D:\dfwforth\include\marquard.frt(266): -1e-3 F~ ; D:\dfwforth\include\spifsim.frt(2943): F2DUP F= closeness F~ OR ; PRIVATE Found 17 occurrence(s) in 22 file(s), 23706 ms

Searching for: F=
Found 468 occurrence(s) in 87 file(s), 1473 ms

Searching for: FSIGN
Found 32 occurrence(s) in 13 file(s), 1473 ms

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

-marcel

--
"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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/07/2022 05:55, albert wrote:

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?

FCOMP is the Intel FPU instruction that compares two f/p values.
It doesn't discriminate between positive and negative zero.
Given there is no instruction that compares them as different,
we can conclude Intel saw the former as more useful. Forth's
question to answer is how it came to conclude the opposite.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/07/2022 21:59, Paul Rubin wrote:

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.

Gforth 0.7.9_20200709

\ test if sign passed on input
0e pad f! pad 1 floats dump
6FFFFF877278: 00 00 00 00 00 00 00 00

-0e pad f! pad 1 floats dump
6FFFFF877278: 00 00 00 00 00 00 00 80

\ test if sign passed on output
0e pad 10 represent drop nip . 0 ok
-0e pad 10 represent drop nip . 0 ok

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth <dxforth@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
--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Rubin <no.email@nospam.invalid> writes:

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.

One other thing that changed:

-0e 0e f/ f. \ -na ok \ 0.7.3
-0e 0e f/ f. \ NaN ok \ 0.7.9_20220707

Maybe these changes are related. If you want to know for sure, you
can bisect it :-).

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/07/2022 21:48, Anton Ertl wrote:

dxforth <dxforth@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.

By precedence I mean convention. ANS has a convention for inputting
and outputting negative numbers.

Whether it should
be printed differently from positive zero is the question.

I see nothing in the definition of F. which permits a change of sign.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

There's precedence for printing it differently to other numbers?

Not sure what you mean with "precedence" here

I think he meant "precedent". It means it has been that way in the
past, though maybe not consistently.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/07/2022 02:21, minf...@arcor.de wrote:

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:

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.

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.

A system isn't required to support signed-zero (e.g. stock SwiftForth) but
if it chooses to, it has no option but to convey the result to the user.

-1e 0e f* f.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth <dxforth@gmail.com> writes:

I see nothing in the definition of F. which permits a change of sign.

The specification of F. does not specify much about it's output. In particular, it does not specify anything about which number is
displayed how.

Anyway, I gather from the reactions here that people think that in a high-quality implementation

0e fnegate f.

should output "-0.". So that's what Gforth now does; see

http://git.savannah.gnu.org/cgit/gforth.git/commit/?id=ffb2db329329c0ad67a5914be7f577b67726301e

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Mittwoch, 20. Juli 2022 um 21:11:31 UTC+2:

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:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

Everyone is free and happy to cook her own soup ;-)

Wolfram Alpha does:
log(0.0) or log(-0.0) --> undefined, whereas
log(0+0i) -> -inf, whereas
log(0.0+0.0i) -> undefined

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 21, 2022 at 4:37:24 PM UTC+2, minf...@arcor.de wrote:

Marcel Hendrix schrieb am Mittwoch, 20. Juli 2022 um 21:11:31 UTC+2:

[..]

MATLAB:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

Everyone is free and happy to cook her own soup ;-)

Wolfram Alpha does:
log(0.0) or log(-0.0) --> undefined, whereas
log(0+0i) -> -inf, whereas
log(0.0+0.0i) -> undefined

Soup? More like a bitches' brew.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

VFX:
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

[..]

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:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

VFX:
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

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

^

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/07/2022 15:16, Anton Ertl wrote:

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.

^

Looks likes 32->64 conversion issues (for Win x64 anyway).
I've sent Stephen an email and mentioned your result.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/07/2022 15:05, Marcel Hendrix wrote:

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:
[..]

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:

log(-0)

ans = -Inf

log(+0)

ans = -Inf

VFX:
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

After applying a fix to VFX64 I get those, in addition to 0e FLN working
as expected. Why is it classic?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/07/2022 15:16, Anton Ertl wrote:

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.

^

Stephen advises the fix will be in the next release.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/22 12:16, minf...@arcor.de wrote:

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:

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

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.

Since Forth 2012 doesn't mandate IEEE floating point arithmetic, error
codes 54 and 55 are not specific to IEEE arithmetic specs. My guess is
that they were intended for use by processors which can provide
interrupts on such generic errors. The floating point arithmetic
exceptions which can be enabled on the x86 fpus are

INVALID
DENORMAL
ZERODIVIDE
OVERFLOW
UNDERFLOW
INEXACT

All of these, except DENORMAL, map to the IEEE standard arithmetic
exceptions. From the IEEE Std 754-2008 document,

7.2 Invalid Operation
7.3 Division by zero
7.4 Overflow
7.5 Underflow
7.6 Inexact

With regard to Table 9.1 of the Forth-94 and 2012 standards, exception
code -54 can be thrown for an x86 fpu UNDERFLOW (7.5) error. I'm not
entirely sure about when to throw exception code -55.

Note that the standard also provides the following floating point error
codes:

-41 loss of precision (I assume this is floating point?)
-42 floating-point divide by zero
-43 floating-point result out of range
-46 floating-point invalid argument

It would be good to have common practice for mapping the x86 fpu
exceptions to the standard error codes.

--
Krishna

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/22 11:31, Krishna Myneni wrote:

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

The above line of code,

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 code is not generating an exception for the reason I thought. I
noticed this because strings.4th is not needed by any of the code, but
if I omit it, the code fails to generate an exception.

The fpu-x86.4th file permits examining the status and control registers
of the fpu as follows:

getFPUStatusX86 fpu-status ?
getFPUStateX86 fpu-control ?

Also, the word ClearFPUexceptionsX86 clears the fpu status register.

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.

Stay tuned.

--
KM

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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@

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/22 07:30, Krishna Myneni wrote:

On 7/30/22 23:02, Krishna Myneni wrote:

...

0 unmaskFPUexceptions \ mask all exceptions

...

Sigh. I just realized that the above line is bad logic. It does not mask
all fpu exceptions. It has no effect on the mask pattern. Corrected
code, using the definition maskAllFPUexceptions, is given below.

fpu-signals-test.4th
------
include ans-words
include modules
include syscalls
include mc
include asm-x86
include fpu-x86

: maskAllFPUexceptions ( -- )
FPU_CW_INVALID
FPU_CW_DENORMAL or
FPU_CW_ZERODIVIDE or
FPU_CW_OVERFLOW or
FPU_CW_UNDERFLOW or
FPU_CW_INEXACT or
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

: unmaskFPUexceptions ( bits -- )
invert getFPUStateX86 fpu-control @ and
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

cr .( Press a key to mask all FPU exceptions [default] )
cr .( and compute FLN of zero )
cr key drop

maskAllFPUexceptions
0e fln f. cr

cr .( Press a key to unmask the divideByZero FPU exception )
cr .( and compute FLN of zero.)
cr key drop

\ Clear current fpu exceptions before unmasking exceptions

clearFPUexceptionsX86

FPU_CW_ZERODIVIDE unmaskFPUexceptions
0e fln f.
-------

KM

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/22 23:02, Krishna Myneni wrote:

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.

...
The word modifyFPUStateX86 works but I used it incorrectly. The
following code illustrates the working method for unmasking fpu exceptions.

fpu-signals-test.4th
-------
include ans-words
include modules
include syscalls
include mc
include asm-x86
include fpu-x86
include dump
include ssd

: unmaskFPUexceptions ( bits -- )
invert getFPUStateX86 fpu-control @ and
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

cr .( Press a key to mask all FPU exceptions [default] )
cr .( and compute FLN of zero )
cr key drop

0 unmaskFPUexceptions \ mask all exceptions
0e fln f. cr

cr .( Press a key to unmask the divideByZero FPU exception )
cr .( and compute FLN of zero.)
cr key drop

\ Clear current fpu exceptions before unmasking exceptions

clearFPUexceptionsX86

FPU_CW_ZERODIVIDE unmaskFPUexceptions
0e fln f.
--------

Note that I define the word unmaskFPUexceptions which takes a bit
pattern for the exceptions to be unmasked. Several exceptions may be
unmasked by or'ing the mask constants together. Also note that any
pending exceptions in the fpu's status register will immediate signal a floating point exception if that particular exception is unmasked. If
you don't want that to happen, use clearFPUexceptionsX86 before
executing unmaskFPUexceptions, as illustrated above.

Output of the above code in kforth32 is given below.

------
include fpu-signals-test

Press a key to mask all FPU exceptions [default]
and compute FLN of zero
-inf

Press a key to unmask the divideByZero FPU exception
and compute FLN of zero.
Floating point exception (core dumped)
$
--------

--
Krishna Myneni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/22 00:38, dxforth wrote:

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@

Agreed that it's better to load the bit pattern for NAN than to actually generate exception(s) which are stored in the FPU status register and
can later trigger a floating point exception if the particular
exception(s) are unmasked. The alternative is to clear the FPU status
register after generating the exceptions.

--
Krishna

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)