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

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

...

should be "will provide separate fp stack".

--
KM

[dxforth]

Post by Krishna Myneni
...

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

...
should be "will provide separate fp stack".

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:
[..]

Post by dxforth
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]

Post by Marcel Hendrix
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

[Marcel Hendrix]

[..]

Post by Anton Ertl
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.)

Post by Anton Ertl
I also inspected what C does with printf(), and eventually settled on
|'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

[Anton Ertl]

Post by Marcel Hendrix
[..]

Post by Anton Ertl
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.

Post by Marcel Hendrix
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.

Post by Marcel Hendrix
There is printing with and without a trailing
space (when appending '.' or ','),

F.RDP vs. F.RDP SPACE

Post by Marcel Hendrix
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.

Post by Marcel Hendrix
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).

Post by Marcel Hendrix
( 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.

Post by Marcel Hendrix

Post by Anton Ertl
|'f.rdp' ( rf +nr +nd +np -- ) gforth-0.6 "f.rdp"

Yes... What to do if printing in HEX,

F.RDP is always decimal.

Post by Marcel Hendrix
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.

Post by Marcel Hendrix
+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

Post by Marcel Hendrix
in too short fields

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

Post by Marcel Hendrix
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.

Post by Marcel Hendrix
suppressing/adding trailing space,

(Don't) call SPACE afterwards.

Post by Marcel Hendrix
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

[dxforth]

Post by Marcel Hendrix
[..]

Post by Anton Ertl
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.

Post by Marcel Hendrix
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.)

Post by Anton Ertl
I also inspected what C does with printf(), and eventually settled on
|'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]

[..]

Post by Anton Ertl
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

[..]

: #. ( 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]

Post by Marcel Hendrix

[..]

Post by Anton Ertl
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

[..]

: #. ( 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).

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

[dxforth]

Post by Anton Ertl

Post by Marcel Hendrix
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
<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
|
| 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 )
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]

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** ok

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

-marcel

[dxforth]

Post by Marcel Hendrix

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** 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?

[Marcel Hendrix]

Post by dxforth

Post by Marcel Hendrix

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** 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?

Deep Thought> **

-marcel

[dxforth]

Post by Marcel Hendrix

Post by dxforth

Post by Marcel Hendrix

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** 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?

Deep Thought> **

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:
[..]

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

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]

Post by Marcel Hendrix
[..]

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

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

or EXCEL

[none) (albert]

Post by dxforth

Post by Marcel Hendrix

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** 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.)

Groetjes Albert

[dxforth]

Post by none) (albert

Post by dxforth

Post by Marcel Hendrix

Post by dxforth

...There is always something
slightly different that is needed ...

[..]

Post by dxforth
1e8 f* 6 8 (f.r) cr type

[..]

Post by dxforth
******** 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:

: (F.R) ( r prec wid -- a u )
2drop -1 (fs.)
\ dup r@ > if <# r> [char] * nhold #> exit then
else 2>r fdrop 2r> then
r> over - 0 max bl nhold #> ;

[dxforth]

Post by dxforth
...
ISTM the primary function of F.RDP is to squeeze the number into a given
\ 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> [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:
[..]

Post by dxforth
\ 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> [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]

Post by Marcel Hendrix
[..]

Post by dxforth
\ 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> [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

[none) (albert]

Post by Marcel Hendrix
[..]

Post by dxforth
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.

Post by Marcel Hendrix
-marcel

Groetjes Albert

[[e-mail]]

Post by none) (albert

Post by Marcel Hendrix
[..]

Post by dxforth
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

Post by none) (albert
FLOAT REPRESENT and text interpreter ....

[Marcel Hendrix]

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

Post by ***@arcor.de
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

[Anton Ertl]

Post by ***@arcor.de
Then there is the old head-scratcher caused by the differing formats between

Post by none) (albert
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().

- anton

[Gerry Jackson]

Post by Anton Ertl

Post by ***@arcor.de
Then there is the old head-scratcher caused by the differing formats between

Post by none) (albert
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?

[dxforth]

Post by Anton Ertl

Post by ***@arcor.de
Then there is the old head-scratcher caused by the differing formats between

Post by none) (albert
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?

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]

Post by Gerry Jackson

Post by Anton Ertl

Post by ***@arcor.de
Then there is the old head-scratcher caused by the differing formats between

Post by none) (albert
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?

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

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.

[dxforth]

Post by Gerry Jackson

Post by Anton Ertl

Post by ***@arcor.de
Then there is the old head-scratcher caused by the differing formats between

Post by none) (albert
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?

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

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

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.

[Anton Ertl]

Post by Gerry Jackson
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.

- anton

[dxforth]

Post by Anton Ertl

Post by Gerry Jackson
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.
* 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]

Post by Anton Ertl

Post by Gerry Jackson
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.
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.

Post by Anton Ertl
* 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.

Post by Anton Ertl
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.

Post by Anton Ertl
* 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.

Post by Anton Ertl
* 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.

[Anton Ertl]

Post by Gerry Jackson

Post by Anton Ertl

Post by Gerry Jackson
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.

Post by Gerry Jackson
I don't why it need pose a problem for users. All that has to be
( 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.

Post by Anton Ertl
* 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.

Post by Anton Ertl
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>.

Post by Gerry Jackson

Post by Anton Ertl
* 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).

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
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".

- anton

[Gerry Jackson]

Post by Anton Ertl

Post by Gerry Jackson
- 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.

Post by Anton Ertl
: 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).

