Double Number Words and Nomenclature

[krishna...@ccreweb.org]

I'm missing a few useful words for working with double numbers in kForth, which will be added in the next development versions. However, I'm a bit uncertain about naming of one of the words. I want to add an intrinsic word to print an unsigned double number, and my inclination is to call it "UD.". However, a standard word for comparing two unsigned double numbers is named "DU<". Why is this word not named "UD<"? I notice that gforth provides "DU<" and "UD.". Is there any good reason behind this inconsistency?

I believe UD. is not a standard word, unless it appears in Forth 20xx. It can be written in source but it seems to me better for it to be a standardized word.

Krishna

[Elizabeth D. Rather]

The general philosophy is to take an existing word, of which a special
version is needed, and add a prefix denoting what is special. Here, the
basic word is, of course, . for which there is also U. (unsigned .).
There is also D. (Double .). SwiftForth has U. D. and DU. (suggesting
that the latter is "Double U." rather than "Unsigned D.". It probably
depends on the order in which the need was identified. My guess is that,
historically, the single-precision words came first, so the double
versions are the modification, so DU. would be preferred. But, it's
really up to you, since your editor can do a "search and replace" on UD.
--> DU. in the blink of an eye. Unless, of course, you have some of both!

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Anton Ertl]

krishna...@ccreweb.org writes:
>I'm missing a few useful words for working with double numbers in kForth, w=
>hich will be added in the next development versions. However, I'm a bit unc=
>ertain about naming of one of the words. I want to add an intrinsic word to=
> print an unsigned double number, and my inclination is to call it "UD.". H=
>owever, a standard word for comparing two unsigned double numbers is named =
>"DU<". Why is this word not named "UD<"? I notice that gforth provides "DU<=

>" and "UD.". Is there any good reason behind this inconsistency?

Not that I remember. I guess it was just intuitively named, using the
same intuition that you had.

Gforth has:

Documented:

ud. ud.r
du< du> du<= du>=

Undocumented (may change in the future):

ud/mod
du= du<> du/mod

ud/mod and du/mod are different (a pretty bad idea IMO).

ud/mod ( ud1 u2 -- urem udquot )

du/mod ( d u -- n u1 )
""d=n*u+u1, u>u1>=0; PolyForth style mixed division""

So DU/MOD is somewhere between UM/MOD and FM/MOD

>I believe UD. is not a standard word, unless it appears in Forth 20xx. It c=
>an be written in source but it seems to me better for it to be a standardiz=
>ed word.

If you write the proposal, you have to choose a name.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/

[krishna...@ccreweb.org]

On Wednesday, June 29, 2016 at 6:05:17 AM UTC-5, Anton Ertl wrote:
> krishna...@ccreweb.org writes:
> >I'm missing a few useful words for working with double numbers in kForth, w=
> >hich will be added in the next development versions. However, I'm a bit unc=
> >ertain about naming of one of the words. I want to add an intrinsic word to=
> > print an unsigned double number, and my inclination is to call it "UD.". H=
> >owever, a standard word for comparing two unsigned double numbers is named =
> >"DU<". Why is this word not named "UD<"? I notice that gforth provides "DU<=
> >" and "UD.". Is there any good reason behind this inconsistency?
>
> Not that I remember. I guess it was just intuitively named, using the
> same intuition that you had.
>

Personally, I prefer that all words dealing with unsigned double argument(s) (or "double unsigneds" ?) start with the prefix, "UD", rather than with "DU". This seems more natural to me, but it is just my bias, probably rooted in experience with C: A data type of "unsigned double" is like "unsigned long long" in C, while "double unsigned" is less familiar. Regardless of which is used, I think we should have consistency, and, as Elizabeth points out, SwiftForth was consistent in providing "DU<" and "DU." Thus far, the standard only has one word "DU<", but even in the specification of this word in the standard, the stack diagram is shown as ( ud1 ud2 -- b ), so it seems there is a consistency problem.

