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 1 of 2  [1] 2  Next page →

#135410 — Make double numbers notation more strict

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
-- 
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] | [next] | [standalone]

#135411

albert@spenarnc.xs4all.nl writes:
>Proposed:
>A double precision integer has to start and end with a '.',
...
>This clears the way to have numbers like
>    12.0 12. .123
>naturally meaning floating point.

We already have a notation for double numbers that cannot be an FP
number: prefixed numbers, e.g.:

#10.
$10.

And in development Gforth you already get a warning if you write a
double number without prefix.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

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

#135412

On 24 Aug 2026 at 12:36:29 GMT+1, "albert@spenarnc.xs4all.nl"
<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.

This topic comes up every decade or so.

My attitude is based on two attitudes towards Forth:
1) Don't bury your tools
2) Notation matters

IMHO the Forth standard notation for both floats and integers is all but
useless for handling number entry from a user of a commercial application. I
state this having helped maintain a Forth application of over 1 million lines
of Forth source code for over 30 years. The standard number for this
application is a 128 bit integer to avoid rounding errors in spreadsheet
recalculation. Yes, double numbers still matter and we have a 128 bit flat
pack for VFX - thak you to David Kuhling.

At least in Europe, there are two main forms of writing large integers
  123,456,789
  123.456.789
If the '.' character is used as an integer digits separator, the ',' character
usually used a decimal point and vice versa.

As a starting point it is trivial to make these characters settable.
  Char . Dp-char c!
  Char , fp-char c!
Now you can add the e1234 notation to extend the floating point notation.

There are extensions that I leave as an exercise for the reader to make the
notation compatible with Forth-2012.

In order to improve the readability of long integers in binary or hex, it is
useful to define a character that is always ignored in number conversion, e.g.
  char : ign-char c!

VFX Forth has worked this way for a very long time (decades) and no technical
support has ensued.
No recognisers were needed, broken, or abused in constructing this notation.

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]

#135414

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.

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

#135415

dxf <dxforth@gmail.com> writes:
> floating-point which isn't even forth's niche (RPN and all that)

Users of a certain age probably learned RPN on HP calculators,
i.e. floating point.

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

#135418

On 25/08/2026 11:25 am, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> floating-point which isn't even forth's niche (RPN and all that)
> 
> Users of a certain age probably learned RPN on HP calculators,
> i.e. floating point.

Standard today is full algebraic.  Drives me so crazy that I keep
reaching for an old $5 calc.  No idea how students these days cope.

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

#135416

On 8/24/26 8:10 PM, 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.
> 

1) Which Forth systems are getting rid of double length integer input?

I originally did not implement double length integer input in kForth to 
avoid confusion with floating point. However, with the standardization 
of base prefixes, and with recognizers (though they are not needed for 
this), it became easy to implement an unambiguous form of input for 
double length numbers, requiring a base prefix character and a trailing 
decimal point e.g.

#-170141183460469231731687303715884105728.
$ffffffffffffffffffffffffffffffff.
%10110001111011000101111.


2) What is Forth's niche, in your opinion?

I have used Forth for engineering and scientific tasks for over 40 
years, with nearly all of my journal publications containing results 
obtained with Forth. Julian Noble, Charles Montgomery, and Marcel 
Hendrix also used/use it for the same purposes. The late Prof. Noble 
even wrote a book called Scientific Forth. Many others have widened 
Forth's application space well beyond Chuck Moore's original use.

--
Krishna

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

#135417

On 25/08/2026 11:51 am, Krishna Myneni wrote:
> On 8/24/26 8:10 PM, 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.
>>
> 
> 1) Which Forth systems are getting rid of double length integer input?
> 
> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
> 
> #-170141183460469231731687303715884105728.
> $ffffffffffffffffffffffffffffffff.
> %10110001111011000101111.

Interesting because ...

  hex #23E1 decimal f. 230.  ok

works on my system (but apparently not others)

> 
> 2) What is Forth's niche, in your opinion?
> 
> I have used Forth for engineering and scientific tasks for over 40 years, with nearly all of my journal publications containing results obtained with Forth. Julian Noble, Charles Montgomery, and Marcel Hendrix also used/use it for the same purposes. The late Prof. Noble even wrote a book called Scientific Forth. Many others have widened Forth's application space well beyond Chuck Moore's original use.

