• Re: What do floating point words do with NAN?

    From Marcel Hendrix@21:1/5 to dxforth on Tue Jul 19 05:02:29 2022
    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)
  • From Marcel Hendrix@21:1/5 to dxforth on Tue Jul 19 04:59:57 2022
    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)
  • From Paul Rubin@21:1/5 to dxforth on Tue Jul 19 05:05:04 2022
    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)
  • From dxforth@21:1/5 to Paul Rubin on Tue Jul 19 23:53:09 2022
    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)
  • From dxforth@21:1/5 to Marcel Hendrix on Wed Jul 20 00:34:28 2022
    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)
  • From Marcel Hendrix@21:1/5 to dxforth on Tue Jul 19 09:32:43 2022
    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)
  • From none) (albert@21:1/5 to mhx@iae.nl on Tue Jul 19 21:55:16 2022
    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)
  • From dxforth@21:1/5 to albert on Wed Jul 20 09:33:25 2022
    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)
  • From dxforth@21:1/5 to Paul Rubin on Wed Jul 20 14:00:53 2022
    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)
  • From Anton Ertl@21:1/5 to dxforth on Wed Jul 20 11:48:52 2022
    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)
  • From Anton Ertl@21:1/5 to Paul Rubin on Wed Jul 20 11:46:17 2022
    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)
  • From dxforth@21:1/5 to Anton Ertl on Wed Jul 20 23:12:33 2022
    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)
  • From minforth@arcor.de@21:1/5 to Anton Ertl on Wed Jul 20 09:21:03 2022
    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)
  • From Marcel Hendrix@21:1/5 to minf...@arcor.de on Wed Jul 20 12:11:30 2022
    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)
  • From Paul Rubin@21:1/5 to Anton Ertl on Wed Jul 20 18:08:18 2022
    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)
  • From dxforth@21:1/5 to minf...@arcor.de on Thu Jul 21 13:33:40 2022
    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)
  • From Anton Ertl@21:1/5 to dxforth on Thu Jul 21 13:52:09 2022
    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)
  • From minforth@arcor.de@21:1/5 to Marcel Hendrix on Thu Jul 21 07:37:23 2022
    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)
  • From Marcel Hendrix@21:1/5 to minf...@arcor.de on Thu Jul 21 10:25:06 2022
    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)
  • From dxforth@21:1/5 to Marcel Hendrix on Fri Jul 22 12:38:02 2022
    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)
  • From Marcel Hendrix@21:1/5 to dxforth on Thu Jul 21 22:05:40 2022
    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)
  • From Anton Ertl@21:1/5 to dxforth on Fri Jul 22 05:16:41 2022
    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)
  • From dxforth@21:1/5 to Anton Ertl on Fri Jul 22 16:38:57 2022
    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)
  • From dxforth@21:1/5 to Marcel Hendrix on Fri Jul 22 17:49:51 2022
    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)
  • From dxforth@21:1/5 to Anton Ertl on Sun Jul 24 14:31:16 2022
    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)
  • From minforth@arcor.de@21:1/5 to dxforth on Sat Jul 30 05:22:51 2022
    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)
  • From Krishna Myneni@21:1/5 to minf...@arcor.de on Sat Jul 30 11:31:34 2022
    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)
  • From minforth@arcor.de@21:1/5 to Krishna Myneni on Sat Jul 30 10:16:30 2022
    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)
  • From Krishna Myneni@21:1/5 to minf...@arcor.de on Sat Jul 30 20:56:24 2022
    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)
  • From Krishna Myneni@21:1/5 to Krishna Myneni on Sat Jul 30 23:02:57 2022
    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)
  • From dxforth@21:1/5 to Krishna Myneni on Sun Jul 31 15:38:19 2022
    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)
  • From Krishna Myneni@21:1/5 to Krishna Myneni on Sun Jul 31 08:04:02 2022
    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)
  • From Krishna Myneni@21:1/5 to Krishna Myneni on Sun Jul 31 07:30:03 2022
    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)
  • From Krishna Myneni@21:1/5 to dxforth on Sun Jul 31 07:34:47 2022
    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)