> Gforth has:
>
> Documented:
>
> ud. ud.r
> du< du> du<= du>=
>

Consistency would be best, because a programmer shouldn't have to remember these differences.

> Undocumented (may change in the future):
>
> ud/mod
> du= du<> du/mod
>
> ud/mod and du/mod are different (a pretty bad idea IMO).
>
> ud/mod ( ud1 u2 -- urem udquot )
>
> du/mod ( d u -- n u1 )
> ""d=n*u+u1, u>u1>=0; PolyForth style mixed division""
>
> So DU/MOD is somewhere between UM/MOD and FM/MOD
>

A full set of words for working with signed and unsigned double integers is very much needed, particularly for 32-bit systems. I suspect a full set will be useful on 64-bit systems as well. It's clear to me that the standard at present is too poor in the double number words.

> >I believe UD. is not a standard word, unless it appears in Forth 20xx. It c=
> >an be written in source but it seems to me better for it to be a standardiz=
> >ed word.
>
> If you write the proposal, you have to choose a name.
>

I'd be inclined to reset the words to UD<x> , where <x> is the operation, since the standard at present specifies only one such word, "DU<". My guess is that non-standard double number words for working with unsigned doubles are not so entrenched in use that we can't propose a consistent standard. However, it would be good to know the provisions of current and past Forth systems on the topic of word names for operating on unsigned doubles.

Krishna

[Coos Haak]

Op Wed, 29 Jun 2016 04:58:59 -0700 (PDT) schreef
krishna...@ccreweb.org:

Agreed.
I view 'double unsigned' to much as 'double negated'

groet Coos

[m...@iae.nl]

On Wednesday, June 29, 2016 at 1:59:01 PM UTC+2, krishna...@ccreweb.org wrote:
> On Wednesday, June 29, 2016 at 6:05:17 AM UTC-5, Anton Ertl wrote:
> > krishna...@ccreweb.org writes:

[..]

> I'd be inclined to reset the words to UD<x> ,
> where <x> is the operation, since the standard
> at present specifies only one such word, "DU<".
> My guess is that non-standard double number
> words for working with unsigned doubles are
> not so entrenched in use that we can't propose
> a consistent standard. However, it would be
> good to know the provisions of current and
> past Forth systems on the topic of word names
> for operating on unsigned doubles.

iForth has

UD>F
UDFLOCAL
(UDFLOCAL)
UDLOCAL
(UDLOCAL)
UDEC.
UD.
UD.R
(UD.)
(UD.R)
UD/MOD
UD+c

DFDUMP
DU<
DU>
DU<=
DU>=

(The last 3 words are undocumented and can only be compiled).

-marcel

[krishna...@ccreweb.org]

...

This suggest to me that we may want to transition from DU< to UD< , for consistency of naming. If we take this approach, UD< can be added as a synonym for DU< in Forth 20xx, and DU< can be deprecated. In addition the following words would be good candidates for including into the standard: UD. UD.R UD/MOD UD>F

I'm thinking two separate RfDs may be in order, one for establishing the naming convention for words which operate on unsigned doubles and a second one proposing additional double number words, for both signed and unsigned doubles, to be included in the standard. The latter proposal should keep the list of added words to a minimum to satisfy an acceptable level of convenience for programmers -- at present the double number words and extensions in the standard is far too sparse for convenient programming.


By the way, what does DFDUMP do?

Krishna

[m...@iae.nl]

On Thursday, June 30, 2016 at 1:37:11 PM UTC+2, krishna...@ccreweb.org wrote:
> On Wednesday, June 29, 2016 at 1:44:18 PM UTC-5, m...@iae.nl wrote:
> > On Wednesday, June 29, 2016 at 1:59:01 PM UTC+2, krishna...@ccreweb.org wrote:
[..]

> By the way, what does DFDUMP do?