IIRC Prof Noble wrote FTRAN with the aim of making forth more palatable to
scientists/engineers.  AFAICS one has to like forth to begin with.

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

#135419

On 8/24/26 11:17 PM, dxf wrote:
> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>> On 8/24/26 8:10 PM, 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.
>>>
>>
>> 1) Which Forth systems are getting rid of double length integer input?
>>
>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>
>> #-170141183460469231731687303715884105728.
>> $ffffffffffffffffffffffffffffffff.
>> %10110001111011000101111.
> 
> Interesting because ...
> 
>    hex #23E1 decimal f. 230.  ok
> 
> works on my system (but apparently not others)
> ...

How is your example above relevant to interpreting double length 
integers? What happens when you append a trailing decimal point to 
"#23E1"? Does your system still interpret it as a floating point number?

--
KM

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

#135420

On 25/08/2026 8:51 pm, Krishna Myneni wrote:
> On 8/24/26 11:17 PM, dxf wrote:
>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>> On 8/24/26 8:10 PM, 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.
>>>>
>>>
>>> 1) Which Forth systems are getting rid of double length integer input?
>>>
>>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>>
>>> #-170141183460469231731687303715884105728.
>>> $ffffffffffffffffffffffffffffffff.
>>> %10110001111011000101111.
>>
>> Interesting because ...
>>
>>    hex #23E1 decimal f. 230.  ok
>>
>> works on my system (but apparently not others)
>> ...
> 
> How is your example above relevant to interpreting double length integers?

It's not.  Though I did expect it to work on other forths.

> What happens when you append a trailing decimal point to "#23E1"? Does your system still interpret it as a floating point number?

It's not recognized as any number.  # forces decimal interpretation.
It fails as an integer/double due to 'E'.  It then fails as a float
due to dp after the exponent.

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

#135421

On 8/25/26 6:20 AM, dxf wrote:
> On 25/08/2026 8:51 pm, Krishna Myneni wrote:
>> On 8/24/26 11:17 PM, dxf wrote:
>>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>>> On 8/24/26 8:10 PM, 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.
>>>>>
>>>>
>>>> 1) Which Forth systems are getting rid of double length integer input?
>>>>
>>>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>>>
>>>> #-170141183460469231731687303715884105728.
>>>> $ffffffffffffffffffffffffffffffff.
>>>> %10110001111011000101111.
>>>
>>> Interesting because ...
>>>
>>>     hex #23E1 decimal f. 230.  ok
>>>
>>> works on my system (but apparently not others)
>>> ...
>>
>> How is your example above relevant to interpreting double length integers?
> 
> It's not.  Though I did expect it to work on other forths.
> 

While the Forth 2012 standard does specify base prefix characters for 
the text interpreter when dealing with integers (3.4.1.3), it does not 
do so for text interpretation of floating point numbers:

12.3.7 Text interpreter input number conversion
If the Floating-Point word set is present in the dictionary and the 
current base is DECIMAL, the input number-conversion algorithm shall be 
extended to recognize floating-point numbers in this form:

Convertible string := <significand><exponent>
<significand> := [<sign>]<digits>[.<digits0>]
<exponent> := E[<sign>]<digits0>
<sign> := { + | - }
<digits> := <digit><digits0>
<digits0> := <digit>*
<digit> := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }

...

If you want portable source for text input of floating point numbers, 
it's better to not use a base prefix for them.

>> What happens when you append a trailing decimal point to "#23E1"? Does your system still interpret it as a floating point number?
> 
> It's not recognized as any number.  # forces decimal interpretation.
> It fails as an integer/double due to 'E'.  It then fails as a float
> due to dp after the exponent.
> 

That's good. This is why I adopted the requirement of both the base 
prefix and trailing decimal point for source input of double length 
integers.

--
Krishna

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

#135425

On 26/08/2026 1:41 am, Krishna Myneni wrote:
> On 8/25/26 6:20 AM, dxf wrote:
>> On 25/08/2026 8:51 pm, Krishna Myneni wrote:
>>> On 8/24/26 11:17 PM, dxf wrote:
>>>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>>>> On 8/24/26 8:10 PM, 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.
>>>>>>
>>>>>
>>>>> 1) Which Forth systems are getting rid of double length integer input?
>>>>>
>>>>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>>>>
>>>>> #-170141183460469231731687303715884105728.
>>>>> $ffffffffffffffffffffffffffffffff.
>>>>> %10110001111011000101111.
>>>>
>>>> Interesting because ...
>>>>
>>>>     hex #23E1 decimal f. 230.  ok
>>>>
>>>> works on my system (but apparently not others)
>>>> ...
>>>
>>> How is your example above relevant to interpreting double length integers?
>>
>> It's not.  Though I did expect it to work on other forths.
>>
> 
> While the Forth 2012 standard does specify base prefix characters for the text interpreter when dealing with integers (3.4.1.3), it does not do so for text interpretation of floating point numbers:
> ...

