Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135300 > unrolled thread

E.P E. E.EXACT

Back to article view | Back to comp.lang.forth

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#135300 — E.P E. E.EXACT

Gforth now has three new words:

E. ( r -- ) prints an FP number r in a format that is understood by
   Gforth's text interpreter and produces the same number.  Tries to
   produce short outputs.

E.EXACT ( r -- ) prints an FP number, showing all (possibly hundreds)
   of the mantissa digits.

E.P ( r u -- ) prints an FP number with at most u (or, if that saves
   printing an exponent, u+1) mantissa digits.

Example usage and output (as comment):

: s-as-f {: w^ n :} n f@ ;
0e e.         \ 0e ok
1e e.         \ 1e ok
0.1e e.       \ .1e ok
0.00005e e.   \ .00005e ok
0.000005e e.  \ 5e-6 ok
2000e e.      \ 2e3 ok
20000e e.     \ 2e4 ok
1 s-as-f e.   \ 5e-324 ok

Note that the latter number takes more than 700 digits when printed
with e.exact; only one mantissa digit is necessary to distinguish it
from other numbers, because the next FP number has a value close to
1e-323.

0e e.exact        \ 0e ok
1e e.exact        \ 1e ok
0.1e e.exact      \ .1000000000000000055511151231257827021181583404541015625e ok
0.00005e e.exact  \ .0000500000000000000023960868011929647991564706899225711822509765625e ok
0.000005e e.exact \ 5.0000000000000004090152695701565477293115691281855106353759765625e-6 ok
2000e e.exact     \ 2000e ok
20000e e.exact    \ 20000e ok
2e23 e.exact      \ 199999999999999983222784e ok

Note that the difference between the input and the output in these
cases comes from the input side (>FLOAT): 0.1e, 0.00005e, 0.000005e
and 2e23 cannot be represented exactly in binary64 (IEEE
double-precision) FP, do >FLOAT produces the FP number closest to the
decimal representation.  E.EXACT then prints all the digits of this
number, while E. prints a number that is close and consumes as few
digits as possible.

0e 6 e.p        \ 0e ok
1e 6 e.p        \ 1e ok
0.1e 6 e.p      \ .1e ok
0.00005e 6 e.p  \ .00005e ok
0.000005e 6 e.p \ 5e-6 ok
2000e 6 e.p     \ 2000e ok
20000e 6 e.p    \ 20000e ok
1234567e 6 e.p  \ 1234567e ok

The last case is one where we prefer to print one additional mantissa
digit and leave the exponent away instead of writing 1.23457e6.

You can find the source code at
<https://cgit.git.savannah.gnu.org/cgit/gforth.git/tree/edot.fs>

- 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

[toc] | [next] | [standalone]

#135303

On 8/5/26 13:02, Anton Ertl wrote:
> Gforth now has three new words:
> 
> E. ( r -- ) prints an FP number r in a format that is understood by
>     Gforth's text interpreter and produces the same number.  Tries to
>     produce short outputs.
> 
> E.EXACT ( r -- ) prints an FP number, showing all (possibly hundreds)
>     of the mantissa digits.
> 
> E.P ( r u -- ) prints an FP number with at most u (or, if that saves
>     printing an exponent, u+1) mantissa digits.
> 
> Example usage and output (as comment):
> 
> : s-as-f {: w^ n :} n f@ ;
> 0e e.         \ 0e ok
> 1e e.         \ 1e ok
> 0.1e e.       \ .1e ok
> 0.00005e e.   \ .00005e ok
> 0.000005e e.  \ 5e-6 ok
> 2000e e.      \ 2e3 ok
> 20000e e.     \ 2e4 ok
> 1 s-as-f e.   \ 5e-324 ok
> 
> Note that the latter number takes more than 700 digits when printed
> with e.exact; only one mantissa digit is necessary to distinguish it
> from other numbers, because the next FP number has a value close to
> 1e-323.
> 
> 0e e.exact        \ 0e ok
> 1e e.exact        \ 1e ok
> 0.1e e.exact      \ .1000000000000000055511151231257827021181583404541015625e ok
> 0.00005e e.exact  \ .0000500000000000000023960868011929647991564706899225711822509765625e ok
> 0.000005e e.exact \ 5.0000000000000004090152695701565477293115691281855106353759765625e-6 ok
> 2000e e.exact     \ 2000e ok
> 20000e e.exact    \ 20000e ok
> 2e23 e.exact      \ 199999999999999983222784e ok
> 
> Note that the difference between the input and the output in these
> cases comes from the input side (>FLOAT): 0.1e, 0.00005e, 0.000005e
> and 2e23 cannot be represented exactly in binary64 (IEEE
> double-precision) FP, do >FLOAT produces the FP number closest to the
> decimal representation.  E.EXACT then prints all the digits of this
> number, while E. prints a number that is close and consumes as few
> digits as possible.
> 
> 0e 6 e.p        \ 0e ok
> 1e 6 e.p        \ 1e ok
> 0.1e 6 e.p      \ .1e ok
> 0.00005e 6 e.p  \ .00005e ok
> 0.000005e 6 e.p \ 5e-6 ok
> 2000e 6 e.p     \ 2000e ok
> 20000e 6 e.p    \ 20000e ok
> 1234567e 6 e.p  \ 1234567e ok
> 

