Date: Fri, 28 Jun 2024 22:19:05 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: 0 SET-ORDER why?
Newsgroups: comp.lang.forth
References: <v5fjkr$1p13i$1@dont-email.me>
 <2024Jun26.094910@mips.complang.tuwien.ac.at> <667bd654$1@news.ausics.net>
 <v5h5h6$2565d$1@dont-email.me> <667cda36$1@news.ausics.net>
 <v5m13j$3811n$1@dont-email.me>
Content-Language: en-GB
From: dxf <dxforth@gmail.com>
In-Reply-To: <v5m13j$3811n$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: news.ausics.net
Message-ID: <667eaa3b@news.ausics.net>
Organization: Ausics - https://newsgroups.ausics.net
Lines: 56
X-Complaints: abuse@ausics.net
Path: ...!news.mixmin.net!news.ausics.net!not-for-mail
Bytes: 2797

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.

> 
> 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.  Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

> ... 
> 
> What is the problem anyway that the behavior is specified for
> "0 SET-ORDER"?  What are bad consequences for systems or for users?

It would be a problem if there were no use for it.  It's not clear to me
that we're there yet.