ver. 3.x -- in progress (no releases yet); will provide integrated
fp/data stack.
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".
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?
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
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 haveI once has the conviction that I was to define a wordset similar
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?
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 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.
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"
IMO a simple format string will do for most Forth applications, similar to: https://eml.berkeley.edu/sst/fmttop.html
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?
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?
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.
In article <tqjd3j$iql$1@gioia.aioe.org>, dxforth <dxforth@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.
Then there is the old head-scratcher caused by the differing formats between >>FLOAT REPRESENT and text interpreter ....
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.)
|'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,
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?
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?
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-[..]
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).
"minf...@arcor.de" <minforth@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().
On 22/01/2023 18:36, Anton Ertl wrote:community but do they use FP much?
"minf...@arcor.de" <minforth@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
On 24/01/2023 2:10 am, Gerry Jackson wrote:
On 22/01/2023 18:36, Anton Ertl wrote:
"minf...@arcor.de" <minforth@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?
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
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
On 23/01/2023 15:54, dxforth wrote:community but do they use FP much?
On 24/01/2023 2:10 am, Gerry Jackson wrote:
On 22/01/2023 18:36, Anton Ertl wrote:
"minf...@arcor.de" <minforth@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
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.
Gerry Jackson <do-not-use@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.
Gerry Jackson <do-not-use@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.
Gerry Jackson <do-not-use@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.
- anton
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
And even using [sprintf] poses problems: ...
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.)
It does not (yet) solve the basic problem of ".".
anton@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?
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?
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/isFortran offers even more formatting than C. https://www.l3harrisgeospatial.com/docs/format_codes_fortran.html
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?
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.
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
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.RDPOverkill would be when the output routines represent a significant portion
of the space available to the application.
On 23/01/2023 21:57, Anton Ertl wrote:
Gerry Jackson <do-not-use@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!
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.
- 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.
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.
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.
With such a scheme a user can compile the as much functionality as
needed, reducung unnecessary bloat.
--
Gerry
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:Overkill would be when the output routines represent a significant portion >> of the space available to the application.
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" 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).
In article <tqoik1$3jks$1@dont-email.me>,
Gerry Jackson <do-not-use@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?
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 as5 layers reducing unnecessary bloat?
needed, reducung unnecessary bloat.
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.
...
If I only want <# family type formatting, but much improved only layers 0 and 1 are loaded, even less code.
...
Fortran offers even more formatting than C. https://www.l3harrisgeospatial.com/docs/format_codes_fortran.html
On 25/01/2023 11:35, Anton Ertl wrote:
Gerry Jackson <do-not-use@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.
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.
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.
Gerry Jackson <do-not-use@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.
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".
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?
On 25/01/2023 11:35, Anton Ertl wrote:
Gerry Jackson <do-not-use@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
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.
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
- 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.
In article <tqvups$1jctm$1@dont-email.me>,
Gerry Jackson <do-not-use@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.
Gerry Jackson <do-not-use@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.
Marcel Hendrix <mhx@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.
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
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.
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 resultYou mean to say the user's choice significant digits and field width
after a 10 minute calculation and demand
'a slightly different' representation.
didn't work. Whose fault was that?
...
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
\ 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@ > if2drop -1 (fs.) dup r@ > if
<# r> [char] * nhold #> exit
then
else 2>r fdrop 2r> then
over - 0 max bl nhold #> ;
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@ > if2drop -1 (fs.) dup r@ > if
<# r> [char] * nhold #> exit
then
else 2>r fdrop 2r> then
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>
On Sunday, January 29, 2023 at 10:19:08 AM UTC+1, dxforth 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:You mean to say the user's choice significant digits and field width
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.
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.
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).
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?
In article <tr5dm9$2mjja$1@dont-email.me>, dxforth <dxforth@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.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 35:38:46 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,388 |