I would use FS.EXACT (instead of E.EXACT) and keep the output in 
scientific notation. Less to remember that way.

Similarly, E.P is unneeded if you format the output in scientific 
notation and use FS. in combination with SET-PRECISION to specify the 
number of digits after the decimal point.

How does "E." work for an inexactly representable binary64 floating 
point number?

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135304

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 8/5/26 13:02, Anton Ertl wrote:
>> Gforth now has three new words:
>> 
>> E. ( r -- ) prints an FP number r in a format that is understood by
>>     Gforth's text interpreter and produces the same number.  Tries to
>>     produce short outputs.
>> 
>> E.EXACT ( r -- ) prints an FP number, showing all (possibly hundreds)
>>     of the mantissa digits.
>> 
>> E.P ( r u -- ) prints an FP number with at most u (or, if that saves
>>     printing an exponent, u+1) mantissa digits.
>> 
>> Example usage and output (as comment):
>> 
>> : s-as-f {: w^ n :} n f@ ;
>> 0e e.         \ 0e ok
>> 1e e.         \ 1e ok
>> 0.1e e.       \ .1e ok
>> 0.00005e e.   \ .00005e ok
>> 0.000005e e.  \ 5e-6 ok
>> 2000e e.      \ 2e3 ok
>> 20000e e.     \ 2e4 ok
>> 1 s-as-f e.   \ 5e-324 ok
>> 
>> Note that the latter number takes more than 700 digits when printed
>> with e.exact; only one mantissa digit is necessary to distinguish it
>> from other numbers, because the next FP number has a value close to
>> 1e-323.
>> 
>> 0e e.exact        \ 0e ok
>> 1e e.exact        \ 1e ok
>> 0.1e e.exact      \ .1000000000000000055511151231257827021181583404541015625e ok
>> 0.00005e e.exact  \ .0000500000000000000023960868011929647991564706899225711822509765625e ok
>> 0.000005e e.exact \ 5.0000000000000004090152695701565477293115691281855106353759765625e-6 ok
>> 2000e e.exact     \ 2000e ok
>> 20000e e.exact    \ 20000e ok
>> 2e23 e.exact      \ 199999999999999983222784e ok
>> 
>> Note that the difference between the input and the output in these
>> cases comes from the input side (>FLOAT): 0.1e, 0.00005e, 0.000005e
>> and 2e23 cannot be represented exactly in binary64 (IEEE
>> double-precision) FP, do >FLOAT produces the FP number closest to the
>> decimal representation.  E.EXACT then prints all the digits of this
>> number, while E. prints a number that is close and consumes as few
>> digits as possible.
>> 
>> 0e 6 e.p        \ 0e ok
>> 1e 6 e.p        \ 1e ok
>> 0.1e 6 e.p      \ .1e ok
>> 0.00005e 6 e.p  \ .00005e ok
>> 0.000005e 6 e.p \ 5e-6 ok
>> 2000e 6 e.p     \ 2000e ok
>> 20000e 6 e.p    \ 20000e ok
>> 1234567e 6 e.p  \ 1234567e ok
>> 
>
>I would use FS.EXACT (instead of E.EXACT) and keep the output in 
>scientific notation.

Go ahead.  I find the non-scientific notation helpful when it does not
introduce too many zeros.

> Less to remember that way.

?


>Similarly, E.P is unneeded if you format the output in scientific 
>notation and use FS. in combination with SET-PRECISION to specify the 
>number of digits after the decimal point.

