kForth 32-bit Development Plans

[Krishna Myneni]

While I have had a brief couple of months respite from actively
developing kForth, one of the reasons has been that I have been actively
using it successfully on computing tasks. Although Bernd Paysan has
expressed the opinion that 32-bit computing is retro computing, for me
it still remains useful and I don't plan to abandon continued
development of the 32-bit versions of kForth, which presently come in
two variants:

ver. 1.x -- mostly Forth-94 compatible, uses integrated fp/data stack.

ver. 2.x -- provides Forth-2012 functionality, but still uses integrated
fp/data stack.

ver. 3.x -- in progress (no releases yet); will provide integrated
fp/data stack.

Retirement of ver. 1.x, currently available for Linux and Win32, is
imminent. No further development beyond v1.8.x will occur.

Version 2.x will switch from development to maintenance mode after its
Win32 release. New 32-bit development will focus on ver 3.x.

Ver 3.x will be the 32-bit counterpart of kForth-64.

--
Krishna Myneni

[Krishna Myneni]

On 1/21/23 11:35, Krishna Myneni wrote:
...

> ver. 3.x -- in progress (no releases yet); will provide integrated
> fp/data stack.
>

...

should be "will provide separate fp stack".

--
KM

[dxforth]

That will give you access to a wealth of new f/p applications.
At least that's what I've been told :)

Speaking of f/p I've just ditched output functions G.R and G. and
subsumed the functionality into F.R and F. While this breaks the
ANS notion of what F. was intended to print*, I still retain (F.)
and (G.) which output fixed and mixed notation respectively.

*It's an open question what F. is exactly supposed to print because
the sole example ANS gave was ambiguous. So in making the changes
mentioned in the previous paragraph I don't consider I'm shooting
myself (or anyone) in the foot.

[Marcel Hendrix]

On Sunday, January 22, 2023 at 7:22:12 AM UTC+1, dxforth wrote:
[..]

> Speaking of f/p I've just ditched output functions G.R and G. and
> subsumed the functionality into F.R and F. While this breaks the
> ANS notion of what F. was intended to print*, I still retain (F.)
> and (G.) which output fixed and mixed notation respectively.

Probably worth a new thread, but... Over the years I have
needed dozens of variants of the basic floating-point
formatting words. There is always something
slightly different that is needed (sufficiently
different or useful to put in a new word). Is
this a commonly accepted fact, or does it
indicate that we don't have the proper
Forth way to factor the problem yet?

-marcel

[Anton Ertl]

Marcel Hendrix <m...@iae.nl> writes:
>Probably worth a new thread, but... Over the years I have
>needed dozens of variants of the basic floating-point
>formatting words. There is always something
>slightly different that is needed (sufficiently
>different or useful to put in a new word). Is
>this a commonly accepted fact, or does it
>indicate that we don't have the proper
>Forth way to factor the problem yet?

