dxforth <dxforth@gmail.com> writes:
> But chose to provide it as hardware didn't? 'Negative zero' is only
> meaningful if a system expressly supports it.

Negative zero is supported by essentially all floating point hardware
these days. But oh man, F~ is ugly. 0e and -0e have different
encodings (bit patterns) even though F= compares them as equal.

> E.g. there doesn't seem much point having F~ do:
> 0e -0e 0e f~ . 0 ok

On that system 0e and -0e have the same bit pattern, so

> if one couldn't print it out:
> -0e f. 0. ok

should operate as you describe. On an IEEE system (most systems now),
-0e f. prints -0.

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

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

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

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

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?

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

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

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

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/

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

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.

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

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

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.

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

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

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

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.

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.

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

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.

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.

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