Re: E.P E. E.EXACT

Date	2026-08-09 04:50 +1000
Subject	Re: E.P E. E.EXACT
Newsgroups	comp.lang.forth
References	(4 earlier) <1152lu4$3788$1@dont-email.me> <6a752ecb$1@news.ausics.net> <2026Aug7.121124@mips.complang.tuwien.ac.at> <6a76b305$1@news.ausics.net> <2026Aug8.083201@mips.complang.tuwien.ac.at>
From	dxf <dxforth@gmail.com>
Message-ID	<6a777a5b@news.ausics.net> (permalink)
Organization	Ausics - https://newsgroups.ausics.net

Show all headers | View raw

On 8/08/2026 4:32 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 7/08/2026 8:11 pm, Anton Ertl wrote:
>>> F. produces output that cannot be cut and pasted into the text
>>> interpreter.  
>>
>> That may be but has nothing to do with F. which outputs classic fixed-
>> point notation.
> 
> Given that it is a statement about F., it obviously has to do with F.

Only if F. had a responsibility to the text interpreter.  It doesn't.

>> If F. has an issue it's ambiguity in what precisely is printed.
>> Programmers need that detail to plan applications.
> 
> That's doubtful.  The problem is that the width of the output of
> F. depends on the printed number.  Given that variability, a
> predictable output for a specific number and SET-PRECISION setting has
> very little practical value.

I know what my F. prints.  I don't know what another's F. prints.
That's what a standard is meant to sort out.

> ...
>>> Moreover, if implemented as specified in the standard,
>>> you get really long outputs when printing numbers like 1e300 or 1e-300.
>>
>> Good.  That's exactly what fixed-point notation predicts.
> 
> But it's not practical.  Also, I reread the specification again:
> 
> |An ambiguous condition exists if [...] the character string
> |representation exceeds the size of the pictured numeric output string
> |buffer.
> 
> So F. working for 1e300 or 1e-300 is not guaranteed.

If printing 1e300 with F. was in any way the norm, I imagine ANS would
have guaranteed it.

> ...
>>> E.P is there for cases when you want shorter output than E. gives, at
>>> the cost of a loss of precision.
>>
>> So for all practical purposes E.P differs from Gforth's F. only in
>> respect of its switching to scientific mode?
> 
> It also differs by
> 
> 1) showing a number that can be copied and pasted into the Forth text
> interpreter (which F. output cannot).
> 
> 2) passing the precision on the data stack rather than through
> SET-PRECISION.
> 
> So it differs in pretty much every respect.

I expressed the question poorly.  From the examples you've shown,
E.P has used precision values well short of the 800 used by E.EXACT.
It appears E.P's target is the same as G.R in VFX i.e. numbers
printed at a precision no greater than the nominal precision of the
floats involved.