DFDUMP ( addr u -- ) dumps the u IEEE double precision FP
numbers starting at addr to the terminal.
Only needed when the Forth does not use a 64-bit IEEE double
as its default format (see DUMP, SFDUMP, FDUMP). The list could
be extended but I use the missing ones only very infrequently.

-marcel

[ruvim...@gmail.com]

On Wednesday, June 29, 2016 at 2:59:01 PM UTC+3, krishna...@ccreweb.org wrote:

> Personally, I prefer that all words dealing with unsigned double
> argument(s) (or "double unsigneds" ?) start with the prefix, "UD",
> rather than with "DU". This seems more natural to me, but it is just
> my bias, probably rooted in experience with C: A data type of
> "unsigned double" is like "unsigned long long" in C,
> while "double unsigned" is less familiar.

For consistency we should look below the surface
and don't take into account how it can be translated into C:
"double unsigned" or "unsigned double".

By history reasons and conventions in Forth, one words family can be based
(in terms of naming) on another words family via using some prefix
for their names.

Particularly, single unsigned number words family is based on single signed
number words family via prefix 'U' (e.g. 'U<' from '<').

In the same way double number words family is based on single number words
family via prefix 'D'. Namely, double-signed-number words family is based
on single-signed-number words family e.g.
'D<' from '<'

But further we have two options.

1. Double-unsigned-number words family is based on single-unsigned-number
words family. And we get the final prefix 'DU' e.g.
'DU<' from 'U<'
And consequently:
'D0<' from '0<' (particular double from particular single)

2. Double-unsigned-number words family is based on double-signed-number
words family. And we get the final prefix 'UD' e.g.
'UD<' from 'D<'
And consequently:
'0D<' from 'D<' (particular double from basic double)


So to be consistent, we should take into account not only double unsigned number words family, but the whole double number words family, and use the same rule for all the names.

I prefer the first reasoning, and 'DU<', 'D0<', etc. form of the names.


--
Ruvim

[krishna...@ccreweb.org]

Ruvim writes:
...
> 2. . Double-unsigned-number words family is based on double-signed-number

words family. And we get the final prefix 'UD' e.g.
'UD<' from 'D<'
And consequently:
'0D<' from 'D<' (particular double from basic double)

...

This argument does not seem sensible to me. The operation is "less than zero", operating on signed double numbers. Then, it should either be D0< or 0<D. Clearly, the latter is problematic.

...

>I prefer the first reasoning, and 'DU<', 'D0<', etc. form of the names.

Your preference for the ordering is fine. There is really nothing wrong with this ordering, but, for the reasons I listed in my RfD for proposing UD<x>, I believe it is the more readily accepted convention. There is no logical basis that I can see to prefer DU<x> other than the existing standard contained a single word which used this convention. A consistent naming convention is the important goal here.

Krishna

[hughag...@gmail.com]

Straight Forth is significantly simpler than ANS-Forth --- about half the size --- none of these complicated naming issues are present in Straight Forth.

Straight Forth has a 64-bit cell with an assumed unity if 2^32. All addresses are 32-bit signed (the dictionary is in the positive half and the heap is in the negative half). There are no unsigned numbers.

Double numbers would be an optional extension. This may never be needed however, and if it is needed it will only be needed by a few programmers --- unless you are guiding a spaceship to Pluto, you don't really need 128-bit numbers.

All the operators working on double-numbers would have a 'D' prefix. Also, there is a separate stack for doubles (similar to how ANS-Forth has a separate stack for floats). One of the major causes of hard-to-read stack-juggling in ANS-Forth is that single-precision and double-precision numbers are mixed together on the same stack. Mixed-precision operators use both stacks. For example, M* takes two parameters off the single-stack and puts one result on the double-stack. As another example, S>D takes one parameter off the single-stack and puts one result on the double-stack.

All in all, ANS-Forth is just over-complicated! I would really expect Straight Forth to be half the size, which means that it can be learned in half the time, and twice as powerful and featureful.