10 set-precision 20e fs. \ 2.000000000E1  ok
20e 10 e.p               \ 20e ok

To each their own.  Also, E.P is a factor of E. and E.EXACT, so not
documenting it buys little.

>How does "E." work for an inexactly representable binary64 floating 
>point number?

For printing r, it first tries

r 1 e.p

and looks if applying >FLOAT on the result produces r.  If not it tries

r 2 e.p

and so on.  In the end you have the string with the shortest mantissa
that converts back to r.

Yes, this approach is expensive (~9us per e. for random normal numbers
on a Ryzen 8700G (~5GHz Zen4)).

In the meantime I found, that for normal (not subnormal) numbers, it's
probably enough to test

r 15 e.p
r 16 e.p

and if that's not enough

r 17 e.p

can be used without checking (that's for binary64 numbers, other
formats need other precisions).  The benefit would be that e. now only
takes about 1.6us.  One would need a mathematical proof to be sure,
though.

- 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

[toc] | [prev] | [next] | [standalone]

#135305

On 8/6/26 09:00, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
...
>>
>> I would use FS.EXACT (instead of E.EXACT) and keep the output in
>> scientific notation.
> 
> Go ahead.  I find the non-scientific notation helpful when it does not
> introduce too many zeros.
> 
>> Less to remember that way.
> 
> ?
> 

I meant not having to remember a new prefix for floating point output 
words. Currently the standard has "F", "FS", and "FE" prefixes.

> 
>> Similarly, E.P is unneeded if you format the output in scientific
>> notation and use FS. in combination with SET-PRECISION to specify the
>> number of digits after the decimal point.
> 
> 10 set-precision 20e fs. \ 2.000000000E1  ok
> 20e 10 e.p               \ 20e ok
> 

Apparently I misunderstood what E.P was intended to do. The example 
above clarifies that the requested number of digits may not be printed 
if a shorter representation is available.

> 
>> How does "E." work for an inexactly representable binary64 floating
>> point number?
> 
> For printing r, it first tries
> 
> r 1 e.p
> 
> and looks if applying >FLOAT on the result produces r.  If not it tries
> 
> r 2 e.p
> 
> and so on.  In the end you have the string with the shortest mantissa
> that converts back to r.
> 
> Yes, this approach is expensive (~9us per e. for random normal numbers
> on a Ryzen 8700G (~5GHz Zen4)).
> 
> In the meantime I found, that for normal (not subnormal) numbers, it's
> probably enough to test
> 
> r 15 e.p
> r 16 e.p
> 
> and if that's not enough
> 
> r 17 e.p
> 
> can be used without checking (that's for binary64 numbers, other
> formats need other precisions).  The benefit would be that e. now only
> takes about 1.6us.  One would need a mathematical proof to be sure,
> though.
> 
E. is useful for finding the shortest decimal input which will convert 
to the internal representation for a given decimal floating point input. 
I wonder if there is a more direct way to arrive at that, rather than 
the iterative procedure.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135306

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>E. is useful for finding the shortest decimal input which will convert 
>to the internal representation for a given decimal floating point input. 
>I wonder if there is a more direct way to arrive at that, rather than 
>the iterative procedure.

There sure is, and that's what the papers are about, and the best
approach is probably at least 50 times faster than my current
E. implementation.  But these approaches are more complicated to
implement, so for now, I'll stick with the slow one.

- 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

[toc] | [prev] | [next] | [standalone]

#135307

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>There sure is, and that's what the papers are about, and the best
>approach is probably at least 50 times faster than my current
>E. implementation.

This was an estimate based on very little.  In order to produce a
firmer base, my guess is that a fast implementation would be roughly
as fast as REPRESENT with a 17-digit buffer (certainly not faster).
So I measured that, and it costs about 0.35us, i.e., a factor 25
faster than the current E.

- 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

[toc] | [prev] | [next] | [standalone]

#135308

On 8/6/2026 5:45 PM, Krishna Myneni wrote:
> On 8/6/26 09:00, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
[..]
> E. is useful for finding the shortest decimal input which will convert 
> to the internal representation for a given decimal floating point input. 
> I wonder if there is a more direct way to arrive at that, rather than 
> the iterative procedure.[..]

HEX string input and output when the provider and consumer can not 
communicate in binary, or when the binary formats are not standard IEEE.
As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, 
it could be done without adding new words. However, >FLOAT might be a 
problem.

-marcel