When I looked into the problem, I found no good way to apply the
flexible approach used for integers (with # HOLD etc.) for FP output.
I also inspected what C does with printf(), and eventually settled on
F.RDP. Here's the documentation:

|'f.rdp' ( rf +nr +nd +np -- ) gforth-0.6 "f.rdp"
| Print float rf formatted. The total width of the output is nr. For
|fixed-point notation, the number of digits after the decimal point is
|+nd and the minimum number of significant digits is np. 'Set-precision'
|has no effect on 'f.rdp'. Fixed-point notation is used if the number of
|siginicant digits would be at least np and if the number of digits
|before the decimal point would fit. If fixed-point notation is not
|used, exponential notation is used, and if that does not fit, asterisks
|are printed. We recommend using nr>=7 to avoid the risk of numbers not
|fitting at all. We recommend nr>=np+5 to avoid cases where 'f.rdp'
|switches to exponential notation because fixed-point notation would have
|too few significant digits, yet exponential notation offers fewer
|significant digits. We recommend nr>=nd+2, if you want to have
|fixed-point notation for some numbers; the smaller the value of np, the
|more cases are shown in fixed-point notation (cases where few or no
|significant digits remain in fixed-point notation). We recommend np>nr,
|if you want to have exponential notation for all numbers. the field
|width for f.s output. Other precision details are derived from that
|value.
|
| To give you a better intuition of how they influence the output, here
|are some examples of parameter combinations; in each line the same
|number is printed, in each column the same parameter combination is used
|for printing:
|
| 12 13 0 7 3 4 7 3 0 7 3 1 7 5 1 7 7 1 7 0 2 4 2 1
| |-1.234568E-6|-1.2E-6| -0.000|-1.2E-6|-1.2E-6|-1.2E-6|-1.2E-6|****|
| |-1.234568E-5|-1.2E-5| -0.000|-1.2E-5|-.00001|-1.2E-5|-1.2E-5|****|
| |-1.234568E-4|-1.2E-4| -0.000|-1.2E-4|-.00012|-1.2E-4|-1.2E-4|****|
| |-1.234568E-3|-1.2E-3| -0.001| -0.001|-.00123|-1.2E-3|-1.2E-3|****|
| |-1.234568E-2|-1.2E-2| -0.012| -0.012|-.01235|-1.2E-2|-1.2E-2|-.01|
| |-1.234568E-1|-1.2E-1| -0.123| -0.123|-.12346|-1.2E-1|-1.2E-1|-.12|
| |-1.2345679E0| -1.235| -1.235| -1.235|-1.23E0|-1.23E0|-1.23E0|-1E0|
| |-1.2345679E1|-12.346|-12.346|-12.346|-1.23E1|-1.23E1| -12.|-1E1|
| |-1.2345679E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2| -123.|-1E2|
| |-1.2345679E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3| -1235.|-1E3|
| |-1.2345679E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-12346.|-1E4|
| |-1.2345679E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1E5|

F.RDP has proved sufficient for my needs, but then I do not do as much
with FP numbers as you do.

- 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: https://euro.theforth.net

[none albert]

In article <05d987fd-f21e-430d...@googlegroups.com>,

I once has the conviction that I was to define a wordset similar
to the #-set for floating point numbers. Then I lost the code or
interest, or both. It is doable, but not to you, expert
programmers. An expert designer will be needed.

>
>-marcel

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[minf...@arcor.de]

none albert schrieb am Sonntag, 22. Januar 2023 um 12:21:40 UTC+1:
> In article <05d987fd-f21e-430d...@googlegroups.com>,
> Marcel Hendrix <m...@iae.nl> wrote:
> >On Sunday, January 22, 2023 at 7:22:12 AM UTC+1, dxforth wrote:
> >[..]
> >> Speaking of f/p I've just ditched output functions G.R and G. and
> >> subsumed the functionality into F.R and F. While this breaks the
> >> ANS notion of what F. was intended to print*, I still retain (F.)
> >> and (G.) which output fixed and mixed notation respectively.
> >
> >Probably worth a new thread, but... Over the years I have
> >needed dozens of variants of the basic floating-point
> >formatting words. There is always something
> >slightly different that is needed (sufficiently
> >different or useful to put in a new word). Is
> >this a commonly accepted fact, or does it
> >indicate that we don't have the proper
> >Forth way to factor the problem yet?
> I once has the conviction that I was to define a wordset similar
> to the #-set for floating point numbers. Then I lost the code or
> interest, or both. It is doable, but not to you, expert
> programmers. An expert designer will be needed.

IMO a simple format string will do for most Forth applications, similar to:
https://eml.berkeley.edu/sst/fmttop.html

Then there is the old head-scratcher caused by the differing formats between
>FLOAT REPRESENT and text interpreter ....

[Marcel Hendrix]

On Sunday, January 22, 2023 at 11:43:13 AM UTC+1, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
[..]

> When I looked into the problem, I found no good way to apply the
> flexible approach used for integers (with # HOLD etc.) for FP output.

Yes, I am still hoping somebody finds a nice way to let the same
approach work with FP.

Basic problems I have with # based printing is output
to be in HEX or DECIMAL without changing BASE, and safe
against THROWs. There is printing with and without a trailing
space (when appending '.' or ','), and left/right aligning of possibly
negative numbers (print BL where a '+' is expected). And o yeah, every
one of these words should give a string result that can be further processed
with other string words. ( BTW, I use I/O device redirection to memory for TYPE
and friends for that.)

> I also inspected what C does with printf(), and eventually settled on
> F.RDP. Here's the documentation:
>
> |'f.rdp' ( rf +nr +nd +np -- ) gforth-0.6 "f.rdp"

Yes... What to do if printing in HEX, ligning up decimal points in a column
of +/- numbers, +Infinity -NaN etc. in too short fields, interchange
',' and '.', interchange 'E', 'e', 'd', 'D', print with scaling ( 1.1k instead
of 1.100e3 ), suppressing/adding trailing space, etc.? Of course
it is not possible to catch all these (and more) in a single word,
but is there a collection of words that anticipates all possible
results?

-marcel

[dxforth]

I don't accept Forth has more problems to solve than C and FORTRAN.
If their users can get by with the functions provided them, why not
Forth?

[Marcel Hendrix]

On Sunday, January 22, 2023 at 1:18:39 PM UTC+1, minf...@arcor.de wrote:
[..]

> IMO a simple format string will do for most Forth applications, similar to:
> https://eml.berkeley.edu/sst/fmttop.html

That is for reading floating point as text, which is a lot easier than printing.
Also, there is normally a way to get the equivalent in binary.
But a (nested) FORMAT string may have some merit...

-marcel

[none albert]

In article <tqjd3j$iql$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
<SNIP>

>
>I don't accept Forth has more problems to solve than C and FORTRAN.
>If their users can get by with the functions provided them, why not
>Forth?

Need to ask? C and FORTRAN programmers have their solutions forced
down their throat.

[dxforth]

On 23/01/2023 12:46 am, albert wrote:
> In article <tqjd3j$iql$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
> <SNIP>
>>
>> I don't accept Forth has more problems to solve than C and FORTRAN.
>> If their users can get by with the functions provided them, why not
>> Forth?
>
> Need to ask? C and FORTRAN programmers have their solutions forced
> down their throat.

Yes, they have a standard that provides. Isn't that what forthers have
been asking for?

[Krishna Myneni]

On 1/22/23 00:22, dxforth wrote:
...

> Speaking of f/p I've just ditched output functions G.R and G. and
> subsumed the functionality into F.R and F.  While this breaks the
> ANS notion of what F. was intended to print*, I still retain (F.)
> and (G.) which output fixed and mixed notation respectively.
>

...

From kForth's strings.4th,

\ F>FPSTR ( n -- a u ) ( F: r -- ) | ( r n -- a u )
\ F.RD ( w n -- ) ( F: r -- ) | ( r w n -- )

\ Convert r to a formatted fixed point string with
\ n decimal places, 0 <= n <= 17.
\ WARNING: Requesting a number fixed point decimal places which
\ results in total number of digits > 17 will give
\ incorrect results, e.g. "65536.9921875e 15 f>fpstr type"
\ will output garbage (20 digits are being requested).
: f>fpstr ( n -- a u ) ( F: r -- ) \ ( r n -- a u )
0 max 17 min >r 10e r@ s>f f**
f* fround f>d dup -rot dabs
<# r> 0 ?DO # LOOP [char] . hold #s rot sign #> ;

\ Print an fp number as a fixed point string with
\ n decimal places, right-justified in a field of width, w
: f.rd ( w n -- ) ( F: r -- ) \ ( r w n -- )
swap >r f>fpstr dup 20 > IF
\ Too many digits requested in fixed point output
2drop r> 0 ?DO [char] * emit LOOP
ELSE
r> over -
dup 0> IF spaces ELSE drop THEN type
THEN ;

F.RD is my workhorse formatting output word for fixed point output of
floating point numbers with a specified number of decimal places. It
uses F>FPSTR which returns a string instead of performing console output.

Along with FS. and F. (which provides 6 significant digits output in
either fixed point or scientific notation depending on the number), and
the PRECISION control words appear to be sufficient for most of my
floating point output needs.

--
Krishna

[Anton Ertl]

Marcel Hendrix <m...@iae.nl> writes:
>On Sunday, January 22, 2023 at 11:43:13 AM UTC+1, Anton Ertl wrote:
>> Marcel Hendrix <m...@iae.nl> writes:
>[..]
>> When I looked into the problem, I found no good way to apply the
>> flexible approach used for integers (with # HOLD etc.) for FP output.
>
>Yes, I am still hoping somebody finds a nice way to let the same
>approach work with FP.

One problem is that with FP you have rounding, and a number that would
print as 9.99 if enough space is available will print as 10. if less
space is available.

Another problem is that a fixed format like COBOL-style ##.## is only
usefuk for numbers x where 0.01<=abs(x)<100.

>Basic problems I have with # based printing is output
>to be in HEX or DECIMAL without changing BASE, and safe
>against THROWs.

Gforth's BASE-EXECUTE wraps a BASE change in a word; even if there is
a throw inside, BASE is the same afterwards as before.

|'base-execute' ( i*x xt u -- j*x ) gforth-0.7 "base-execute"
| execute xt with the content of 'BASE' being u, and restoring the
|original 'BASE' afterwards.

>There is printing with and without a trailing
>space (when appending '.' or ','),

F.RDP vs. F.RDP SPACE

>and left/right aligning of possibly
>negative numbers (print BL where a '+' is expected).

F.RDP aligns the . for the fixed-point notation when it can satisfy
the requirements for that notation, and switches to exponential
notation otherwise. Positive numbers are printed without a leading
sign (this means that for some numbers x>0, x can be printed in
fixed-point notation, and it may have to switch to exponential
notation for -x.

>And o yeah, every
>one of these words should give a string result that can be further processed
>with other string words.

There is f>str-rdp (produces string in pictured numeric output buffer)
and f>bud-rdp (produces string in buffer provided by the caller).

>( BTW, I use I/O device redirection to memory for TYPE
>and friends for that.)

Yes, Gforth has >STRING-EXECUTE, which wraps the redirection and
produces a string that contains the output. It's useful for dealing
with words where we don't have non-printing equivalents, but it is
also useful for constructing strings.

>> |'f.rdp' ( rf +nr +nd +np -- ) gforth-0.6 "f.rdp"
>
>Yes... What to do if printing in HEX,

F.RDP is always decimal.

> ligning up decimal points in a column
>of +/- numbers

That's what f.rdp is designed for. You see it in all the examples where fixed-point notation is output.

>+Infinity -NaN etc.

0e 0e f/ 7 3 1 '|' emit f.rdp '|' emit \ |NaN | ok
1e 0e f/ 7 3 1 '|' emit f.rdp '|' emit \ |Inf | ok
-1e 0e f/ 7 3 1 '|' emit f.rdp '|' emit \ |-Inf | ok

>in too short fields

Too-short fields give you **** as output. Just use nr>=7 (for
binary64 FP numbers) to avoid that.

> interchange ',' and '.', interchange 'E', 'e', 'd', 'D',
> print with scaling ( 1.1k instead
>of 1.100e3 ),

All not supported, so you may need some enhancement of F.RDP.

For the decimal separator, have a context wrapper to which you pass it.
Likewise for the exponent separator.

For a different base, BASE-EXECUTE already provides a context wrapper,
but the implementation of F.RDP would have to be changed significantly.

>suppressing/adding trailing space,

(Don't) call SPACE afterwards.

>Of course
>it is not possible to catch all these (and more) in a single word,
>but is there a collection of words that anticipates all possible
>results?

For "print with scaling" maybe a different word is necessary.

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>Then there is the old head-scratcher caused by the differing formats between
>>FLOAT REPRESENT and text interpreter ....

The text interpreter supports less than >FLOAT, because it also has to
recognize things other than floats.

REPRESENT is the other direction. Its interface is modeled on ecvt(),
with one important feature left away: output length; what is also
missing is the companion fcvt() (this caused quite a bit of
complication during the development of F.RDP). In the meantime, the C
guys decided that ecvt()/fcvt() is not the way to go, and they leave
it all to sprintf().

[dxforth]

On 23/01/2023 12:05 am, Marcel Hendrix wrote:
> On Sunday, January 22, 2023 at 11:43:13 AM UTC+1, Anton Ertl wrote:
>> Marcel Hendrix <m...@iae.nl> writes:
> [..]
>> When I looked into the problem, I found no good way to apply the
>> flexible approach used for integers (with # HOLD etc.) for FP output.
>
> Yes, I am still hoping somebody finds a nice way to let the same
> approach work with FP.

In fact SwiftForth included the rudiments of such a system. It goes
something like this:

: <#. ( F: r1 -- r2 ) FROUND <# ;
: #. ( F: r1 -- r2 ) 10.E F/ FDUP FLOOR FSWAP FOVER F-
10.E F* FROUND F>S [CHAR] 0 + HOLD ;
: #S. ( F: r1 -- r2 ) BEGIN #. FDUP F0= UNTIL ;
: #>. ( F: r -- ) ( c-addr u ) FDROP 0 0 #> ;

Turning it into something useful is another thing. I would rather have
string versions of F. FS. FE. with a decimal places parameter and go
from there. Which is what I did.

>
> Basic problems I have with # based printing is output
> to be in HEX or DECIMAL without changing BASE, and safe
> against THROWs. There is printing with and without a trailing
> space (when appending '.' or ','), and left/right aligning of possibly
> negative numbers (print BL where a '+' is expected). And o yeah, every
> one of these words should give a string result that can be further processed
> with other string words. ( BTW, I use I/O device redirection to memory for TYPE
> and friends for that.)
>
>> I also inspected what C does with printf(), and eventually settled on
>> F.RDP. Here's the documentation:
>>
>> |'f.rdp' ( rf +nr +nd +np -- ) gforth-0.6 "f.rdp"
>
> Yes... What to do if printing in HEX, ligning up decimal points in a column
> of +/- numbers, +Infinity -NaN etc. in too short fields, interchange
> ',' and '.', interchange 'E', 'e', 'd', 'D', print with scaling ( 1.1k instead
> of 1.100e3 ), suppressing/adding trailing space, etc.? Of course
> it is not possible to catch all these (and more) in a single word,
> but is there a collection of words that anticipates all possible
> results?

Most of these things are accomplished with string manipulation. I assume
that's how the C and FORTRAN folks do it. Code for a decimal point aligner
is trivial and has already been posted on this forum.

[Marcel Hendrix]

On Monday, January 23, 2023 at 1:50:16 AM UTC+1, dxforth wrote:
> On 23/01/2023 12:05 am, Marcel Hendrix wrote:
> > On Sunday, January 22, 2023 at 11:43:13 AM UTC+1, Anton Ertl wrote:
> >> Marcel Hendrix <m...@iae.nl> writes:
> > [..]
> >> When I looked into the problem, I found no good way to apply the
> >> flexible approach used for integers (with # HOLD etc.) for FP output.

[..]

> In fact SwiftForth included the rudiments of such a system. It goes
> something like this:

[..]

> : #. ( F: r1 -- r2 ) 10.E F/ FDUP FLOOR FSWAP FOVER F-

[..]

That is not going to work for extended precision (and maybe not even for double precision).

-marcel

[dxforth]

Seems to work for me

DX-Forth 4.53 2023-01-01

80387 18-digit floating point (common stack)

Using FORTH.SCR

include sfpout FDP is redefined (FS.) is redefined FS.R is redefined
(FE.) is redefined FE.R is redefined (F.) is redefined F.R is redefined
F. is redefined FS. is redefined FE. is redefined ok
17 places ok
pi cr f.
3.14159265358979324 ok

You can test it for yourself:

http://dxforth.mirrors.minimaltype.com/sfpout.html

[Gerry Jackson]

On 22/01/2023 18:36, Anton Ertl wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:
>> Then there is the old head-scratcher caused by the differing formats between
>>> FLOAT REPRESENT and text interpreter ....
>
> The text interpreter supports less than >FLOAT, because it also has to
> recognize things other than floats.
>
> REPRESENT is the other direction. Its interface is modeled on ecvt(),
> with one important feature left away: output length; what is also
> missing is the companion fcvt() (this caused quite a bit of
> complication during the development of F.RDP). In the meantime, the C
> guys decided that ecvt()/fcvt() is not the way to go, and they leave
> it all to sprintf().
>

What's wrong with Forth using sprintf apart from its C provenance and
taking quite a lot of Forth code for FP which is irrelevant to those
using a desktop PC and who lack a visceral hatred of C. I can see it
wouldn't be attractive to the embedded community but do they use FP much?

--
Gerry

[dxforth]

Visceral hatred of bloat. C likes to roll everything into one function;
whereas Forth opts to separate them. See Starting FORTH 1st ed. p.312

[Gerry Jackson]

That book was written 42 years ago in 1981 when there were severe
hardware limitations such as:
- slow processors
- tiny amount of RAM
- expensive floppy & hard disks with sod-all capacity
- unaffordable hard disks with
- ...

Surely what constitutes bloat has changed since then.

Anyway that cartoon is a silly comparison - sprintf is one tool for
formatting text, not several totally different tools.

--
Gerry

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>What's wrong with Forth using sprintf apart from its C provenance and
>taking quite a lot of Forth code for FP which is irrelevant to those
>using a desktop PC

Not for those who would have to write that code.

And even using it poses problems:

* It consumes a variable number of arguments, something relatively
unusual in Forth; and these arguments are a mix of integer and FP
numbers in arbitrary order, which exacerbates the problem.

* It has a very complicated and not very intuitive interface (e.g.,
see https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html),
so it's not particularly attractive to use.

* And it still cannot do all the things that Marcel Hendrix asked for.

[dxforth]

sprintf is but an API to a range of functions. Forth believes it can dispense
with API's, program the functions directly and save code in the process. I'm
sure sprintf would be nostalgia for some. To me it just looks complicated.

[dxforth]

On 24/01/2023 8:57 am, Anton Ertl wrote:
> Gerry Jackson <do-no...@swldwa.uk> writes:
>> What's wrong with Forth using sprintf apart from its C provenance and
>> taking quite a lot of Forth code for FP which is irrelevant to those
>> using a desktop PC
>
> Not for those who would have to write that code.
>
> And even using it poses problems:
>
> * It consumes a variable number of arguments, something relatively
> unusual in Forth; and these arguments are a mix of integer and FP
> numbers in arbitrary order, which exacerbates the problem.
>
> * It has a very complicated and not very intuitive interface (e.g.,
> see https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html),
> so it's not particularly attractive to use.
>
> * And it still cannot do all the things that Marcel Hendrix asked for.

A forther believes only he can do something justice. So even when
one demonstrates to Marcel there are other - perhaps better - ways
of approaching the problem, it is water off a duck's back. We can
do this in Forth because we know the world is not looking on and
consequently no pressure to change.

[Gerry Jackson]

On 23/01/2023 21:57, Anton Ertl wrote:
> Gerry Jackson <do-no...@swldwa.uk> writes:
>> What's wrong with Forth using sprintf apart from its C provenance and
>> taking quite a lot of Forth code for FP which is irrelevant to those
>> using a desktop PC
>
> Not for those who would have to write that code.

Once written, which it has been, it can be used by all were it not that
Forthers, in general, don't like using code written by others!

BTW thanks for a factual reply. Much better than snarky responses from
others.

>
> And even using it poses problems:

I don't why it need pose a problem for users. All that has to be
provided to sprintf is:
( arg1 arg2 ... argn caddr u -- caddr2 u2 ) where (caddr u) is the
format control string and (caddr2 u2) is the result in the current
output buffer. Args1 to n are any mix of integers, FP, strings and
characters in the left to right order they occur in the control string.

>
> * It consumes a variable number of arguments, something relatively
> unusual in Forth;

That presents a challenge to an implementer and makes it more
interesting. The number of arguments and their type is calculated when
the format string is processed. The order in which they appear can be
handled either by using a deep PICK sanitised by using DEPTH or, as
SwiftForth does, by recursion.

> and these arguments are a mix of integer and FP
> numbers in arbitrary order, which exacerbates the problem.

Makes it even more interesting. Don't forget double integers and the
fact that FP numbers can be on the data stack or a separate stack. On
the data stack that would be handled during control string processing.
On a separate stack is more difficult as standard Forth lacks FPICK,
FDEPTH, F>R etc but can be handled by copying the number of FP numbers
into a FP array and accessing that array.

>
> * It has a very complicated and not very intuitive interface (e.g.,
> see https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html),
> so it's not particularly attractive to use.

People seem to manage and other languages have adopted the approach.

>
> * And it still cannot do all the things that Marcel Hendrix asked for.

Forth is distributed as source code and someone with Marcel's skills
could, if he thought it worth the effort, add the extra functionality.

Loooking at Marcel's list:

<Marcel>

Basic problems I have with # based printing is output
to be in HEX or DECIMAL without changing BASE, and safe
against THROWs. There is printing with and without a trailing
space (when appending '.' or ','), and left/right aligning of possibly
negative numbers (print BL where a '+' is expected). And o yeah, every
one of these words should give a string result that can be further processed
with other string words. ( BTW, I use I/O device redirection to memory
for TYPE
and friends for that.)

Yes... What to do if printing in HEX, ligning up decimal points in a column

of ± numbers, +Infinity -NaN etc. in too short fields, interchange

',' and '.', interchange 'E', 'e', 'd', 'D', print with scaling ( 1.1k
instead
of 1.100e3 ), suppressing/adding trailing space, etc.? Of course
it is not possible to catch all these (and more) in a single word,
but is there a collection of words that anticipates all possible
results?

</Marcel>

- Hex & Decimal - Can be done with sprintf without changing BASE.
- THROW safe - execute sprintf via CATCH
- trailing spaces with commas etc - OK with sprintf
- left/right aligning with negative numbers - OK
- BL for a + sign - OK
- string result - OK
- lining up decimal points in too short fields - not in sprintf, but
surely a user problem
- 'E' or 'e' etc - OK
- print with scaling - No
- adding trailing space - OK, either left justified or include spaces in
the control string

Not much there that can't be done with sprintf.

It's worth noting that after starting to tidy up my sprintf I thought
that there must be a better way to do it and came up with a layered scheme.

Layer 0; a buffer providing basic saving of strings with full buffer
overflow checking, multiple buffers. A greatly extended
equivalent of Forth's <# etc. I've used <~ etc instead of <#

Layer 1: uses layer 0, basic operators to format numbers and text e.g.
~i ~u ~id ~ud etc for signed and unsigned (double) integer
conversions
~w for field width. Positive/negative argument for right/left
alignment
~uc ~lc for upper/lower case
~s ~c for strings, characters

Layer 2: basic integer sprintf, calls lower layers. Provides layer 1
functionality with a sprintf control string. Layer 1 operators
can be mixed with sprintf. An addition is that the code
generated by sprintf can be compiled as a colon definition.

Layer 3: full functionality of integer sprintf. Uses lower layers.

Layers 4 and 5 (proposed but not yet implemented), basic and full
sprintf functionality respepctively. Floating point conversions
will probably be done by treating the components of a floating
point numbers as a series of integer and character fields and
calling layer 1 operators.

Layers 0 to 3 are complete, the rest is on the back burner at present.
With such a scheme it should be easy to add extra functionality such as
that on Marcel's list.

With such a scheme a user can compile the as much functionality as
needed, reducung unnecessary bloat.

--
Gerry

[none albert]

In article <2023Jan2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Gerry Jackson <do-no...@swldwa.uk> writes:
>>What's wrong with Forth using sprintf apart from its C provenance and
>>taking quite a lot of Forth code for FP which is irrelevant to those
>>using a desktop PC
>
>Not for those who would have to write that code.
>
>And even using it poses problems:
>
>* It consumes a variable number of arguments, something relatively
>unusual in Forth; and these arguments are a mix of integer and FP
>numbers in arbitrary order, which exacerbates the problem.
>
>* It has a very complicated and not very intuitive interface (e.g.,
> see https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html),
> so it's not particularly attractive to use.
>
>* And it still cannot do all the things that Marcel Hendrix asked for.

We can do much better than sprintf seen all the facilities the
Forth interpreter delivers. It will be easier and more flexible.

1. have a wordlist with formatting words.
2. In formatting copy the first characters up till % to the output
3. Separate a word after the % till a blank, look it up in the formatting
wordlist and execute it, presumably adding output to the buffer.
4. rinse, repeat till the formatting string is exhausted.

We will collect the output in a buffer CR$
In the wordlist we will have e.g.
: s ( sc -- ) CR$ $+! ;
: d ( d -- ) S>D 0 (D.R) CR$ $+! ;
..

And analysing the string is trivial:
\ Format the first part of STRING, up till %, leave REST.
\ Another glorious usage of $/ ("string-split")
: _plain &% $/ CRS$ $+! ;

Example of usage
x @ "x" "The value of %s is %d" FORMAT TYPE
Useful additions .FORMAT FORMAT&EVAL

MPE has a similar type of mechanism.

The source of class / endclass in ciforth is down to one screen thanks
to 4 uses of FORMAT&EVAL . Moreover it is much easier to understand.

I haven't done so, but it is easy to add some
floating point format's, in as far needed.
Add the fp format's that c lacks!
(because they forgot to add the kitchen sink.)

>- anton

[Marcel Hendrix]

On Tuesday, January 24, 2023 at 1:27:27 PM UTC+1, none albert wrote:
> In article <2023Jan2...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >Gerry Jackson <do-no...@swldwa.uk> writes:

[..]

> Example of usage
> x @ "x" "The value of %s is %d" FORMAT TYPE

x @ S" x" .( The value of ) TYPE .( is ) .

It does not (yet) solve the basic problem of ".".
Gerry's approach looks much better.

I think "printf" adds an interpreter to a compiler. That is not
necessary in Forth, we already have (a much more capable) one.

-marcel

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> And even using [sprintf] poses problems: ...

I don't remember how Fortran numeric formatting worked, but it was/is
used extensively for scientific computing, so I'd like to hope that it
had the issues ironed out after all these years. Is it worth examining
for this thread?

[dxforth]

On 24/01/2023 11:27 pm, albert wrote:
>
> I haven't done so, but it is easy to add some
> floating point format's, in as far needed.
> Add the fp format's that c lacks!
> (because they forgot to add the kitchen sink.)

Classic forth response :)

[dxforth]

On 25/01/2023 2:12 am, Marcel Hendrix wrote:
>
> It does not (yet) solve the basic problem of ".".

What problem was that exactly?

[dxforth]

What's wrong with the format Forth has used in the past? I refer to Forth
Vendors Group F/P Standard and the floating point output package used in
Amiga J-Forth. These may not have been the last word on the subject but
they pointed the way and were 'forth friendly'. In fact an early draft of
ANS included the words (F.) (E.) PLACES before the devil whispered in the
TC's ear.

[minf...@arcor.de]

Fortran offers even more formatting than C.
https://www.l3harrisgeospatial.com/docs/format_codes_fortran.html

For embedded Forths this is overkill.

In fat OS-based Forths you have C libraries for free. Just use them.

IMO the Forthy golden middle-ground would be like gforth's F.RDP

[Marcel Hendrix]

FMP, the reason to use Forth is to get exactly what I want. In the FP case
I have that already, but I'm interested if the mess can be cleaned up a bit,
and the interface made more intuitive.

-marcel

[Marcel Hendrix]

On Wednesday, January 25, 2023 at 11:15:41 AM UTC+1, Marcel Hendrix wrote:
[..]

> FMP, the reason to use Forth is to get exactly what I want. In the FP case
> I have that already, but I'm interested if the mess can be cleaned up a bit,
> and the interface made more intuitive.

Fortran's FORMAT string is an idea. It would be self-documenting and each
application can use a default or define a few formats/templates for itself.

-marcel

[dxforth]

Overkill would be when the output routines represent a significant portion
of the space available to the application. OTOH routines that are too
minimal risk never being used - precisely because they were too minimal.
To put some figures on this, my output f/p routines take 1210 bytes (less
headers and excluding REPRESENT). I don't know what F.RDP would consume
(it uses locals and <<# which I'd have to load) but let's say 600 bytes.
Either way, we're talking small numbers. Let's talk about FORTRAN's
FORMAT. It was used for more than f/p so the cost of the mini-interpreter
was spread. That won't be the case in Forth unless one is planning to
throw out all the existing output routines. Even then I'd be scratching
my head wondering what I was getting in return for turning Forth on its
head. Perhaps someone can enlighten me.

[minf...@arcor.de]

dxforth schrieb am Mittwoch, 25. Januar 2023 um 13:05:20 UTC+1:
> On 25/01/2023 8:58 pm, minf...@arcor.de wrote:
> > Paul Rubin schrieb am Mittwoch, 25. Januar 2023 um 00:23:02 UTC+1:
> >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>> And even using [sprintf] poses problems: ...
> >>
> >> I don't remember how Fortran numeric formatting worked, but it was/is
> >> used extensively for scientific computing, so I'd like to hope that it
> >> had the issues ironed out after all these years. Is it worth examining
> >> for this thread?
> >
> > Fortran offers even more formatting than C.
> > https://www.l3harrisgeospatial.com/docs/format_codes_fortran.html
> >
> > For embedded Forths this is overkill.
> >
> > In fat OS-based Forths you have C libraries for free. Just use them.
> >
> > IMO the Forthy golden middle-ground would be like gforth's F.RDP
> Overkill would be when the output routines represent a significant portion
> of the space available to the application.

"Overkill" for fancy fp-output was addressed at small devices eg embedded machines.
Such devices communicate through some links to other devices or servers and
sometimes engineering terminals.

There I never needed better fp-formatting eg for csv data transfer of in json files.
The usual Forth words were good enough (when data was not transferred in binary
chunks anyhow).

FP-output "de luxe" came into play later: formatted logs and reports on screen or
dumped to paper/archive/email. This was server-side post-processing (in Java).

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>On 23/01/2023 21:57, Anton Ertl wrote:
>> Gerry Jackson <do-no...@swldwa.uk> writes:
>>> What's wrong with Forth using sprintf apart from its C provenance and
>>> taking quite a lot of Forth code for FP which is irrelevant to those
>>> using a desktop PC
>>
>> Not for those who would have to write that code.
>
>Once written, which it has been, it can be used by all were it not that
>Forthers, in general, don't like using code written by others!

Sure, NIH may play a role, but it has not prevented ALLOCATE and FREE
to be standardized, nor many Forth systems from calling C library
functions malloc() and free() to implement them.

>> And even using it poses problems:
>
>I don't why it need pose a problem for users. All that has to be
>provided to sprintf is:
>( arg1 arg2 ... argn caddr u -- caddr2 u2 ) where (caddr u) is the
>format control string and (caddr2 u2) is the result in the current
>output buffer. Args1 to n are any mix of integers, FP, strings and
>characters in the left to right order they occur in the control string.
>
>>
>> * It consumes a variable number of arguments, something relatively
>> unusual in Forth;
>
>That presents a challenge to an implementer and makes it more
>interesting. The number of arguments and their type is calculated when
>the format string is processed. The order in which they appear can be
>handled either by using a deep PICK sanitised by using DEPTH or, as
>SwiftForth does, by recursion.
>
>> and these arguments are a mix of integer and FP
>> numbers in arbitrary order, which exacerbates the problem.
>
>Makes it even more interesting. Don't forget double integers and the
>fact that FP numbers can be on the data stack or a separate stack. On
>the data stack that would be handled during control string processing.
>On a separate stack is more difficult as standard Forth lacks FPICK,
>FDEPTH, F>R etc but can be handled by copying the number of FP numbers
>into a FP array and accessing that array.

I was mainly thinking of calling the C libary function. If one wanted
to do that, the Forth side would have to use exactly the same
interpretation of the format string to write a parser for that string
that performs the translation from the Forth stacks to the ABI of C on
the platform at hand.

Implementing everything on the Forth side also requires such a parser
and even more, but, as you write, you have implemented such an SPRINTF
and released it under the MIT license
<http://theforth.net/package/sprintf>.

>> * It has a very complicated and not very intuitive interface (e.g.,
>> see https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html),
>> so it's not particularly attractive to use.
>
>People seem to manage and other languages have adopted the approach.

If sprintf() is what you have available, you do what you can to get
by.

If you build your language on top of C, you may be able to use C's
sprintf() and save yourself the trouble of implementing something,
even if sprintf() is less than optimal (however, constructing calls
with arbitrary arguments is badly supported in C, and I wonder whether
(and if so, how) awk did it before the advent of libffcall and
libffi).

>- Hex & Decimal - Can be done with sprintf without changing BASE.

My understanding is that Marcel Hendrix wants hex base for FP output,
and your implementation of sprintf does not implement this.

>- THROW safe - execute sprintf via CATCH
>- trailing spaces with commas etc - OK with sprintf
>- left/right aligning with negative numbers - OK
>- BL for a + sign - OK
>- string result - OK
>- lining up decimal points in too short fields - not in sprintf, but
>surely a user problem
>- 'E' or 'e' etc - OK
>- print with scaling - No
>- adding trailing space - OK, either left justified or include spaces in
>the control string
>
>Not much there that can't be done with sprintf.

About as much as with F.RDP; you have to postprocess for 'E' or 'e',
though.

Side topic:

I tested your PRINTF to see how well it implements rounding:

: t fdup '|' emit 7 1 1 f.rdp '|' emit s" %7.1f" printf '|' emit ;

0.7499999999999999e t | 0.7| 0.8|

The incorrect result of PRINTF is a result of double rounding: You ask
represent to round for 16 (I think) digits, resulting in
(0.)7500000000000000, and then you round that to 0.8.

Another issue is rounding to nearest or even (RNE):

1e 4e f/ t | 0.2| 0.3| ok
3e 4e f/ t | 0.8| 0.8| ok

You always round away from 0 when both rounding directions are equally
near.

Both problems can be fixed by arranging things such that REPRESENT
does the rounding for the desired number of digits. Of course, for
RNE you need a REPRESENT that does RNE.

> Floating point conversions
> will probably be done by treating the components of a floating
> point numbers as a series of integer and character fields and
> calling layer 1 operators.

The hard part is not the string processing, but the float-to-string
conversion. This is a hairy topic. A student happened to do a
literature review some time ago. Even in 2018, a paper about the
topic was still seen as relevant research, as demonstrated by PLDI
accepting Ulf Adams' paper "Fast Float-to-String Conversion".

[none albert]

In article <tqoik1$3jks$1...@dont-email.me>,

Gerry Jackson <do-no...@swldwa.uk> wrote:

>
>I don't why it need pose a problem for users. All that has to be
>provided to sprintf is:
>( arg1 arg2 ... argn caddr u -- caddr2 u2 ) where (caddr u) is the
>format control string and (caddr2 u2) is the result in the current
>output buffer. Args1 to n are any mix of integers, FP, strings and
>characters in the left to right order they occur in the control string.

Why don't you use the, supposedly, superior FORTRAN formatting?
Or does that pose a problem for users?
Hint, the effort to hook up FORTRAN libraries to Forth far exceeds
the possibly benefits.

>With such a scheme a user can compile the as much functionality as
>needed, reducung unnecessary bloat.

5 layers reducing unnecessary bloat?

>
>--
>Gerry

[dxforth]

Surely it's not a question of need but cost. You don't need a 32Gb flash drive
at the moment but it costs the same as a 16Gb drive. You don't buy the bigger
drive?

[Marcel Hendrix]

On Wednesday, January 25, 2023 at 5:42:04 PM UTC+1, none albert wrote:
> In article <tqoik1$3jks$1...@dont-email.me>,
> Gerry Jackson <do-no...@swldwa.uk> wrote:

[..]

> Hint, the effort to hook up FORTRAN libraries to Forth far exceeds
> the possibly benefits.
> >With such a scheme a user can compile the as much functionality as
> >needed, reducung unnecessary bloat.
> 5 layers reducing unnecessary bloat?

I do this. Same effort as for 'C'. Of course not for FORMAT, but for
the SLICOT library

It's a bit wordy :--)

void AB04MD(char* type, int* N, int* M, int* P, double* alpha, double* beta,
double* a, int* lda, double* b, int* ldb, double* c, int* ldc, double* d, int* ldd,
int* iwork, double* dwork, int* ldwork, int* info);
...

-marcel

[Gerry Jackson]

On 25/01/2023 16:42, albert wrote:
> In article <tqoik1$3jks$1...@dont-email.me>,
> Gerry Jackson <do-no...@swldwa.uk> wrote:
>
>>
>> I don't why it need pose a problem for users. All that has to be
>> provided to sprintf is:
>> ( arg1 arg2 ... argn caddr u -- caddr2 u2 ) where (caddr u) is the
>> format control string and (caddr2 u2) is the result in the current
>> output buffer. Args1 to n are any mix of integers, FP, strings and
>> characters in the left to right order they occur in the control string.
>
> Why don't you use the, supposedly, superior FORTRAN formatting?
> Or does that pose a problem for users?
> Hint, the effort to hook up FORTRAN libraries to Forth far exceeds
> the possibly benefits.

I have never used Fortran and so wasn't aware of it. I don't know if it
offers more than sprintf. Anyway I'm not hooking up to C libraries so
why would I hook up to a Fortran library.

>
>> With such a scheme a user can compile the as much functionality as
>> needed, reducung unnecessary bloat.
>
> 5 layers reducing unnecessary bloat?

If you need full blown FP you need a lot of code i.e. all 5 layers. If
you only want simple integer sprintf you only load layers 0, 1 and 2
which is much less code. If bloat is unnecessary code for the task at
hand, that looks like bloat reduction to me. If I only want <# family
type formatting, but much improved only layers 0 and 1 are loaded, even
less code.


--
Gerry

[Anton Ertl]

Marcel Hendrix <m...@iae.nl> writes:
>Fortran's FORMAT string is an idea. It would be self-documenting and each
>application can use a default or define a few formats/templates for itself.

The Fortran FORMAT stuff looks similar to the printf stuff to me (and
an earlier version probably inspired printf). I don't see that it
satisfies your requirements any more than printf does, and it seems
even more complex and harder to implement than printf.

Using such an interface adopted from another programming language has
the potential advantage that users can reuse knowledge from the other
programming language. However, in the case of printf() I find that
the simple cases are sufficiently well supported with standard Forth
words, so printf() is not needed for that.

The not-so-simple cases (like particular FP output formatting) is rare
enough and the way to specify them is bad enough that I have to dig
through the horrible documentation every time I need one of those
features, so there is no benefit (for me) in transferring the printf
interface to Forth.

Concerning Fortran, I think the number of people who use both is very
small, and the potential advantage is therefore very small, too. And
I think that Fortran's FORMAT is at least as hard to use as the
printf() interface, so the same considerations apply as above.

[dxforth]

On 25/01/2023 8:58 pm, minf...@arcor.de wrote:

> ...

> Fortran offers even more formatting than C.
> https://www.l3harrisgeospatial.com/docs/format_codes_fortran.html

BTW that may not be FORTRAN - rather 'FORTRAN style' as the article
calls it:

"The FORTRAN-style format codes specify how data should be transferred
using a format similar to that in the FORTRAN language."

When I researched the f/p output options available from FORTRAN and
C (some 20 odd years ago now) there wasn't a lot between or in them.

[dxforth]

On 26/01/2023 5:36 am, Gerry Jackson wrote:
> ...

> If I only want <# family type formatting, but much improved only layers 0 and 1 are loaded, even less code.

Do you have examples of things that can be done with 'layers 0 and 1'
that you feel is currently lacking in forth?

[Gerry Jackson]

On 25/01/2023 11:35, Anton Ertl wrote:
> Gerry Jackson <do-no...@swldwa.uk> writes:
>> On 23/01/2023 21:57, Anton Ertl wrote:
>> - Hex & Decimal - Can be done with sprintf without changing BASE.
>
> My understanding is that Marcel Hendrix wants hex base for FP output,
> and your implementation of sprintf does not implement this.

I hadn't read his comment that way. I suppose you mean the %a and %A
conversions. I see that these are not included in the link you provided.
I used the spec at https://linux.die.net/man/3/printf but didn't fully
understand %A and didn't find an implementation to experiment with and
so shelved it for another time.

> Side topic:
>
> I tested your PRINTF to see how well it implements rounding:
>
> : t fdup '|' emit 7 1 1 f.rdp '|' emit s" %7.1f" printf '|' emit ;
>
> 0.7499999999999999e t | 0.7| 0.8|
>
> The incorrect result of PRINTF is a result of double rounding: You ask
> represent to round for 16 (I think) digits, resulting in
> (0.)7500000000000000, and then you round that to 0.8.

You're right. There is a configuration VALUE called MAX-PRECISION that
is set to 15. I tried your test with MAX-PRECISION set to 20 and got the
correct result
0.7499999999999999e t | 0.7| 0.7| ok

I think setting it to 15 was in the mistaken belief that it was better
to omit the garbage that occurs after about 16 digits and forgot about
the rounding. Setting PRECISION to 20 may be a good solution as
anything after 15 or 16 digits is an error from an exact representation
and likely to be small, leaving the rounding to later. But it's probably
better to let REPRESENT do it (as long as it's done properly).

>
> Another issue is rounding to nearest or even (RNE):
>
> 1e 4e f/ t | 0.2| 0.3| ok
> 3e 4e f/ t | 0.8| 0.8| ok
>
> You always round away from 0 when both rounding directions are equally
> near.

Yes I have that on the list of things to do as its best to be more
accurate. But in practice does it matter so much as even the LS bit set
or not pushes rounding up or down and there must be far more FP numbers
that are not an exact representation of a decimal number than not.

>
> Both problems can be fixed by arranging things such that REPRESENT
> does the rounding for the desired number of digits. Of course, for
> RNE you need a REPRESENT that does RNE.
>
>> Floating point conversions
>> will probably be done by treating the components of a floating
>> point numbers as a series of integer and character fields and
>> calling layer 1 operators.
>
> The hard part is not the string processing, but the float-to-string
> conversion. This is a hairy topic. A student happened to do a
> literature review some time ago. Even in 2018, a paper about the
> topic was still seen as relevant research, as demonstrated by PLDI
> accepting Ulf Adams' paper "Fast Float-to-String Conversion".

Yes that's why I decided to use the Forth system's REPRESENT rather than
me doing an inferior job. I remember seeing a paper that was about
guaranteeing that if a FP number was converted to a decimal string and
then converted back. IIRC it needed a high precision conversion to cover
all cases.

--
Gerry

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>On 25/01/2023 11:35, Anton Ertl wrote:
>> Gerry Jackson <do-no...@swldwa.uk> writes:
>>> On 23/01/2023 21:57, Anton Ertl wrote:
>>> - Hex & Decimal - Can be done with sprintf without changing BASE.
>>
>> My understanding is that Marcel Hendrix wants hex base for FP output,
>> and your implementation of sprintf does not implement this.
>
>I hadn't read his comment that way. I suppose you mean the %a and %A
>conversions.

I was not aware of them. I just mentioned Marcel Hendrix
requirements.

>> Side topic:
>>
>> I tested your PRINTF to see how well it implements rounding:
>>
>> : t fdup '|' emit 7 1 1 f.rdp '|' emit s" %7.1f" printf '|' emit ;
>>
>> 0.7499999999999999e t | 0.7| 0.8|
>>
>> The incorrect result of PRINTF is a result of double rounding: You ask
>> represent to round for 16 (I think) digits, resulting in
>> (0.)7500000000000000, and then you round that to 0.8.
>
>You're right. There is a configuration VALUE called MAX-PRECISION that
>is set to 15. I tried your test with MAX-PRECISION set to 20 and got the
>correct result
>0.7499999999999999e t | 0.7| 0.7| ok
>
>I think setting it to 15 was in the mistaken belief that it was better
>to omit the garbage that occurs after about 16 digits and forgot about
>the rounding. Setting PRECISION to 20 may be a good solution as
>anything after 15 or 16 digits is an error from an exact representation
>and likely to be small, leaving the rounding to later. But it's probably
>better to let REPRESENT do it (as long as it's done properly).

Setting the precision to 20 reduces the erroneous cases, and makes it
harder to find one, but I don't think that it eliminates them. There
will still be cases where REPRESENT's rounding rounds up to 5 in the
digit just below the last digit you want to output, or down to 4, and
then your rounding produces the wrong result.

If it was that easy to do correctly, people would not be publishing
papers in high-profile conferences about the topic in 2018.

>> Another issue is rounding to nearest or even (RNE):
>>
>> 1e 4e f/ t | 0.2| 0.3| ok
>> 3e 4e f/ t | 0.8| 0.8| ok
>>
>> You always round away from 0 when both rounding directions are equally
>> near.
>
>Yes I have that on the list of things to do as its best to be more
>accurate. But in practice does it matter so much as even the LS bit set
>or not pushes rounding up or down and there must be far more FP numbers
>that are not an exact representation of a decimal number than not.

It produces a bias away from zero, which may matter if somebody uses
the numbers from a report produced with such an output function and
processes them statistically.

>> The hard part is not the string processing, but the float-to-string
>> conversion. This is a hairy topic. A student happened to do a
>> literature review some time ago. Even in 2018, a paper about the
>> topic was still seen as relevant research, as demonstrated by PLDI
>> accepting Ulf Adams' paper "Fast Float-to-String Conversion".
>
>Yes that's why I decided to use the Forth system's REPRESENT rather than
>me doing an inferior job.

And we in Gforth use libc's ecvt() for REPRESENT when present rather
than our not so great replacement.

[Gerry Jackson]

Off the top of my head the only thing I can think of is that it
overcomes the deficiencies of the pictured output buffer (<# and
friends) which are (IMHO of course, YMMV):

- transient, can be corrupted by the system e.g. being moved
or overwritten
- suffering from the problem of being built up from right to left
- fixed in size by the system
- doesn't use dataspace or the heap
- only one buffer being available to the programmer
- the inability to nest or concatenate buffers
- system words such as .S may use <# etc that hinders debugging (a
quality of implementation issue)
- the system need not check the <# buffer for overflow (a quality
- of implementation issue)

Regarding sprintf, one thing I didn't mention was that instead of
calling the layer 1 primitives directly it builds Forth source code
that uses layer 1 primitives in a layer 0 buffer. This code is evaluated
at the end of the sprintf string analysis. It can also be compiled as a
colon definition the code of which could be saved in a file for
inclusion in an application - but I haven't done the last bit yet, which
ought to be trivial. This could make use of sprintf more attractive to
embedded systems as the sprintf code would not be needed.

--
Gerry

[none albert]

In article <tqvups$1jctm$1...@dont-email.me>,

That is where hex comes in. Printing a fp in hex yields an exact
representation. That was what Marcel Hendrix hinting at.
Of course FORTRAN people have a blind spot in this regard.
>
>--
>Gerry

[dxforth]

On 27/01/2023 9:25 pm, albert wrote:
>
> That is where hex comes in. Printing a fp in hex yields an exact
> representation. That was what Marcel Hendrix hinting at.
> Of course FORTRAN people have a blind spot in this regard.

Perhaps they're waiting to see if the fad runs its course. For all
we know IEEE could be gone 20 years hence. Decimal representation
will always be here. How many things have come and gone in the 50
years Forth has been around. FORTRAN has seen it all longer.

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>On 26/01/2023 00:54, dxforth wrote:
>> Do you have examples of things that can be done with 'layers 0 and 1'
>> that you feel is currently lacking in forth?
>>
>
>Off the top of my head the only thing I can think of is that it
>overcomes the deficiencies of the pictured output buffer (<# and
>friends) which are (IMHO of course, YMMV):
>
>- transient, can be corrupted by the system e.g. being moved
> or overwritten

The "overwritten" aspect is solved in Gforth by system words always
using <<#..#>>. The "moved" aspect is there, but I have never
encountered a situation where I wanted to ALLOT in the middle of
pictured numeric output.

>- suffering from the problem of being built up from right to left

It makes stuff like # # '.' HOLD # #s a bit unintuitive to read, true,
but given that's how the digits are generated, I don't consider it a
problem.

>- fixed in size by the system

Yes, although that could be changed. It's not innate in the
interface.

>- doesn't use dataspace or the heap

A deficiency? But of course it uses data space; I guess you mean that
it does not use ALLOTed memory.

>- only one buffer being available to the programmer

Solved with <<# ... #>>.

>- the inability to nest or concatenate buffers

Solved with <<# ... #>>.

>- system words such as .S may use <# etc that hinders debugging (a
> quality of implementation issue)

Solved in Gforth with <<# ... #>>.

>- the system need not check the <# buffer for overflow (a quality
>- of implementation issue)

But the system can, and in Gforth it does. Let everybody try

: foo 0 0 <# begin '.' hold again ; foo

on their systems.

iForth 5.1-mini reports "HOLD space overflow / invalid BASE ?".

SwiftForth x64-Linux 4.0.0-RC52 reports a Pictured numeric output
string overflow.

On VFX64 5.11 RC2 this results in a SIGSEGV and an apparently pretty
badly corrupted system.

>Regarding sprintf, one thing I didn't mention was that instead of
>calling the layer 1 primitives directly it builds Forth source code
>that uses layer 1 primitives in a layer 0 buffer. This code is evaluated
>at the end of the sprintf string analysis. It can also be compiled as a
>colon definition the code of which could be saved in a file for
>inclusion in an application - but I haven't done the last bit yet, which
>ought to be trivial. This could make use of sprintf more attractive to
>embedded systems as the sprintf code would not be needed.

For the usage

... s" ..." sprintf

inside a colon definition, development Gforth's literal stack can be
used to parse the string in an optimizer and compile some lower-level
calls, avoiding the need to parse the string at run-time.

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>In article <tqvups$1jctm$1...@dont-email.me>,
>Gerry Jackson <do-no...@swldwa.uk> wrote:
>>I remember seeing a paper that was about
>>guaranteeing that if a FP number was converted to a decimal string and
>>then converted back. IIRC it needed a high precision conversion to cover
>>all cases.
>
>That is where hex comes in. Printing a fp in hex yields an exact
>representation.

And it's so easy. Fetch the FP number onto the data stack and then

HEX U.

(the Chuck Moore way) or

`U. $10 BASE-EXECUTE

(my way); at least for 64-bit FP numbers and 64-bit cells. You were
probably thinking of stuff like the C99 %a conversion, which outputs
something in the style [-]0xh.hhhhp±d. However, the resulting output
of the latter is almost as incomprehensible as the output of the
former. It's only advantage is that you can use the latter to convert
between FP formats, but given that IEEE FP has won, the benefit is not
as big as it once was; still, given that a number of Forth systems use
80-bit floats, while others use 64-bit floats, there is still a little
benefit to the %a style.

[Gerry Jackson]

My use of 'need not' implies that I recogbise that a system can.

> and in Gforth it does. Let everybody try
>
> : foo 0 0 <# begin '.' hold again ; foo
>
> on their systems.
>
> iForth 5.1-mini reports "HOLD space overflow / invalid BASE ?".
>
> SwiftForth x64-Linux 4.0.0-RC52 reports a Pictured numeric output
> string overflow.
>
> On VFX64 5.11 RC2 this results in a SIGSEGV and an apparently pretty
> badly corrupted system.

The fact that you've addressed many of the items on my list means that
you agree the pictured output buffer has these deficiencies. Having
criticised the <# buffer my layer1 does use it to do what it is good for
- conversion of an integer to text prior to further processing like left
or right justification and copying the result across

>
>> Regarding sprintf, one thing I didn't mention was that instead of
>> calling the layer 1 primitives directly it builds Forth source code
>> that uses layer 1 primitives in a layer 0 buffer. This code is evaluated
>> at the end of the sprintf string analysis. It can also be compiled as a
>> colon definition the code of which could be saved in a file for
>> inclusion in an application - but I haven't done the last bit yet, which
>> ought to be trivial. This could make use of sprintf more attractive to
>> embedded systems as the sprintf code would not be needed.
>
> For the usage
>
> ... s" ..." sprintf
>
> inside a colon definition, development Gforth's literal stack can be
> used to parse the string in an optimizer and compile some lower-level
> calls, avoiding the need to parse the string at run-time.
>

That sounds useful, will it be available to a user?

--
Gerry

[dxforth]

On 22/01/2023 9:31 pm, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
>> Probably worth a new thread, but... Over the years I have
>> needed dozens of variants of the basic floating-point
>> formatting words. There is always something
>> slightly different that is needed (sufficiently
>> different or useful to put in a new word). Is
>> this a commonly accepted fact, or does it
>> indicate that we don't have the proper
>> Forth way to factor the problem yet?
>
> When I looked into the problem, I found no good way to apply the
> flexible approach used for integers (with # HOLD etc.) for FP output.
> I also inspected what C does with printf(), and eventually settled on
> F.RDP. Here's the documentation:
>
> <snipped>
>
> | To give you a better intuition of how they influence the output, here
> |are some examples of parameter combinations; in each line the same
> |number is printed, in each column the same parameter combination is used
> |for printing:
> |
> | 12 13 0 7 3 4 7 3 0 7 3 1 7 5 1 7 7 1 7 0 2 4 2 1
> | |-1.234568E-6|-1.2E-6| -0.000|-1.2E-6|-1.2E-6|-1.2E-6|-1.2E-6|****|
> | |-1.234568E-5|-1.2E-5| -0.000|-1.2E-5|-.00001|-1.2E-5|-1.2E-5|****|
> | |-1.234568E-4|-1.2E-4| -0.000|-1.2E-4|-.00012|-1.2E-4|-1.2E-4|****|
> | |-1.234568E-3|-1.2E-3| -0.001| -0.001|-.00123|-1.2E-3|-1.2E-3|****|
> | |-1.234568E-2|-1.2E-2| -0.012| -0.012|-.01235|-1.2E-2|-1.2E-2|-.01|
> | |-1.234568E-1|-1.2E-1| -0.123| -0.123|-.12346|-1.2E-1|-1.2E-1|-.12|
> | |-1.2345679E0| -1.235| -1.235| -1.235|-1.23E0|-1.23E0|-1.23E0|-1E0|
> | |-1.2345679E1|-12.346|-12.346|-12.346|-1.23E1|-1.23E1| -12.|-1E1|
> | |-1.2345679E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2| -123.|-1E2|
> | |-1.2345679E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3| -1235.|-1E3|
> | |-1.2345679E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-12346.|-1E4|
> | |-1.2345679E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1E5|
>
> F.RDP has proved sufficient for my needs, but then I do not do as much
> with FP numbers as you do.

ISTM the primary function of F.RDP is to squeeze the number into a given
field. For myself I would code the problem as follows:

\ DX-Forth has this built-in
: NHOLD ( n char -- ) swap 0 ?do dup hold loop drop ;

\ Output r right-justified in field wid with prec significant
\ digits in fixed point format. If doesn't fit, try scientific
\ else print asterisk. Uses (F.) (FS.) from DX-Forth and VFX
: (F.R) ( r prec wid -- a u )
>r set-precision fdup -1 (f.) dup r@ > if
2drop -1 (fs.) dup r@ > if
<# r> [char] * nhold #> exit
then
else 2>r fdrop 2r> then
r> over - 0 max bl nhold #> ;

3.14159265358979e
fdup 1e3 f* 5 8 (f.r) cr type
fdup 1e7 f* 5 8 (f.r) cr type
1e8 f* 6 8 (f.r) cr type

3141.6 ok
3.1416E7 ok
******** ok

[Marcel Hendrix]

On Sunday, January 29, 2023 at 5:23:02 AM UTC+1, dxforth wrote:
> On 22/01/2023 9:31 pm, Anton Ertl wrote:
> > Marcel Hendrix <m...@iae.nl> writes:

> >> ...There is always something
> >> slightly different that is needed ...
[..]

> 1e8 f* 6 8 (f.r) cr type

[..]
> ******** ok

A user will not be amused with this result
after a 10 minute calculation and demand
'a slightly different' representation.

-marcel

[dxforth]

You mean to say the user's choice significant digits and field width
didn't work. Whose fault was that?

[Marcel Hendrix]

Deep Thought> **

-marcel

[dxforth]

On 29/01/2023 3:22 pm, dxforth wrote:
> ...

> ISTM the primary function of F.RDP is to squeeze the number into a given
> field.  For myself I would code the problem as follows:
>
> \ DX-Forth has this built-in
> : NHOLD ( n char -- )  swap 0 ?do dup hold loop drop ;
>
> \ Output r right-justified in field wid with prec significant
> \ digits in fixed point format.  If doesn't fit, try scientific
> \ else print asterisk.  Uses (F.) (FS.) from DX-Forth and VFX
> : (F.R) ( r prec wid -- a u )
>   >r  set-precision  fdup -1 (f.)  dup r@ > if
>     2drop  -1 (fs.)  dup r@ > if
>       <#  r> [char] * nhold  #>  exit
>     then
>   else  2>r fdrop 2r>  then
>   r> over - 0 max bl nhold  #> ;
>
> 3.14159265358979e
> fdup 1e3 f* 5 8 (f.r) cr type
> fdup 1e7 f* 5 8 (f.r) cr type
>      1e8 f* 6 8 (f.r) cr type
>
>   3141.6 ok
> 3.1416E7 ok
> ******** ok

If anyone has tried the above with INF/NAN as input, they will have found
it doesn't print! The good news is the routine is solid. The bad news is
there's a bug in (F.) (FS.) . A patch to fix the problem has been sent to MPE.

[Marcel Hendrix]

On Sunday, January 29, 2023 at 5:23:02 AM UTC+1, dxforth wrote:

[..]

> \ Output r right-justified in field wid with prec significant
> \ digits in fixed point format. If doesn't fit, try scientific
> \ else print asterisk. Uses (F.) (FS.) from DX-Forth and VFX
> : (F.R) ( r prec wid -- a u )
> >r set-precision fdup -1 (f.) dup r@ > if
> 2drop -1 (fs.) dup r@ > if
> <# r> [char] * nhold #> exit
> then
> else 2>r fdrop 2r> then
> r> over - 0 max bl nhold #> ;

[..]

Clear as mud?
I didn't know VFX had floats on the datastack?
Your `<#` does not expect a double on the datastack but a single ( -1 )?

FORTH> 3.14159265358979e ok
{1}FORTH> fdup 1e3 f* 5 8 (f.r) cr type
******** ok
[2]{1}FORTH> fdup 1e7 f* 5 8 (f.r) cr type
******** ok
[4]{1}FORTH> 1e8 f* 6 8 (f.r) cr type
******** ok
[6]FORTH> .s
Data: -1 -1 -1 -1 -1 -1 ---
System: ---
Float: --- ok
[6]FORTH> 3drop 3drop +inf ok
{1}FORTH> fdup 1e3 f* 5 8 (f.r) cr type
+INF ok
[1]{1}FORTH> fdup 1e7 f* 5 8 (f.r) cr type
+INF ok
[2]{1}FORTH> 1e8 f* 6 8 (f.r) cr type
+INF ok
[3]FORTH> .s
Data: -1 -1 -1 ---
System: ---
Float: --- ok
[3]FORTH>

-marcel

[dxforth]

On 1/02/2023 7:05 am, Marcel Hendrix wrote:
> On Sunday, January 29, 2023 at 5:23:02 AM UTC+1, dxforth wrote:
> [..]
>> \ Output r right-justified in field wid with prec significant
>> \ digits in fixed point format. If doesn't fit, try scientific
>> \ else print asterisk. Uses (F.) (FS.) from DX-Forth and VFX
>> : (F.R) ( r prec wid -- a u )
>>> r set-precision fdup -1 (f.) dup r@ > if
>> 2drop -1 (fs.) dup r@ > if
>> <# r> [char] * nhold #> exit
>> then
>> else 2>r fdrop 2r> then
>> r> over - 0 max bl nhold #> ;
> [..]
>
> Clear as mud?
> I didn't know VFX had floats on the datastack?
> Your `<#` does not expect a double on the datastack but a single ( -1 )?
>

> <results snipped>

What version of VFX are you using? I get:

VFX Forth 64 for Windows x64
© MicroProcessor Engineering Ltd, 1998-2022

Version: 5.20 [build 4088]
Build date: 5 September 2022

...

3.14159265358979e ok F:-1

fdup 1e3 f* 5 8 (f.r) cr type

3141.6 ok F:-1

fdup 1e7 f* 5 8 (f.r) cr type

3.1416E7 ok F:-1

1e8 f* 6 8 (f.r) cr type
******** ok

.s
DATA STACK
empty stack
ok

[dxforth]

Speaking of which, I'm not sure the task is usefully spec'd (for general-
purpose use). I can't think of many instances where printing **** instead
of the number is a good result. E.g. the classic forth function .R tries
to print a number in the specified field width but if it can't, it prints
the number regardless. For something like (F.R) I would change the spec
such that if it can't print fixed-point format in the specified width, then
it prints scientific mode as that will generally be shorter.

[Marcel Hendrix]

On Wednesday, February 1, 2023 at 12:48:36 AM UTC+1, dxforth wrote:
[..]

> Speaking of which, I'm not sure the task is usefully spec'd (for general-
> purpose use). I can't think of many instances where printing **** instead
> of the number is a good result. E.g. the classic forth function .R tries
> to print a number in the specified field width but if it can't, it prints
> the number regardless. For something like (F.R) I would change the spec
> such that if it can't print fixed-point format in the specified width, then
> it prints scientific mode as that will generally be shorter.

That was my original point. I don't know how to solve it in general, but
printing "***" appears never to be ok (Unless in Malbolge or ArnoldC).

-marcel

[dxforth]

or EXCEL

[none albert]

The language designed after FORTRAN algol60 stipulates that if
a result doesn't fit in the field, a free format is used.
It is learning from prior mistakes.
(In the 70's it took a day to look at the result of even a
2 second calculations, batch processing.)

Groetjes Albert

[dxforth]

On 1/02/2023 11:27 pm, albert wrote:
> In article <tr5dm9$2mjja$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
>> On 29/01/2023 7:48 pm, Marcel Hendrix wrote:
>>> On Sunday, January 29, 2023 at 5:23:02 AM UTC+1, dxforth wrote:
>>>> On 22/01/2023 9:31 pm, Anton Ertl wrote:
>>>>> Marcel Hendrix <m...@iae.nl> writes:
>>>>>> ...There is always something
>>>>>> slightly different that is needed ...
>>> [..]
>>>> 1e8 f* 6 8 (f.r) cr type
>>> [..]
>>>> ******** ok
>>>
>>> A user will not be amused with this result
>>> after a 10 minute calculation and demand
>>> 'a slightly different' representation.
>>
>> You mean to say the user's choice significant digits and field width
>> didn't work. Whose fault was that?
>
> The language designed after FORTRAN algol60 stipulates that if
> a result doesn't fit in the field, a free format is used.
> It is learning from prior mistakes.
> (In the 70's it took a day to look at the result of even a
> 2 second calculations, batch processing.)

Which may not be what's wanted in an electronic spreadsheet. Hindsight
suggests languages shouldn't provide right-justified print routines as
application needs vary. Instead of .R it may have been better for forth
to have provided (D.) and let programmers define right-justified functions
from it as the need requires. Once I had (F.) and (FS.) I could define
(F.R) whichever way I pleased: