Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Recognizer proposal

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

Contents

  Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-09 07:49 +0000
    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-10 13:36 +0100
      Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-10 17:48 +0000
        Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-11 11:21 +1100
          Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 09:05 +0000
            Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:46 +0100
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:36 +0100
              Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:49 +0000
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 18:37 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:25 +0100
          Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 14:34 +0100
            Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 11:35 +1100
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:24 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:59 +0100
                  Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 10:13 +0000
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:22 +0100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:07 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 20:59 +1100
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:35 +0100
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:30 +0100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:44 +0100
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:35 +0000
              Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:55 +0100
                Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-13 08:27 +0000
                  Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:43 +0100
                    Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-13 23:50 +0000
                      Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 12:53 +1100
                        Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-15 13:33 +0100
                          Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-16 12:18 +1100
                        Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-19 13:42 +0100
                          Evolution of Forths  was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-19 14:38 +0100
                            Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-20 12:33 +1100
                              Re: Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-20 11:58 +0100
                                Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 10:45 +1100
                              Re: Evolution of Forths was Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-21 16:35 +0100
                                Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 13:13 +1100
            Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-25 20:25 -0800
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-26 06:53 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-26 13:09 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-27 20:24 +1100
                Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-27 09:25 +0000
                  Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-27 14:48 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-27 19:21 +0100
                  Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-28 10:15 +1100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-28 15:34 +0100
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-28 17:56 +0100
                    Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-28 22:45 -0800
                      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-01 07:54 +0000
                        Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-01 14:17 -0800
                          Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:21 +0000
                            Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-02 12:36 +0100
                              Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:48 -0800
                        Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:17 +0000
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-26 07:32 -0600
              Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-02 13:23 +0000
                Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-03 13:47 +0100
                  Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-03 14:39 +0000
                    Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:52 -0800
                      Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-06 10:54 +0000
                      Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-06 12:22 +0100
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-07 17:58 +0100
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-03 18:33 +0100
        Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:54 +0100
          Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 13:09 +0000
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 15:59 +0100
              Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:46 +0000
          Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 16:30 +0000
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 12:07 +0100
              Re: Recognizer proposal Lars Brinkhoff <lars.spam@nocrew.org> - 2026-02-12 13:00 +0000
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 12:55 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 14:17 +0100
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:28 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 01:23 +1100
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-16 22:07 -0600
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-17 21:25 +1100
                  Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-17 08:16 -0600
                    Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:32 +0000
                Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-02-17 14:13 +0000
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-17 20:21 +0100
                  Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-18 13:08 +1100
      Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:29 +0100
    Re: Recognizer proposal minforth <minforth@gmx.net> - 2026-02-18 11:14 +0100
      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:40 +0000
        Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-24 02:43 -0600
          Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-08 18:15 -0500
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-09 07:49 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-09 10:37 +0100
                Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-10 07:35 +0000
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-10 12:06 +0100
                    Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:48 -0500
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-09 16:48 -0500
                Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:45 -0500
    Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-18 12:33 +0100
      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:48 +0000
        Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-25 14:11 +0100
    Re: Recognizer proposal NN <november.nihal@gmail.com> - 2026-03-19 19:23 +0000
      Re: Recognizer proposal thresh3@fastmail.com (Lev) - 2026-03-19 23:13 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#134627

On 26/02/2026 12:09, albert@spenarnc.xs4all.nl wrote:
> There are people who are font of 01/02/03 date (2003 januari 2 )
> indications that are examples in Starting Forth.
> You could do this with recognizers (I suppose).

It's better to use the ISO 8601 format YYYY-MM-DD where your example 
date is 2003-01-02 which is unambiguous and easy to sort.

-- 
Gerry

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

#134628

Gerry Jackson <do-not-use@swldwa.uk> writes:
>On 26/02/2026 12:09, albert@spenarnc.xs4all.nl wrote:
>> There are people who are font of 01/02/03 date (2003 januari 2 )
>> indications that are examples in Starting Forth.
>> You could do this with recognizers (I suppose).
>
>It's better to use the ISO 8601 format YYYY-MM-DD where your example 
>date is 2003-01-02 which is unambiguous and easy to sort.