[toc] | [prev] | [next] | [standalone]

#135309

marcel hendrix <mhx@iae.nl> writes:
>On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>> On 8/6/26 09:00, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>[..]
>> E. is useful for finding the shortest decimal input which will convert 
>> to the internal representation for a given decimal floating point input. 
>> I wonder if there is a more direct way to arrive at that, rather than 
>> the iterative procedure.[..]
>
>HEX string input and output when the provider and consumer can not 
>communicate in binary, or when the binary formats are not standard IEEE.

We have DF@ and DF! for getting standard IEEE binary format.  But
sure, if you want to accurately represent the full contents of an FP
stack item, that's not good enough.

Concerning some hex representation, the advantage of E. over that is
that many more people have a good idea what the result actually means.

- 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

[toc] | [prev] | [next] | [standalone]

#135310

On 8/6/26 14:05, marcel hendrix wrote:
> On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>> On 8/6/26 09:00, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
> [..]
>> E. is useful for finding the shortest decimal input which will convert 
>> to the internal representation for a given decimal floating point 
>> input. I wonder if there is a more direct way to arrive at that, 
>> rather than the iterative procedure.[..]
> 
> HEX string input and output when the provider and consumer can not 
> communicate in binary, or when the binary formats are not standard IEEE.
> As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, 
> it could be done without adding new words. However, >FLOAT might be a 
> problem.
> 

Do you main "cannot communicate in decimal"? HEX and binary convey the 
same information since 16 is a power of 2, while 10 is not, and 
therefore may require a large number of digits. In any case, if the 
binary formats are not the same between provider and consumer, how does 
a hex string help e.g. convey IEEE special values to a format which does 
not include them?

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135311

On 7/08/2026 5:05 am, marcel hendrix wrote:
> On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>> On 8/6/26 09:00, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
> [..]
>> E. is useful for finding the shortest decimal input which will convert to the internal representation for a given decimal floating point input. I wonder if there is a more direct way to arrive at that, rather than the iterative procedure.[..]
> 
> HEX string input and output when the provider and consumer can not communicate in binary, or when the binary formats are not standard IEEE.
> As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, it could be done without adding new words. However, >FLOAT might be a problem.

AFAICS E.EXACT E. are for academics only.  E.P just tells me the minimal
and ambiguous functions ANS suggested were never going to be enough.  If
the user can specify a level of precision then 'exact' was never the goal.

[toc] | [prev] | [next] | [standalone]

#135312

dxf <dxforth@gmail.com> writes:
>AFAICS E.EXACT E. are for academics only.

What makes you think so?

E. is intended to be the go-to way to print FP numbers if there are no
formatting constraints.  In particular, E. produces an output that you
can copy-and-paste again as input for the Forth text interpreter.

>E.P just tells me the minimal
>and ambiguous functions ANS suggested were never going to be enough.

The standard FP-printing words all have shortcomings:

F. produces output that cannot be cut and pasted into the text
interpreter.  Moreover, if implemented as specified in the standard,
you get really long outputs when printing numbers like 1e300 or 1e-300.

The output of FS. and FE. is not what I want when printing numbers
with absolute values between 0.001e and 1000000e.

E.P is there for cases when you want shorter output than E. gives, at
the cost of a loss of precision.

- 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

[toc] | [prev] | [next] | [standalone]

#135315

On 7/08/2026 8:11 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> AFAICS E.EXACT E. are for academics only.
> 
> What makes you think so?
> 
> E. is intended to be the go-to way to print FP numbers if there are no
> formatting constraints.  In particular, E. produces an output that you
> can copy-and-paste again as input for the Forth text interpreter.
> 
>> E.P just tells me the minimal
>> and ambiguous functions ANS suggested were never going to be enough.
> 
> The standard FP-printing words all have shortcomings:
> 
> 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.

If F. has an issue it's ambiguity in what precisely is printed.
Programmers need that detail to plan applications.  See end of post
which compares F. across a several forths.  FS. FE. also show variation
though not as pronounced.

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

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

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

> 
> - anton

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
1e         f. 1.00000000  ok
1e4        f. 10000.00000000  ok
1e-4       f. 0.00010000  ok

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

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

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

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
1e         f. 1  ok
1e4        f. 10000  ok
1e-4       f. 0.0001  ok

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

[toc] | [prev] | [next] | [standalone]

#135316

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

[toc] | [prev] | [next] | [standalone]