Post by Anton Ertl
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.

Post by Anton Ertl
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.

Post by Gerry Jackson
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.

[Anton Ertl]

Post by Gerry Jackson

Post by Anton Ertl

Post by Gerry Jackson
- 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.

Post by Gerry Jackson

Post by Anton Ertl
: 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.

Post by Gerry Jackson

Post by Anton Ertl
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.

Post by Gerry Jackson

Post by Anton Ertl
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.

- anton

[none) (albert]

Post by Gerry Jackson

Post by Anton Ertl

Post by Gerry Jackson
- 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.

Post by Anton Ertl
: 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).

Post by Anton Ertl
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.

Post by Anton Ertl
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.

Post by Gerry Jackson
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.

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.

Post by Gerry Jackson
--
Gerry

[dxforth]

Post by none) (albert
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]

Post by none) (albert

Post by Gerry Jackson
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.

- anton

[none) (albert]

Post by Gerry Jackson
I don't why it need pose a problem for users. All that has to be
( 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.

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

5 layers reducing unnecessary bloat?

Post by Gerry Jackson
--
Gerry

Groetjes Albert

[Marcel Hendrix]

[..]

Post by none) (albert
Hint, the effort to hook up FORTRAN libraries to Forth far exceeds
the possibly benefits.

Post by Gerry Jackson
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]

Post by none) (albert

Post by Gerry Jackson
I don't why it need pose a problem for users. All that has to be
( 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.

Post by none) (albert

Post by Gerry Jackson
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.

[dxforth]

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

Post by dxforth

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

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.

[Anton Ertl]

Post by Gerry Jackson

Post by dxforth
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
- 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.

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
- fixed in size by the system

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

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
- only one buffer being available to the programmer

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

Post by Gerry Jackson
- the inability to nest or concatenate buffers

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

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

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

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
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

[Gerry Jackson]

Post by Anton Ertl

Post by Gerry Jackson

Post by dxforth
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
- 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.

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
- fixed in size by the system

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

Post by Gerry Jackson
- 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.

Post by Gerry Jackson
- only one buffer being available to the programmer

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

Post by Gerry Jackson
- the inability to nest or concatenate buffers

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

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

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

Post by Gerry Jackson
- the system need not check the <# buffer for overflow (a quality
- of implementation issue)

But the system can,

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

Post by Anton Ertl
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

Post by Anton Ertl

Post by Gerry Jackson
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?

[none) (albert]

Post by Anton Ertl

Post by Gerry Jackson
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.
* 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.)

Post by Anton Ertl
- anton

Groetjes Albert

[Marcel Hendrix]

[..]

Post by none) (albert
Example of usage

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

[dxforth]

Post by Marcel Hendrix
It does not (yet) solve the basic problem of ".".

What problem was that exactly?

[dxforth]

Post by none) (albert
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 :)

[Paul Rubin]

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]

Post by Paul Rubin

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?

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.

[[e-mail]]

Post by Paul Rubin

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

[Marcel Hendrix]

Post by ***@arcor.de

Post by Paul Rubin

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

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:
[..]

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

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

[Anton Ertl]

Post by Marcel Hendrix
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.

- anton

[dxforth]

Post by ***@arcor.de

Post by Paul Rubin

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

[[e-mail]]

Post by dxforth

Post by ***@arcor.de

Post by Paul Rubin

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

[dxforth]

Post by ***@arcor.de

Post by dxforth

Post by ***@arcor.de

Post by Paul Rubin

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

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?

[dxforth]

Post by ***@arcor.de
...
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]

Post by Marcel Hendrix
[..]

Post by dxforth
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 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?

[none) (albert]

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

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

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

Groetjes Albert

[dxforth]

Post by none) (albert
<SNIP>

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

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

Post by dxforth
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