Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135316
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: E.P E. E.EXACT |
| Date | 2026-08-08 06:32 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2026Aug8.083201@mips.complang.tuwien.ac.at> (permalink) |
| References | (3 earlier) <1152a6j$3uh9r$1@dont-email.me> <1152lu4$3788$1@dont-email.me> <6a752ecb$1@news.ausics.net> <2026Aug7.121124@mips.complang.tuwien.ac.at> <6a76b305$1@news.ausics.net> |
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.
>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 certainly have not received any
complaint about the output of F. in Gforth, and I guess the other
implementors have not received such complaints for their
implementations, either.
>> 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.
>> The output of FS. and FE. is not what I want when printing numbers
>> with absolute values between 0.001e and 1000000e.
>
>I agree that's useful and ANS doesn't preclude making such a function
>from existing ones.
And that's what E. does. In the meantime the implementation has changed again, and now
2e4 e.
prints "20000e". Currently
2e15 e.
prints "2000000000000000e" and I wonder if it would not be better to
switch to scientific notation at 1e8 or so.
>> 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.
>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.
- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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