#135320

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.

[toc] | [prev] | [next] | [standalone]

#135325

On 9/08/2026 4:50 am, dxf wrote:
> On 8/08/2026 4:32 pm, Anton Ertl wrote:
>> ...
>> 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.

As mentioned some time ago ANS-TC began with a very different scheme
to what was eventually released.  Originally fp output was specified in
terms of 'decimal places' - the industry standard.  After the switch
to 'significant digits' all references to PLACES were replaced with
PRECISION.  But they missed some.  Here's what F. currently states:

    12.6.2.1427 F.
    f-dot FLOATING EXT
            ( -- ) ( F: r -- ) or ( r -- )

   Display, with a trailing space, the top number on the floating-point
   stack using fixed-point notation:   

"fixed-point notation" means *decimal places*.  Unfortunately for implementers
there are no 'decimal PLACES' to be found in the document.  It didn't help that
there was no explanation as to how to apply PRECISION either.  They went from
proven technology to something that was speculative and untried.  The silver
lining is it gave forthers something to think about.

[toc] | [prev] | [next] | [standalone]

#135331

dxf <dxforth@gmail.com> writes:
>As mentioned some time ago ANS-TC began with a very different scheme
>to what was eventually released.  Originally fp output was specified in
>terms of 'decimal places' - the industry standard.

I never heard of that "industry standard".  So I typed "decimal
places" into en.wikipedia.org, and the first hit is "decimal", and the
second hit is "Significant figures (Redirected from Decimal places)".
Funny industry standard.

>After the switch
>to 'significant digits' all references to PLACES were replaced with
>PRECISION.  But they missed some.  Here's what F. currently states:
>
>    12.6.2.1427 F.
>    f-dot FLOATING EXT
>            ( -- ) ( F: r -- ) or ( r -- )
>
>   Display, with a trailing space, the top number on the floating-point
>   stack using fixed-point notation:   
>
>"fixed-point notation" means *decimal places*.

You conveniently elided the stuff following after the colon, which indicates what they mean with "fixed-point notation":

|     [-] <digits>.<digits0>

No mention about "places" anywhere.  And the rationale says:

|A.12.6.2.1427 F.
|
|For example, 1E3 F. displays 1000.

Not something I would expect if they had decimal place in mind.

In any case, SET-PRECISION and PRECISION are clear: They talk about
significant digits.

>Unfortunately for implementers
>there are no 'decimal PLACES' to be found in the document.

What's unfortunate about that?

>It didn't help that
>there was no explanation as to how to apply PRECISION either.

PRECISION just returns the number of significant digits.  More
relevant is:

|12.6.2.2200 SET-PRECISION FLOATING EXT ( u -- )
|
|Set the number of significant digits currently used by F., FE., or FS. to u.

That's unambiguous, except wrt. trailing zeros.

>They went from
>proven technology to something that was speculative and untried.

?

Significant digits are neiter speculative nor untried, and were not
when Forth-94 was designed, either.  E.g.,
<https://en.wikipedia.org/wiki/Decimal_places> cites (reference 2)

| Chemistry in the Community; Kendall-Hunt:Dubuque, IA 1988

- 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

[toc] | [prev] | [next] | [standalone]

#135330

dxf <dxforth@gmail.com> writes:
>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.

Sure, but that's one more reason not to use it, and use E. instead.

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

Given that well-reputed Forth systems deviate even from what the
standard specifies, that seems to be the position of an insignificant
minority.  The rest just does not care about the format and precision
of the F. output, or at least not for what the standard specifies for
it.

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

Maybe they had that in mind as escape hatch: With 32-bit cells
(considered large when Forth-94 was designed) the pictured numeric
output buffer shall be at least 66 chars, so printing any FP number
that requires more chars would be ambigous (for 16-bit cells already
at 34 chars).  And in that case, the Forth system can do something
more practical, such as outputting the number in scientific notation.

With 64-bit cells and a PNO buffer >=130 chars, the practicality of
this escape hatch is doubtful, however.

>From the examples you've shown,
>E.P has used precision values well short of the 800 used by E.EXACT.

r E. already outputs a number within 0.5 epsilon of r.  Printing
anything longer only makes sense if you want to print r exactly.  And
that mainly makes sense to demonstrate which numbers binary FP can
represent exactly, and what becomes of the numbers that cannot be
represented exactly.

