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: | 505 |
Nodes: | 16 (2 / 14) |
Uptime: | 54:09:27 |
Calls: | 9,922 |
Calls today: | 9 |
Files: | 13,804 |
Messages: | 6,347,970 |