Re: REPRESENT revisited
- From: anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
- Date: Mon, 05 Sep 2005 18:29:59 GMT
"Ed" <nospam@xxxxxxxxxxx> writes:
>Though intended to be portable, REPRESENT 's loose definition
>has given rise to implementations that differ in critical
>respects. It is also lacks adequate functionality to implement
>fixed-point notation display.
For the amount of control you want, instead of tightening up
REPRESENT, maybe it would be better to provide lower-level words like
those proposed by David N. Williams, and using them to implement
output words.
>It is perhaps inevitable that REPRESENT will need revision
>in the future. To that end, I wish to propose the following
>redefinition. It addresses all the key issues while remaining
>compatible with the Forth-94 specification.
Compatible in which way?
1) All currently standard programs run on systems that implement the
proposal.
2) The proposal describes behaviour that all currently standard
systems already implement.
The required compatibility is 1), but 2) makes it much easier to get
the proposal accepted by systems implementors.
> If u is zero the string shall consist of one digit representing
> the fractional significand r rounded to a whole number, either
> one or zero, with an implied decimal point to the left of the
> digit.
That's a change from the current version, and since it changes a case
that is currently defined, it is not a compatible change.
However, I guess that few, if any, programs actually call REPRESENT
with u=0, so one might get away with changing the behaviour for that
case.
But I think it is a very bad idea if a word that should fill a string
buffer writes beyond the end of the buffer as proposed here. Whatever
you want to achieve with this change is probably better achieved by
defining a separate word for it. This looks like the kind of
word-overloading that some people propose in order to avoid increasing
the number of words; this results in nonsense like F~.
> If r is zero or evaluates to zero after rounding,
> then n is 1 and the sign is implementation-defined.
This is also new, and a compatible extension (previously undefined).
A quick check indicates that Gforth on Linux implements this.
I don't see how r can evaluate to zero after rounding.
> When flag2 is false, n and flag1 are implementation-defined,
> as are the contents of c-addr. The string at c-addr shall
> consist of graphic characters left-justified in a field width
> as determined by u with any unused positions to the right
> filled with space characters.
Sounds good (also an extension).
>Rationale
>---------
....
> Mathematically any value would do since zero raised to any
> power remains zero.
This should be: "multiplied with any value remains zero"; the mantissa
is not raised to a power in FP representations.
> [C library function ecvt similarly returns 1 for the
> exponent value - presumably for the same reasons.]
Well, "man ecvt" on my Linux system says:
|If number is zero, it is unspecified whether *decpt is 0 or 1.
So, better don't claim this, or you will get Forth systems that call
ecvt and then just give you *decpt as n.
>2. Out of range numbers
....
> - The length of the returned string is the same as when
> flag2 = true i.e. the length is determined by u.
That is necessary; there is no return value for reporting a different
length.
>b) Value of n and flag1
>
> "n and flag1 are implementation defined"
>
> Some forths have REPRESENT return a basic string ('NAN'
> 'INF' etc) and then use flag1 to later indicate the sign.
> While such practices are permitted under Forth-94, they are
> not portable.
>
> Portable applicationa can only make use of the returned
> string. If a sign needs to be passed to an application
> then it must be included in the string e.g. '+NAN' '-INF'
This did not become clear to me in the specification. Maybe you
should make it clearer. You would have to define the resulting string
in the case of flag2=false.
>c) String length
>
> A difficulty with the present system is that the returned
> string becomes increasingly truncated as u decreases. At
> one or two characters most strings are unintelligible.
If the programmer asks for 1, 2, or 0 characters, they hopefully know
what they are doing. It's not our job to protect them from
themselves.
> But what if we need to display 0.6489 rounded to 0 decimal
> places? This would require fraction .6489 be rounded to
> the nearest whole number i.e. 1.
>
> Such situations arise when displaying fixed-point notation
> to a given number of decimal places. Failure to round the
> entire significand when appropriate leads to incorrect
> results. Here are some examples.
>
> Display 0.009 to 2 decimal places in a field width of 5
> characters -
>
> 0.009E 2 5 F.R 0.00 ok ( FPOUT 1.6 and prior )
> 0.009E 5 2 0 F.RDP 0.00 ok ( Gforth 0.6.2 )
>
> ( The result should have been 0.01 )
Yes. Looks like a bug in f.rdp. Interestingly,
0.0096E 5 2 0 F.RDP
prints 0.01.
> Luckily we can add the missing functionality by simply
> allowing 'u' to take the value zero e.g.
u is allowed to take the value 0 already.
>
> ( r ) PAD u REPRESENT 2DROP PAD u 1 MAX TYPE SPACE .
>
> r u string n (exponent)
> -- -- ------ --
> 0.6489 4 '6489' 0
> 0.6489 3 '649' 0
> 0.6489 2 '65' 0
> 0.6489 1 '6' 0
> 0.6489 0 '1' 1
>
> As the above table shows we are merely extending REPRESENT
> in a logical direction.
No, the logical continuation is:
> 0.6489 0 '' 0
And guess what, that's what Gforth under Linux does.
- 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
EuroForth 2005: http://www.complang.tuwien.ac.at/anton/euroforth2005/
.
- Follow-Ups:
- Re: REPRESENT revisited
- From: Krishna Myneni
- Re: REPRESENT revisited
- From: Ed
- Re: REPRESENT revisited
- References:
- REPRESENT revisited
- From: Ed
- REPRESENT revisited
- Prev by Date: Re: pentomino program revisited
- Next by Date: Re: pentomino program revisited
- Previous by thread: REPRESENT revisited
- Next by thread: Re: REPRESENT revisited
- Index(es):
Relevant Pages
|
