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

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

Make double numbers notation more strict

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

Contents

  Make double numbers notation more strict albert@spenarnc.xs4all.nl - 2026-08-24 13:36 +0200
    Re: Make double numbers notation more strict anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-24 14:44 +0000
    Re: Make double numbers notation more strict Stephen Pelc <stephen@vfxforth.com> - 2026-08-24 16:57 +0000
    Re: Make double numbers notation more strict dxf <dxforth@gmail.com> - 2026-08-25 11:10 +1000
      Re: Make double numbers notation more strict Paul Rubin <no.email@nospam.invalid> - 2026-08-24 18:25 -0700
        Re: Make double numbers notation more strict dxf <dxforth@gmail.com> - 2026-08-25 14:44 +1000
      Re: Make double numbers notation more strict Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-24 20:51 -0500
        Re: Make double numbers notation more strict dxf <dxforth@gmail.com> - 2026-08-25 14:17 +1000
          Re: Make double numbers notation more strict Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-25 05:51 -0500
            Re: Make double numbers notation more strict dxf <dxforth@gmail.com> - 2026-08-25 21:20 +1000
              Re: Make double numbers notation more strict Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-25 10:41 -0500
                Re: Make double numbers notation more strict dxf <dxforth@gmail.com> - 2026-08-26 13:51 +1000
            Re: Make double numbers notation more strict albert@spenarnc.xs4all.nl - 2026-08-26 11:54 +0200
              Re: Make double numbers notation more strict albert@spenarnc.xs4all.nl - 2026-08-26 12:00 +0200
                Re: Make double numbers notation more strict antispam@fricas.org (Waldek Hebisch) - 2026-08-26 14:39 +0000
                  Re: Make double numbers notation more strict anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-26 15:28 +0000
                    Re: Make double numbers notation more strict peter <peter.noreply@tin.it> - 2026-08-26 18:42 +0200
                    Re: Make double numbers notation more strict anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-26 17:04 +0000
                  Re: Make double numbers notation more strict albert@spenarnc.xs4all.nl - 2026-08-27 12:43 +0200
          Re: Make double numbers notation more strict Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-26 09:12 +0200
      Re: Make double numbers notation more strict Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-26 09:15 +0200
    Re: Make double numbers notation more strict Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-26 09:09 +0200
      Re: Make double numbers notation more strict albert@spenarnc.xs4all.nl - 2026-08-26 12:22 +0200
        Re: Make double numbers notation more strict Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-26 19:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#135429

On 25-08-2026 03:10, dxf wrote:
> On 24/08/2026 9:36 pm, albert@spenarnc.xs4all.nl wrote:
>> What does the Forth community think of the following:
>>
>> Now double numbers have to end with a '.' (c-notation).
>> Double precision numbers loose significance in the 64 bit era.
>> Time to de-emphasize this.
>> ...
> 
> Moore said that about 32-bit (and double operators) back in '89 and
> still folks are finding uses.  Getting rid of doubles/input just to
> support floating-point which isn't even forth's niche (RPN and all that)
> ... seems so wrong.
> 

Still it was one of the causes to abandon ALL mixed and double words 
from 4tH. Until I needed them in order to implement high level floating 
point words -- and I consequently had to eat my words ;-)

Hans Bezemer

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

#135427

On 24-08-2026 13:36, albert@spenarnc.xs4all.nl wrote:
> What does the Forth community think of the following:
> 
> Now double numbers have to end with a '.' (c-notation).
> Double precision numbers loose significance in the 64 bit era.
> Time to de-emphasize this.
> 
> Proposed:
> A double precision integer has to start and end with a '.',
> possible other places are allowed:
> .0000.0000.DEAD.BEEF.1234.1234.1234.1234.
> .12.
> All other notations are obsolescent.
> 
> Of course inexact numbers ("floating point") cannot contain two '.'.
> This clears the way to have numbers like
>      12.0 12. .123
> naturally meaning floating point.
> 
> Groetjes Albert

Well, I can be incredibly short about this one: I don't like prefixes. 
Make a parsing word. ;-) D% or D#. Easy, don't need ugly recognizers. My 
arguments should be common knowledge by now. Even if it is adopted, I 
won't follow.

Hans Bezemer

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

#135433

In article <116m3f1$dtoq$1@dont-email.me>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>On 24-08-2026 13:36, albert@spenarnc.xs4all.nl wrote:
>> What does the Forth community think of the following:
>>
>> Now double numbers have to end with a '.' (c-notation).
>> Double precision numbers loose significance in the 64 bit era.
>> Time to de-emphasize this.
>>
>> Proposed:
>> A double precision integer has to start and end with a '.',
>> possible other places are allowed:
>> .0000.0000.DEAD.BEEF.1234.1234.1234.1234.
>> .12.
>> All other notations are obsolescent.
>>
>> Of course inexact numbers ("floating point") cannot contain two '.'.
>> This clears the way to have numbers like
>>      12.0 12. .123
>> naturally meaning floating point.
>>
>> Groetjes Albert
>
>Well, I can be incredibly short about this one: I don't like prefixes.
>Make a parsing word. ;-) D% or D#. Easy, don't need ugly recognizers. My
>arguments should be common knowledge by now. Even if it is adopted, I
>won't follow.

