Re: 0 SET-ORDER why?

On 28/06/2024 11:48 pm, Ruvim wrote:

On 2024-06-28 16:19, dxf wrote:

On 28/06/2024 7:51 pm, Ruvim wrote:

On 2024-06-27 07:19, dxf wrote:

On 26/06/2024 11:36 pm, Ruvim wrote:

On 2024-06-26 12:50, dxf wrote:

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

>
>
I think, in this case it's better to specify behavior than to declare an ambiguous condition.

>
No need to specify useless behaviours.

>
Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
>
BTW, do you think 0 PICK and 0 ROLL are useless?

>
No, because I've used them (at least in the case of PICK :)
>

u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

>
<https://forth-standard.org/standard/float/REPRESENT>
>
Of course, it's specified. It's specified for any u, including 0.
For example:
   "The character string shall consist of the u most significant digits"
>
If u is zero, the string must consist of zero digits.

>
Spec says:
>
    "u most significant digits of the significand"
>
Do you have a definition for '0 most significant digits of the significand' ?
I don't.  Nor did ANS provide one.

 
It's seems obvious to me: 0 digits means the empty string.

REPRESENT does two things:
- Round the number to produce another number
- Convert the resulting number to a string

u=0 fails on the first step as there's no such thing as a number rounded to
zero significant digits.  The resulting string is thus undefined.

>
Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.
>
Probably, "represent" may return false at the top if u is zero.

>
No.  The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest.

 
"the significand represented as a decimal fraction", so each digit is chosen from {0,1, ..., 9}.

That refers to the resulting number after rounding.  There's no difficulty
representing 1.0 as a fraction and adjusted exponent.

Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

 
It's a problem of particular implementations.

It's a problem if they think ANS wanted them to return an empty string.