Yes, I noticed that.  I introduced '#' prefix in 2005.  I can't say that I
looked into what was 'common practice' but my feeling was it should apply
to all numbers.  Recognizer fans might argue otherwise.

> If you want portable source for text input of floating point numbers, it's better to not use a base prefix for them.
> 
>>> What happens when you append a trailing decimal point to "#23E1"? Does your system still interpret it as a floating point number?
>>
>> It's not recognized as any number.  # forces decimal interpretation.
>> It fails as an integer/double due to 'E'.  It then fails as a float
>> due to dp after the exponent.
>>
> 
> That's good. This is why I adopted the requirement of both the base prefix and trailing decimal point for source input of double length integers.
> 
> -- 
> Krishna
> 
> 

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

#135431

In article <116js4d$3le16$1@dont-email.me>,
Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
>On 8/24/26 11:17 PM, dxf wrote:
>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>> On 8/24/26 8:10 PM, 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.
>>>>
>>>
>>> 1) Which Forth systems are getting rid of double length integer input?
>>>
>>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>>
>>> #-170141183460469231731687303715884105728.
>>> $ffffffffffffffffffffffffffffffff.
>>> %10110001111011000101111.
>>
>> Interesting because ...
>>
>>    hex #23E1 decimal f. 230.  ok
>>
>> works on my system (but apparently not others)
>> ...
>
>How is your example above relevant to interpreting double length
>integers? What happens when you append a trailing decimal point to
>"#23E1"? Does your system still interpret it as a floating point number?

My goals was severely restricted. In the absence of prefixes and a
E fields, make double numbers such that it cannot possible be
interpreted as an inexact ("floating point") number.

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

#135432

In article <nnd$6d306c76$0159a1e5@5ebe29de058d18a5>,
 <albert@spenarnc.xs4all.nl> wrote:
>In article <116js4d$3le16$1@dont-email.me>,
>Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
>>On 8/24/26 11:17 PM, dxf wrote:
>>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>>> On 8/24/26 8:10 PM, 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.
>>>>>
>>>>
>>>> 1) Which Forth systems are getting rid of double length integer input?
>>>>
>>>> I originally did not implement double length integer input in kForth
>to avoid confusion with floating point. However, with the
>standardization of base prefixes, and with recognizers (though they are
>not needed for this), it became easy to implement an unambiguous form of
>input for double length numbers, requiring a base prefix character and a
>trailing decimal point e.g.
>>>>
>>>> #-170141183460469231731687303715884105728.
>>>> $ffffffffffffffffffffffffffffffff.
>>>> %10110001111011000101111.
>>>
>>> Interesting because ...
>>>
>>>    hex #23E1 decimal f. 230.  ok
>>>
>>> works on my system (but apparently not others)
>>> ...
>>
>>How is your example above relevant to interpreting double length
>>integers? What happens when you append a trailing decimal point to
>>"#23E1"? Does your system still interpret it as a floating point number?
>
>My goals was severely restricted. In the absence of prefixes and a
>E fields, make double numbers such that it cannot possible be
>interpreted as an inexact ("floating point") number.

The next step on this road is to require explicit number prefixes
for double precision integers and declare the rest obsolescent.
So each number with a single decimal point or an
exponent designator lacking a prefix is fp.

Fine with me.


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

#135437