You can recognize both, plus "2.1.2003".  The benefit compared to the
bad old solution of just treating all of them as a double number is
that the recognizer can determine year, month, and day based on the
separator used, as well as identifying the correct day and month
irrespective of whether they are written with one or with two digits.
Unfortunately, I have seen some people use the wrong order-separator
combination, so better give some feedback on what date has been
understood.

- 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]

#134629

On 26-02-2026 13:09, albert@spenarnc.xs4all.nl wrote:
> In article <87qzq8b07r.fsf@nightsong.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> I still think that meddling with the text interpreter is a big no-no
>>> and an invitation to disaster.
>>
>> Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
>> "123.45" change depending on whether the floating point wordset is
>> loaded is also horrible.  Probably best to leave things as they are, and
>> maybe suggest a nonstandard extension to treat 123.45 as a float.  To
>> get a double cell you'd use
> 
> Offically 123.45 is not a double number. It should end with a decimal point.
> 
> How is the support for a proposal:
> 
> Double numbers should start and end with a dot.
> Now any numbers containing a single dot are automatically fp
> 
> A program that uses single dots to indicate doubles, should
> declare an environmental dependancy. The default behaviour it
> that they are floats.
> 
> In this way most programs that uses fp and use single dots are
> fully compliant.
> 
> There are people who are font of 01/02/03 date (2003 januari 2 )
> indications that are examples in Starting Forth.
> You could do this with recognizers (I suppose).
> 
>>
>> It does seem to me that with 32-bit systems widespread, double ints have
>> gotten less important.  I wouldn't want the standard behaviour to
>> change, but I'd probably use the nonstandard extension if it existed.
>> With the extension turned on, to get the double int, you'd use 12345 0
>> or maybe something like "D# 123 45" .
>>
>> Double ints are maybe still useful on 8 bit systems with 16 bit cells.
> 
> I have published yourforth, an altenative to jonesforth. It is 32 bits
> and I have eliminated all double precision crap, contributing to
> it pedagogical value.
> 
> Groetjes Albert

Although I can understand the technical, historical and pragmatic 
reasons of Chuck for (a) signifying a double number by a dot and (b) the 
inclusion of a double number recognizer in the text interpreter, I never 
followed suit.

Double number support was NEVER part of the 4tH core - and frankly, the 
initial idea was even to never support double numbers AT ALL. The 
rationale behind that one was that integers at that time were 32bit 
anyway - the identical precision that double numbers covered - so.. why?

The range of 64bit numbers covers just about everything under the sun, 
so I agree fullheartedly with the idea that double numbers are close to 
complete obsolescence. The last time I used triple numbers was when I 
wrote several IBAN related utilities on a 32-bit platform. Which most 
double number applications boils down to nowadays.

But.. I've been around here for a while and I think given there are 
still people using WORD and vanilla counted strings that the 22nd 
century Forths will still support double numbers - resulting in 1024 bit 
double numbers.

Hans Bezemer

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

#134630

On 28/02/2026 5:21 am, Hans Bezemer wrote:
> ... 
> The range of 64bit numbers covers just about everything under the sun, so I agree fullheartedly with the idea that double numbers are close to complete obsolescence. The last time I used triple numbers was when I wrote several IBAN related utilities on a 32-bit platform. Which most double number applications boils down to nowadays.
> 
> But.. I've been around here for a while and I think given there are still people using WORD and vanilla counted strings that the 22nd century Forths will still support double numbers - resulting in 1024 bit double numbers.

If the hardware, the OS and its applications still specify doubles then
surely Forth has no option but to follow, and Moore's suggestion in his
1989 speech to the ANS-TC that doubles words might be scrapped, somewhat
short-sighted?  On this forum itself, I recall reading posts talking of
crypto apps which apparently requires such numbers and calculations.

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

#134631