So I don't see a point for any p between what E. uses (p<=17) and what
E.EXACT uses (p=800 for binary64 (IEEE DP)).  But you may want shorter
output (at the expense of less precision), then you use E.P with a
smaller p than E. uses.

About demonstrations, here's one:

0.1e e.exact \ .1000000000000000055511151231257827021181583404541015625e ok
\ now produce the next-smaller FP value: \ ok
0.1e pad f! -1 pad +! pad f@ \ ok f:1
\ and print it \ ok f:1
e.exact \ .09999999999999999167332731531132594682276248931884765625e ok

If we compare these numbers:

.1000000000000000055511151231257827021181583404541015625e
.09999999999999999167332731531132594682276248931884765625e

we see that the former is closer to 0.1 than the latter.

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

G.R provides fixed-length output and is therefore more along the lines
of F.RDP.  G.R and G. also does not guarantee numbers that can be
pasted into the text interpreter.

>I don't think there's enough detail in ANS to say something is a bug.

There definitely is, otherwise I would not have been able to point out
bugs.

- 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

[toc] | [prev] | [next] | [standalone]

#135334

On 11/08/2026 3:24 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 8/08/2026 4:32 pm, Anton Ertl wrote:
>>> dxf <dxforth@gmail.com> writes:
> ... 
>> 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.
> 
> Given that well-reputed Forth systems deviate even from what the
> standard specifies, that seems to be the position of an insignificant
> minority.  The rest just does not care about the format and precision
> of the F. output, or at least not for what the standard specifies for
> it.

I can't speak for "well-reputed Forth systems" but I do my best to
document what I have.  Should I knowingly deviate from what a standard
word does, I'll make it clear how.  As most of the systems I tested
haven't done so in regard to F. FS. FE. (1) I can only assume they did
their best to comply with the standard as they understood it.

(1) iForth's definition of PRECISION plainly differs from the standard:

    PRECISION                                                            FLOAT
    ( -- u )

    PRECISION returns the number of decimal places (digits to the right of the 
    radix point) displayed by E. , FE. or FS. .

> ...
>> If printing 1e300 with F. was in any way the norm, I imagine ANS would
>> have guaranteed it.
> 
> Maybe they had that in mind as escape hatch: With 32-bit cells
> (considered large when Forth-94 was designed) the pictured numeric
> output buffer shall be at least 66 chars, so printing any FP number
> that requires more chars would be ambigous (for 16-bit cells already
> at 34 chars).  And in that case, the Forth system can do something
> more practical, such as outputting the number in scientific notation.
> 
> With 64-bit cells and a PNO buffer >=130 chars, the practicality of
> this escape hatch is doubtful, however.

Apparently ANS saw F. and FS. as two distinct notations - as do I.
I see nothing impractical about 'floating point notation' (what F.
does) in the circumstances in which one would use it.  You appear
to have reached the same conclusion in respect of E.P and F.RDP

FWIW classic 16-bit Fig-Forth (and probably most forths of the day)
had more than 34 chars available to print numbers.  It was more like
68 chars as the buffer was shared with WORD (each building from the
opposite direction).

[toc] | [prev] | [next] | [standalone]

#135333

On 8/8/26 01:32, Anton Ertl wrote:
...
>> 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.
> 

Yes, the value of SET-PRECISION currently does not affect F. in kForth, 
though it is specified by the standard. This was an oversight. I 
typically use FS. when I need to specify the number of digits shown.

F. will be modified to conform to the standard -- it is not an 
immediately pressing issue, but thanks for pointing it out.


>> 1e         f. 1  ok
>> 1e4        f. 10000  ok
> 
> F. specifies a required ".", but that's missing here.
> 
The only indication in the standard that a trailing "." appears is the 
example in the appendix; otherwise, my reading of the standard is 
ambiguous on the trailing decimal point. It should be explicitly stated 
if the trailing decimal point was the intent.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135335

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 8/8/26 01:32, Anton Ertl wrote:
>> F. specifies a required ".", but that's missing here.
>> 
>The only indication in the standard that a trailing "." appears is the 
>example in the appendix; otherwise, my reading of the standard is 
>ambiguous on the trailing decimal point.

The standard specifies:

| 12.6.2.1427 F.
| [...]
| [-] <digits>.<digits0> 

If they intended the "." to be optional, they would have specified that as

[-] <digits>[.<digits0>]

>It should be explicitly stated 
>if the trailing decimal point was the intent.

It is.

- 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web