interpretation of PRECISION
Krishna Myneni
of the Floating Point Extension word, PRECISION, or the value
contained therein, which controls the output of F. , FS. , and FE. in
Forth-94. The key phrase in the specification (below) is "significant
digits", which has a specific and unambiguous meaning. Take the
following cases,
Example 1)
3 set-precision
9.11e-31 f.
Gforth: 0.000000000000000000000000000000911
PFE: 0.000
Example 2)
3 set-precision
1000.123e f.
Gforth: 1000.
PFE: 1000.123
According to the strict interpretation of the specification for
PRECISION, Gforth is correct for example 1). The output produced by
PFE may have been the intended goal of the specification, but is
inconsistent with its wording.
What do other Forth systems do with these examples?
Krishna
--
12.6.2.2035 PRECISION
FLOATING EXT
( -- u )
Return the number of significant digits currently used by F., FE., or
FS. as u.
Also,
12.6.2.2200 SET-PRECISION
FLOATING EXT
( u -- )
Set the number of significant digits currently used by F., FE., or FS.
to u.
Josh Grams
> There appears to be confusion by some Forth systems about the meaning
> of the Floating Point Extension word, PRECISION, or the value
> contained therein, which controls the output of F. , FS. , and FE. in
> Forth-94. The key phrase in the specification (below) is "significant
> digits", which has a specific and unambiguous meaning. Take the
> following cases,
Hmm. Doesn't seem like there are many other Forth systems which
even *implement* set-precision. At least not that I can get to
run easily.
> Example 1)
>
> 3 set-precision
> 9.11e-31 f.
>
> Gforth: 0.000000000000000000000000000000911
> PFE: 0.000
SP-Forth: 0.000000000000000000000000000000
pforth: 0.000
>
> Example 2)
>
> 3 set-precision
> 1000.123e f.
>
> Gforth: 1000.
> PFE: 1000.123
SP-Forth: 100.
pforth: 1000.
FICL has floating-point, but doesn't implement PRECISION. Ditto
kForth, but you knew that. :) Win32Forth does, but I still
haven't gotten around to figuring out why it doesn't work under
Wine for me, so I can't give you results there.
--Josh
Alex McDonald
Win32Forth (all the versions I have to hand);
3 set-precision ok
1000.123e f. 1000. ok
3 set-precision ok
9.11e-31 f. .000 ok
George Hubert
For Win32forth
3 set-precision ok
9.11e-31 f. .000 ok
3 set-precision ok
1000.123e f. 1000. ok
George Hubert
Krishna Myneni
> ...
> FICL has floating-point, but doesn't implement PRECISION. Ditto
> kForth, but you knew that. :) Win32Forth does, but I still
> haven't gotten around to figuring out why it doesn't work under
> Wine for me, so I can't give you results there.
Thanks for the partial survey. Yes, kForth has limited intrinsic fp
output capability and relies on Forth source output formatting words
(e.g. F>STRING in strings.4th). However, this situation will change in
the next release, and the following words will be implemented:
PRECISION SET-PRECISION FS.
Also, F. will work with PRECISION , but the question is how should it
work? Apparently there is no consensus on this issue, and the
specification has the following problem: fixed point output, using
F. , can be ambiguous with respect to a fixed number of significant
digits. That is, if the specification is going to be with respect to a
fixed number of significant digits, the current specification is
incomplete.
Furthermore, there is apparent confusion in the implementation of FS.
as well. In scientific notation, there is no ambiguity in the output
representation for a fixed number of significant digits, and Gforth
gets this right, e.g.
3 set-precision ok
3.141596e FS. 3.14E0 ok
Unfortunately, PFE does not interpret the meaning of significant
digits correctly, and, instead produces:
3 set-precision ok
3.14159e FS. 3.142E+00 ok
The above output of FS. has 4 significant digits, not 3.
Obviously, unambiguous specifications of PRECISION and F. FS. and FE.
are needed to write portable code to produce formatted floating point
number output.
Krishna
Andreas
FWIW the code snippet below works for me "since decades" ;-)
(of course based on a working REPRESENT)
\ ------ FP Number Output
CODE REPRESENT _represent \ ( f: r d: adr u -- d: exp sign flag )
\ convert fp number r to string in buffer at adr
\ results: exponent, sign and valid-flag
8 VALUE PRECISION \ ( -- p ) actual significant digits
: SET-PRECISION \ ( p -- ) set no. of significand digits for output
dup 1 17 within not -24 ?throw \ max. 15 valid digits
to precision ;
: FPAD \ ( -- adr ) transient region for pictured FP output
here 256 + ;
: ?SIGN \ ( flag -- ) print sign
0< if [char] - emit then ;
: .DOT \ ( -- ) print decimal point
[char] . emit ;
: .EXP \ ( exp -- ) print exponent
[char] E emit . space ;
: FTRIM \ ( a u -- a' u' ) cut trailing zeroes
[char] 0 -1 trim ;
: (F.) \ ( f: r -- d: -- exp sign )
\ base @ 10 <> -40 ?throw
fpad 16 [char] 0 fill
fpad precision represent \ exp sign flag --
if exit then \ "normal" exit
r> 3drop
fpad precision ftrim type ; \ type infs and nans
: FS. \ ( f: r -- ) print fp number in scientific notation
(f.) ?sign \ exp
fpad dup c@ emit .dot
char+ precision 1- ftrim type 1- .exp ;
: FE. \ ( f: r -- ) print fp number in engineering notation
(f.) ?sign \ exp
fpad c@ [char] 0 = if drop ." 0.E0 " exit then
dup 3 mod over 0< if 3 + else dup 0= if drop 3 then then \ exp m
fpad over type .dot
fpad over + precision pluck - \ exp m a u
dup 0< if 2drop else ftrim type then
- .exp ;
: F. \ ( f: r -- ) print fp number in fixed-point notation
fdup (f.) over 1- precision negate precision within
not if 2drop fs. exit then \ exp sign
?sign dup 0<= if \ abs(r) < 1
." 0." dup begin dup while 1+ [char] 0 emit repeat drop
fpad precision rot + tuck represent 3drop
fpad swap ftrim type
else \ abs(r) >= 1
fpad over type .dot
fpad over + precision rot -
dup 0< if 2drop else ftrim type then fdrop
then space ;
Ed
> ...
> FWIW the code snippet below works for me "since decades" ;-)
> (of course based on a working REPRESENT)
Perhaps you never had to output tables of decimal-aligned data
in fixed-point format ?
Below is some formatted output which represents the minimum
capability I would expect from of a language with floating-point.
For C and Fortran users, generating it would be trivial. Today's
crop of forth compilers would find it all but impossible.
While forthers continue to argue about what Forth-94 "intended"
for FS. F. FE. and how their fellow hackers implemented it,
the world and its needs have moved on.
--
C version
Scientific Fixed-point
Output numbers to 5 decimal places
-1.23457e-08 -0.00000
-1.23457e+00 -1.23457
-9.00000e-01 -0.90000
-4.00000e-01 -0.40000
-NAN -NAN
+INF +INF
Same numbers at 0 decimal places
-1e-08 -0
-1e+00 -1
-9e-01 -1
-4e-01 -0
-NAN -NAN
+INF +INF
Anton Ertl
>Also, F. will work with PRECISION , but the question is how should it
>work? Apparently there is no consensus on this issue,
Why do you think so?
> and the
>specification has the following problem: fixed point output, using
>F. , can be ambiguous with respect to a fixed number of significant
>digits. That is, if the specification is going to be with respect to a
>fixed number of significant digits, the current specification is
>incomplete.
Why do you think so? Ad could you explain your terms? What do you
mean with "fixed point output" etc.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2010: http://www.euroforth.org/ef10/
Andreas
> Perhaps you never had to output tables of decimal-aligned data
> in fixed-point format ?
Well, we are in Forth's realm, not in COBOL's. ;-)
Krishna Myneni
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >Also, F. will work with PRECISION , but the question is how should it
> >work? Apparently there is no consensus on this issue,
>
> Why do you think so?
>
My statement that there appears to be no consensus on how F. and
PRECISION work together is based on the output from different Forth
systems, for the examples I gave earlier:
( 1)
3 SET-PRECISION
9.11e-31 F.
( 2)
3 SET-PRECISION
1000.123e F.
The above two examples produced various output in Gforth, PFE, SP-
Forth, pforth, and Win32Forth. The current specification cannot cover
completely the behavior of F. if we are to interpret it literally, as
I will explain below.
I think the (implied) specification of how FS. and FE. are to work
with PRECISION is adequate and unambiguous. But, as I showed earlier,
at least one system deviates from my literal interpretation of the
spec. This was for the example,
( 3)
3 SET-PRECISION
3.14159e FS.
> > and the
> >specification has the following problem: fixed point output, using
> >F. , can be ambiguous with respect to a fixed number of significant
> >digits. That is, if the specification is going to be with respect to a
> >fixed number of significant digits, the current specification is
> >incomplete.
>
> Why do you think so? Ad could you explain your terms? What do you
> mean with "fixed point output" etc.
>
Thanks for this question about the meaning of "fixed point output".
This is an important term to clarify, and gets to the heart of the
matter. Let us first note that the F. spec. in DPANS94 says,
"Display, with a trailing space, the top number on the floating-point
stack using fixed-point notation:"
The term, "fixed point notation", implies (to me) that the decimal
point is at a fixed position in the output. Ideally, the output field
width is constant, and the decimal point is at a fixed location within
this field width. Since F. does not use a field width parameter, one
must fix the decimal point position with respect to either the left
side of the output field or the right side of the output field. Since
F. deals with floating point numbers, it seems more sensible to
require that the decimal point be fixed in position with respect to
the right side of the output field. Then, the value in PRECISION would
indicate the decimal point offset from the right hand side of the
output field. All digits to the left of the decimal point, needed to
represent the number, would be output. However, the interpretation of
the value in PRECISION, to mean the number of significant digits, is
inconsistent with this reasoning.
So, let us consider examples 1) and 2) above. The output of PFE for
these two examples is,
( PFE 1) 0.000
( PFE 2) 1000.123
This output seems consistent with our argument above, for what fixed
point output is intended to accomplish. It is not consistent with the
notion that PRECISION represents the number of significant digits for
the output of F. .
Now, let's consider the example 1) and 2) output from Gforth:
( Gforth 1) 0.000000000000000000000000000000911
( Gforth 2) 1000.
The Gforth output for example 1) is consistent with the notion that
PRECISION represents the number of significant digits --- there are 3
significant digits in the output. However, the decimal point position
is not at a fixed position, either from the left side or the right
side of the output field. So the two requirements, fixed number of
significant digits, and fixed decimal point position, are
incompatible. Also, the Gforth output for example 2) has, by
convention, 4 significant digits. This is due to the presence of the
decimal point. More on this point, below.
To sum up for fixed point output, if we accept the notion that the
term, "fixed point notation", implies a fixed position of the decimal
point from the right side of the output field, the specification for
PRECISION should be made clear that it does not represent the number
of significant digits for the word F. .
For scientific and engineering notation, it is entirely reasonable to
treat the value in PRECISION as representing the number of significant
digits, and not indicating the position of the decimal point with
respect to the left or right side of the output field. Considering
example 3), we see from the following,
( Gforth 3) 3.14E0
( PFE 3) 3.142E+00
that Gforth's output is consistent with the stated meaning of
PRECISION in the Forth-94 spec.
One further clarification which needs to be made is with regard to the
term, "significant digits". I take the meaning in the scientific
sense, explained below, but I believe this meaning is consistent with
the way the term is used in computing.
Reference [1] states the following about the term, "significant
figures" (taken to be equivalent to significant digits):
" The number of significant figures in a result is defined as follows:
1. The leftmost nonzero digit is the most significant digit.
2. If there is no decimal point, the rightmost nonzero digit is the
least significant digit.
3. If there is a decimal point, the rightmost digit is the least
significant digit, even if it is a 0.
4. All digits between the least and most significant digits are
counted as significant digits.
For example, the following numbers each have four significant digits:
1,234; 123,400; 123.4; 1,001; 1,000.; 10.10; 0.0001010; 100.0."
[1] P.R. Bevington, "Data Reduction and Error Analysis for the
Physical Sciences", 1969, McGraw-Hill.
Krishna
Anton Ertl
>For C and Fortran users, generating it would be trivial.
Show me the code.
>Today's
>crop of forth compilers would find it all but impossible.
Let's see:
>Output numbers to 5 decimal places
> -1.23457e-08 -0.00000
> -1.23457e+00 -1.23457
> -9.00000e-01 -0.90000
> -4.00000e-01 -0.40000
> -NAN -NAN
> +INF +INF
-1.234570E-8 -1.23E-8
-1.2345700E0 -1.23457
-9.000000E-1 -0.90000
-4.000000E-1 -0.40000
-nan -nan
inf inf
Not exactly what you asked for, but it's certainly useful for tables.
The code is:
: foo ( r -- )
cr 8 spaces
fdup
12 5 13 f.rdp
10 spaces
8 5 0 f.rdp ;
-1.23457e-8 foo
-1.23457e foo
-9e-1 foo
-4e-1 foo
-0e 0e f/ foo
1e 0e f/ foo
Anton Ertl
>On Feb 3, 5:23=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
>> >Also, F. will work with PRECISION , but the question is how should it
>> >work? Apparently there is no consensus on this issue,
>>
>> Why do you think so?
>>
>
>My statement that there appears to be no consensus on how F. and
>PRECISION work together is based on the output from different Forth
>systems
That just shows that there are a lot of buggy systems, not that there
is no consensus. The large number of buggy systems indicates that
hardly anybody cares about the correct implementation of the
specification.
>Let us first note that the F. spec. in DPANS94 says,
>
>"Display, with a trailing space, the top number on the floating-point
>stack using fixed-point notation:"
>
>The term, "fixed point notation", implies (to me) that the decimal
>point is at a fixed position in the output.
As you then explain, this interpretation is inconsistent with other
requirements, which are less open to interpretation. So I conclude
that this interpretation is incorrect.
>Now, let's consider the example 1) and 2) output from Gforth:
>
>( Gforth 1) 0.000000000000000000000000000000911
>( Gforth 2) 1000.
>
>The Gforth output for example 1) is consistent with the notion that
>PRECISION represents the number of significant digits --- there are 3
>significant digits in the output. However, the decimal point position
>is not at a fixed position, either from the left side or the right
>side of the output field. So the two requirements, fixed number of
>significant digits, and fixed decimal point position, are
>incompatible. Also, the Gforth output for example 2) has, by
>convention, 4 significant digits.
No, it has only 3 significant digits. This is not obvious with your
input, but try
3 set-precision
1234.567e f.
which produces the output "1230.", and then look up the "123,400"
example you cited.
Some people may wish for better formatting control for FP output. The
way to get there is to define words for this purpose. Gforth has
F.RDP; maybe other Forth systems have words for that, too. F. does
not appear to be useful for that, and apparently people don't care
much (as shown by the buggy implementations).
Krishna Myneni
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >On Feb 3, 5:23=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >> >Also, F. will work with PRECISION , but the question is how should it
> >> >work? Apparently there is no consensus on this issue,
>
> >> Why do you think so?
>
> >My statement that there appears to be no consensus on how F. and
> >PRECISION work together is based on the output from different Forth
> >systems
>
> That just shows that there are a lot of buggy systems, not that there
> is no consensus. The large number of buggy systems indicates that
> hardly anybody cares about the correct implementation of the
> specification.
>
> >Let us first note that the F. spec. in DPANS94 says,
>
> >"Display, with a trailing space, the top number on the floating-point
> >stack using fixed-point notation:"
>
> >The term, "fixed point notation", implies (to me) that the decimal
> >point is at a fixed position in the output.
>
> As you then explain, this interpretation is inconsistent with other
> requirements, which are less open to interpretation. So I conclude
> that this interpretation is incorrect.
>
I think we agree on the following facts:
1. The term, "fixed point notation", is not defined in the DPANS94
specification of F. , nor is it defined in section 2.1, "Definition of
Terms".
2. Certain interpretation(s) of "fixed point notation", including the
one I suggested earlier, are mutually exclusive with the implicit
requirement that PRECISION (see specification for PRECISION) specify
the number of significant digits to be output by F. .
Based on these facts, we may conclude that the DPANS94 spec. for F. is
too vague to ensure uniform behavior across Forth-94 systems. This
vagueness has led to a number of system implementers ignoring the
significant digits requirement in favor of their understanding of the
term, "fixed point notation", which could well be the common
understanding. I would not reach the conclusion that these systems are
buggy, but that the specification is sufficiently flawed to lead to
non-compliant F. implementations. With respect to FS. , however, there
is no wiggle room in interpretation with the present standard.
> >Now, let's consider the example 1) and 2) output from Gforth:
>
> >( Gforth 1) 0.000000000000000000000000000000911
> >( Gforth 2) 1000.
>
> >The Gforth output for example 1) is consistent with the notion that
> >PRECISION represents the number of significant digits --- there are 3
> >significant digits in the output. However, the decimal point position
> >is not at a fixed position, either from the left side or the right
> >side of the output field. So the two requirements, fixed number of
> >significant digits, and fixed decimal point position, are
> >incompatible. Also, the Gforth output for example 2) has, by
> >convention, 4 significant digits.
>
> No, it has only 3 significant digits. This is not obvious with your
> input, but try
>
> 3 set-precision
> 1234.567e f.
>
> which produces the output "1230.", and then look up the "123,400"
> example you cited.
>
The F. output of Gforth is not compliant with the significant digits
requirement. Note the trailing decimal point present in the output,
and refer to rule 3) for significant figures in my earlier message:
3. If there is a decimal point, the rightmost digit is the least
significant digit, even if it is a 0.
Therefore, the output "1000." has 4 significant digits, not 3.
Likewise,
3 set-precision ok
1234.567e f. 1230. ok
the output has 4 significant digits. Gforth cannot claim compliance
with DPANS94 specs for PRECISION and F. either.
> Some people may wish for better formatting control for FP output. The
> way to get there is to define words for this purpose. Gforth has
> F.RDP; maybe other Forth systems have words for that, too. F. does
> not appear to be useful for that, and apparently people don't care
> much (as shown by the buggy implementations).
>
I agree that other words, e.g. fixed field width output words, are
needed for better formatting control of FP output. Also, I'm not
arguing for removing the significant digits output requirement for F.
in the current spec. --- in fact this is a very useful type of output
to have, when implemented correctly. However, the spec needs to be
free of ambiguity, so that common behavior for F. becomes possible. I
see this as a pre-requisite for adding words with better format
control.
Krishna
Krishna Myneni
> ... Also, I'm not
> arguing for removing the significant digits output requirement for F.
> in the current spec. --- in fact this is a very useful type of output
> to have, when implemented correctly. ...
Actually, if we agree that the term "fixed point notation" means that
there is no exponent field in the output, then there is no possible
way to reconcile the DPANS94 specs for F. and PRECISION.
Consider the number 1201e0 to be output in fixed point notation to a
PRECISION of 3. There is no way to represent 1.20e3 in fixed point to
unambiguously indicate 3 significant digits. This is why scientific
notation is used when it is important to display the number of
significant digits unambiguously. The behavior of PFE's F. is quite
reasonable in treating PRECISION as something other than the number of
significant digits to be output.
The specification for PRECISION likely needs to be rethought.
Krishna
Krishna Myneni
There seem to be several non-standard words in this code. What do your
F. and FS. implementations give as output for my examples?
Krishna
Anton Ertl
>On Feb 3, 7:36=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
>> >Also, the Gforth output for example 2) has, by
>> >convention, 4 significant digits.
>>
>> input, but try
>>
>> 3 set-precision
>> 1234.567e f.
>>
>> which produces the output "1230.", and then look up the "123,400"
>> example you cited.
>>
>
>The F. output of Gforth is not compliant with the significant digits
>requirement. Note the trailing decimal point present in the output,
>and refer to rule 3) for significant figures in my earlier message:
>
>3. If there is a decimal point, the rightmost digit is the least
>significant digit, even if it is a 0.
>
>Therefore, the output "1000." has 4 significant digits, not 3.
The decimal point is a requirement of "F.".
<http://en.wikipedia.org/wiki/Significant_digit> says:
| * The significance of trailing zeros in a number not containing a
| decimal point can be ambiguous.[...]
|
| * A decimal point may be placed after the number; for example
| "100." indicates specifically that three significant digits
| are meant.[1]
|
|However, these conventions are not universally used,
Gforth puts the decimal point there to comply with the requirements of
the specification, not to comply with the conventions of a book that
the authors of Gforth had never heard of. Gforth does not include a
way to indicate the number of significant digits, and I don't see a
standard-compliant way to indicate them.
A more serious issue in this respect is shown by the example
3 set-precision 1e f.
Here there would be a way to indicate the number of significant
digits: print "1.00". However, Gforth does not use it. And I think
that this is the approach that most users prefer, because with the
default precision of 15 they would see lots of trailing zeroes
otherwise.
>Also, I'm not
>arguing for removing the significant digits output requirement for F.
>in the current spec. --- in fact this is a very useful type of output
>to have, when implemented correctly.
What would be a correct implementation, IYO?
I don't think it is useful for F., though, and the wild divergence in
implementations indicate that hardly anybody cares about the exact
format that F. produces.
Also, I think that SET-PRECISION is a horrible interface for this kind
of functionality.
> However, the spec needs to be
>free of ambiguity, so that common behavior for F. becomes possible.
Sure, one can nail it down further. But given that hardly anybody
seems to care, I doubt it would be useful.
>I
>see this as a pre-requisite for adding words with better format
>control.
I don't. Even if the F. spec is weakened to allow all the current
implementations, it will be just as useful as it is now: as a word for
casual use (e.g., in debugging), not for nicely formatted reports.
And if we introduce other words (like F.RDP), they work independently
of F., so whether F. is tightened or weakened does not affect them at
all, and F. is certainly no prerequisite for them.
- anton
David N. Williams
http://tinyurl.com/EffectOfSet-Precision-clf
-- David
Krishna Myneni
Thanks for the link showing past discussion of the issue with
significant digits, PRECISION, and F. . I can't say if the present
thread adds some clarity to the issue, or further muddies the water.
Krishna
Charles G Montgomery
Also in the historical context:
I seem to recall an extended period when gforth's REPRESENT was badly
broken, as I understood it because it relied on a buggy piece of the C
library that nobody wanted to mess with. Eventually things improved.
I disagree with Anton's interpretation that "hardly anybody seems to
care". My interpretation is that those who cared, in the face of the
unclear standard and the wild variety of views, just threw up their hands
and found their own workarounds. I agree with Anton's view that the
solution is to be found in creating new words which do what is wanted.
There are a number of useful examples to be found.
I do think it would be good to have a clearer specification of the
nominally-standard F. and its cousins. Adding some useful words to
Forth200x would be nice, but the history may make it infeasible to find
something that there is agreement about.
regards to all cgm
Krishna Myneni
I assume the authors of Gforth are capable of verifying from
independently authoritative sources what are the conventionally
accepted rules concerning representation of significant digits.
If a specification has contradictory requirements, such as placing the
decimal point at the end, but still providing a representation of
significant digits, one should not claim compliance.
> Gforth does not include a
> way to indicate the number of significant digits, and I don't see a
> standard-compliant way to indicate them.
>
As you point out above, there is no way to be compliant with *all* of
the requirements. If the requirement to insert the decimal point is
dropped, one could, in principle, indicate the number of significant
digits in the fixed point output using some delimiter character.
However, doing so would probably lead to adverse side effects, such as
downstream processing of the output.
> A more serious issue in this respect is shown by the example
>
> 3 set-precision 1e f.
>
> Here there would be a way to indicate the number of significant
> digits: print "1.00". ...
Yes, that would be correct (even though you claimed not to accept the
stated convention in a book of which you never heard).
> However, Gforth does not use it. And I think
> that this is the approach that most users prefer, because with the
> default precision of 15 they would see lots of trailing zeroes
> otherwise.
Which users? The same ones who don't know or care about significant
digits?
>
> >Also, I'm not
> >arguing for removing the significant digits output requirement for F.
> >in the current spec. --- in fact this is a very useful type of output
> >to have, when implemented correctly.
>
> What would be a correct implementation, IYO?
>
As far as how PRECISION and F. are to interact, I think it's not
possible to do a clean specification where PRECISION determines the
number of significant digits (unless one is willing to accept the
introduction of a delimiter character in the output). I think some
sort of consensus has to be reached in discussion about the desired
behavior of F. and its use of the value in PRECISION.
As for PRECISION and FS. and FE. , there is no known problem, so I
don't suggest any changes to the specification.
> I don't think it is useful for F., though, and the wild divergence in
> implementations indicate that hardly anybody cares about the exact
> format that F. produces.
>
Still, a specification which seems to have been premised on a
misunderstanding of the term, "significant digits", and possibly only
a vague notion of the term, "fixed point notation", is a candidate for
clarification when the opportunity arises.
> Also, I think that SET-PRECISION is a horrible interface for this kind
> of functionality.
>
I notice that the value of PRECISION can be set using TO in a couple
of Forth systems. This appears to be a non-standard feature, but could
be made standard, eliminating the need for SET-PRECISION. Whether or
not it is desirable to do this needs discussion.
> > However, the spec needs to be
> >free of ambiguity, so that common behavior for F. becomes possible.
>
> Sure, one can nail it down further. But given that hardly anybody
> seems to care, I doubt it would be useful.
>
> >I
> >see this as a pre-requisite for adding words with better format
> >control.
>
> I don't. ...
Perhaps not. Words with better format control can probably be
specified fully independently. However, the opportunity exists to fix
any issues with PRECISION so that it could be used in the context of
any new output words.
> ... Even if the F. spec is weakened to allow all the current
> implementations, it will be just as useful as it is now: as a word for
> casual use (e.g., in debugging), not for nicely formatted reports.
> ...
And a word for casual use is quite useful! But, that doesn't mean its
specification should be self-contradicting.
Krishna
Ed
> "Ed" <nos...@invalid.com> writes:
> >For C and Fortran users, generating it would be trivial.
>
> Show me the code.
I assume most here know how to format a number in
other languages e.g.
printf("\n%20.5e%20.5f",a,a);
printf("\n%20.0e%20.0f",a,a);
> >Today's
> >crop of forth compilers would find it all but impossible.
>
> Let's see:
>
> >Output numbers to 5 decimal places
> > -1.23457e-08 -0.00000
> > -1.23457e+00 -1.23457
> > -9.00000e-01 -0.90000
> > -4.00000e-01 -0.40000
> > -NAN -NAN
> > +INF +INF
>
> -1.234570E-8 -1.23E-8
> -1.2345700E0 -1.23457
> -9.000000E-1 -0.90000
> -4.000000E-1 -0.40000
> -nan -nan
> inf inf
>
> Not exactly what you asked for, but it's certainly useful for tables.
A writer of spreadsheet and other serious apps might disagree.
Ed
That realm appears to be confined to c.l.f. :)
Anton Ertl
>Anton Ertl wrote:
>> "Ed" <nos...@invalid.com> writes:
>> >For C and Fortran users, generating it would be trivial.
>>
>> Show me the code.
>
>I assume most here know how to format a number in
>other languages e.g.
>
> printf("\n%20.5e%20.5f",a,a);
> printf("\n%20.0e%20.0f",a,a);
Works brilliantly for, e.g., a=-234567e120.
Anton Ertl
>On Feb 4, 9:20=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)>> >On Feb 3, 7:36=3DA0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)>> <http://en.wikipedia.org/wiki/Significant_digit> says:
[Conventions for indicating the number of significant digits elided]
>> |However, these conventions are not universally used,
>>
>> Gforth puts the decimal point there to comply with the requirements of
>> the specification, not to comply with the conventions of a book that
>> the authors of Gforth had never heard of. ...
>
>I assume the authors of Gforth are capable of verifying from
>independently authoritative sources what are the conventionally
>accepted rules concerning representation of significant digits.
Yes, and it says that the conventions are not universally used.
>If a specification has contradictory requirements, such as placing the
>decimal point at the end, but still providing a representation of
>significant digits, one should not claim compliance.
I interpret the specification as requiring the decimal point and also
requiring printing as many significant digits as shown by PRECISION,
but I don't see it as requiring following any conventions for showing
the number of significant digits.
>> However, Gforth does not use it. =A0And I think
>> that this is the approach that most users prefer, because with the
>> default precision of 15 they would see lots of trailing zeroes
>> otherwise.
>
>Which users? The same ones who don't know or care about significant
>digits?
Yes. I believe that most users don't use SET-PRECISION and use
F. just as a way to print FP numbers in an arbitrary, but convenient
format. Actually F. fails in that because it does not switch to
scientific notation when that would be convenient; but I guess it
works well enough in the usual cases.
>> Also, I think that SET-PRECISION is a horrible interface for this kind
>> of functionality.
>>
>
>I notice that the value of PRECISION can be set using TO in a couple
>of Forth systems. This appears to be a non-standard feature, but could
>be made standard, eliminating the need for SET-PRECISION. Whether or
>not it is desirable to do this needs discussion.
The problem with SET-PRECISION is not SET-PRECISION, but the use of
global state to pass a parameter to F. FS. FE. I think the right
solution in this case is to pass the parameter directly (used in e.g.,
F.RDP).
Krishna Myneni
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >On Feb 4, 9:20=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >> >On Feb 3, 7:36=3DA0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >> >wrote:
> >> >> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >> <http://en.wikipedia.org/wiki/Significant_digit> says:
>
> [Conventions for indicating the number of significant digits elided]
>
> >> |However, these conventions are not universally used,
>
> >> Gforth puts the decimal point there to comply with the requirements of
> >> the specification, not to comply with the conventions of a book that
> >> the authors of Gforth had never heard of. ...
>
> >I assume the authors of Gforth are capable of verifying from
> >independently authoritative sources what are the conventionally
> >accepted rules concerning representation of significant digits.
>
> Yes, and it says that the conventions are not universally used.
>
Universal Conventional <>
> >If a specification has contradictory requirements, such as placing the
> >decimal point at the end, but still providing a representation of
> >significant digits, one should not claim compliance.
>
> I interpret the specification as requiring the decimal point and also
> requiring printing as many significant digits as shown by PRECISION,
> but I don't see it as requiring following any conventions for showing
> the number of significant digits.
>
Ok. If we relax the significant digits rule on the trailing decimal
point, then at best, the output is ambiguous with respect to
significant digits. That's fine, and the spec for F. should state as
much. But, I think there's a better solution, given below.
> >> However, Gforth does not use it. =A0And I think
> >> that this is the approach that most users prefer, because with the
> >> default precision of 15 they would see lots of trailing zeroes
> >> otherwise.
>
> >Which users? The same ones who don't know or care about significant
> >digits?
>
> Yes. I believe that most users don't use SET-PRECISION and use
> F. just as a way to print FP numbers in an arbitrary, but convenient
> format. Actually F. fails in that because it does not switch to
> scientific notation when that would be convenient; but I guess it
> works well enough in the usual cases.
>
Of course, this is how I use F. personally, as a convenient way to
display fp numbers. In kForth, F. does switch to scientific notation
automatically. I had thought to revise the behavior of F. to comply
more tightly with the Forth-94 spec, and link it to PRECISION, but now
I think I will leave the behavior of F. intact, since it is much more
useful to me with its present behavior.
One reasonable solution to the problems in the Forth-94 specs for
PRECISION and F. would be to do the following:
1) remove the explicit connection between PRECISION and F. . That is,
the value of PRECISION determines the number of significant digits for
FS. and FE. , but no mention of F. is made in the spec for PRECISION.
2) The spec. for F. permits it to be an implementation defined output
word for floating point numbers. It may or may not use PRECISION to
determine the output format, and it is not restricted to use "fixed
point notation", i.e. it can switch from fixed point to scientific
notation, as is deemed convenient by the implementation.
> >> Also, I think that SET-PRECISION is a horrible interface for this kind
> >> of functionality.
>
> >I notice that the value of PRECISION can be set using TO in a couple
> >of Forth systems. This appears to be a non-standard feature, but could
> >be made standard, eliminating the need for SET-PRECISION. Whether or
> >not it is desirable to do this needs discussion.
>
> The problem with SET-PRECISION is not SET-PRECISION, but the use of
> global state to pass a parameter to F. FS. FE. ...
It's a user convenience issue. In an interactive environment, one does
not want to pass additional parameter(s) every time an fp number needs
to be output. The use of SET-PRECISION facilitates interactive use.
> ... I think the right
> solution in this case is to pass the parameter directly (used in e.g.,
> F.RDP).
>
Formatted output words are not as likely to be used interactively, so
passing parameters is fine for cases such as F.RDP.
Krishna
Ed
> >I assume most here know how to format a number in
> >other languages e.g.
> >
> > printf("\n%20.5e%20.5f",a,a);
> > printf("\n%20.0e%20.0f",a,a);
>
> Works brilliantly for, e.g., a=-234567e120.
It does.
When used appropriately %f can be relied upon to do what it says.
It has always been the responsibility of the programmer to select
and use functions responsibly within the limits of the application
and system.
But let's not worry about contrived situations and how individual
C compilers might handle it. Until such time as Forth floating-point
output can match C in basic functionality, it has little to crow about.
Andrew Haley
> Until such time as Forth floating-point output can match C in basic
> functionality, it has little to crow about.
This makes no sense: Forth is not in some kind of competition to match
C feature-for-feature. If you want C, use C. The Forth flating-point
wordset is much smaller than that of C and that's a feature, not a
bug.
Andrew.
Marcel Hendrix
> Anton Ertl wrote:
>> "Ed" <nos...@invalid.com> writes:
>> >For C and Fortran users, generating it would be trivial.
>> Show me the code.
> I assume most here know how to format a number in
> other languages e.g.
> printf("\n%20.5e%20.5f",a,a);
> printf("\n%20.0e%20.0f",a,a);
[..]
Well, that's only two lines of code with a modern Forth.
-- -------8<--------------------------------------------------------------------
NEEDS -dynlibs WINDOWS? [IF] Library: msvcrt.dll [ELSE] Library: libm.so [THEN]
Extern: int sprintf ( char *buffer, char *spec, double fval1, double fval2 );
: 1LINE5 ( F: r -- ) pad dup S\" %20.5e%20.5f" DROP fdup sprintf CR TYPE ;
-1.23457e-08 1LINE5
-1.23457e+00 1LINE5
-9.00000e-01 1LINE5
-4.00000e-01 1LINE5
-NAN 1LINE5
+INF 1LINE5
: 1LINE0 ( F: r -- ) pad dup S\" %20.0e%20.0f" DROP fdup sprintf CR TYPE ;
-1.23457e-08 1LINE0
-1.23457e+00 1LINE0
-9.00000e-01 1LINE0
-4.00000e-01 1LINE0
-NAN 1LINE0
+INF 1LINE0
-- -------8<--------------------------------------------------------------------
\ Windows output
-1.23457e-008 -0.00000
-1.23457e+000 -1.23457
-9.00000e-001 -0.90000
-4.00000e-001 -0.40000
-1.#IND0e+000 -1.#IND0
1.#INF0e+000 1.#INF0
-1e-008 -0
-1e+000 -1
-9e-001 -1
-4e-001 -0
-1e+000 -1
1e+000 1 ok
\ Linux output
-1.23457e-08 -0.00000
-1.23457e+00 -1.23457
-9.00000e-01 -0.90000
-4.00000e-01 -0.40000
nan nan
inf inf
-1e-08 -0
-1e+00 -1
-9e-01 -1
-4e-01 -0
nan nan
inf inf ok
However, the two C compilers I used disagree about the correct output,
and the one approximately right suppresses the sign.
That will not please the average spreadsheet writer.
-marcel
Krishna Myneni
wrote:
Ed's point is valid. He chose not to make it in a constructive way,
probably given the ill-mannered responses often seen in c.l.f.
The Forth floating point word set is too sparse, a point which you
yourself made earlier, I believe. It's not unreasonable to expect
basic floating point output formatting words as a standard part of the
language. User's should not be required to write such a layer for such
minimum functionality.
OTOH, someone is likely to suggest that since this problem has already
been solved in other languages, we should just standardize an external
library interface, and use a library call, say to printf, to output a
nicely formatted fp number!
Krishna
doc
programming for minimal functionality, and standardization.
Sparse yes, and perhaps as pointed out, deliberately so.
"nicely formatted fp number", IMHO, depends entirely on
the context of the application for which the format is
"nice" - or better still "appropriate".
The F94 specification - while perhaps worded ambiguously
or incompletely - is a perfectly reasonable set of base
functionality from which an application is free to
construct more specific and useful words that are
germane to the application.
To wit: I don't believe any group of folks
working in a standards environment would likely
agree that an FP zero should be output as 0.
irrespective of F. FS. FE. or the value of PRECISION ,
but I've worked on myriad matrix manipulation and
display applications where it is far 'easier on the
eye' (humans are much better at noticing anomalies
in patterns than they are at absorbing and assimilating
the meaning of a plethora of similarly formatted
columnar numbers) to find/ignore the zeros when
they appear this way.
Another example: in those same matrix applications
it was far more useful to create a non-standard
word for FP output, perhaps not unlike GForth's
F.RDP - I named it FP. - which is a deferred word
whose xt can be manipulated interactively in terms of
words that use F. FS. FE. and/or PRECISION. The
application is written to use FP. The user interface
permits the fp display to be altered without having to
reload the application. I don't hold much hope that
a construct like this is likely to be standardized either.
However, with the current F94 basis words, it is possible.
At some point "standardization" for the sake of
standardization, outside the context of a set
of requirements for a specific problem or
solution space, reduces to an interesting endeavor
whose effort may not justify the value of the
result. I question if this discussion is nearing
such a threshold.
FWIW,
doc
Krishna Myneni
> RE: Sparse set of words, basic functionality, user
> programming for minimal functionality, and standardization.
>
> Sparse yes, and perhaps as pointed out, deliberately so.
>
> "nicely formatted fp number", IMHO, depends entirely on
> the context of the application for which the format is
> "nice" - or better still "appropriate".
>
Sure, the appropriate format may be application dependent. But, isn't
there a common factor at the heart of such application specific words?
For example, a fixed field width, fixed number of decimal places,
fixed point output word. This would take two arguments: the field
width, and the number of decimal places. Applications which need fixed
point output can use this base word for their specific needs.
> The F94 specification - while perhaps worded ambiguously
> or incompletely - is a perfectly reasonable set of base
> functionality from which an application is free to
> construct more specific and useful words that are
> germane to the application.
>
Given the wildly variant implementations of F. , I don't consider the
specification for F. to be "reasonable". IMO, the spec either needs to
be free of ambiguity, or should declare F. 's behavior to be
implementation defined.
> To wit: I don't believe any group of folks
> working in a standards environment would likely
> agree that an FP zero should be output as 0.
> irrespective of F. FS. FE. or the value of PRECISION ,
> but I've worked on myriad matrix manipulation and
> display applications where it is far 'easier on the
> eye' (humans are much better at noticing anomalies
> in patterns than they are at absorbing and assimilating
> the meaning of a plethora of similarly formatted
> columnar numbers) to find/ignore the zeros when
> they appear this way.
>
For interactive use, one typically needs a word that produces
convenient, easy to read output, without having to set associated
parameters such as PRECISION. C and C++ provide such capability with
their default formatting (%f and %lf) when field width and number of
decimal places are not specified, automatically switching between
fixed point and scientific notation as appropriate.
> Another example: in those same matrix applications
> it was far more useful to create a non-standard
> word for FP output, perhaps not unlike GForth's
> F.RDP - I named it FP. - which is a deferred word
> whose xt can be manipulated interactively in terms of
> words that use F. FS. FE. and/or PRECISION. The
> application is written to use FP. The user interface
> permits the fp display to be altered without having to
> reload the application. I don't hold much hope that
> a construct like this is likely to be standardized either.
> However, with the current F94 basis words, it is possible.
>
Yes, presuming F. had reasonable and consistent behavior.
> At some point "standardization" for the sake of
> standardization, outside the context of a set
> of requirements for a specific problem or
> solution space, reduces to an interesting endeavor
> whose effort may not justify the value of the
> result. I question if this discussion is nearing
> such a threshold.
>
It's usually an iterative process to get it right.
> FWIW,
> doc
Krishna
doc
I agree with you on the actual (lack of) utility of
F. as presently specified. I think your response raises
three issues for folks to weigh in on:
A) Should F. be qualified further than F94 to state
that its behavior is implementation defined?
IMHO: yes as F. appears from this thread, to be
implemented so disparately.
B) Should some sort of ".R" analogous word for FP
output, beyond FE. and FS. , be considered for
standardization?
IMHO: unequivocally, yes ... but, if somebody familiar
with the F94 TC discussions knows technical reasons
why this didn't happen, I'd be interested in
having that recounted.
C) Should an automatic behavior exist, either in the F.
specification or in some new word, such that FE. or FS.
format is used when the default (F.) representation
exceeds some format specification (either precision or
the width of the field).
IMHO: I'd like to see it as my own implementations have
done this since 1979, but I believe (a) and (b) are of more
immediate concern.
Maybe an RfD for Forth200x could emerge?
FWIW,
doc
Andrew Haley
> On Feb 6, 2:58?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Ed <nos...@invalid.com> wrote:
>> > Until such time as Forth floating-point output can match C in basic
>> > functionality, it has little to crow about.
>>
>> This makes no sense: Forth is not in some kind of competition to match
>> C feature-for-feature. If you want C, use C. The Forth flating-point
>> wordset is much smaller than that of C and that's a feature, not a
>> bug.
>
> probably given the ill-mannered responses often seen in c.l.f.
>
> The Forth floating point word set is too sparse, a point which you
> yourself made earlier, I believe. It's not unreasonable to expect
> basic floating point output formatting words as a standard part of
> the language. User's should not be required to write such a layer
> for such minimum functionality.
So, let's have a library to do it, then. My point about floating-
point was rather different: standard Forth didn't have the tools to do
what I needed done, and there is no way to write them.
I'm sticking to my point: C's floating-point I/O is a monster, and and
matching it is not a sensible goal.
Andrew.
Krishna Myneni
I concur. The statement A) implies that further restrictions are
placed on F. , when, in fact, I think we want to place fewer
restrictions on F. to take into account existing practice. Other than
that, I agree with your answer for A. In time, the standard could
evolve to require certain behavior for F. .
For B) I also agree with you. With regard to C) , if A) was
implemented, it gives implementers the freedom to provide such default
behavior for F. . In time, if it becomes common practice for F. to be
similar to/equivalent of C's default "%f" or "%lf" format, then it can
be codified as such.
Krishna
Ed
> ...
> It's not unreasonable to expect
> basic floating point output formatting words as a standard part of the
> language. User's should not be required to write such a layer for such
> minimum functionality.
>
> OTOH, someone is likely to suggest that since this problem has already
> been solved in other languages, we should just standardize an external
> library interface, and use a library call, say to printf, to output a
> nicely formatted fp number!
Not every target can rely on the availability of an external library from
which to obtain its functions. Nor should such extremes be necessary.
For myself, the layer of words of which you speak already exist in the
form of the FPOUT package. It is useful and sufficient - a synthesis
of the C and Fortran output functions expressed as 15 non-overlapping
words and controls in what must be the smallest possible code.
Importantly the functions do what they say, free from unwanted
side-effects.
As for ANS compliance I believe usefulness comes first. There is
little point complying with a function spec that is confused or covers
ground better handled by another function. Having said that, I might
argue FPOUT functions FS. FE. are ANS compliant - it depends
how one chooses to interpret "used by" in PRECISION. I chose an
interpretation that avoided duplication with other functions in the
package. FPOUT's F. differs from the ANS spec in that it is
"floating-point". The "fixed-point" functions are better handled by
F.R FS.R etc. as they print right-justified.
The sample output I posted earlier was deliberately chosen. Its intent
to exercise those areas where an inferior output function or primitive
might fail - shortcomings such as dropping to exponent form, or NAN/
INF truncation, when it should not.
Andso finally, the test ...
Forth version
Scientific Fixed-point
Output numbers to 5 decimal places
-1.23457E-008 -0.00000
-1.23457E+000 -1.23457
-9.00000E-001 -0.90000
-4.00000E-001 -0.40000
-NAN -NAN
+INF +INF
-2.34567E+125-234567000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000.00000
Same numbers at 0 decimal places
-1E-008 -0
-1E+000 -1
-9E-001 -1
-4E-001 -0
-NAN -NAN
+INF +INF
-2E+125-234567000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000
---
forth definitions decimal
include FPOUT.F
: init ( -- )
\ dos-io ( allow MS-DOS redirection)
\ 500 sys-vec 26 + ! ( increase numeric output buffer size)
\ signed-zero on ( allow negative-zero display)
\ FPOUT options
0 fdp ! ( disable trailing decimal points)
3 fedigits ! ( set number of exponent digits)
;
init
-1.234567E-8 fconstant a
-1.234567E0 fconstant b
-0.9e0 fconstant c
-0.4e0 fconstant d
0e0 0e0 f/ fconstant e
1e0 0e0 f/ fconstant f
-234567e120 fconstant x ( anton's number)
: FTEST ( -- )
cr cr ." Forth version"
cr cr ." Scientific Fixed-point"
cr cr ." Output numbers to 5 decimal places"
cr a 5 20 fs.r a 5 20 f.r
cr b 5 20 fs.r b 5 20 f.r
cr c 5 20 fs.r c 5 20 f.r
cr d 5 20 fs.r d 5 20 f.r
cr e 5 20 fs.r e 5 20 f.r
cr f 5 20 fs.r f 5 20 f.r
cr x 5 20 fs.r x 5 20 f.r
cr cr ." Same numbers at 0 decimal places"
cr a 0 20 fs.r a 0 20 f.r
cr b 0 20 fs.r b 0 20 f.r
cr c 0 20 fs.r c 0 20 f.r
cr d 0 20 fs.r d 0 20 f.r
cr e 0 20 fs.r e 0 20 f.r
cr f 0 20 fs.r f 0 20 f.r
cr x 0 20 fs.r x 0 20 f.r
;
ftest
---
Anton Ertl
>On Feb 5, 5:09=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Yes. =A0I believe that most users don't use SET-PRECISION and use
>> F. just as a way to print FP numbers in an arbitrary, but convenient
>> scientific notation when that would be convenient; but I guess it
>> works well enough in the usual cases.
>>
>
>Of course, this is how I use F. personally, as a convenient way to
>display fp numbers. In kForth, F. does switch to scientific notation
>automatically. I had thought to revise the behavior of F. to comply
>more tightly with the Forth-94 spec, and link it to PRECISION, but now
>I think I will leave the behavior of F. intact, since it is much more
>useful to me with its present behavior.
>
>One reasonable solution to the problems in the Forth-94 specs for
>PRECISION and F. would be to do the following:
>
>1) remove the explicit connection between PRECISION and F. . That is,
>the value of PRECISION determines the number of significant digits for
>FS. and FE. , but no mention of F. is made in the spec for PRECISION.
Yes.
>2) The spec. for F. permits it to be an implementation defined output
>word for floating point numbers. It may or may not use PRECISION to
>determine the output format, and it is not restricted to use "fixed
>point notation", i.e. it can switch from fixed point to scientific
>notation, as is deemed convenient by the implementation.
Yes, something like that (except that I am not very fond of
"implementation-defined").
>> The problem with SET-PRECISION is not SET-PRECISION, but the use of
>> global state to pass a parameter to F. FS. FE. =A0...
>
>It's a user convenience issue. In an interactive environment, one does
>not want to pass additional parameter(s) every time an fp number needs
>to be output. The use of SET-PRECISION facilitates interactive use.
In interactive use, one usually does not need a specific output
format, and will usually be content with the output produced by a
generic FP output word. I believe that most current FP output in
interactive work just uses F. without setting the precision. And that
that would continue to be the case after your suggested change to
"F.".
For those few cases where a particular format is desired, more
specific words with explicit parameters can be used.
Compare the situation to integers: Interactively we use "." in most
cases, and for the cases where we want a specific format, we have .R
with an explicit parameter (instead of passing the width through a
global). That's the way to go.
Anton Ertl
Let's see. I just tested with OpenOffice, using the default display format:
Output Input
-1.23E-008 -1.23457e-8
-1.23E+000 -1.23457e0
-1.23 -1.23457
-9.00E-001 -0.9e0
#DIV/0! =-0/0
#DIV/0! =1/0
-2.35E+125 -234567e120
0 -0.00000123
### 123333333333333
Anton Ertl
>Anton Ertl wrote:
>> "Ed" <nos...@invalid.com> writes:
>> > ...
>> >I assume most here know how to format a number in
>> >other languages e.g.
>> >
>> > printf("\n%20.5e%20.5f",a,a);
>> > printf("\n%20.0e%20.0f",a,a);
>>
>> Works brilliantly for, e.g., a=-234567e120.
>
>It does.
>
>When used appropriately %f can be relied upon to do what it says.
>It has always been the responsibility of the programmer to select
>and use functions responsibly within the limits of the application
>and system.
That can be said about F.RDP and even about F. FS. FE. as implemented
in Gforth as well. You just proved that you can select numbers and
format strings such that C's FP output looks ok. That says nothing
about the relative merits of C's and Forth's FP output capabilities in
general.
Anton Ertl
>The F94 specification - while perhaps worded ambiguously
>or incompletely - is a perfectly reasonable set of base
>functionality from which an application is free to
>construct more specific and useful words that are
>germane to the application.
No. As Ed has pointed out, there are certain things one cannot do
well with REPRESENT. His solution (replace REPRESENT with a word that
behaves differently, breaks existing code, and induces buffer overflow
vulnerabilities) is bad, but the problem exists.
If we look at where REPRESENT is coming from, it's pretty clearly
inspired by C's evct(). Now C also has a function called fcvt(),
which provides the functionality that Ed missed; so maybe we should
provide a word that relates to fcvt() in the way that REPRESENT
relates to ecvt(). Or maybe we should do something completely
different; ecvt() and fcvt() are deprecated in C in favor of sprintf,
so maybe we should not be following down this path.
One other problem with REPRESENT is that it cannot provide shorter or
longer output strings than the given buffer, whereas ecvt() can.
Krishna Myneni
wrote:
For the sake of reviewing all options, there is one other that may be
appealing. This is to simply delete the "fixed point notation" output
requirement in the spec for F. , while keeping the link between F. and
PRECISION. Then, F. can display the number of significant digits
specified by PRECISION and use scientific notation when output in
fixed point cannot be accomplished.
> >> The problem with SET-PRECISION is not SET-PRECISION, but the use of
> >> global state to pass a parameter to F. FS. FE. =A0...
>
> >It's a user convenience issue. In an interactive environment, one does
> >not want to pass additional parameter(s) every time an fp number needs
> >to be output. The use of SET-PRECISION facilitates interactive use.
>
> In interactive use, one usually does not need a specific output
> format, and will usually be content with the output produced by a
> generic FP output word. I believe that most current FP output in
> interactive work just uses F. without setting the precision. And that
> that would continue to be the case after your suggested change to
> "F.".
>
> For those few cases where a particular format is desired, more
> specific words with explicit parameters can be used.
>
> Compare the situation to integers: Interactively we use "." in most
> cases, and for the cases where we want a specific format, we have .R
> with an explicit parameter (instead of passing the width through a
> global). That's the way to go.
>
I agree for any F.xR type of words. But FS. and FE. are fine for
interactive use also. Recently, I used SET-PRECISION and FS. to
troubleshoot issues related to internal conversion of fp numbers. And
there are times when I want to see the result of a calculation to a
greater number of digits than provided by my F. . I don't see any
compelling reason to change the specd for FS. and FE. , and their
relation to PRECISION and SET-PRECISION. Would it be desirable to
state explicitly in the specs for FS. and FE. that they output the
number of significant digits specified by PRECISION, or is the spec.
for PRECISION sufficiently clear to indicate this? PFE's FS. outputs
one more than the number of significant digits. Other Forth systems
may also have this issue.
Krishna
Krishna Myneni
> For myself, the layer of words of which you speak already exist in the
> form of the FPOUT package. It is useful and sufficient - a synthesis
> of the C and Fortran output functions expressed as 15 non-overlapping
> words and controls in what must be the smallest possible code.
> Importantly the functions do what they say, free from unwanted
> side-effects.
>
I think FPOUT could be useful. Mostly, our discussion in this thread
is about cleaning up the spec for PRECISION and F. so that Forth
implementations can be more consistent and useful in what they output.
And possibly adding a useful fixed point formatting word to the
standard. Not much more than that. Most everything else could build
upon this base, as Andrew suggests, and you demonstrate, although
there are difficulties with what you have done.
> As for ANS compliance I believe usefulness comes first. There is
> little point complying with a function spec that is confused or covers
> ground better handled by another function. Having said that, I might
> argue FPOUT functions FS. FE. are ANS compliant - it depends
> how one chooses to interpret "used by" in PRECISION.
12.6.2.2035 PRECISION
FLOATING EXT
( -- u )
Return the number of significant digits currently used by F., FE., or
FS. as u.
The spec for PRECISION explicitly uses the term "significant digits",
not "number of decimal places". To interpret the words "used by" to
mean "add 1" is, IMO, an unwarranted distortion. I do not consider
your implementations of FS. and FE. to be ANS compliant.
Krishna
Krishna Myneni
> ...
> As for PRECISION and FS. and FE. , there is no known problem, so I
> don't suggest any changes to the specification.
> ...
Nuts! I hadn't looked at the spec for FE. closely enough until now,
and there is a problem with respect to significant digits. The spec
for FE. requires the significand, a, to be scaled such that its
absolute value, |a| is in the range 1.0 to 1000: 1 <= |a| < 1000
The scaling requirement makes it impossible for FE. to output the
correct number of significant digits specified by PRECISION, without
ambiguity, when PRECISION is less than 3.
I can think of two alternatives to deal with this:
1) Remove the scaling requirement for the significand, i.e. allow |a|
< 1.
2) Accept the ambiguity in significant digits for PRECISION < 3, and
revise the spec of FE. to warn of the ambiguity.
Krishna
Marcel Hendrix
> On Feb 4, 7:08 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
...
>> As for PRECISION and FS. and FE. , there is no known problem, so I
>> don't suggest any changes to the specification.
...
> Nuts! I hadn't looked at the spec for FE. closely enough until now,
> and there is a problem with respect to significant digits. The spec
> for FE. requires the significand, a, to be scaled such that its
> absolute value, |a| is in the range 1.0 to 1000: 1 <= |a| < 1000
> The scaling requirement makes it impossible for FE. to output the
> correct number of significant digits specified by PRECISION, without
> ambiguity, when PRECISION is less than 3.
Occam's razor: when the committee writes 'significant digits' they
mean 'most significant digits,' i.e. a measure of the number of digits
after the decimal point.
> I can think of two alternatives to deal with this:
> 1) Remove the scaling requirement for the significand, i.e. allow |a| < 1.
And talk about 1 milliKiloOhms ( 0.001e3 ) when 1 Ohm is meant?
> 2) Accept the ambiguity in significant digits for PRECISION < 3, and
> revise the spec of FE. to warn of the ambiguity.
Given that the definition of FE. carefully states 'engineering notation',
it is clear that the ambiguity is understood and *deliberately* tolerated:
"Compared to normalized scientific notation, one disadvantage of
using SI prefixes and engineering notation is that significant
figures are not always readily apparent."
( http://en.wikipedia.org/wiki/Engineering_notation )
Nothing left to do.
-marcel
Ed
> On Feb 7, 8:44 pm, "Ed" <nos...@invalid.com> wrote:
>
> > For myself, the layer of words of which you speak already exist in the
> > form of the FPOUT package. It is useful and sufficient - a synthesis
> > of the C and Fortran output functions expressed as 15 non-overlapping
> > words and controls in what must be the smallest possible code.
> > Importantly the functions do what they say, free from unwanted
> > side-effects.
> >
> Mostly, our discussion in this thread
> implementations can be more consistent and useful in what they output.
> And possibly adding a useful fixed point formatting word to the
> standard. Not much more than that. Most everything else could build
> upon this base, as Andrew suggests, and you demonstrate, although
> there are difficulties with what you have done.
FPOUT works for me. I mentioned it because its functions are
"normal" as far as the industry is concerned. One could do worse.
>
> 12.6.2.2035 PRECISION
> FLOATING EXT
>
> ( -- u )
>
> Return the number of significant digits currently used by F., FE., or
> FS. as u.
>
> The spec for PRECISION explicitly uses the term "significant digits",
> not "number of decimal places". To interpret the words "used by" to
> mean "add 1" is, IMO, an unwarranted distortion. I do not consider
> your implementations of FS. and FE. to be ANS compliant.
Had I interpreted it as "add 1" then I would not be able to do this:
precision . 15 ok
pi fs. 3.14159265358979E0 ok
pi f. 3.14159265358979 ok
1e fs. 1.E0 ok
1e f. 1. ok
4 set-precision ok
pi fs. 3.142E0 ok
pi f. 3.142 ok
1e fs. 1.E0 ok
1e f. 1. ok
One cannot deny this is a useful result and an adjunct to the
formatted output functions in the package.
I did precisely what the specification said. I "used" PRECISION
significant digits. All of my output functions do. That I chose to
use them as a limit, rather than display them, turned out to be
most fortuitous. It created order where previously there was chaos.
Good luck.
Krishna Myneni
> Krishna Myneni <krishna.myn...@ccreweb.org> writes Re: interpretation of PRECISION
>
> > On Feb 4, 7:08 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> ...>> As for PRECISION and FS. and FE. , there is no known problem, so I
> >> don't suggest any changes to the specification.
>
> ...
>
> > Nuts! I hadn't looked at the spec for FE. closely enough until now,
> > and there is a problem with respect to significant digits. The spec
> > for FE. requires the significand, a, to be scaled such that its
> > absolute value, |a| is in the range 1.0 to 1000: 1 <= |a| < 1000
> > The scaling requirement makes it impossible for FE. to output the
> > correct number of significant digits specified by PRECISION, without
> > ambiguity, when PRECISION is less than 3.
>
> Occam's razor: when the committee writes 'significant digits' they
> mean 'most significant digits,' i.e. a measure of the number of digits
> after the decimal point.
>
"most significant digits" = "measure of the number of digits after the
decimal point" ??
I don't understand what you are attempting to say, but the above is
certainly not true.
> > I can think of two alternatives to deal with this:
> > 1) Remove the scaling requirement for the significand, i.e. allow |a| < 1.
>
> And talk about 1 milliKiloOhms ( 0.001e3 ) when 1 Ohm is meant?
>
How do you output the following in engineering notation, using FE. ?
1) 100 ohm resistor with 10% tolerance
2) 100 ohm resistor with 1% tolerance
In scientific notation, you would write,
1) 1.0E2
2) 1.00E2
I guess the answer is that you cannot do this in engineering notation,
which is why scientific notation is preferable when significant digits
convey meaning in the output.
> > 2) Accept the ambiguity in significant digits for PRECISION < 3, and
> > revise the spec of FE. to warn of the ambiguity.
>
> Given that the definition of FE. carefully states 'engineering notation',
> it is clear that the ambiguity is understood and *deliberately* tolerated:
>
> "Compared to normalized scientific notation, one disadvantage of
> using SI prefixes and engineering notation is that significant
> figures are not always readily apparent."
> (http://en.wikipedia.org/wiki/Engineering_notation)
>
> Nothing left to do.
>
Note that option 2) does not modify the behavior, but suggests adding
a clarification of the limitations in the spec.
Krishna
Krishna Myneni
>
> 1) 100 ohm resistor with 10% tolerance
>
> 2) 100 ohm resistor with 1% tolerance
>
Actually, I just realized example 2) is fine since it requires three
significant digits. So, in engineering notation, it could be written
as
2) 100.E0
The least significant digit in the significand has some associated
uncertainty, which, unless specified separately, is taken to be +/- 1
unit, by convention.
Krishna
Krishna Myneni
...
> precision . 15 ok
> pi fs. 3.14159265358979E0 ok
> pi f. 3.14159265358979 ok
> 1e fs. 1.E0 ok
> 1e f. 1. ok
>
> One cannot deny this is a useful result and an adjunct to the
> formatted output functions in the package.
I don't doubt the output of your FS. can be useful in some situations.
However, it is not generally useful. The reason is that now you have
to inform the user of both your precision setting as well as the
result, when you output a number using FS. . For example, let's say
that you write a program to compute the integral of some function,
f(x), between two limits. If the result happens to be
1.000000000000000E0, your F. and FS. words would simply show the
result 1.E0. Without knowing the value of PRECISION , the user could
just as well infer that the result was 1.2E0 (for PRECISION = 1). Of
course you can separately output the value of PRECISION, and then have
the user go through some manual transcription of the result to the
correct number of significant figures, but this is error prone and
unnecessary. My argument with your FS. is that it is not generally
useful in the context of scientific computing.
Krishna
Ed
> On Feb 9, 5:42 pm, "Ed" <nos...@invalid.com> wrote:
> ...
> > precision . 15 ok
> > pi fs. 3.14159265358979E0 ok
> > pi f. 3.14159265358979 ok
> > 1e fs. 1.E0 ok
> > 1e f. 1. ok
> ...
> >
> > One cannot deny this is a useful result and an adjunct to the
> > formatted output functions in the package.
> > ...
>
> I don't doubt the output of your FS. can be useful in some situations.
> However, it is not generally useful.
It would appear I need to make one more post to allay such claims.
FPOUT has existed with all the functionality you claim to need for at
least six years. Apparently few bothered to look.
Indeed FS. *was* intended for general use. It operates in the same
spirit as the C / Fortran 'g' output functions in that it displays only as
many zeros and signs as are strictly necessary. Many applications
(and programmers in particular) don't need to see extraneous trailing
zeros. The compact or "short form" output works equally well as
input while consuming less space.
Displaying a given number of mantissa digits or decimal places is
properly handled by the formatted output functions. That function
is provided in other languages via %e %f etc and in FPOUT via
FS.R and F.R.
I could simply have defined FS. F. as
: FS. ( r -- ) PRECISION 1- 0 FS.R SPACE ;
: F. ( r -- ) PRECISION 1- 0 F.R SPACE ;
4 set-precision ok
pi fs. 3.142E+00 ok
1e fs. 1.000E+00 ok
pi f. 3.142 ok
1e f. 1.000 ok
But it was decided an application programmer can readily do that
anytime he needs it. More importantly, why waste two perfectly good
names FS. F. on trivially defined functions when one could better
employ them for other modes andso increase the flexibility of Forth
floating-point output.
--
IMO the "problem" of PRECISION - what it means and how it can
be usefully incorporated in f/p display while maintaining norms set
by other languages - was resolved years ago.
However I understand your goal is consensus. That may involve a
difference set of criteria altogether :)