In article <nnd$73692009$4971d447@b0f461aaf5ef0059>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>On 26-02-2026 13:09, albert@spenarnc.xs4all.nl wrote:
>> In article <87qzq8b07r.fsf@nightsong.com>,
>> Paul Rubin  <no.email@nospam.invalid> wrote:
>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>> I still think that meddling with the text interpreter is a big no-no
>>>> and an invitation to disaster.
>>>
>>> Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
>>> "123.45" change depending on whether the floating point wordset is
>>> loaded is also horrible.  Probably best to leave things as they are, and
>>> maybe suggest a nonstandard extension to treat 123.45 as a float.  To
>>> get a double cell you'd use
>>
>> Offically 123.45 is not a double number. It should end with a decimal point.
>>
>> How is the support for a proposal:
>>
>> Double numbers should start and end with a dot.
>> Now any numbers containing a single dot are automatically fp
>>
>> A program that uses single dots to indicate doubles, should
>> declare an environmental dependancy. The default behaviour it
>> that they are floats.
>>
>> In this way most programs that uses fp and use single dots are
>> fully compliant.
>>
>> There are people who are font of 01/02/03 date (2003 januari 2 )
>> indications that are examples in Starting Forth.
>> You could do this with recognizers (I suppose).
>>
>>>
>>> It does seem to me that with 32-bit systems widespread, double ints have
>>> gotten less important.  I wouldn't want the standard behaviour to
>>> change, but I'd probably use the nonstandard extension if it existed.
>>> With the extension turned on, to get the double int, you'd use 12345 0
>>> or maybe something like "D# 123 45" .
>>>
>>> Double ints are maybe still useful on 8 bit systems with 16 bit cells.
>>
>> I have published yourforth, an altenative to jonesforth. It is 32 bits
>> and I have eliminated all double precision crap, contributing to
>> it pedagogical value.
>>
>> Groetjes Albert
>
>Although I can understand the technical, historical and pragmatic
>reasons of Chuck for (a) signifying a double number by a dot and (b) the
>inclusion of a double number recognizer in the text interpreter, I never
>followed suit.
>
>Double number support was NEVER part of the 4tH core - and frankly, the
>initial idea was even to never support double numbers AT ALL. The
>rationale behind that one was that integers at that time were 32bit
>anyway - the identical precision that double numbers covered - so.. why?
>
>The range of 64bit numbers covers just about everything under the sun,
>so I agree fullheartedly with the idea that double numbers are close to
>complete obsolescence. The last time I used triple numbers was when I
>wrote several IBAN related utilities on a 32-bit platform. Which most
>double number applications boils down to nowadays.

If you want to have a serious mature Forth (gforth, ciforth) Anton Ertl
has explained that you need to have double precisions support for
multi precision, cryptography, crc and the like.
That doesn't mean that you have to build number display around the
<# #S #> wordset.


>
>But.. I've been around here for a while and I think given there are
>still people using WORD and vanilla counted strings that the 22nd
>century Forths will still support double numbers - resulting in 1024 bit
>double numbers.

Users of ciforth discover that WORD is a loaded extension, and they get
educated as soon as they complain about this.

>
>Hans Bezemer

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134632