albert@spenarnc.xs4all.nl wrote:
> In article <nnd$6d306c76$0159a1e5@5ebe29de058d18a5>,
>  <albert@spenarnc.xs4all.nl> wrote:
>>In article <116js4d$3le16$1@dont-email.me>,
>>Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
>>>On 8/24/26 11:17 PM, dxf wrote:
>>>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>>>> On 8/24/26 8:10 PM, 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.
>>>>>>
>>>>>
>>>>> 1) Which Forth systems are getting rid of double length integer input?
>>>>>
>>>>> I originally did not implement double length integer input in kForth
>>to avoid confusion with floating point. However, with the
>>standardization of base prefixes, and with recognizers (though they are
>>not needed for this), it became easy to implement an unambiguous form of
>>input for double length numbers, requiring a base prefix character and a
>>trailing decimal point e.g.
>>>>>
>>>>> #-170141183460469231731687303715884105728.
>>>>> $ffffffffffffffffffffffffffffffff.
>>>>> %10110001111011000101111.
>>>>
>>>> Interesting because ...
>>>>
>>>>    hex #23E1 decimal f. 230.  ok
>>>>
>>>> works on my system (but apparently not others)
>>>> ...
>>>
>>>How is your example above relevant to interpreting double length
>>>integers? What happens when you append a trailing decimal point to
>>>"#23E1"? Does your system still interpret it as a floating point number?
>>
>>My goals was severely restricted. In the absence of prefixes and a
>>E fields, make double numbers such that it cannot possible be
>>interpreted as an inexact ("floating point") number.
> 
> The next step on this road is to require explicit number prefixes
> for double precision integers and declare the rest obsolescent.
> So each number with a single decimal point or an
> exponent designator lacking a prefix is fp.
> 
> Fine with me.

Just a little comment: it is easy to input or output floating point
numbers in hexadecimal.  Advantage compared to decimal is that
input and output can be exact.  So hexadecimal prefix on floating
point numbers makes sense.  But to allow this one either needs
separate hex float prefix or some other syntactic way to
distinguish them from double integers.

-- 
                              Waldek Hebisch

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

#135438

antispam@fricas.org (Waldek Hebisch) writes:
>Just a little comment: it is easy to input or output floating point
>numbers in hexadecimal.  Advantage compared to decimal is that
>input and output can be exact.

