From: the.beez.speaks@gmail.com
On 07-04-2025 13:05, dxf wrote:
As a matter of fact, the whole issue can be solved by one single very
simple addition to the standard. All my FP systems hold this very
definition for SET-PRECISION:
\ 34: Reimplemented PRECISION and SET-PRECISION.
maxdigits VALUE PRECISION
: SET-PRECISION ( n -- ) maxdigits MIN TO PRECISION ;
Since the FLOAT wordset is always in decimal (12.4.1.2 Ambiguous
conditions - BASE is not decimal (12.6.1.2143 REPRESENT, 12.6.2.1427 F.,
12.6.2.1513 FE., 12.6.2.1613 FS.) it is trivial to calculate the number
of significant digits.
The definition given here ( --- CONSTANT MAXDIGITS) ensures that the
value issued to SET-PRECISION is always sane.
Of course, if one does not have access to some carnal knowledge
concerning the mantissa, one does have a problem concerning porting and
maintenance.
Hans Bezemer
> On 7/04/2025 4:42 pm, Anton Ertl wrote:
>> dxf writes:
>>> On the topic of documentation Forth Standard (the document to which
>>> everyone looks) hasn't clarified aspects of REPRESENT F. etc.
>>
>> The document does not write itself.
>
> No, and neither has anyone as the Synod doesn't say what needs to be
done.
> Can you imagine if Forth-94 had used that approach? AFAIK sub-committees
> were allocated tasks.
>
>> If you think that something is
>> unclear, you can make a request for clarification on
>> (when it runs again, hopefully soon).
>> If you think that some text should be changed in a specific way, you
>> can make a proposal for that. If you have no interest in doing that
>> for these topics (which seem to be important enough to mention them
>> here), why should anybody else have an interest in doing that?
>>
>>> That holes still exist after 30 years can only mean forthers are
>>> content with less than perfect documentation. No?
>>
>> In the case of "F.", I actually believe that most users would prefer
>> something that produces an output, possibly in scientific
>> representation, of up to 20 characters over the exact implementation
>> of the specification that is implemented by Gforth and VFX:
>>
>> 1e200 f.
1000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000.
ok
>> 1e-200 f.
0.00000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000001
ok
>>
>> But nobody has written a proposal for changing "F." in that way. The
>> feedback on such a proposal would indicate whether my belief is
>> correct or not. The absence of such a proposal indicates that the
>> topic is not important enough for Forth programmers and implementors.
>
> That wasn't it. Rather the relation between 'significant digits' and
> output is never really specified. Even the example Forth-94 gave (
1E3 F. )
> didn't help because no mention of the PRECISION used.
>
> NT/FORTH (C) 2005 Peter Fälth Version 1.6-983-824 Compiled on
2017-12-03
>
> 3 set-precision
> 1e3 f. 1000. ok
>
> 6 set-precision ok
> 1e f. 1.00000 ok
> 1e4 f. 10000.0 ok
> 1e-4 f. 0.000100000 ok
> 0e f. 0.00000 ok
>
>
> Gforth 0.7.9_20200709
>
> 3 set-precision
> 1e3 f. 1000. ok
>
> 6 set-precision ok
> 1e f. 1. ok
> 1e4 f. 10000. ok
> 1e-4 f. 0.0001 ok
> 0e f. 0. ok
>
> Not sure whether it would affect a Standard Program but I imagine porting
> a real-world app could be a problem.
>
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
