| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:07:21 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
Yes ... those traditions ... as was COMPILE from earlier Forths.
Banned because it was ambiguous.
Luckily we now have POSTPONE which makes everything clearer.
But sorry, that was an inappropriate remark ...
Back to double numbers: with the new recogniser concept
recognition of different double number formats is laid into
the hand of users, and such standardisation becomes more of a
recommendation.
albert@spenarnc.xs4all.nl writes:
One step further is to use 0x for hex values, and free $ for
environment strings.
Forth systems can use 0x as hex prefix already, and in 2007 I checked
several systems <http://www.forth200x.org/number-prefixes.html>: PFE,
Gforth 0.6.9, Win32Forth (4.x and 6.x), and VFX Forth understood 0x10
as well as 0X10; iForth, bigForth, SwiftForth, and lxf did not.
Someone would need to make a proposal for making the $ prefix for hex
numbers obsolescent as a first step towards destandardization.
Meanwhile, Gforth has a recognizer for environment variables:
${HOME} type
prints "/home/anton".
- anton
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
<https://forth-standard.org/standard/double#subsection.8.3.1>
Aha, thanks. Similarly 8.3.2 for DPANS94. Oddly, in gforth, "123.45"
pushes 12345 0. I can understand "123." is a number (123) followed by a >decimal point, but I'd expect the 45 to either be invalid or another
number, giving 123 0 45.
A forth that interprets e.g. 3.14 as a floating point number
is as non-standard as a Forth that interprets 3.14 is a double.
How would a proposal like this fare:
"
A double number is only recognized as it ends *and starts*
with a period.
Recognizing a double if it ends only in a period becomes
obsolescent.
"
To support DPL I have >NUMBER increment it for every digit successfully converted. While most systems today have DPL (?) usage is probably too diverse to standardize.
there's been little historical demand '1.34' be recognized as a float.
dxf <dxforth@gmail.com> writes:
there's been little historical demand '1.34' be recognized as a float.
It's a mistake I make all the time, but I figure it's one of Forth's
frozen oddities.
In a non-ANS Forth, I'd probably make 1.34 a float and
use some other scheme for literal doubles.
So it's one or the other and your comment suggests doubles are
preferred.
This relates to the forth interpreter and from my observation there's
been little historical demand '1.34' be recognized as a float.
A curiosity it certainly is as it's so unusual.
On 1/01/2025 2:42 pm, Bernd Linsel wrote:
It's usually implemented that DPL is reset to -1 when entering >NUMBER,
each successful digit conversion increments it only if it is >= 0, and the first decimal separator encountered changes it from -1 to 0.
Yes, in Fig-Forth. In Swiftforth DPL is just a flag.
But does anybody actually make use of DPL? I have not seen a single
use, ever. Is it just some feature that someone thought up and
implemented, and we all continued to implement it because we could and
it was traditional?
I have used DPL sporadically:<SNIPPED examples of assemblers>
Found 25 occurrence(s) in 6 file(s), 35346 ms
Given it is in the assembler and the postscript plotter, I would not be
a happy customer when it proved to be lacking.
-marcel
Embedded punctuation in doubles was something I was never happy with (misleading, can make a typo and still be accepted). So when ANS limited
it to one decimal point at the end I was rather relieved.
I'm having trouble finding the place in ANS 94[0] or Forth 2012[1] where
any of this is specified. That surprises me. Particularly, 3.4.1.3
Text interpreter input number conversion doesn't discuss the matter.
<https://forth-standard.org/standard/double#subsection.8.3.1>
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
<https://forth-standard.org/standard/double#subsection.8.3.1>
Aha, thanks. Similarly 8.3.2 for DPANS94. Oddly, in gforth, "123.45"
pushes 12345 0. I can understand "123." is a number (123) followed by a decimal point, but I'd expect the 45 to either be invalid or another
number, giving 123 0 45.
On 26/12/2024 10:28 am, Paul Rubin wrote:
dxf <dxforth@gmail.com> writes:
there's been little historical demand '1.34' be recognized as a float.
It's a mistake I make all the time, but I figure it's one of Forth's
frozen oddities. In a non-ANS Forth, I'd probably make 1.34 a float and
use some other scheme for literal doubles.
Embedded punctuation in doubles was something I was never happy with >(misleading, can make a typo and still be accepted). So when ANS limited
it to one decimal point at the end I was rather relieved.
albert@spenarnc.xs4all.nl writes:
A forth that interprets e.g. 3.14 as a floating point number
is as non-standard as a Forth that interprets 3.14 is a double.
Forth-94 and Forth-2012 do not standardize recognizing 3.14, so
standard systems are allowed to deal with "3.14" as they deem useful.
The possible options include recognizing "3.14" as a double-cell
integer, as a FP number, or not recognizing "3.14" and producing an
error message.
However, I think that recognizing "314." as a double-cell integer (as >required by these standards), but recognizing "3.14" as an FP number
is even more confusing and error prone than recognizing both as a
double-cell integer.
How would a proposal like this fare:
"
A double number is only recognized as it ends *and starts*
with a period.
Existing practice? What's wrong with "#314."?
I meantRecognizing a double if it ends only in a period becomes
obsolescent.
"
That part may have an easier time.
- anton--
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
The confusion between 31E0 (hex) 31E0 (fp) 3.10 is another
roadblock to Forth newbies.
Paul Rubin <no.email@nospam.invalid> writes:
I'm having trouble finding the place in ANS 94[0] or Forth 2012[1] where >>any of this is specified. That surprises me. Particularly, 3.4.1.3
Text interpreter input number conversion doesn't discuss the matter.
<https://forth-standard.org/standard/double#subsection.8.3.1>
- anton
FWIW, probably nothing, there is no mention of DPL in the standard.It is one of those traditions.
Well, I consider mixed-math to be genius :) Was it a Forth first -
or it pre-existed in some language/system?
More recent CPUs use different implementation techniques, so recent architectures tend not to provide mixed-width division instructions.
They tend to have support for mixed-width multiplication (but usually
split that into two instructions), probably because it's important for implementing wide multiplication, which is important for cryptography.
albert@spenarnc.xs4all.nl writes:
The confusion between 31E0 (hex) 31E0 (fp) 3.10 is another
roadblock to Forth newbies.
Certainly, especially the latter. The hex problem can be eliminated
by always keeping the BASE as DECIMAL, and writing hex numbers as
$31E0. The 3.10 tradition and the 31. standard can be addressed with
a variation of your statement:
Recognizing a double if it contains no number prefix and one single
period at the end is obsolescent.
One step later a standard Forth system could recognize 3.10 as well as
31. and 31e as FP values, #31. as a double-cell integer, and $31e
as a single-cell integer.
- anton
One step further is to use 0x for hex values, and free $ for
environment strings.
Then probably one can forget BASE DECIMAL
1] This is not easy. I have been in many projects where floating points
were transferred in text, loosing precision.
But of course parameters
in oil drill samples need not 5 decimal places.