Decimal input and output can also be exact (for input you have to
input a number that can be represented exactly as an FP number, but
that's also the case with hex).  The difference is that the hex-base
FP numbers are much shorter.  Never more than 14 hex digits in the
mantissa of a binary64 number compared to up to 751 decimal digits.
Also, as long as the exponent is in the range of normal numbers, every
number of the form

1.hhhhhhhhhhhhhp<exp>

can be represented exactly as FP number, while there are lots of even
very short decimal numbers that cannot be represented exactly as FP
number.

>But to allow this one either needs
>separate hex float prefix or some other syntactic way to
>distinguish them from double integers.

C99's %a conversion format for printf uses (in regexp syntax):

  -?0xh.h*[+-]d+

and I dimly remember that at least one Forth system also uses "p" to
indicate the exponent of a hex float.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

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

#135439

On Wed, 26 Aug 2026 15:28:19 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> antispam@fricas.org (Waldek Hebisch) writes:
> >Just a little comment: it is easy to input or output floating point
> >numbers in hexadecimal.  Advantage compared to decimal is that
> >input and output can be exact.
> 
> Decimal input and output can also be exact (for input you have to
> input a number that can be represented exactly as an FP number, but
> that's also the case with hex).  The difference is that the hex-base
> FP numbers are much shorter.  Never more than 14 hex digits in the
> mantissa of a binary64 number compared to up to 751 decimal digits.
> Also, as long as the exponent is in the range of normal numbers, every
> number of the form
> 
> 1.hhhhhhhhhhhhhp<exp>
> 
> can be represented exactly as FP number, while there are lots of even
> very short decimal numbers that cannot be represented exactly as FP
> number.
> 
> >But to allow this one either needs
> >separate hex float prefix or some other syntactic way to
> >distinguish them from double integers.
> 
> C99's %a conversion format for printf uses (in regexp syntax):
> 
>   -?0xh.h*[+-]d+
> 
> and I dimly remember that at least one Forth system also uses "p" to
> indicate the exponent of a hex float.

I use that in lxf64 (and also in lxf for 80 bit floats)
It is very useful for input of exact constants

1e-6 fh.  0x1.0C6F7A0B5ED8Dp-20  ok
0x1.0C6F7A0B5ED8Dp-20 e.  1e-6  ok

works for input and out put.

Peter

> - anton

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

#135440

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>C99's %a conversion format for printf uses (in regexp syntax):
>
>  -?0xh.h*[+-]d+

In converting this to regexp syntax, I accidentially deleted the
exponent indicator "p"; this should have been:

-?0xh.h*p[+-]d+

where h is [0-9a-f] and d is [0-9].

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

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

#135443

In article <116mtrp$3d9f8$2@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>albert@spenarnc.xs4all.nl wrote:
>> In article <nnd$6d306c76$0159a1e5@5ebe29de058d18a5>,
>>  <albert@spenarnc.xs4all.nl> wrote:
>>>In article <116js4d$3le16$1@dont-email.me>,
>>>Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
>>>>On 8/24/26 11:17 PM, dxf wrote:
>>>>> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>>>>>> On 8/24/26 8:10 PM, 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.
>>>>>>>
>>>>>>
>>>>>> 1) Which Forth systems are getting rid of double length integer input?
>>>>>>
>>>>>> I originally did not implement double length integer input in kForth
>>>to avoid confusion with floating point. However, with the
>>>standardization of base prefixes, and with recognizers (though they are
>>>not needed for this), it became easy to implement an unambiguous form of
>>>input for double length numbers, requiring a base prefix character and a
>>>trailing decimal point e.g.
>>>>>>
>>>>>> #-170141183460469231731687303715884105728.
>>>>>> $ffffffffffffffffffffffffffffffff.
>>>>>> %10110001111011000101111.
>>>>>
>>>>> Interesting because ...
>>>>>
>>>>>    hex #23E1 decimal f. 230.  ok
>>>>>
>>>>> works on my system (but apparently not others)
>>>>> ...
>>>>
>>>>How is your example above relevant to interpreting double length
>>>>integers? What happens when you append a trailing decimal point to
>>>>"#23E1"? Does your system still interpret it as a floating point number?
>>>
>>>My goals was severely restricted. In the absence of prefixes and a
>>>E fields, make double numbers such that it cannot possible be
>>>interpreted as an inexact ("floating point") number.
>>
>> The next step on this road is to require explicit number prefixes
>> for double precision integers and declare the rest obsolescent.
>> So each number with a single decimal point or an
>> exponent designator lacking a prefix is fp.
>>
>> Fine with me.
>
>Just a little comment: it is easy to input or output floating point
>numbers in hexadecimal.  Advantage compared to decimal is that
>input and output can be exact.  So hexadecimal prefix on floating
>point numbers makes sense.  But to allow this one either needs
>separate hex float prefix or some other syntactic way to
>distinguish them from double integers.

I'm dabbling around with hex floating point numbers manipulating base
just fine:

S[ ] OK 1E-6

S[ ] OK HEX
S[ ] OK FDUP FS.
1.0C6F7A0B5ED8D36600_-5
S[ ] OK FDUP 20 F.R
1.0C6F7A0B5ED8D3660000000000000000_-5

The hexadecimal notation can be read back just fine.
It just requires the exponent character not to be 'E'.

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

#135428

On 25-08-2026 06:17, dxf wrote:
> On 25/08/2026 11:51 am, Krishna Myneni wrote:
>> On 8/24/26 8:10 PM, 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.
>>>
>>
>> 1) Which Forth systems are getting rid of double length integer input?
>>
>> I originally did not implement double length integer input in kForth to avoid confusion with floating point. However, with the standardization of base prefixes, and with recognizers (though they are not needed for this), it became easy to implement an unambiguous form of input for double length numbers, requiring a base prefix character and a trailing decimal point e.g.
>>
>> #-170141183460469231731687303715884105728.
>> $ffffffffffffffffffffffffffffffff.
>> %10110001111011000101111.
> 
> Interesting because ...
> 
>    hex #23E1 decimal f. 230.  ok
> 
> works on my system (but apparently not others)
> 
>>
>> 2) What is Forth's niche, in your opinion?
>>
>> I have used Forth for engineering and scientific tasks for over 40 years, with nearly all of my journal publications containing results obtained with Forth. Julian Noble, Charles Montgomery, and Marcel Hendrix also used/use it for the same purposes. The late Prof. Noble even wrote a book called Scientific Forth. Many others have widened Forth's application space well beyond Chuck Moore's original use.
> 
> IIRC Prof Noble wrote FTRAN with the aim of making forth more palatable to
> scientists/engineers.  AFAICS one has to like forth to begin with.
> 

It's integral part of the 4tH preprocessor: "LET x = 15;" simply works. 
You can select floating point operation, double word operation or single 
operation by issuing the appropriate word before execution of the "LET".

Hans Bezemer

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web