On 28-02-2026 15:34, albert@spenarnc.xs4all.nl wrote:
> In article <nnd$73692009$4971d447@b0f461aaf5ef0059>,
> Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>> On 26-02-2026 13:09, albert@spenarnc.xs4all.nl wrote:
>>> In article <87qzq8b07r.fsf@nightsong.com>,
>>> Paul Rubin  <no.email@nospam.invalid> wrote:
>>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>>> I still think that meddling with the text interpreter is a big no-no
>>>>> and an invitation to disaster.
>>>>
>>>> Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
>>>> "123.45" change depending on whether the floating point wordset is
>>>> loaded is also horrible.  Probably best to leave things as they are, and
>>>> maybe suggest a nonstandard extension to treat 123.45 as a float.  To
>>>> get a double cell you'd use
>>>
>>> Offically 123.45 is not a double number. It should end with a decimal point.
>>>
>>> How is the support for a proposal:
>>>
>>> Double numbers should start and end with a dot.
>>> Now any numbers containing a single dot are automatically fp
>>>
>>> A program that uses single dots to indicate doubles, should
>>> declare an environmental dependancy. The default behaviour it
>>> that they are floats.
>>>
>>> In this way most programs that uses fp and use single dots are
>>> fully compliant.
>>>
>>> There are people who are font of 01/02/03 date (2003 januari 2 )
>>> indications that are examples in Starting Forth.
>>> You could do this with recognizers (I suppose).
>>>
>>>>
>>>> It does seem to me that with 32-bit systems widespread, double ints have
>>>> gotten less important.  I wouldn't want the standard behaviour to
>>>> change, but I'd probably use the nonstandard extension if it existed.
>>>> With the extension turned on, to get the double int, you'd use 12345 0
>>>> or maybe something like "D# 123 45" .
>>>>
>>>> Double ints are maybe still useful on 8 bit systems with 16 bit cells.
>>>
>>> I have published yourforth, an altenative to jonesforth. It is 32 bits
>>> and I have eliminated all double precision crap, contributing to
>>> it pedagogical value.
>>>
>>> Groetjes Albert
>>
>> Although I can understand the technical, historical and pragmatic
>> reasons of Chuck for (a) signifying a double number by a dot and (b) the
>> inclusion of a double number recognizer in the text interpreter, I never
>> followed suit.
>>
>> Double number support was NEVER part of the 4tH core - and frankly, the
>> initial idea was even to never support double numbers AT ALL. The
>> rationale behind that one was that integers at that time were 32bit
>> anyway - the identical precision that double numbers covered - so.. why?
>>
>> The range of 64bit numbers covers just about everything under the sun,
>> so I agree fullheartedly with the idea that double numbers are close to
>> complete obsolescence. The last time I used triple numbers was when I
>> wrote several IBAN related utilities on a 32-bit platform. Which most
>> double number applications boils down to nowadays.
> 
> If you want to have a serious mature Forth (gforth, ciforth) Anton Ertl
> has explained that you need to have double precisions support for
> multi precision, cryptography, crc and the like.
> That doesn't mean that you have to build number display around the
> <# #S #> wordset.
> 
> 
>>
>> But.. I've been around here for a while and I think given there are
>> still people using WORD and vanilla counted strings that the 22nd
>> century Forths will still support double numbers - resulting in 1024 bit
>> double numbers.
> 
> Users of ciforth discover that WORD is a loaded extension, and they get
> educated as soon as they complain about this.
> 
>>
>> Hans Bezemer
> 
> Groetjes Albert

Sure, if you dig deep enough you will always find applications for ANY 
feature. That doesn't necessarily mean they're essential. I mean - even 
in C you don't find too many "long long long long long long long long 
int" declarations.

But I'm sure there are libs for that. If you need 'em, you load 'em. 
Like I did with my triple libs for my IBAN utilities.

And where <# #S #> are concerned - in 4tH they have always been cell 
sized. For the double version I have a double version. Lo and behold: 
for the triple wordset I even have a TRIPLE version. I'm quite confident 
I can even pull off a QUADRO version if need be.

/hold 3 * constant /thold
/thold string tholdbuf
tholdbuf /thold + constant tholdend
variable hld

: thold hld -1 over +! @ c! ;
: <t# tholdend hld ! ;
: t#> 3drop hld @ tholdend over - ;
: tsign >r >r >r 0< if [char] - thold then r> r> r> ;
: t# base @ tu/mod >r >r >r digit>c thold r> r> r> ;
: t#s begin t# 3dup t0= until ;
: (tsigned) dup >r -rot r> tabs ;

Hans Bezemer

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

#134633

albert@spenarnc.xs4all.nl writes:
> If you want to have a serious mature Forth (gforth, ciforth) Anton Ertl
> has explained that you need to have double precisions support for
> multi precision, cryptography, crc and the like.

It's not clear that you'd need particular syntax for double-cell
literals though.  You'll rarely want double arithmetic per se.  You'd
possibly use it as a building block for multi precision.

In practice, multi precision arithmetic would likely be written as asm
primitives.

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

#134634

Paul Rubin <no.email@nospam.invalid> writes:
>In practice, multi precision arithmetic would likely be written as asm
>primitives.

That's what GMP does, but only for certain operations, while other
code may be more efficient for combinations of these operations (e.g.,
three-input addition).

In the history of programming, we usually started out with assembly
language, but over time, that has given way to programming in
higher-level languages.  In the case of multi-precision arithmetics,
the support from high-level languages has been:

1) Double-precision types such as uint128_t in C, allowing to express
   double-precision arithmetics and mixed single/double-precision
   addition and multiplication.

2) Double-precision (D+) and mixed single/double precision words (UM*
   M*) in Forth (M+ is not quite there, UM+ would be helpful for
   multi-precision).

3) Add-with-carry builtins (compiler-specific) and intrinsics
   (architecture-specific) in C compilers.

4) Arbitrary-precision arithmetics in a number of higher-level
   langyages.  The size depends on the data, which results in boxing
   and unboxing overhead, which makes that feature really slow in all
   implementations I know.  Also, in most languages the usual case is
   single-precision, so the incentives for making the multi-precision
   ase fast are small.  It's just an insurance against overflow.

5) _Bitint() in C23.  gcc-15.1 supports numbers up to 65,535 bits, and
   clang-20.1 supports numbers up to 8,388,608bits.  The code produced
   for now is mediocre, but that can change.

I have compared assembly language, 1), 3), and 5) [ertl25-carry2].
One can get C compilers to produce quite good code with 1) and 3),
but, depending on the architecture, sometimes 1) is better, and
sometimes 3).  Ideally the compilers should produce the optimal code
with 5), but for now, they don't.

As long as we do not add something like 5) to Forth, 2) (close to C's
1) is the way to go if we want to express this stuff in Forth.  Not
everyone wants Forth to be able to express such things with ease and
efficiency competetive with C (before _Bitint()), though.

- anton

@InProceedings{ertl25-carry2,
  author =       {M. Anton Ertl},
  title =        {Multi-precision integer arithmetics},
  booktitle =    {Tagungsband des Jahrestreffens 2025 der
                  GI-Fachgruppe ``Programmiersprachen und
                  Rechenkonzepte''},
  year =         {2025},
  series =       {INSIGHTS --- Schriftenreihe der Fakult\"at Technik},
  pages =        {15--25},
  url =		 {https://www.complang.tuwien.ac.at/papers/ertl25-carry2.pdf},
  slides-url =   {https://www.complang.tuwien.ac.at/papers/ertl25-carry2-slides.pdf},
url-proceedings = {https://www.dhbw-stuttgart.de/fileadmin/dateien/Forschung/Forschungsschwerpunkte_Technik/DHBW_Stuttgart_INSIGHTS_1_2025_Tagungsband_Jahrestreffen_GI-Fachgruppe_Programmiersprachen_und_Rechenkonzepte_2025.pdf},
  abstract =     {Multi-precision integer arithmetics is widely used,
                  among other things in public-key cryptography and
                  when computing many digits of transcendental
                  numbers.  The present paper discusses
                  multi-precision addition and multiplication:
                  architectural support and its use in hand-written
                  assembly language, libraries that use such
                  assembly-language code, and programming language
                  support and how close the code generated by Clang
                  and GCC is to the hand-written assembly language.}
}
-- 
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]

#134635

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>   author =       {M. Anton Ertl},
>   title =        {Multi-precision integer arithmetics},

This paper and the linked one about adding carry bits to the RISC-V
machine registers are interesting.  Someone recently mentioned that the
RISC-V vector extension has ADC so it might be worth evaluating that in
future versions of the paper.

IDK if it's in the spirit of Forth to have anything like _Bitint() and
I'm surprised to hear about it in C (I didn't know about it before).  I
doubt it but your judgment is better than mine on such questions.

I think variable sized bignum arithmetic like 4096 bits is fading out of
public key cryptography these days, as algorithms like RSA are being
replaced by elliptic curve algorithms with fixed key sizes, typically
256 bits.

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

#134637

Paul Rubin <no.email@nospam.invalid> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>   author =       {M. Anton Ertl},
>>   title =        {Multi-precision integer arithmetics},
> 
> This paper and the linked one about adding carry bits to the RISC-V
> machine registers are interesting.  Someone recently mentioned that the
> RISC-V vector extension has ADC so it might be worth evaluating that in
> future versions of the paper.
> 
> IDK if it's in the spirit of Forth to have anything like _Bitint() and
> I'm surprised to hear about it in C (I didn't know about it before).  I
> doubt it but your judgment is better than mine on such questions.
> 
> I think variable sized bignum arithmetic like 4096 bits is fading out of
> public key cryptography these days, as algorithms like RSA are being
> replaced by elliptic curve algorithms with fixed key sizes, typically
> 256 bits.

Elliptic curve algorithms can use significanty smaller primes than
RSA, but IIUC 256 bits is deemed to be dangerously low.

-- 
                              Waldek Hebisch

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

#134638

In article <10o2l5i$1u2r0$2@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>   author =       {M. Anton Ertl},
>>>   title =        {Multi-precision integer arithmetics},
>>
>> This paper and the linked one about adding carry bits to the RISC-V
>> machine registers are interesting.  Someone recently mentioned that the
>> RISC-V vector extension has ADC so it might be worth evaluating that in
>> future versions of the paper.
>>
>> IDK if it's in the spirit of Forth to have anything like _Bitint() and
>> I'm surprised to hear about it in C (I didn't know about it before).  I
>> doubt it but your judgment is better than mine on such questions.

