GARTHWILSON wrote:
As far as I can tell, ANS and Forth2012 don't use DPL, but still use things like the decimal point to indicate that the literal-number input is a double. (I'm having trouble figuring out exactly how ANS works in this area. ANS's unnecessary (IMO) complication is partly why I have not made my Forth ANS-compliant.)
DPL does not hide any of the desired digits. All it does is tell you where the . was found, if at all.
This is also where I am having trouble accepting the purpose of the DPL.
For example, all these mean the same thing, these values are in hex:
.1111 D.
11.11 D.
1111. D.
1111 0 D.
They all print the same numeric output of 1111. Personally, I think this is a really poor use of the period. I refuse to call it a decimal point which has a different meaning for me
If the printout is going to be a double number anyways, I think I would have preferred the DPL use this as a double number representation of each number:
.1111 - would be the same as entering 1111 0 D. - which prints out 1111
11.11 - would be the same as entering 11<spc>11 D. - which prints out 110011
1111. - would be the same as entering 0 1111 D. - which prints out 11110000 (remember these are 32-bit hex representations)
This way makes much more sense especially when dealing with binary numbers and having a long row of zeroes as it would basically eliminate leading zeroes for both the low value and the high value. Lets switch to binary mode and see what this looks like:
Note: the spaces are only used here for demonstration purposes so the zeroes can be counted, but actually the numbers would be entered as one big long string:
00000000 00000001 00000000 00000001 - would have been much easier to type in 1.1 even though it is the same as 1<spc>1 D.
00000001 00000000 00000001 00000000 - would still be much easier to type 100000000.100000000 (19-digits) as it still eliminates a few leading zeroes. It takes more thought to enter the regular way as the period is not used to show separation between the low and high values. The regular use of the period always requires 16-digits to be used for the low number before the high number can be identified (if the high# is not zero). This number would minimally be portrayed as 100000000.0000000100000000 (requiring 26-digits and the period can be anywhere within the string)
10000000 00000000 10000000 00000000 - would require a full entry of 32 digits: 100000000000000.100000000000000
00000000 00000001 10000000 00000000 - would be entered as 1.1000000000000000 (18-digits)
For me, not only does this look like a significant savings in typing in some cases, if the DPL were to be used this way instead, but also takes a lot less thought. The less I have to think about something the easier things are.
Thoughts?