6502.org

[ Oops, another post while I've been busy typing. Might as well share this anyway... ]
Yes, that's correct. In FIG Forth (a 16-bit Forth), a literal that's a double number (32 bits) it is compiled as two separate 16-bit literals.

Referring to SCR # 52 of the FIG source code (found in the widely available Installation Manual), we see INTERPRET is the loop to "interpret or compile source text input words." If the word/string can't be recognized by -FIND then it's assumed to be some sort of number, and is evaluated by NUMBER which always returns a double precision result (two 16-bit halves, one stack cell each).

As Garth said, the presence or absence of a decimal point makes a difference to what gets compiled. With no decimal point, the most significant cell returned by NUMBER is DROPped, and what's complied to the dictionary is LITERAL followed by the least-significant half of the number.

But if a decimal point was present, INTERPRET compiles...

• LITERAL followed by the least-significant half of the number, then
  LITERAL followed by the most-significant half of the number.

-- Jeff

Remember that you can use the <# # #S HOLD #> directly for specially formatted output ... they are not limited to the predefined numeric output words. And while you would normally compile them, you are free to use them in the interpreter... for instance, to experiment with different formats to see which one looks best. So the interpreter has to be able to work while the PNO buffer is in use. And IIRC, the fig-Forth interpreter uses WORD.

I have to say, calling a period a decimal point, really is confusing when used this way. A decimal point is a position that is supposed to indicate a fraction of a whole number. And not, the fraction of the input of a whole number.

In this instance, the word, "fraction", is being taken as two different meanings.

This is the definition of DPL in the FigForth manual:
DPL - Number of digits to the right of the decimal point on double integer input. It may also be used to hold output column location of a decimal point in user generated formatting. The default value on single number input is -1.

This is like saying, that the input has only a fraction of the digits of what we really want. The first question I have is then, "Where are the rest of the digits and how do I get them?"

Can I get the definition of DPL (decimal place) to be changed to DNI (double number indicator) or DNR (double number representation). This would alleviate a lot of confusion when explaining how a double number is interpreted.


Does '83 Forth or Ansi-Forth have a different name for the concept of interpreting a double number?

I am at great risk of proclaiming my ignorance on the subject (or stating the painfully obvious), but I think that all of the digits are parsed, and the dot is a modifier (not a delimiter) that can appear anywhere in the stream. So, in a 16-bit FORTH .16777216 and 16.777216 and 16777216. all provide the double $0100 0000 and it's up to you to decide if the position of the dot is supposed to provide additional meaning over its simple presence.

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?

I still welcome your input Mike.

How would one "decide if the the position of the dot is supposed to provide additional meaning", if the dot is hard coded into the interpreter as just a means of identifying if a number is to be recognized as a double number for printout purposes? There isn't any interpretation of the period after a number has already been interpreted.

You're right; the word "decimal" isn't always appropriate. Some folks call it a radix point instead.
The answer to "How would one [...]" is, you'd provide that extra code yourself. If you need the extra capability, that is (and can spare the extra memory). Not all users do and can.

I see Garth has touched on this point. Because "you can know how many were after the period" (thanks to DPL) you therefore have the info you need if you want to create more capable code.

I hope you're not complaining that FIG doesn't have a fully fleshed out system for inputting and outputting double precision numbers. For a piece of work made freely available in 1980, what they managed to achieve and include is pretty amazing, I'd say!

-- Jeff

Right! I wouldn't normally use binary for anything either, but I am using it as an example to justify the space between HERE and PAD as that seems the most likely reason that is how the 68 byte gap was calculated. Yeah, I am starting to see that I will have to do more with numeric definitions to fully appreciate what I can do with the period. But currently I only have the D.R definition to print a double number, and that is a closed loop as it converts the number on the stack to a numeric printout and then is immediately printed using TYPE. To do anything with the period, I have to be able to insert some programming between those two actions, which basically means separating the definition, or redefining it.

I am slowly coming around. Thanks for everyone's patience.

The most common PURPOSE is as a decimal point. Suppose an application works in integer money scaled to the mill. You enter "45.95" so on checking where the DPL is located, the entry word multiplies the value entered by 10 so that the unit remains mills.

You can see why doubles were specified for this back in the late 70s... $ to the mill with single cells in a 16bit Forth would mean $66 would be out of range.

DPL has nothing to do with output. It doesn't directly modify input, it only provides the ability for an input word to respond to the placement of the seperator point if desired. But if it does, that changes the contents of the stack. It would be highly objectionable if unformatted output words were to violate their definitions in response to the contents of DPL: given the same stack contents, they should always have the same output.

Now, both the early Forth Inc. people and the Forth Interest Group people pragmatists, and if there was an application with a non-decimal base where using a "hexedecimal point" or an "octal point" was useful, I am sure they would not let the "D" in DPL stand in their way. But for bases other than 10, the point was typically a final point just used to indicate that a double cell number was being input, so that operation of the point was orthogonal to choice of base.