Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Krishna Myneni <krishna.myneni@ccreweb.org>
Newsgroups: comp.lang.forth
Subject: Re: F*/ (f-star-slash)
Date: Mon, 27 May 2024 13:48:05 -0500
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <v32kh5$5nvo$2@dont-email.me>
References: <v2dqte$3ir32$1@dont-email.me> <v2drrv$3ivnm$1@dont-email.me>
 <41a09e78173bc899fd23b9d75227dffb@www.novabbs.com>
 <v2egeo$3q5ij$1@dont-email.me>
 <e3a6fd2c9176cb65918bc0a915308325@www.novabbs.com>
 <v2ffa8$3vla3$2@dont-email.me>
 <9d04eed2c654bd62ef9ad8b4f11e6488@www.novabbs.com>
 <v2gm9p$7qfs$1@dont-email.me>
 <0fd5222e7a755b9bb354872bbd547c87@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 27 May 2024 20:48:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="34e332c27d62f53107dfa2365b6e0eab";
	logging-data="188408"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19RILn3mLj7M8mC4IaTB/gd"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iYBrrYiDd++wT298BwHAKFcmMkc=
Content-Language: en-US
In-Reply-To: <0fd5222e7a755b9bb354872bbd547c87@www.novabbs.com>
Bytes: 3113

On 5/21/24 14:17, minforth wrote:
> Krishna Myneni wrote:
>>>> MANTMAX dp-components.
>>>> significand =   9007199254740991  exponent =   52  sign = 0  ok
>>>> hex
>>>>   ok
>>>> MANTMAX FFFF S>F FDUP F*/
>>>>   ok
>>>> decimal dp-components.
>>>> significand =   9007199254740990  exponent =   52  sign = 0  ok
>>>
>>>> The lowest bit is different in the significand. Need to look into 
>>>> why the lowest fraction bit is different.
>>>
>>> It looks like you are truncating the result and not rounding to nearest
>>> which is expected by F*  and F/.
>>> You save the remainder but do not use it for anything!
>>>
> 
>> I think you're correct, but the rounding used by F*/ should be to 
>> whatever rounding mode the FPU is set. In kForth, the FPU is always 
>> initialized to round to nearest. Since we are doing the calculation for
>>
>> F*/ in integer arithmetic, it is not observing the round-to-nearest mode
>>
>> of the FPU.
> 
> Manual cross-check with quad precision floats:
> 
> MinForth 3.6 (64 bit) (fp 128 bit)
> # $1FFFFFFFFFFFFF S>F FCONSTANT MANTMAX  ok
> # mantmax  ok
> f: 9.0072e+15 | # $FFFF s>f  ok
> f: 9.0072e+15 65535 | # f*  ok
> f: 5.90287e+20 | # fdup f>d  ok
> f: 5.90287e+20 | -9007199254806527 31 # hex  ok
> f: 5.90287e+20 | FFDFFFFFFFFF0001 1F $ decimal 65535e f/  ok
> f: 9.0072e+15 | -9007199254806527 31 # 2drop f>s  ok
> 9007199254740991 # hex  ok
> 1FFFFFFFFFFFFF $
> 
> So for the 64-bit F*/ challenge, the interim significand after the
> multiplication step should be $1F_FFDF_FFFF_FFFF_0001.
> 
> It is now easy to check whether the erroneous 1-digit offset was caused
> by the multiplication step or the division step.

Ok. Will go back and compare.

--
Krishna