If you take Forth as a serious programming language, the paper about multi
precision is valuable.

>>
>> I think variable sized bignum arithmetic like 4096 bits is fading out of
>> public key cryptography these days, as algorithms like RSA are being
>> replaced by elliptic curve algorithms with fixed key sizes, typically
>> 256 bits.
>
>Elliptic curve algorithms can use significanty smaller primes than
>RSA, but IIUC 256 bits is deemed to be dangerously low.

Moreover the USA NSA pushes towards elliptic curves. Maybe they have
a backdoor. Otoh RSA 4096 is well established.

>--
>                              Waldek Hebisch

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134643

albert@spenarnc.xs4all.nl writes:
> Moreover the USA NSA pushes towards elliptic curves. Maybe they have
> a backdoor. Otoh RSA 4096 is well established.

There was a famous incident where NSA tried to peddle a specific rigged
curve, but the curves in general use today aren't related to that.

RSA seems to be giving way to ECC because of possible vulnerability of
RSA to "index calculus" attacks.  I don't claim to understand what that
is.  This might help:  https://cr.yp.to/papers/safecurves-20240809.pdf

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

#134636

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>In practice, multi precision arithmetic would likely be written as asm
>>primitives.
> 
> That's what GMP does, but only for certain operations, while other
> code may be more efficient for combinations of these operations (e.g.,
> three-input addition).
> 
> In the history of programming, we usually started out with assembly
> language, but over time, that has given way to programming in
> higher-level languages.  In the case of multi-precision arithmetics,
> the support from high-level languages has been:
> 
> 1) Double-precision types such as uint128_t in C, allowing to express
>    double-precision arithmetics and mixed single/double-precision
>    addition and multiplication.
> 
> 2) Double-precision (D+) and mixed single/double precision words (UM*
>    M*) in Forth (M+ is not quite there, UM+ would be helpful for
>    multi-precision).
> 
> 3) Add-with-carry builtins (compiler-specific) and intrinsics
>    (architecture-specific) in C compilers.
> 
> 4) Arbitrary-precision arithmetics in a number of higher-level
>    langyages.  The size depends on the data, which results in boxing
>    and unboxing overhead, which makes that feature really slow in all
>    implementations I know.  Also, in most languages the usual case is
>    single-precision, so the incentives for making the multi-precision
>    ase fast are small.  It's just an insurance against overflow.
> 
> 5) _Bitint() in C23.  gcc-15.1 supports numbers up to 65,535 bits, and
>    clang-20.1 supports numbers up to 8,388,608bits.  The code produced
>    for now is mediocre, but that can change.
> 
> I have compared assembly language, 1), 3), and 5) [ertl25-carry2].
> One can get C compilers to produce quite good code with 1) and 3),
> but, depending on the architecture, sometimes 1) is better, and
> sometimes 3).  Ideally the compilers should produce the optimal code
> with 5), but for now, they don't.
> 
> As long as we do not add something like 5) to Forth, 2) (close to C's
> 1) is the way to go if we want to express this stuff in Forth.  Not
> everyone wants Forth to be able to express such things with ease and
> efficiency competetive with C (before _Bitint()), though.
> 
> - anton
> 
> @InProceedings{ertl25-carry2,
>   author =       {M. Anton Ertl},
>   title =        {Multi-precision integer arithmetics},
>   booktitle =    {Tagungsband des Jahrestreffens 2025 der
>                   GI-Fachgruppe ``Programmiersprachen und
>                   Rechenkonzepte''},
>   year =         {2025},
>   series =       {INSIGHTS --- Schriftenreihe der Fakult\"at Technik},
>   pages =        {15--25},
>   url =          {https://www.complang.tuwien.ac.at/papers/ertl25-carry2.pdf},
>   slides-url =   {https://www.complang.tuwien.ac.at/papers/ertl25-carry2-slides.pdf},
> url-proceedings = {https://www.dhbw-stuttgart.de/fileadmin/dateien/Forschung/Forschungsschwerpunkte_Technik/DHBW_Stuttgart_INSIGHTS_1_2025_Tagungsband_Jahrestreffen_GI-Fachgruppe_Programmiersprachen_und_Rechenkonzepte_2025.pdf},
>   abstract =     {Multi-precision integer arithmetics is widely used,
>                   among other things in public-key cryptography and
>                   when computing many digits of transcendental
>                   numbers.  The present paper discusses
>                   multi-precision addition and multiplication:
>                   architectural support and its use in hand-written
>                   assembly language, libraries that use such
>                   assembly-language code, and programming language
>                   support and how close the code generated by Clang
>                   and GCC is to the hand-written assembly language.}
> }

-- 
                              Waldek Hebisch

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

#134625

On 2/25/26 10:25 PM, Paul Rubin wrote:
...
> It does seem to me that with 32-bit systems widespread, double ints have
> gotten less important. ...
Double numbers are still useful on 64-bit systems, in physics, 
chemistry, and number theory. For example, consider factorials, which 
occur in evaluating quantities of fundamental importance in areas like 
atomic and molecular physics and quantum chemistry.

https://github.com/mynenik/kForth-64/blob/master/forth-src/fsl/extras/cg.4th

In particular, notice this limitation for 32-bit systems (using single 
length numbers) in the above file:

13 INTEGER ARRAY fac_table{
1  1  2  6  24  120  720  5040  40320  362880
3628800 39916800 479001600
13 fac_table{ }iput


With double-length integers, the code becomes useful over a wider range 
of systems. I haven't yet converted it to use double length integers, 
but it is something on my list of tbd.

--
Krishna

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

#134639

On 26 Feb 2026 at 05:25:12 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:

> Hans Bezemer <the.beez.speaks@gmail.com> writes:
> It does seem to me that with 32-bit systems widespread, double ints have
> gotten less important.  I wouldn't want the standard behaviour to
> change, but I'd probably use the nonstandard extension if it existed.
> With the extension turned on, to get the double int, you'd use 12345 0
> or maybe something like "D# 123 45" .
> 
> Double ints are maybe still useful on 8 bit systems with 16 bit cells.

We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
on 128 bit integers. They have in excess of 10,000 users of their
application.

Even if they converted to a 64 bit host Forth, they would still need
double numbers.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

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

#134640

In article <10o42vp$15sg5$1@dont-email.me>,
Stephen Pelc  <stephen@vfxforth.com> wrote:
>On 26 Feb 2026 at 05:25:12 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:
>
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> It does seem to me that with 32-bit systems widespread, double ints have
>> gotten less important.  I wouldn't want the standard behaviour to
>> change, but I'd probably use the nonstandard extension if it existed.
>> With the extension turned on, to get the double int, you'd use 12345 0
>> or maybe something like "D# 123 45" .
>>
>> Double ints are maybe still useful on 8 bit systems with 16 bit cells.
>
>We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
>on 128 bit integers. They have in excess of 10,000 users of their
>application.

I appreciate that you will not disclose much on your clients.
Can you reveal what kind of applications would use 128 bit integers
but not more precision?

>
>Even if they converted to a 64 bit host Forth, they would still need
>double numbers.

I use double precision for numbertheoretical examples.
Bezemer is right that you can get rid of doubles on small systems,
but not for a serious tool that is to universably usable.

>
>Stephen

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134641

On 3 Mar 2026 at 13:47:54 CET, "albert@spenarnc.xs4all.nl"
<albert@spenarnc.xs4all.nl> wrote:

>> We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
>> on 128 bit integers. They have in excess of 10,000 users of their
>> application.
> 
> I appreciate that you will not disclose much on your clients.
> Can you reveal what kind of applications would use 128 bit integers
> but not more precision?

The application is construction planning. Sometimes over 10 currencies are
used. The app must allow for a total cost of well over 10 billion dollars US.
They tried 80 bit FP, but the difference in dollars given by an 128 bit
integer calculation (effectively a huge spreadsheet) and an 80 bit floating
point version was 10 million dollars for capping the piles in the new Hong
Kong airport.. There are many examples in construction of dealing with two
quantities, one of which is large and the other small. Capping piles is one of
these.

Stephen

-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

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

#134644

Stephen Pelc <stephen@vfxforth.com> writes:
> The application is construction planning. Sometimes over 10 currencies
> are used. The app must allow for a total cost of well over 10 billion
> dollars US.  They tried 80 bit FP, but the difference in dollars given
> by an 128 bit integer calculation (effectively a huge spreadsheet) and
> an 80 bit floating point version was 10 million dollars for capping
> the piles in the new Hong Kong airport.. There are many examples in
> construction of dealing with two quantities, one of which is large and
> the other small. Capping piles is one of these.

I wonder if this was due to some kind of numerical instability in which
case 128 bits might not be enough either.  80 bit FP has a 53 bit
mantissa and 2**53 pennies is 9e15 dollars.  Did you try the same
calculation with say 256 bit FP, bignums, or whatever?

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

#134645

On 5 Mar 2026 at 01:52:06 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:

> Stephen Pelc <stephen@vfxforth.com> writes:
>> The application is construction planning. Sometimes over 10 currencies
>> are used. The app must allow for a total cost of well over 10 billion
>> dollars US.  They tried 80 bit FP, but the difference in dollars given
>> by an 128 bit integer calculation (effectively a huge spreadsheet) and
>> an 80 bit floating point version was 10 million dollars for capping
>> the piles in the new Hong Kong airport.. There are many examples in
>> construction of dealing with two quantities, one of which is large and
>> the other small. Capping piles is one of these.
> 
> I wonder if this was due to some kind of numerical instability in which
> case 128 bits might not be enough either.  80 bit FP has a 53 bit
> mantissa and 2**53 pennies is 9e15 dollars.  Did you try the same
> calculation with say 256 bit FP, bignums, or whatever?

128 bit ints were good enough. We could probably have got away with 96 bits
but 128 bits were as easy. Note that this is a production app. Speed was also
important. Porting the system from ProForth for Windows (a DTC Forth) to VFX
Forth (native code compilation) gave a factor of ten improvement in
recalculation speed.

Stephen

-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

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

#134646

In article <87a4wnayix.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Stephen Pelc <stephen@vfxforth.com> writes:
>> The application is construction planning. Sometimes over 10 currencies
>> are used. The app must allow for a total cost of well over 10 billion
>> dollars US.  They tried 80 bit FP, but the difference in dollars given
>> by an 128 bit integer calculation (effectively a huge spreadsheet) and
>> an 80 bit floating point version was 10 million dollars for capping
>> the piles in the new Hong Kong airport.. There are many examples in
>> construction of dealing with two quantities, one of which is large and
>> the other small. Capping piles is one of these.
>
>I wonder if this was due to some kind of numerical instability in which
>case 128 bits might not be enough either.  80 bit FP has a 53 bit
>mantissa and 2**53 pennies is 9e15 dollars.  Did you try the same
>calculation with say 256 bit FP, bignums, or whatever?

Financial calculations donot like floating point. If you started with 32 bits
integers, stepping up to quad precision is a smaller step, then introducing
fp.

Groetjes.
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web