|
|
 | | From: | Ed | | Subject: | A note on PRECISION F. FS. FE. | | Date: | Sun, 16 Jan 2005 16:23:19 +1100 |
|
|
 | Re-reading the Forth-94 standard has forced me to revise the
way my F. FS. and FE. display floating point numbers.
Checking with other forths, I find that they make similar errors.
In fact, I have yet to discover a forth where F. FS. FE. display
according to the standard.
The following is my interpretation of what the Standard says
in relation to floating point displays.
First, let's clarify what PRECISION means.
12.6.2.2035 PRECISION FLOATING EXT
( -- u )
Return the number of significant digits currently used by
F., FE., or FS. as u.
From the definition we see that:
1. It says "significant digits" - not "digits after the decimal point".
While some languages use (or misuse) the term precision to
mean digits after the decimal point, nowhere in Forth-94 is
such an association made.
2. It says "used by" [F. FE. FS.]. While this phrase could be taken
to include "displayed by" one should not take it as a given. (I'll
explain later why this is NOT the case)
I take PRECISION to mean the number of "meaningful" decimal
mantissa digits that will be extracted from the floating point
number. Thus while one may display an fp number with 100 digits,
if PRECISION returns 6 then only a maximum of 6 digits will be
meaningful or "significant".
A consequence of the above is that PRECISION cannot [should
not] return more digits than the internal representation of the fp
number is capable of providing.
Getting back to the display words, we find FS. defined as:
12.6.2.1613 FS. f-s-dot FLOATING EXT
( -- ) ( F: r -- ) or ( r -- )
Display, with a trailing space, the top number on the floating-
point stack in scientific notation:
where:
:= [-].
:= E[-]
From this we see that:
1. Trailing zeros in the fraction are not displayed
2. A decimal point is always shown
3. No sign is displayed if the exponent is positive
4. A '0' is shown if the exponent is zero.
While it does not state so, we may assume leading zeros in
the exponent are not shown (since FS. is clearly meant as a
"compact" display)
The point to note is that PRECISION does *not* set the
number of digits displayed. Rather, it sets the maximum
number of significant digits that may *possibly* be displayed.
Looking at the definition of F. we see it is similarly intended
as a compact display i.e. no trailing zeros in the fraction.
Lastly we have FE. which is a real problem. Unlike FS. or F.
no display semantics are given. No mention of how, or if, an
exponent should be shown. Add to this the fact that engineers
don't use exponents anyway - they use prefixes (micro, milli,
kilo, etc).
In summary, I find the Standard's F. and FS. to be both adequately
defined and useful. On the other hand, FE. is a white elephant in
several respects and is best deleted.
Ed
|
|
| | From: | Anton Ertl | | Subject: | Re: A note on PRECISION F. FS. FE. | | Date: | Sun, 16 Jan 2005 09:03:04 GMT |
|
|
| "Ed" writes:
> 12.6.2.2035 PRECISION FLOATING EXT
>
> ( -- u )
>
> Return the number of significant digits currently used by
> F., FE., or FS. as u.
>
>From the definition we see that:
>
>1. It says "significant digits" - not "digits after the decimal point".
> While some languages use (or misuse) the term precision to
> mean digits after the decimal point, nowhere in Forth-94 is
> such an association made.
>
>2. It says "used by" [F. FE. FS.]. While this phrase could be taken
> to include "displayed by" one should not take it as a given. (I'll
> explain later why this is NOT the case)
>
>I take PRECISION to mean the number of "meaningful" decimal
>mantissa digits that will be extracted from the floating point
>number. Thus while one may display an fp number with 100 digits,
>if PRECISION returns 6 then only a maximum of 6 digits will be
>meaningful or "significant".
>
>A consequence of the above is that PRECISION cannot [should
>not] return more digits than the internal representation of the fp
>number is capable of providing.
I don't follow you here. I think the case is much stronger for
letting PRECISION return the value that was last passed to
SET-PRECISION.
>Getting back to the display words, we find FS. defined as:
>
> 12.6.2.1613 FS. f-s-dot FLOATING EXT
>
> ( -- ) ( F: r -- ) or ( r -- )
>
> Display, with a trailing space, the top number on the floating-
> point stack in scientific notation:
>
>
>
> where:
> := [-].
> := E[-]
>
>From this we see that:
>
> 1. Trailing zeros in the fraction are not displayed
I don't see that. The definition of is:
:= *
:= { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
i.e., 0 or more digits in the range 0-9; so, e.g., a string "000"
would match this syntax and it has trailing zeroes.
>While it does not state so, we may assume leading zeros in
>the exponent are not shown (since FS. is clearly meant as a
>"compact" display)
That's not clear to me. The output of FS. is necessarily not as
compact as possible for stuff like 5e or .5e.
Another intention for FS. might have been to provide a fixed-width
printing option for generating tables. In that case it would be a
good idea to have as many digits in the mantissa as specified by
PRECISION, and to have as many digits in the exponent as necessary to
fill the maximum opponent width (e.g., 4 characters for IEEE
double-precision numbers).
>Lastly we have FE. which is a real problem. Unlike FS. or F.
>no display semantics are given.
I assume you mean display syntax. I would use the syntax given for
FS. with the changes specified in the FE. definition.
> No mention of how, or if, an
>exponent should be shown.
It says: "Display ..., where ... the decimal exponent is a multiple of
three". Sounds like displaying an exponent to me. I guess the
definition presumes knowledge of TI calculators (which had the same
idea of "engineering notation").
>Add to this the fact that engineers
>don't use exponents anyway - they use prefixes (micro, milli,
>kilo, etc).
Yes, and in contrast to TI calculators a Forth system can display the
prefixes or their letters. Nevertheless, it is easier to convert the
FE. output to a prefix than the FS. output.
In practice, though, I wonder if engineers would not prefer a specific
prefix in a given context and print with something like
1e3 f/ f. ." k"
Overall, I am not sure that more precise definitions (or
interpretations of the definitions) of these words are needed and
useful. I see the following purposes for precisely defined FP output:
- To have a predictable width for printing tables and reports. This
width should not depend on the data being printed. F. FS. FE. are not
defined precisely enough to guarantee that, and your proposed
clarifications make their output width data-dependent, i.e., unfit for
this purpose.
- To make the output of a program totally repeatable across systems.
However, given that the standard does not specify much about FP
numbers and FP arithmetic anyway, that goal is utopian. Some systems
use IEEE FP doubles, some use 387 80-bit extended precision, some may
use IEEE singles, some may use some machine-specific types. And even
between IEEE DP FP implementations, the results may still vary for
transcendental functions, even within an architecture (e.g., they vary
between the 486 and the Pentium).
- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
|
|
| | From: | Ed | | Subject: | Re: A note on PRECISION F. FS. FE. | | Date: | Tue, 18 Jan 2005 19:26:12 +1100 |
|
|
|
"Anton Ertl" wrote in message
news:2005Jan16.100304@mips.complang.tuwien.ac.at...
> "Ed" writes:
> >
> > [..]
> >A consequence of the above is that PRECISION cannot [should
> >not] return more digits than the internal representation of the fp
> >number is capable of providing.
>
> I don't follow you here. I think the case is much stronger for
> letting PRECISION return the value that was last passed to
> SET-PRECISION.
What benefit would that give? Being able to display more
zeros than the internal representation allows adds nothing
to the precision. It would only serve to shore up the
formatting argument - and that doesn't work as I explain
below).
> > 1. Trailing zeros in the fraction are not displayed
>
> I don't see that. The definition of is:
>
> := *
> := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
>
> i.e., 0 or more digits in the range 0-9; so, e.g., a string "000"
> would match this syntax and it has trailing zeroes.
Yes. That is the other possible interpretation.
However, it is one which I now reject as it leads to oddities
such as F. displaying:
..0001
..0010
..0100
..1000
1.000
10.00
100.0
1000.
10000.
100000.
1000000.
10000000.
100000000.
I can't think of any use for such a display. Why should the Standard
require it?
> >While it does not state so, we may assume leading zeros in
> >the exponent are not shown (since FS. is clearly meant as a
> >"compact" display)
>
> That's not clear to me. The output of FS. is necessarily not as
> compact as possible for stuff like 5e or .5e.
Compact enough. The requirement for a leading zero could simply
be to match the corresponding Forth input format! This would be
important in cases where EMIT is redirected to a file which is then
subsequently used as Forth input.
> Another intention for FS. might have been to provide a fixed-width
> printing option for generating tables. In that case it would be a
> good idea to have as many digits in the mantissa as specified by
> PRECISION, and to have as many digits in the exponent as necessary to
> fill the maximum opponent width (e.g., 4 characters for IEEE
> double-precision numbers).
Formatting is the main argument for the view of some that
the Standard intended PRECISION digits always be displayed.
There are several reasons why I see it as unlikely:
1. The Standard mandates that + signs in both mantissa and
exponent *not* be shown. This destroys any possibility
of aligned or fixed width displays!
2. The definition of F. makes alignment/fixed width
impossible anyway.
3. The Standard only defines three fp output words. It is
therefore much more likely that these words would have been
designed with simplicity and compactness in mind. The
Standard understood that users would require more complex
output forms andso provided the primitive REPRESENT.
Thanks, Anton for providing such a strong critique! If there are
flaws in my interpretation then I would prefer to know it sooner
than later.
I would like to think my reading of the Standard is the correct
one. Certainly I find the outcome far more desirable than that
produced by other interpretations. They also seem to align
better to the floating point outputs one sees in other languages.
The improvement is such that I now find it difficult to believe
the Standard intended anything else!
Ed
|
|
| | From: | Anton Ertl | | Subject: | Re: A note on PRECISION F. FS. FE. | | Date: | Tue, 18 Jan 2005 14:38:32 GMT |
|
|
| "Ed" writes:
>
>"Anton Ertl" wrote in message
>news:2005Jan16.100304@mips.complang.tuwien.ac.at...
>> "Ed" writes:
>> >
>> > [..]
>> >A consequence of the above is that PRECISION cannot [should
>> >not] return more digits than the internal representation of the fp
>> >number is capable of providing.
>>
>> I don't follow you here. I think the case is much stronger for
>> letting PRECISION return the value that was last passed to
>> SET-PRECISION.
>
>What benefit would that give?
The results of PRECISION would not be system-specific.
Programs that rely on the property I outlined would work (no, I don't
know such programs, but then I don't do much FP code).
> Being able to display more
>zeros than the internal representation allows adds nothing
>to the precision.
That's a different issue than that of what PRECISION returns.
>> > 1. Trailing zeros in the fraction are not displayed
>>
>> I don't see that. The definition of is:
>>
>> := *
>> := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
>>
>> i.e., 0 or more digits in the range 0-9; so, e.g., a string "000"
>> would match this syntax and it has trailing zeroes.
>
>Yes. That is the other possible interpretation.
>
>However, it is one which I now reject as it leads to oddities
>such as F. displaying:
>
>.0001
>.0010
>.0100
>.1000
>1.000
>10.00
>100.0
>1000.
>10000.
>100000.
>1000000.
>10000000.
>100000000.
>
>I can't think of any use for such a display. Why should the Standard
>require it?
The standard does not require it. But it does not require not
displaying trailing zeroes either. It does not require very much
about F. FS. FE. As you point out, even the role of SET-PRECISION is
not specified precisely.
BTW, trailing zeros with 4 significant digits would lead to output
like
..0001000
Always doing 4 digits after the comma would lead to output like
100.0000
I wonder what principle is embodied in an F. that produces the output
you showed above.
>> That's not clear to me. The output of FS. is necessarily not as
>> compact as possible for stuff like 5e or .5e.
>
>Compact enough. The requirement for a leading zero could simply
>be to match the corresponding Forth input format! This would be
>important in cases where EMIT is redirected to a file which is then
>subsequently used as Forth input.
While FS. can be used for that (to some degree), a word that outputs a
compact and precisely rereadable Forth input format might be a good
idea.
>> Another intention for FS. might have been to provide a fixed-width
>> printing option for generating tables. In that case it would be a
>> good idea to have as many digits in the mantissa as specified by
>> PRECISION, and to have as many digits in the exponent as necessary to
>> fill the maximum opponent width (e.g., 4 characters for IEEE
>> double-precision numbers).
>
>Formatting is the main argument for the view of some that
>the Standard intended PRECISION digits always be displayed.
>
>There are several reasons why I see it as unlikely:
>
>1. The Standard mandates that + signs in both mantissa and
> exponent *not* be shown. This destroys any possibility
> of aligned or fixed width displays!
Not at all. Just display a digit more in both mantissa and exponent
if they are positive.
>2. The definition of F. makes alignment/fixed width
> impossible anyway.
We are discussing FS., not F..
>3. The Standard only defines three fp output words. It is
> therefore much more likely that these words would have been
> designed with simplicity and compactness in mind.
I find it just as likely that at least one of the words would be good
for fixed-width output. However, if that was the intention of FS.,
they botched it, because they did not specify it precisely enough.
>I would like to think my reading of the Standard is the correct
>one. Certainly I find the outcome far more desirable than that
>produced by other interpretations. They also seem to align
>better to the floating point outputs one sees in other languages.
>The improvement is such that I now find it difficult to believe
>the Standard intended anything else!
Take a look at what the various implementations do. Maybe you find
some commonalities that can be refined in the next standard. However,
I guess you have a better chance of getting common behaviour with your
G. proposal (especially since you are providing a reference
implementation).
- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
|
|
| | From: | Ed | | Subject: | Re: A note on PRECISION F. FS. FE. | | Date: | Fri, 21 Jan 2005 17:55:54 +1100 |
|
|
|
"Anton Ertl" wrote in message
news:2005Jan18.153832@mips.complang.tuwien.ac.at...
> "Ed" writes:
> >
> > [..]
> >What benefit would that give?
>
> The results of PRECISION would not be system-specific.
It does not matter that PRECISION varies from system to
system. I suspect that what you are really wanting is "digits
after the decimal point" - which is independent of PRECISION.
"digits after the decimal point" is the traditional way to effect
alignment for floating point output. Words using a "decimal
places" parameter may be readily created with REPRESENT
as my FPOUT package demonstrates.
Using PRECISION in an attempt to achieve formatting is
definitely the wrong approach!
> >I can't think of any use for such a display. Why should the Standard
> >require it?
>
> The standard does not require it.
Sorry, I included the wrong output. It should have been:
0.000100
0.00100
0.0100
0.100
1.00
10.0
100.
1000.
10000.
100000.
1000000.
10000000.
100000000.
It results from applying to F. the same interpretation which you
have used for FS. Namely that PRECISION digits must always
be shown.
If the response is that F. shouldn't display trailing zeros whereas
FS. should, then I must reject it.
Looking at the definitions we see:
for F. [-] .
for FS. [-].
This indicates in no uncertain terms that the fraction part for
F. and FS. must be displayed *identically*
Now, to see how the Standard intended F. to be displayed one
may go to: A.12.6.1.1427
"For example, 1E3 F. displays 1000. ."
Note that there are no trailing zeros displayed.
By definition, FS. must also *not* show trailing zeros!
QED End of argument. I rest my case :)
|
|
|
