Groups > comp.lang.forth > #134948 > unrolled thread

GNU Forth has a floating point floor word, but not floating point ceiling word?

Started by	Buzz McCool <buzz_mccool@yahoo.com>
First post	2026-04-23 16:11 -0700
Last post	2026-05-01 10:18 +0200
Articles	20 on this page of 27 — 7 participants

Back to article view | Back to comp.lang.forth

  GNU Forth has a floating point floor word, but not floating point ceiling word? Buzz McCool <buzz_mccool@yahoo.com> - 2026-04-23 16:11 -0700
    Re: GNU Forth has a floating point floor word, but not floating point ceiling word? dxf <dxforth@gmail.com> - 2026-04-24 11:14 +1000
      Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Buzz McCool <buzz_mccool@yahoo.com> - 2026-04-24 08:29 -0700
      Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-27 17:39 -0500
        Re: GNU Forth has a floating point floor word, but not floating point ceiling word? peter <peter.noreply@tin.it> - 2026-04-28 13:40 +0200
          Re: GNU Forth has a floating point floor word, but not floating point ceiling word? minforth <minforth@gmx.net> - 2026-04-28 14:01 +0200
          Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-28 19:25 -0500
            Re: GNU Forth has a floating point floor word, but not floating point ceiling word? dxf <dxforth@gmail.com> - 2026-04-29 11:20 +1000
              Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-29 08:30 -0500
                Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-29 20:15 -0500
                  Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-05-02 15:56 -0500
            Re: GNU Forth has a floating point floor word, but not floating point ceiling word? dxf <dxforth@gmail.com> - 2026-04-29 11:47 +1000
        Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-30 04:40 -0500
          Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-30 05:37 -0500
            Re: GNU Forth has a floating point floor word, but not floating point ceiling word? peter <peter.noreply@tin.it> - 2026-04-30 15:55 +0200
              Re: GNU Forth has a floating point floor word, but not floating point ceiling word? Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-30 20:49 -0500
                Special memory access words (was: GNU Forth has a ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-01 06:16 +0000
                  Re: Special memory access words (was: GNU Forth has a ...) peter <peter.noreply@tin.it> - 2026-05-01 10:22 +0200
                    Re: Special memory access words (was: GNU Forth has a ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-01 08:57 +0000
                      Re: Special memory access words Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-05-01 10:19 -0500
                        Re: Special memory access words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-01 15:35 +0000
                          Re: Special memory access words Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-05-01 13:28 -0500
                            Re: Special memory access words Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-05-01 13:30 -0500
                            Re: Special memory access words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-02 05:54 +0000
                              Re: Special memory access words Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-05-02 15:49 -0500
                  Re: Special memory access words Hans Bezemer <the.beez.speaks@gmail.com> - 2026-05-01 13:28 +0200
                Re: GNU Forth has a floating point floor word, but not floating point ceiling word? peter <peter.noreply@tin.it> - 2026-05-01 10:18 +0200

Page 1 of 2 [1] 2 Next page →

#134948 — GNU Forth has a floating point floor word, but not floating point ceiling word?

From	Buzz McCool <buzz_mccool@yahoo.com>
Date	2026-04-23 16:11 -0700
Subject	GNU Forth has a floating point floor word, but not floating point ceiling word?
Message-ID	<10se8v4$3d7tj$1@dont-email.me>

$ gforth
Gforth 0.7.9_20260324
...
Type `help' for basic help

1.9e floor  ok f:1
f. 1.  ok

1.9e fceil
*the terminal*:6:6: error: Undefined word
1.9e >>>fceil<<<
Backtrace:
/usr/share/gforth/0.7.9_20260324/kernel/recognizer.fs:124:35:  0 $7DFF9A013568 throw

[toc] | [next] | [standalone]

#134949

From	dxf <dxforth@gmail.com>
Date	2026-04-24 11:14 +1000
Message-ID	<69eac411$1@news.ausics.net>
In reply to	#134948

On 24/04/2026 9:11 am, Buzz McCool wrote:
> $ gforth
> Gforth 0.7.9_20260324
> ...
> Type `help' for basic help
> 
> 1.9e floor  ok f:1
> f. 1.  ok
> 
> 1.9e fceil
> *the terminal*:6:6: error: Undefined word
> 1.9e >>>fceil<<<
> Backtrace:
> /usr/share/gforth/0.7.9_20260324/kernel/recognizer.fs:124:35:  0 $7DFF9A013568 throw

: fceil ( r1 -- r2 )  fnegate floor fnegate ;  ok
1.9e fceil f. 2.  ok
-1.9e fceil f. -1.  ok

[toc] | [prev] | [next] | [standalone]

#134950

From	Buzz McCool <buzz_mccool@yahoo.com>
Date	2026-04-24 08:29 -0700
Message-ID	<10sg287$vn5$1@dont-email.me>
In reply to	#134949

On 4/23/2026 6:14 PM, dxf wrote:
> 
> : fceil ( r1 -- r2 )  fnegate floor fnegate ;  ok
> 1.9e fceil f. 2.  ok
> -1.9e fceil f. -1.  ok
> 

Thanks for that.

I still think that it is strange to have one but not the other.

[toc] | [prev] | [next] | [standalone]

#135000

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-27 17:39 -0500
Message-ID	<10sooig$2o6bk$1@dont-email.me>
In reply to	#134949

On 4/23/26 8:14 PM, dxf wrote:
> On 24/04/2026 9:11 am, Buzz McCool wrote:
>> $ gforth
>> Gforth 0.7.9_20260324
>> ...
>> Type `help' for basic help
>>
>> 1.9e floor  ok f:1
>> f. 1.  ok
>>
>> 1.9e fceil
>> *the terminal*:6:6: error: Undefined word
>> 1.9e >>>fceil<<<
>> Backtrace:
>> /usr/share/gforth/0.7.9_20260324/kernel/recognizer.fs:124:35:  0 $7DFF9A013568 throw
> 
> : fceil ( r1 -- r2 )  fnegate floor fnegate ;  ok
> 1.9e fceil f. 2.  ok
> -1.9e fceil f. -1.  ok
> 
> 

You may want to check the behavior of FLOOR and FCEIL with IEEE special 
values, if your Forth system supports them. The following code should 
run on both 32-bit and 64-bit Forth systems, with or without a separate 
fp stack. Some of the tests may be redundant.

--
KM

\ ============
\ Requires ttester.4th

DECIMAL
0e fconstant F=ZERO
HEX

\ Make an IEEE 754 double precision floating point value from
\ the specified bits for the sign, binary fraction, and exponent.
\ Return the fp value and error code with the following meaning:
\   0  no error
\   1  exponent out of range
\   2  fraction out of range
fvariable temp

: MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
     dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
     14 lshift 3 pick 1F lshift or >r
     dup 100000 u< invert IF
       r> 2drop 2drop F=ZERO 2 EXIT
     THEN
     r> or [ temp 4 + ] literal L! temp L!
     drop temp df@ 0 ;


\ Constants representing  -0e -INF  +INF  -NAN  +NAN

true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]

[DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
[DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]

DECIMAL

: FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;

\ Testing F= for positive and negative special values
t{ +INF -INF F= -> false }t
t{ +NAN -NAN F= -> true }t
t{ F=ZERO F=-ZERO F= -> true }t


1 cells 4 < Abort" Tests not available for cell size < 32 bits"
1 cells 8 = constant 64-bit?

\ fetch double float onto the data stack for comparison
64-bit? [IF]
: fetch-df ( addr -- u ) @ ;
: equal-df = ;  \ bitwise equivalence
[ELSE]
: fetch-df ( addr -- ud ) 2@ ;
: equal-df d= ; \ bitwise equivalence
[THEN]

\ Testing bitwise inequality of positive and negative special values

create r1 8 allot   \ allot dfloat
create r2 8 allot   \ allot dfloat

t{ F=ZERO r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +INF r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +NAN r1 DF! -> }t
t{ -NAN r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

TESTING FLOOR with IEEE 754 Special values
t{ F=ZERO FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FLOOR r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FLOOR r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FLOOR r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FLOOR -NAN F= -> true }t
t{ -NAN FLOOR +NAN F= -> true }t
t{ +NAN FLOOR -NAN F= -> true }t
t{ +NAN FLOOR +NAN F= -> true }t

t{  0.1e FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FLOOR r1 DF! -> }t
t{ -1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

TESTING FCEIL with IEEE 745 values
t{ F=ZERO FCEIL r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FCEIL r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FCEIL r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FCEIL -NAN F= -> true }t
t{ -NAN FCEIL +NAN F= -> true }t
t{ +NAN FCEIL -NAN F= -> true }t
t{ +NAN FCEIL +NAN F= -> true }t

t{ 0.1e FCEIL r1 DF! -> }t
t{ 1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

\ end of tests
\ ============

[toc] | [prev] | [next] | [standalone]

#135003

From	peter <peter.noreply@tin.it>
Date	2026-04-28 13:40 +0200
Message-ID	<20260428134002.000057e7@tin.it>
In reply to	#135000

On Mon, 27 Apr 2026 17:39:11 -0500
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

> On 4/23/26 8:14 PM, dxf wrote:
> > On 24/04/2026 9:11 am, Buzz McCool wrote:
> >> $ gforth
> >> Gforth 0.7.9_20260324
> >> ...
> >> Type `help' for basic help
> >>
> >> 1.9e floor  ok f:1
> >> f. 1.  ok
> >>
> >> 1.9e fceil
> >> *the terminal*:6:6: error: Undefined word
> >> 1.9e >>>fceil<<<
> >> Backtrace:
> >> /usr/share/gforth/0.7.9_20260324/kernel/recognizer.fs:124:35:  0 $7DFF9A013568 throw
> > 
> > : fceil ( r1 -- r2 )  fnegate floor fnegate ;  ok
> > 1.9e fceil f. 2.  ok
> > -1.9e fceil f. -1.  ok
> > 
> > 
> 
> You may want to check the behavior of FLOOR and FCEIL with IEEE special 
> values, if your Forth system supports them. The following code should 
> run on both 32-bit and 64-bit Forth systems, with or without a separate 
> fp stack. Some of the tests may be redundant.
> 
> --
> KM
> 
> \ ============
> \ Requires ttester.4th
> 
> DECIMAL
> 0e fconstant F=ZERO
> HEX
> 
> \ Make an IEEE 754 double precision floating point value from
> \ the specified bits for the sign, binary fraction, and exponent.
> \ Return the fp value and error code with the following meaning:
> \   0  no error
> \   1  exponent out of range
> \   2  fraction out of range
> fvariable temp
> 
> : MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
>      dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
>      14 lshift 3 pick 1F lshift or >r
>      dup 100000 u< invert IF
>        r> 2drop 2drop F=ZERO 2 EXIT
>      THEN
>      r> or [ temp 4 + ] literal L! temp L!
>      drop temp df@ 0 ;
> 
> 
> \ Constants representing  -0e -INF  +INF  -NAN  +NAN
> 
> true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
> true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]
> 
> [DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
> true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
> [DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]
> 
> DECIMAL
> 
> : FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;
> 
> \ Testing F= for positive and negative special values
> t{ +INF -INF F= -> false }t
> t{ +NAN -NAN F= -> true }t
> t{ F=ZERO F=-ZERO F= -> true }t

How is your F= defined?
I see that it returns true for comparing two nans.
Shouldn't that return false in IEEE fp math?

BR
Peter


> 
> 1 cells 4 < Abort" Tests not available for cell size < 32 bits"
> 1 cells 8 = constant 64-bit?
> 
> \ fetch double float onto the data stack for comparison
> 64-bit? [IF]
> : fetch-df ( addr -- u ) @ ;
> : equal-df = ;  \ bitwise equivalence
> [ELSE]
> : fetch-df ( addr -- ud ) 2@ ;
> : equal-df d= ; \ bitwise equivalence
> [THEN]
> 
> \ Testing bitwise inequality of positive and negative special values
> 
> create r1 8 allot   \ allot dfloat
> create r2 8 allot   \ allot dfloat
> 
> t{ F=ZERO r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> t{ +INF r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> t{ +NAN r1 DF! -> }t
> t{ -NAN r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> TESTING FLOOR with IEEE 754 Special values
> t{ F=ZERO FLOOR r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ F=-ZERO FLOOR r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -INF FLOOR r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ +INF FLOOR r1 DF! -> }t
> t{ +INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -NAN FLOOR -NAN F= -> true }t
> t{ -NAN FLOOR +NAN F= -> true }t
> t{ +NAN FLOOR -NAN F= -> true }t
> t{ +NAN FLOOR +NAN F= -> true }t
> 
> t{  0.1e FLOOR r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -0.1e FLOOR r1 DF! -> }t
> t{ -1.0e r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> TESTING FCEIL with IEEE 745 values
> t{ F=ZERO FCEIL r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ F=-ZERO FCEIL r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -INF FCEIL r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ +INF FCEIL r1 DF! -> }t
> t{ +INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -NAN FCEIL -NAN F= -> true }t
> t{ -NAN FCEIL +NAN F= -> true }t
> t{ +NAN FCEIL -NAN F= -> true }t
> t{ +NAN FCEIL +NAN F= -> true }t
> 
> t{ 0.1e FCEIL r1 DF! -> }t
> t{ 1.0e r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -0.1e FCEIL r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> \ end of tests
> \ ============
> 
> 
> 
>

[toc] | [prev] | [next] | [standalone]

#135004

From	minforth <minforth@gmx.net>
Date	2026-04-28 14:01 +0200
Message-ID	<n5blt5F2t8dU1@mid.individual.net>
In reply to	#135003

Am 28.04.2026 um 13:40 schrieb peter:
> On Mon, 27 Apr 2026 17:39:11 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> 
>> On 4/23/26 8:14 PM, dxf wrote:
>>> On 24/04/2026 9:11 am, Buzz McCool wrote:
>>>> $ gforth
>>>> Gforth 0.7.9_20260324
>>>> ...
>>>> Type `help' for basic help
>>>>
>>>> 1.9e floor  ok f:1
>>>> f. 1.  ok
>>>>
>>>> 1.9e fceil
>>>> *the terminal*:6:6: error: Undefined word
>>>> 1.9e >>>fceil<<<
>>>> Backtrace:
>>>> /usr/share/gforth/0.7.9_20260324/kernel/recognizer.fs:124:35:  0 $7DFF9A013568 throw
>>>
>>> : fceil ( r1 -- r2 )  fnegate floor fnegate ;  ok
>>> 1.9e fceil f. 2.  ok
>>> -1.9e fceil f. -1.  ok
>>>
>>>
>>
>> You may want to check the behavior of FLOOR and FCEIL with IEEE special
>> values, if your Forth system supports them. The following code should
>> run on both 32-bit and 64-bit Forth systems, with or without a separate
>> fp stack. Some of the tests may be redundant.
>>
>> --
>> KM
>>
>> \ ============
>> \ Requires ttester.4th
>>
>> DECIMAL
>> 0e fconstant F=ZERO
>> HEX
>>
>> \ Make an IEEE 754 double precision floating point value from
>> \ the specified bits for the sign, binary fraction, and exponent.
>> \ Return the fp value and error code with the following meaning:
>> \   0  no error
>> \   1  exponent out of range
>> \   2  fraction out of range
>> fvariable temp
>>
>> : MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
>>       dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
>>       14 lshift 3 pick 1F lshift or >r
>>       dup 100000 u< invert IF
>>         r> 2drop 2drop F=ZERO 2 EXIT
>>       THEN
>>       r> or [ temp 4 + ] literal L! temp L!
>>       drop temp df@ 0 ;
>>
>>
>> \ Constants representing  -0e -INF  +INF  -NAN  +NAN
>>
>> true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
>> true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]
>>
>> [DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
>> true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
>> [DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]
>>
>> DECIMAL
>>
>> : FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;
>>
>> \ Testing F= for positive and negative special values
>> t{ +INF -INF F= -> false }t
>> t{ +NAN -NAN F= -> true }t
>> t{ F=ZERO F=-ZERO F= -> true }t
> 
> How is your F= defined?
> I see that it returns true for comparing two nans.
> Shouldn't that return false in IEEE fp math?
F= is undefined in standard Forth. However common sense should prevail
indeed, or IOW the principle of least surprise.

[toc] | [prev] | [next] | [standalone]

#135008

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-28 19:25 -0500
Message-ID	<10srj60$3htnj$1@dont-email.me>
In reply to	#135003

On 4/28/26 6:40 AM, peter wrote:
> On Mon, 27 Apr 2026 17:39:11 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> 
...
>>
>> \ Testing F= for positive and negative special values
>> t{ +INF -INF F= -> false }t
>> t{ +NAN -NAN F= -> true }t
>> t{ F=ZERO F=-ZERO F= -> true }t
> 
> How is your F= defined?
> I see that it returns true for comparing two nans.
> Shouldn't that return false in IEEE fp math?
> 
> BR
> Peter
I was just looking for my IEEE 754 documentation, but I think you are 
correct that +NAN should not equal itself or -NAN, since the equality 
comparison is not valid for NANs.

I am using the x87 FCOMP instruction, which I expected to have 
IEEE-compatible behavior. Will need to look closer at this.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135009

From	dxf <dxforth@gmail.com>
Date	2026-04-29 11:20 +1000
Message-ID	<69f15ce7$1@news.ausics.net>
In reply to	#135008

On 29/04/2026 10:25 am, Krishna Myneni wrote:
> On 4/28/26 6:40 AM, peter wrote:
>> On Mon, 27 Apr 2026 17:39:11 -0500
>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>
> ...
>>>
>>> \ Testing F= for positive and negative special values
>>> t{ +INF -INF F= -> false }t
>>> t{ +NAN -NAN F= -> true }t
>>> t{ F=ZERO F=-ZERO F= -> true }t
>>
>> How is your F= defined?
>> I see that it returns true for comparing two nans.
>> Shouldn't that return false in IEEE fp math?
>>
>> BR
>> Peter
> I was just looking for my IEEE 754 documentation, but I think you are correct that +NAN should not equal itself or -NAN, since the equality comparison is not valid for NANs.
> 
> I am using the x87 FCOMP instruction, which I expected to have IEEE-compatible behavior. Will need to look closer at this.

I used FCOMP and got the expected results.

\ fsp points to separate f/p stack in memory
label tst
  addr fsp ) di mov
  qword 1 floats [di] fld  qword 0 [di] fld  fcompp
  ax fstsw  st(0) fstp  2 floats # addr fsp ) add
  41 # ah and  bx bx sub  cl ah cmp  1 $ jnz  bx dec
1 $:  bx push  next
end-code

code F< ( r1 r2 -- flag )  00 # cl mov  tst ju  end-code
code F> ( r1 r2 -- flag )  01 # cl mov  tst ju  end-code
code F= ( r1 r2 -- flag )  40 # cl mov  tst ju  end-code

+NAN +NAN F= . 0  ok
+NAN -NAN F= . 0  ok

[toc] | [prev] | [next] | [standalone]

#135016

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-29 08:30 -0500
Message-ID	<10st150$3uddf$1@dont-email.me>
In reply to	#135009

On 4/28/26 8:20 PM, dxf wrote:
> On 29/04/2026 10:25 am, Krishna Myneni wrote:
>> On 4/28/26 6:40 AM, peter wrote:
>>> On Mon, 27 Apr 2026 17:39:11 -0500
>>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>>
>> ...
>>>>
>>>> \ Testing F= for positive and negative special values
>>>> t{ +INF -INF F= -> false }t
>>>> t{ +NAN -NAN F= -> true }t
>>>> t{ F=ZERO F=-ZERO F= -> true }t
>>>
>>> How is your F= defined?
>>> I see that it returns true for comparing two nans.
>>> Shouldn't that return false in IEEE fp math?
>>>
>>> BR
>>> Peter
>> I was just looking for my IEEE 754 documentation, but I think you are correct that +NAN should not equal itself or -NAN, since the equality comparison is not valid for NANs.
>>
>> I am using the x87 FCOMP instruction, which I expected to have IEEE-compatible behavior. Will need to look closer at this.
> 
> I used FCOMP and got the expected results.
> 
> \ fsp points to separate f/p stack in memory
> label tst
>    addr fsp ) di mov
>    qword 1 floats [di] fld  qword 0 [di] fld  fcompp
>    ax fstsw  st(0) fstp  2 floats # addr fsp ) add
>    41 # ah and  bx bx sub  cl ah cmp  1 $ jnz  bx dec
> 1 $:  bx push  next
> end-code
> 
> code F< ( r1 r2 -- flag )  00 # cl mov  tst ju  end-code
> code F> ( r1 r2 -- flag )  01 # cl mov  tst ju  end-code
> code F= ( r1 r2 -- flag )  40 # cl mov  tst ju  end-code
> 
> +NAN +NAN F= . 0  ok
> +NAN -NAN F= . 0  ok
>                                                                                                 
> 

Thank you. There is likely a mistake in handling the flags from FCOMP 
for this case.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135018

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-29 20:15 -0500
Message-ID	<10suagb$b2q0$1@dont-email.me>
In reply to	#135016

On 4/29/26 8:30 AM, Krishna Myneni wrote:
> On 4/28/26 8:20 PM, dxf wrote:
>> On 29/04/2026 10:25 am, Krishna Myneni wrote:
>>> On 4/28/26 6:40 AM, peter wrote:
>>>> On Mon, 27 Apr 2026 17:39:11 -0500
>>>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>>>
>>> ...
>>>>>
>>>>> \ Testing F= for positive and negative special values
>>>>> t{ +INF -INF F= -> false }t
>>>>> t{ +NAN -NAN F= -> true }t
>>>>> t{ F=ZERO F=-ZERO F= -> true }t
>>>>
>>>> How is your F= defined?
>>>> I see that it returns true for comparing two nans.
>>>> Shouldn't that return false in IEEE fp math?
>>>>
>>>> BR
>>>> Peter
>>> I was just looking for my IEEE 754 documentation, but I think you are 
>>> correct that +NAN should not equal itself or -NAN, since the equality 
>>> comparison is not valid for NANs.
>>>
>>> I am using the x87 FCOMP instruction, which I expected to have IEEE- 
>>> compatible behavior. Will need to look closer at this.
>>
>> I used FCOMP and got the expected results.
>>
>> \ fsp points to separate f/p stack in memory
>> label tst
>>    addr fsp ) di mov
>>    qword 1 floats [di] fld  qword 0 [di] fld  fcompp
>>    ax fstsw  st(0) fstp  2 floats # addr fsp ) add
>>    41 # ah and  bx bx sub  cl ah cmp  1 $ jnz  bx dec
>> 1 $:  bx push  next
>> end-code
>>
>> code F< ( r1 r2 -- flag )  00 # cl mov  tst ju  end-code
>> code F> ( r1 r2 -- flag )  01 # cl mov  tst ju  end-code
>> code F= ( r1 r2 -- flag )  40 # cl mov  tst ju  end-code
>>
>> +NAN +NAN F= . 0  ok
>> +NAN -NAN F= . 0  ok
>>
> 
> Thank you. There is likely a mistake in handling the flags from FCOMP 
> for this case.
> 

There was indeed a problem with my logic for the status bits from the 
x87 fpu. They logic was not correct for handling the status word's 
condition bits C0 -- C3 correctly in the case of NANs. I believe 
comparisons with all other IEEE special values work, but I'm not sure we 
have sufficient tests yet to ensure this.

I am presently reviewing the other floating point comparisons (F< F> F<= 
F>=) for correct comparisons with NAN and fixing the logic as needed. 
I'm also writing the trivial tests to check for ieee-compliant 
comparisons with NANs.

kForth-32/64 will be patched by the end of the week.

--
KM

[toc] | [prev] | [next] | [standalone]

#135056

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-05-02 15:56 -0500
Message-ID	<10t5od6$2ee1a$2@dont-email.me>
In reply to	#135018

On 4/29/26 8:15 PM, Krishna Myneni wrote:
> On 4/29/26 8:30 AM, Krishna Myneni wrote:
>> On 4/28/26 8:20 PM, dxf wrote:
...
>>> I used FCOMP and got the expected results.
>>>
>>> \ fsp points to separate f/p stack in memory
>>> label tst
>>>    addr fsp ) di mov
>>>    qword 1 floats [di] fld  qword 0 [di] fld  fcompp
>>>    ax fstsw  st(0) fstp  2 floats # addr fsp ) add
>>>    41 # ah and  bx bx sub  cl ah cmp  1 $ jnz  bx dec
>>> 1 $:  bx push  next
>>> end-code
>>>
>>> code F< ( r1 r2 -- flag )  00 # cl mov  tst ju  end-code
>>> code F> ( r1 r2 -- flag )  01 # cl mov  tst ju  end-code
>>> code F= ( r1 r2 -- flag )  40 # cl mov  tst ju  end-code
>>>
>>> +NAN +NAN F= . 0  ok
>>> +NAN -NAN F= . 0  ok
>>>
>>
>> Thank you. There is likely a mistake in handling the flags from FCOMP 
>> for this case.
>>
> 
> There was indeed a problem with my logic for the status bits from the 
> x87 fpu. They logic was not correct for handling the status word's 
> condition bits C0 -- C3 correctly in the case of NANs. I believe 
> comparisons with all other IEEE special values work, but I'm not sure we 
> have sufficient tests yet to ensure this.
> 
> I am presently reviewing the other floating point comparisons (F< F> F<= 
> F>=) for correct comparisons with NAN and fixing the logic as needed. 
> I'm also writing the trivial tests to check for ieee-compliant 
> comparisons with NANs.
> 
> kForth-32/64 will be patched by the end of the week.
> 

The patches for kForth-32/64 for Linux (v2.8.0 and v0.8.0, respectively) 
are pushed to Github now. They pass the latest version of my test code 
for NANs.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135010

From	dxf <dxforth@gmail.com>
Date	2026-04-29 11:47 +1000
Message-ID	<69f16329$1@news.ausics.net>
In reply to	#135008

On 29/04/2026 10:25 am, Krishna Myneni wrote:
> On 4/28/26 6:40 AM, peter wrote:
>> On Mon, 27 Apr 2026 17:39:11 -0500
>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>
> ...
>>>
>>> \ Testing F= for positive and negative special values
>>> t{ +INF -INF F= -> false }t
>>> t{ +NAN -NAN F= -> true }t
>>> t{ F=ZERO F=-ZERO F= -> true }t
>>
>> How is your F= defined?
>> I see that it returns true for comparing two nans.
>> Shouldn't that return false in IEEE fp math?
>>
>> BR
>> Peter
> I was just looking for my IEEE 754 documentation, but I think you are correct that +NAN should not equal itself or -NAN, since the equality comparison is not valid for NANs.
> 
> I am using the x87 FCOMP instruction, which I expected to have IEEE-compatible behavior. Will need to look closer at this.

If F= works for everything else, check your NAN constants.
Following is for 16-bit forth and double-prec fp.

7FF0 0000 0000 0000 sp@ f@ 2drop 2drop fconstant +INF
FFF0 0000 0000 0000 sp@ f@ 2drop 2drop fconstant -INF
7FF8 0000 0000 0000 sp@ f@ 2drop 2drop fconstant +NAN
FFF8 0000 0000 0000 sp@ f@ 2drop 2drop fconstant -NAN

[toc] | [prev] | [next] | [standalone]

#135023

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-30 04:40 -0500
Message-ID	<10sv81o$ii2l$1@dont-email.me>
In reply to	#135000

On 4/27/26 5:39 PM, Krishna Myneni wrote:
...
> 
> You may want to check the behavior of FLOOR and FCEIL with IEEE special 
> values, if your Forth system supports them. The following code should 
> run on both 32-bit and 64-bit Forth systems, with or without a separate 
> fp stack. Some of the tests may be redundant.
> 
> -- 
> KM
> 
> \ ============
> \ Requires ttester.4th
> 
> DECIMAL
> 0e fconstant F=ZERO
> HEX
> 
> \ Make an IEEE 754 double precision floating point value from
> \ the specified bits for the sign, binary fraction, and exponent.
> \ Return the fp value and error code with the following meaning:
> \   0  no error
> \   1  exponent out of range
> \   2  fraction out of range
...
Below is the corrected test code, for NAN comparisons. The following 
test results were changed from true to false

> t{ +NAN -NAN F= -> true }t
> t{ -NAN FLOOR -NAN F= -> true }t
> t{ -NAN FLOOR +NAN F= -> true }t
> t{ +NAN FLOOR -NAN F= -> true }t
> t{ +NAN FLOOR +NAN F= -> true }t
> t{ -NAN FCEIL -NAN F= -> true }t
> t{ -NAN FCEIL +NAN F= -> true }t
> t{ +NAN FCEIL -NAN F= -> true }t
> t{ +NAN FCEIL +NAN F= -> true }t 


Please try the revised tests, below, on your Forth system if it is 
intended to be IEEE 754-compliant.

--
KM


\ ============
\ Requires ttester.4th


DECIMAL
0e fconstant F=ZERO
HEX

\ Make an IEEE 754 double precision floating point value from
\ the specified bits for the sign, binary fraction, and exponent.
\ Return the fp value and error code with the following meaning:
\   0  no error
\   1  exponent out of range
\   2  fraction out of range
fvariable temp

: MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
     dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
     14 lshift 3 pick 1F lshift or >r
     dup 100000 u< invert IF
       r> 2drop 2drop F=ZERO 2 EXIT
     THEN
     r> or [ temp 4 + ] literal L! temp L!
     drop temp df@ 0 ;


\ Constants representing  -0e -INF  +INF  -NAN  +NAN

true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]

[DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
[DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]

DECIMAL

: FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;

\ Testing F= for positive and negative special values
t{ +INF -INF F= -> false }t
t{ +NAN -NAN F= -> false }t
t{ F=ZERO F=-ZERO F= -> true }t


1 cells 4 < Abort" Tests not available for cell size < 32 bits"
1 cells 8 = constant 64-bit?

\ fetch double float onto the data stack for comparison
64-bit? [IF]
: fetch-df ( addr -- u ) @ ;
: equal-df = ;  \ bitwise equivalence
[ELSE]
: fetch-df ( addr -- ud ) 2@ ;
: equal-df d= ; \ bitwise equivalence
[THEN]

\ Testing bitwise inequality of positive and negative special values

create r1 8 allot   \ allot dfloat
create r2 8 allot   \ allot dfloat

t{ F=ZERO r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +INF r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +NAN r1 DF! -> }t
t{ -NAN r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

TESTING FLOOR with IEEE 754 Special values
t{ F=ZERO FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FLOOR r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FLOOR r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FLOOR r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FLOOR -NAN F= -> false }t
t{ -NAN FLOOR +NAN F= -> false }t
t{ +NAN FLOOR -NAN F= -> false }t
t{ +NAN FLOOR +NAN F= -> false }t

t{  0.1e FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FLOOR r1 DF! -> }t
t{ -1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

TESTING FCEIL with IEEE 745 values
t{ F=ZERO FCEIL r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FCEIL r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FCEIL r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FCEIL -NAN F= -> false }t
t{ -NAN FCEIL +NAN F= -> false }t
t{ +NAN FCEIL -NAN F= -> false }t
t{ +NAN FCEIL +NAN F= -> false }t

t{ 0.1e FCEIL r1 DF! -> }t
t{ 1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

\ end of tests
\ ============

[toc] | [prev] | [next] | [standalone]

#135024

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-30 05:37 -0500
Message-ID	<10svbcp$ii2l$2@dont-email.me>
In reply to	#135023

On 4/30/26 4:40 AM, Krishna Myneni wrote:
> On 4/27/26 5:39 PM, Krishna Myneni wrote:
> ...

Just realized that the following tests are doing nothing more than 
testing F= rather than testing FLOOR and FCEIL. In order to test that 
FLOOR and FCEIL are returning a valid NAN, one should check the bit 
pattern against any valid representation of a NAN.

> t{ -NAN FLOOR -NAN F= -> false }t
> t{ -NAN FLOOR +NAN F= -> false }t
> t{ +NAN FLOOR -NAN F= -> false }t
> t{ +NAN FLOOR +NAN F= -> false }t
> 

> t{ -NAN FCEIL -NAN F= -> false }t
> t{ -NAN FCEIL +NAN F= -> false }t
> t{ +NAN FCEIL -NAN F= -> false }t
> t{ +NAN FCEIL +NAN F= -> false }t
> 
Meaningful tests for FLOOR and FCEIL may be done with the word FNAN? 
which checks for any valid representation of NAN. Thus the tests above 
should be replaced by

t{ -NAN FLOOR FNAN? -> true }t
t{ +NAN FLOOR FNAN? -> true }t

t{ -NAN FCEIL FNAN? -> true }t
t{ +NAN FLOOR FNAN? -> true }t

The word FNAN? is defined below. Your system must provide the following 
words:

L!  ( n addr -- )  \ perform a 32-bit store to addr
UL@ ( addr -- u )  \ perform an unsigned 32-bit fetch from addr

For 32-bit systems L! and UL@ are simply ! and @ .
64-bit systems will need to provide these words intrinsically.

The revised test code is given below.

--
KM

\ ============
\ Requires ttester.4th

DECIMAL

1 cells 4 < Abort" Tests not available for cell size < 32 bits"
1 cells 8 = constant 64-bit?

\ fetch double float onto the data stack for comparison
64-bit? [IF]
: fetch-df ( addr -- u ) @ ;
: equal-df = ;  \ bitwise equivalence
[ELSE]
: fetch-df ( addr -- ud ) 2@ ;
: equal-df d= ; \ bitwise equivalence
[THEN]

0e fconstant F=ZERO
HEX

\ Make an IEEE 754 double precision floating point value from
\ the specified bits for the sign, binary fraction, and exponent.
\ Return the fp value and error code with the following meaning:
\   0  no error
\   1  exponent out of range
\   2  fraction out of range
fvariable temp

: MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
     dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
     14 lshift 3 pick 1F lshift or >r
     dup 100000 u< invert IF
       r> 2drop 2drop F=ZERO 2 EXIT
     THEN
     r> or [ temp 4 + ] literal L! temp L!
     drop temp df@ 0 ;

: FSIGNBIT ( F: r -- ) ( -- minus? )
     temp df! [ temp 4 + ] literal UL@ 80000000 and 0<> ;

: FEXPONENT ( F: r -- ) ( -- u )
     temp df! [ temp 4 + ] literal UL@ 14 rshift 7FF and ;

: FFRACTION ( F: r -- ) ( -- ud )
     temp df! temp UL@  [ temp 4 + ] literal UL@ 000FFFFF and ;

: FINITE?  ( F: r -- ) ( -- [normal|subnormal]? ) fexponent 7FF <> ;

: FNORMAL? ( F: r -- ) ( -- normal? )  fexponent 0<> ;

: FSUBNORMAL? ( F: r -- ) ( -- subnormal? )  fexponent 0= ;

: FINFINITE? ( F: r -- ) ( -- [+/-]Inf? )
    finite? invert ;

: FNAN? ( F: r -- ) ( -- nan? )
    fdup FEXPONENT 7FF = >r FFRACTION D0= invert r> and ;

\ Constants representing  -0e -INF  +INF  -NAN  +NAN

true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]

[DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
[DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]

DECIMAL

: FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;

\ Testing F= for positive and negative special values
t{ +INF -INF F= -> false }t
t{ F=ZERO F=-ZERO F= -> true }t
t{ +NAN -NAN F= -> false }t

\ Verify FNAN? recognizes both +NAN and -NAN as a NAN
t{ +NAN FNAN? -> true }t
t{ -NAN FNAN? -> true }t

\ Testing bitwise inequality of positive and negative special values

create r1 8 allot   \ allot dfloat
create r2 8 allot   \ allot dfloat

t{ F=ZERO r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +INF r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

t{ +NAN r1 DF! -> }t
t{ -NAN r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> false }t

TESTING FLOOR with IEEE 754 Special values
t{ F=ZERO FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FLOOR r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FLOOR r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FLOOR r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FLOOR FNAN? -> true }t
t{ +NAN FLOOR FNAN? -> true }t

t{  0.1e FLOOR r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FLOOR r1 DF! -> }t
t{ -1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

TESTING FCEIL with IEEE 745 values
t{ F=ZERO FCEIL r1 DF! -> }t
t{ F=ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ F=-ZERO FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -INF FCEIL r1 DF! -> }t
t{ -INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ +INF FCEIL r1 DF! -> }t
t{ +INF r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -NAN FCEIL FNAN? -> true }t
t{ +NAN FCEIL FNAN? -> true }t

t{ 0.1e FCEIL r1 DF! -> }t
t{ 1.0e r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

t{ -0.1e FCEIL r1 DF! -> }t
t{ F=-ZERO r2 DF! -> }t
t{ r1 fetch-df r2 fetch-df equal-df -> true }t

\ end of tests
\ ============

[toc] | [prev] | [next] | [standalone]

#135025

From	peter <peter.noreply@tin.it>
Date	2026-04-30 15:55 +0200
Message-ID	<20260430155547.000018f1@tin.it>
In reply to	#135024

On Thu, 30 Apr 2026 05:37:13 -0500
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

> On 4/30/26 4:40 AM, Krishna Myneni wrote:
> > On 4/27/26 5:39 PM, Krishna Myneni wrote:
> > ...
> 
> Just realized that the following tests are doing nothing more than 
> testing F= rather than testing FLOOR and FCEIL. In order to test that 
> FLOOR and FCEIL are returning a valid NAN, one should check the bit 
> pattern against any valid representation of a NAN.
> 
> > t{ -NAN FLOOR -NAN F= -> false }t
> > t{ -NAN FLOOR +NAN F= -> false }t
> > t{ +NAN FLOOR -NAN F= -> false }t
> > t{ +NAN FLOOR +NAN F= -> false }t
> > 
> 
> > t{ -NAN FCEIL -NAN F= -> false }t
> > t{ -NAN FCEIL +NAN F= -> false }t
> > t{ +NAN FCEIL -NAN F= -> false }t
> > t{ +NAN FCEIL +NAN F= -> false }t
> > 
> Meaningful tests for FLOOR and FCEIL may be done with the word FNAN? 
> which checks for any valid representation of NAN. Thus the tests above 
> should be replaced by
> 
> t{ -NAN FLOOR FNAN? -> true }t
> t{ +NAN FLOOR FNAN? -> true }t
> 
> t{ -NAN FCEIL FNAN? -> true }t
> t{ +NAN FLOOR FNAN? -> true }t
> 
> The word FNAN? is defined below. Your system must provide the following 
> words:
> 
> L!  ( n addr -- )  \ perform a 32-bit store to addr
> UL@ ( addr -- u )  \ perform an unsigned 32-bit fetch from addr
> 
> For 32-bit systems L! and UL@ are simply ! and @ .
> 64-bit systems will need to provide these words intrinsically.
> 
> The revised test code is given below.

Now the test cases run without error on both lxf and lxf64

In lxf64 ABORT" is a compile only word so I just commented out that

I have L@ for zero extended fetch and <L@ for sign extended.
That works well also for C@ and <C@ ( and W@, <W@)

I had already FNAN? defined as : FNAN? FDUP F<> ;

Thanks for your test program I found that I had misspelled FCEIL
It was named FCIEL, probably after the Italian word cielo (sky)
( I live since more that 30 years in Italy)

More importantly I found that f< and friends behaved differently
when they were followed by an IF, not always treating nans correctly

BR
Peter

> 
> --
> KM
> 
> \ ============
> \ Requires ttester.4th
> 
> DECIMAL
> 
> 1 cells 4 < Abort" Tests not available for cell size < 32 bits"
> 1 cells 8 = constant 64-bit?
> 
> \ fetch double float onto the data stack for comparison
> 64-bit? [IF]
> : fetch-df ( addr -- u ) @ ;
> : equal-df = ;  \ bitwise equivalence
> [ELSE]
> : fetch-df ( addr -- ud ) 2@ ;
> : equal-df d= ; \ bitwise equivalence
> [THEN]
> 
> 0e fconstant F=ZERO
> HEX
> 
> \ Make an IEEE 754 double precision floating point value from
> \ the specified bits for the sign, binary fraction, and exponent.
> \ Return the fp value and error code with the following meaning:
> \   0  no error
> \   1  exponent out of range
> \   2  fraction out of range
> fvariable temp
> 
> : MAKE-IEEE-DFLOAT ( signbit udfraction uexp -- r nerror )
>      dup 800 u< invert IF 2drop 2drop F=ZERO 1 EXIT THEN
>      14 lshift 3 pick 1F lshift or >r
>      dup 100000 u< invert IF
>        r> 2drop 2drop F=ZERO 2 EXIT
>      THEN
>      r> or [ temp 4 + ] literal L! temp L!
>      drop temp df@ 0 ;
> 
> : FSIGNBIT ( F: r -- ) ( -- minus? )
>      temp df! [ temp 4 + ] literal UL@ 80000000 and 0<> ;
> 
> : FEXPONENT ( F: r -- ) ( -- u )
>      temp df! [ temp 4 + ] literal UL@ 14 rshift 7FF and ;
> 
> : FFRACTION ( F: r -- ) ( -- ud )
>      temp df! temp UL@  [ temp 4 + ] literal UL@ 000FFFFF and ;
> 
> : FINITE?  ( F: r -- ) ( -- [normal|subnormal]? ) fexponent 7FF <> ;
> 
> : FNORMAL? ( F: r -- ) ( -- normal? )  fexponent 0<> ;
> 
> : FSUBNORMAL? ( F: r -- ) ( -- subnormal? )  fexponent 0= ;
> 
> : FINFINITE? ( F: r -- ) ( -- [+/-]Inf? )
>     finite? invert ;
> 
> : FNAN? ( F: r -- ) ( -- nan? )
>     fdup FEXPONENT 7FF = >r FFRACTION D0= invert r> and ;
> 
> \ Constants representing  -0e -INF  +INF  -NAN  +NAN
> 
> true 0 0 0 make-ieee-dfloat [IF] fdrop [ELSE] fconstant F=-ZERO [THEN]
> true 0 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -INF [THEN]
> 
> [DEFINED] -INF [IF] -INF fnegate fconstant +INF [THEN]
> true  1 0 7FF make-ieee-dfloat [IF] fdrop [ELSE] fconstant -NAN [THEN]
> [DEFINED] -NAN [IF] -NAN fnegate fconstant +NAN [THEN]
> 
> DECIMAL
> 
> : FCEIL ( F: r1 -- r2 ) FNEGATE FLOOR FNEGATE ;
> 
> \ Testing F= for positive and negative special values
> t{ +INF -INF F= -> false }t
> t{ F=ZERO F=-ZERO F= -> true }t
> t{ +NAN -NAN F= -> false }t
> 
> \ Verify FNAN? recognizes both +NAN and -NAN as a NAN
> t{ +NAN FNAN? -> true }t
> t{ -NAN FNAN? -> true }t
> 
> \ Testing bitwise inequality of positive and negative special values
> 
> create r1 8 allot   \ allot dfloat
> create r2 8 allot   \ allot dfloat
> 
> t{ F=ZERO r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> t{ +INF r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> t{ +NAN r1 DF! -> }t
> t{ -NAN r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> false }t
> 
> TESTING FLOOR with IEEE 754 Special values
> t{ F=ZERO FLOOR r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ F=-ZERO FLOOR r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -INF FLOOR r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ +INF FLOOR r1 DF! -> }t
> t{ +INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -NAN FLOOR FNAN? -> true }t
> t{ +NAN FLOOR FNAN? -> true }t
> 
> t{  0.1e FLOOR r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -0.1e FLOOR r1 DF! -> }t
> t{ -1.0e r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> TESTING FCEIL with IEEE 745 values
> t{ F=ZERO FCEIL r1 DF! -> }t
> t{ F=ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ F=-ZERO FCEIL r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -INF FCEIL r1 DF! -> }t
> t{ -INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ +INF FCEIL r1 DF! -> }t
> t{ +INF r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -NAN FCEIL FNAN? -> true }t
> t{ +NAN FCEIL FNAN? -> true }t
> 
> t{ 0.1e FCEIL r1 DF! -> }t
> t{ 1.0e r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> t{ -0.1e FCEIL r1 DF! -> }t
> t{ F=-ZERO r2 DF! -> }t
> t{ r1 fetch-df r2 fetch-df equal-df -> true }t
> 
> \ end of tests
> \ ============
> 
>

[toc] | [prev] | [next] | [standalone]

#135031

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-04-30 20:49 -0500
Message-ID	<10t10r1$13p4b$1@dont-email.me>
In reply to	#135025

On 4/30/26 8:55 AM, peter wrote:
> On Thu, 30 Apr 2026 05:37:13 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> 
>> On 4/30/26 4:40 AM, Krishna Myneni wrote:
>>> On 4/27/26 5:39 PM, Krishna Myneni wrote:
>>> ...
>>
>> Just realized that the following tests are doing nothing more than
>> testing F= rather than testing FLOOR and FCEIL. In order to test that
>> FLOOR and FCEIL are returning a valid NAN, one should check the bit
>> pattern against any valid representation of a NAN.
>>
>>> t{ -NAN FLOOR -NAN F= -> false }t
>>> t{ -NAN FLOOR +NAN F= -> false }t
>>> t{ +NAN FLOOR -NAN F= -> false }t
>>> t{ +NAN FLOOR +NAN F= -> false }t
>>>
>>
>>> t{ -NAN FCEIL -NAN F= -> false }t
>>> t{ -NAN FCEIL +NAN F= -> false }t
>>> t{ +NAN FCEIL -NAN F= -> false }t
>>> t{ +NAN FCEIL +NAN F= -> false }t
>>>
>> Meaningful tests for FLOOR and FCEIL may be done with the word FNAN?
>> which checks for any valid representation of NAN. Thus the tests above
>> should be replaced by
>>
>> t{ -NAN FLOOR FNAN? -> true }t
>> t{ +NAN FLOOR FNAN? -> true }t
>>
>> t{ -NAN FCEIL FNAN? -> true }t
>> t{ +NAN FLOOR FNAN? -> true }t
>>
>> The word FNAN? is defined below. Your system must provide the following
>> words:
>>
>> L!  ( n addr -- )  \ perform a 32-bit store to addr
>> UL@ ( addr -- u )  \ perform an unsigned 32-bit fetch from addr
>>
>> For 32-bit systems L! and UL@ are simply ! and @ .
>> 64-bit systems will need to provide these words intrinsically.
>>
>> The revised test code is given below.
> 
> Now the test cases run without error on both lxf and lxf64
> 
> In lxf64 ABORT" is a compile only word so I just commented out that
> 
> I have L@ for zero extended fetch and <L@ for sign extended.
> That works well also for C@ and <C@ ( and W@, <W@)
> 
> I had already FNAN? defined as : FNAN? FDUP F<> ;
> 
> Thanks for your test program I found that I had misspelled FCEIL
> It was named FCIEL, probably after the Italian word cielo (sky)
> ( I live since more that 30 years in Italy)
> 
> More importantly I found that f< and friends behaved differently
> when they were followed by an IF, not always treating nans correctly
> 

Great. Needless to say the exercise helped me as well. There is a memory 
words proposal that deals with words like UL@ etc. but I'm not sure 
where it is in the pipeline right now. Gforth also uses UL@ for unsigned 
32-bit fetch. kForth uses UL@ and SL@ for unsigned and signed, 
respectively, and we have UW@ and SW@ -- the mnemonic prefix helps me to 
use the correct version, especially given how different Forth systems 
treated W@ as unsigned in some systems and signed in others.

My definition of FNAN? goes by the ieee 754 definition of what 
constitutes a NAN, but there may be no practical difference in the two 
definitions.

I'm guessing you have a flag use conflict if F< behaves differently when 
it is followed by an IF.

I need to review all of the IEEE fp test code written by the late David 
N Williams -- I would like to fill in any missing pieces.

Cheers,
Krishna

[toc] | [prev] | [next] | [standalone]

#135033 — Special memory access words (was: GNU Forth has a ...)

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2026-05-01 06:16 +0000
Subject	Special memory access words (was: GNU Forth has a ...)
Message-ID	<2026May1.081638@mips.complang.tuwien.ac.at>
In reply to	#135031

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>There is a memory 
>words proposal that deals with words like UL@ etc. but I'm not sure 
>where it is in the pipeline right now. Gforth also uses UL@ for unsigned 
>32-bit fetch. kForth uses UL@ and SL@ for unsigned and signed, 
>respectively, and we have UW@ and SW@ -- the mnemonic prefix helps me to 
>use the correct version, especially given how different Forth systems 
>treated W@ as unsigned in some systems and signed in others.

The current state of the proposal is:

https://forth-standard.org/proposals/special-memory-access-words?hideDiff#reply-1531

The state is that the committee likes the proposal and I have to find
the time to do a reference implementation and tests to complete it,
then it should progress further.

As for sw@ and uw@, I used to advocate that approach and precomposed
words in general, but once you add byte-order variations, you get a
lot of words; with precomposed words the W set alone would consist of:

be-sw@ le-sw@ sw@ be-uw@ le-uw@ uw@ be-w! le-w! w!

compared to

w@ w! wbe wle w>s

in the proposal.  Moreover, once you add stuff like "w,", you either
need precomposed versions of that, too, or you need to introduce wbe
and wle anyway.

So eventually I became convinced of the decomposed approach.  W@
produces an zero-extended (unsigned) result in the proposal.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135036 — Re: Special memory access words (was: GNU Forth has a ...)

From	peter <peter.noreply@tin.it>
Date	2026-05-01 10:22 +0200
Subject	Re: Special memory access words (was: GNU Forth has a ...)
Message-ID	<20260501102253.00007757@tin.it>
In reply to	#135033

On Fri, 01 May 2026 06:16:38 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
> >There is a memory 
> >words proposal that deals with words like UL@ etc. but I'm not sure 
> >where it is in the pipeline right now. Gforth also uses UL@ for unsigned 
> >32-bit fetch. kForth uses UL@ and SL@ for unsigned and signed, 
> >respectively, and we have UW@ and SW@ -- the mnemonic prefix helps me to 
> >use the correct version, especially given how different Forth systems 
> >treated W@ as unsigned in some systems and signed in others.
> 
> The current state of the proposal is:
> 
> https://forth-standard.org/proposals/special-memory-access-words?hideDiff#reply-1531
> 
> The state is that the committee likes the proposal and I have to find
> the time to do a reference implementation and tests to complete it,
> then it should progress further.
> 
> As for sw@ and uw@, I used to advocate that approach and precomposed
> words in general, but once you add byte-order variations, you get a
> lot of words; with precomposed words the W set alone would consist of:
> 
> be-sw@ le-sw@ sw@ be-uw@ le-uw@ uw@ be-w! le-w! w!
> 
> compared to
> 
> w@ w! wbe wle w>s
> 
> in the proposal.  Moreover, once you add stuff like "w,", you either
> need precomposed versions of that, too, or you need to introduce wbe
> and wle anyway.
> 
> So eventually I became convinced of the decomposed approach.  W@
> produces an zero-extended (unsigned) result in the proposal.

Whatever the standard will be I will continue with <w@, <C@ etc
They are a great visual help to see the intent.
They are used only in the internals of the compilers and decompilers
and will compile to just one cpu opcode

For the byte order I agree with the proposal be-sw@ looks horrible

BR
Peter

> 
> - anton

[toc] | [prev] | [next] | [standalone]

#135037 — Re: Special memory access words (was: GNU Forth has a ...)

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2026-05-01 08:57 +0000
Subject	Re: Special memory access words (was: GNU Forth has a ...)
Message-ID	<2026May1.105706@mips.complang.tuwien.ac.at>
In reply to	#135036

peter <peter.noreply@tin.it> writes:
>Whatever the standard will be I will continue with <w@, <C@ etc
>They are a great visual help to see the intent.
>They are used only in the internals of the compilers and decompilers
>and will compile to just one cpu opcode

gforth-fast compiles "w@ w>s" into one native instruction, too:

: <w@ w@ w>s ;  ok
see-code <w@ 
<<w@>         w@ w>s     1->1 
<<w@+$8>      w>s    1->1 
   $7FB4A3871B18: movswq 0x0(%r13),%r13
<<w@+$10>     ;s    1->1 
...

It works even with "w@ wle w>s".

>For the byte order I agree with the proposal be-sw@ looks horrible

With the proposal one would write "w@ wbe w>s".  That's not
necessarily less horrible.  But these are not words we will use all
the time.

One interesting case is:

: x w@ wbe w>s ;  ok
see-code x 
<x>           w@ w>< w>s     1->1 
<x+$8>        w><    1->1 
<x+$10>       w>s    1->1 
   $7FB4A3871B29: movzwl 0x0(%r13),%r8d
   $7FB4A3871B2E: mov    %r8d,%r13d
   $7FB4A3871B31: rol    $0x8,%r13w
   $7FB4A3871B36: movswq %r13w,%r13
<x+$18>       ;s    1->1 
...

Let's see what happens if we suppress the superinstruction:

: y w@ noop wbe w>s ;
see-code y 
<y>           w@    1->1 
<y+$8>        noop    1->1 
   $7FB4A3871BDA: movzwl 0x0(%r13),%r13d
<y+$10>       w><    1->1 
   $7FB4A3871BDF: rol    $0x8,%r13w
   $7FB4A3871BE4: movzwl %r13w,%r13d
<y+$18>       w>s    1->1 
   $7FB4A3871BE8: movswq %r13w,%r13
<y+$20>       ;s    1->1 
...

Also less than optimal.

A superinstruction for "w>< w>s" may be more useful on this
architecture than the one for "w@ w>< w>s".

The superinstruction for the 32-bit case is optimal:

: z l@ lbe l>s ;  ok
see-code z 
<z>           l@ l>< l>s     1->1 
<z+$8>        l><    1->1 
<z+$10>       l>s    1->1 
   $7FB4A3871BF8: mov    0x0(%r13),%r8d
   $7FB4A3871BFC: bswap  %r8d
   $7FB4A3871BFF: movslq %r8d,%r13
<z+$18>       ;s    1->1 
...

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135043 — Re: Special memory access words

From	Krishna Myneni <krishna.myneni@ccreweb.org>
Date	2026-05-01 10:19 -0500
Subject	Re: Special memory access words
Message-ID	<10t2g9m$1ge30$1@dont-email.me>
In reply to	#135037

On 5/1/26 3:57 AM, Anton Ertl wrote:
> peter <peter.noreply@tin.it> writes:
>> Whatever the standard will be I will continue with <w@, <C@ etc
>> They are a great visual help to see the intent.
>> They are used only in the internals of the compilers and decompilers
>> and will compile to just one cpu opcode
> 
> gforth-fast compiles "w@ w>s" into one native instruction, too:
> 
> : <w@ w@ w>s ;  ok

IIUC, to do an explicit signed word fetch on little endian system one 
would write using the current proposal

W@ WLE W>S

and on a little-endian system, one could get away with writing

W@ W>S


--
Krishna

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

GNU Forth has a floating point floor word, but not floating point ceiling word?

Contents

#134948 — GNU Forth has a floating point floor word, but not floating point ceiling word?

#134949

#134950

#135000

#135003

#135004

#135008

#135009

#135016

#135018

#135056

#135010

#135023

#135024

#135025

#135031

#135033 — Special memory access words (was: GNU Forth has a ...)

#135036 — Re: Special memory access words (was: GNU Forth has a ...)

#135037 — Re: Special memory access words (was: GNU Forth has a ...)

#135043 — Re: Special memory access words