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.
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.
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.
...
floating-point which isn't even forth's niche (RPN and all that)
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.
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.-a 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.
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.
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.-a 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)
...
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.-a 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 ...
-a-a hex #23E1 decimal f. 230.-a 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?
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.-a 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 ...
-a-a hex #23E1 decimal f. 230.-a 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.
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:It's not.-a Though I did expect it to work on other forths.
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.-a 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 ...
-a-a-a hex #23E1 decimal f. 230.-a ok
works on my system (but apparently not others)
...
How is your example above relevant to interpreting double length integers? >>
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:
...
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.-a # forces decimal interpretation.
It fails as an integer/double due to 'E'.-a 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
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
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.-a 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.
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.
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.-a 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
In article <116js4d$3le16$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
On 8/24/26 11:17 PM, dxf wrote:to avoid confusion with floating point. However, with the
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.-a 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
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.
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--
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:to avoid confusion with floating point. However, with the
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.|e-a 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
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.
But to allow this one either needs
separate hex float prefix or some other syntactic way to
distinguish them from double integers.
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
C99's %a conversion format for printf uses (in regexp syntax):
-?0xh.h*[+-]d+
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
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: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.
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.|e-a 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
My goals was severely restricted. In the absence of prefixes and a
#-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? >>>
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
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 122:20:56 |
| Calls: | 1,194 |
| Files: | 1,352 |
| Messages: | 290,355 |