>> F. output from various forths as mentioned:
>>
>> \ Show F. output
>>
>> 8 set-precision
>>
>> 2e   3e f/ f.
>> 2e4  3e f/ f.
>> 2e-4 3e f/ f.
>> 1e         f.
>> 1e4        f.
>> 1e-4       f.
>>
>> \\
>>
>> SwiftForth:
>> 2e   3e f/ f. 0.66666667  ok
>> 2e4  3e f/ f. 6666.66666667  ok
>> 2e-4 3e f/ f. 0.00006667  ok
> 
> SET-PRECISION specifies the number of significant digits as 8, but the
> previous two lines show 12 or 4 significant digits.  That's a bug.
> 
>> VFX:
>> 2e   3e f/ f. 0.66666667  ok
>> 2e4  3e f/ f. 6666.6667  ok
>> 2e-4 3e f/ f. 0.000066666667  ok
>> 1e         f. 1.  ok
>> 1e4        f. 10000.  ok
>> 1e-4       f. 0.0001  ok
>>
>> Gforth:
>> 2e   3e f/ f. 0.66666667  ok
>> 2e4  3e f/ f. 6666.6667  ok
>> 2e-4 3e f/ f. 0.000066666667  ok
>> 1e         f. 1.  ok
>> 1e4        f. 10000.  ok
>> 1e-4       f. 0.0001  ok
> 
> Both use 8 significant digits and don't show trailing zeros.  See
> below about whether trailing zeros should be shown.
> 
>> Win32Forth:
>> 2e   3e f/ f. .66666667  ok
>> 2e4  3e f/ f. 6666.6667  ok
>> 2e-4 3e f/ f. .00006667  ok
>> 1e         f. 1.0000000  ok
>> 1e4        f. 10000.000  ok
>> 1e-4       f. .00010000  ok
> 
> This one apparently wants to show a fixed number of digits (probably
> influenced by SET-PRECISION), but does not show the required 8
> signficant digits in the third line.  A bug.
> 
>> NT/Forth:
>> 2e   3e f/ f. 0.66666667  ok
>> 2e4  3e f/ f. 6666.6667  ok
>> 2e-4 3e f/ f. 0.000066666667  ok
>> 1e         f. 1.0000000  ok
>> 1e4        f. 10000.000  ok
>> 1e-4       f. 0.00010000000  ok
> 
> This one shows trailing zeros, apparently as many as are significant
> digits.
> 
>> K-Forth: (CR not shown)
>> 2e   3e f/ f. 0.666667  ok
>> 2e4  3e f/ f. 6666.67  ok
>> 2e-4 3e f/ f. 6.66667e-05  ok
> 
> Only 6 significant digits instead of the 8 that were asked for.
> 
>> 1e         f. 1  ok
>> 1e4        f. 10000  ok
> 
> F. specifies a required ".", but that's missing here.
> 
>> MinForth:
>> 2e   3e f/ f. 0.66666667  ok
>> 2e4  3e f/ f. 6666.6667  ok
>> 2e-4 3e f/ f. 0.00006667  ok
>> 1e         f. 1.  ok
>> 1e4        f. 10000.  ok
>> 1e-4       f. 0.0001  ok
> 
> Only 4 significant digits in the third line.  A bug.
> 
> Concerning the differences that are not bugs, the specification of
> F. does not say anything about trailing zeros.  The rationale
> indicates that not showing trailing zeros is intended:
> 
> |For example, 1E3 F. displays 1000.
> 
> But given that that's not normative, showing trailing zeros is not a
> bug.

I don't think there's enough detail in ANS to say something is a bug.
What I'm seeing are varying interpretations.

Thread

E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-05 18:02 +0000
  Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 08:13 -0500
    Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 14:00 +0000
      Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 10:45 -0500
        Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 15:58 +0000
          Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 17:20 +0000
        Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-06 21:05 +0200
          Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 20:38 +0000
          Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 18:44 -0500
          Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-07 11:03 +1000
            Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-07 10:11 +0000
              Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-08 14:39 +1000
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-08 06:32 +0000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-09 04:50 +1000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 20:01 +1000
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 18:06 +0000
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 17:24 +0000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-11 14:01 +1000
                Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-10 22:10 -0500
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-11 04:56 +0000
                Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-11 22:16 -0500
                Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-12 05:47 -0500
                Re: E.P E. E.EXACT peter <peter.noreply@tin.it> - 2026-08-12 18:03 +0200
                Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-12 11:48 -0500
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-08 09:14 +0200
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-08 09:40 +0000
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-08 15:26 +0200
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 16:43 +0000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-09 13:43 +1000
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-09 07:19 +0200
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 19:15 +1000
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-10 13:17 +0200
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 22:59 +1000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 23:54 +1000
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-10 20:42 +0200
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-11 17:10 +1000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-12 14:04 +1000
                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 16:43 +0200
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 15:47 +0000
                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 18:27 +0200
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 16:40 +0000
                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 19:42 +0200
                Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 18:03 +0000
                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 22:56 +0200
                Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-23 00:50 +0200
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-23 12:25 +1000
                Re: E.P E. E.EXACT Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-09 14:52 +0200
            Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-07 07:50 -0500
              Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-08 12:33 +1000
                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 17:01 +0200
          Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 16:15 +0200

csiph-web