I agree with you but I did a slight modification with D% and D#
that leads to a simplification for ordinary numbers alike.
I don't like the original $ # as seen in iforth. So I added $ # as
separately loaded parsing works like you D$ D# .
But now the iforth sources doesn't still compile, you have to
replace
    $DEADBEEF
with
    $ DEADBEEF

Now let "het kwartje val".
A simple addition to the FIND / FOUND is the following:
Look up $DEADBEEF. A simple PREFIX flag in $ makes that
the $ is found as a word.

WANT $-PREFIX

S[ ] OK "$DEADBEEF" FOUND

S[ 156480 ] OK ID.
$

The $ found behave as your D$ . It is possibly IMMEDIATE and compiles
" ' LIT , DEADBEED , " or leaves the stack alone according to STATE.
(From day one numbers like 123 are STATE aware, no need to change.)
The parse pointer (>IN or some such) has to advance, not after
$DEADBEEF but after $.
That is simple advance the parse pointer with the length of the
NAME FOUND in every case.
(Kill the guy with the moustache in starting Forth.)

This single flag is a far cry from the recognizer proposals.

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

#135441

On 26-08-2026 12:22, albert@spenarnc.xs4all.nl wrote:
> In article <116m3f1$dtoq$1@dont-email.me>,
> Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>> On 24-08-2026 13:36, albert@spenarnc.xs4all.nl wrote:
>>> What does the Forth community think of the following:
>>>
>>> Now double numbers have to end with a '.' (c-notation).
>>> Double precision numbers loose significance in the 64 bit era.
>>> Time to de-emphasize this.
>>>
>>> Proposed:
>>> A double precision integer has to start and end with a '.',
>>> possible other places are allowed:
>>> .0000.0000.DEAD.BEEF.1234.1234.1234.1234.
>>> .12.
>>> All other notations are obsolescent.
>>>
>>> Of course inexact numbers ("floating point") cannot contain two '.'.
>>> This clears the way to have numbers like
>>>       12.0 12. .123
>>> naturally meaning floating point.
>>>
>>> Groetjes Albert
>>
>> Well, I can be incredibly short about this one: I don't like prefixes.
>> Make a parsing word. ;-) D% or D#. Easy, don't need ugly recognizers. My
>> arguments should be common knowledge by now. Even if it is adopted, I
>> won't follow.
> 
> I agree with you but I did a slight modification with D% and D#
> that leads to a simplification for ordinary numbers alike.
> I don't like the original $ # as seen in iforth. So I added $ # as
> separately loaded parsing works like you D$ D# .
> But now the iforth sources doesn't still compile, you have to
> replace
>      $DEADBEEF
> with
>      $ DEADBEEF
> 
> Now let "het kwartje val".
> A simple addition to the FIND / FOUND is the following:
> Look up $DEADBEEF. A simple PREFIX flag in $ makes that
> the $ is found as a word.
> 
> WANT $-PREFIX
> 
> S[ ] OK "$DEADBEEF" FOUND
> 
> S[ 156480 ] OK ID.
> $
> 
> The $ found behave as your D$ . It is possibly IMMEDIATE and compiles
> " ' LIT , DEADBEED , " or leaves the stack alone according to STATE.
> (From day one numbers like 123 are STATE aware, no need to change.)
> The parse pointer (>IN or some such) has to advance, not after
> $DEADBEEF but after $.
> That is simple advance the parse pointer with the length of the
> NAME FOUND in every case.
> (Kill the guy with the moustache in starting Forth.)
> 
> This single flag is a far cry from the recognizer proposals.
> 
>>
>> Hans Bezemer

I applaud that! That's how Forth should function! In 4tH, the parsing is 
done with the preprocessor macro "D%". The "hash" name reminds me too 
much of number format generation - so, it became "D%".

The preprocessor lib has some intelligence, though. Take:

include lib/dbldot.4th
include lib/todbl.4th
include 4pp/lib/double.4pp

D%  16384 d. cr
D% -16384 d. cr
D% 18446744073709551616 d. cr

Output:

16384
-16384
18446744073709551616

Intermediate code:

<no interest to you>
16384 U>D d. cr
-16384 -S>D d. cr
S" 18446744073709551616" S>DOUBLE d. cr

So, it's clever enough to automatically chose the most fitting 
conversion method, some barely slower than converting it by hand. A 
similar conversion method is used with F% when integers are concerned - 
"Here 10 items or less".

Hans Bezemer

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web