Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #48695 > unrolled thread

RfD: Unsigned Double Words Naming Convention

Back to article view | Back to comp.lang.forth

Contents

  RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-02 07:25 -0700
    Re: RfD: Unsigned Double Words Naming Convention Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 10:01 -0500
    Re: RfD: Unsigned Double Words Naming Convention ruvim.pinka@gmail.com - 2016-07-02 12:43 -0700
      Re: RfD: Unsigned Double Words Naming Convention rickman <gnuarm@gmail.com> - 2016-07-03 01:05 -0400
        Re: RfD: Unsigned Double Words Naming Convention ruvim.pinka@gmail.com - 2016-07-03 00:31 -0700
          Re: RfD: Unsigned Double Words Naming Convention rickman <gnuarm@gmail.com> - 2016-07-03 11:54 -0400
      Re: RfD: Unsigned Double Words Naming Convention "HAA" <someone@microsoft.com> - 2016-07-05 00:19 +1000
        Re: RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-04 07:37 -0700
          Re: RfD: Unsigned Double Words Naming Convention "HAA" <someone@microsoft.com> - 2016-07-07 13:01 +1000
            Re: RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-09 08:40 -0700
              Re: RfD: Unsigned Double Words Naming Convention "HAA" <someone@microsoft.com> - 2016-07-10 18:23 +1000
                Re: RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-10 08:27 -0700
      Re: RfD: Unsigned Double Words Naming Convention "HAA" <someone@microsoft.com> - 2016-07-04 13:59 +1000
        Re: RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-03 22:42 -0700
      Re: RfD: Unsigned Double Words Naming Convention krishna.myneni@ccreweb.org - 2016-07-03 21:09 -0700
        Re: RfD: Unsigned Double Words Naming Convention ruvim.pinka@gmail.com - 2016-07-10 20:37 -0700
        Re: RfD: Unsigned Double Words Naming Convention ruvim.pinka@gmail.com - 2016-07-10 21:07 -0700

#48695 — RfD: Unsigned Double Words Naming Convention

RfD: Unsigned Double Words Naming Convention

v1 : 2 July 2016  km


Problem:
---------

ANS Forth presently provides a single word for operating on unsigned double length integers, DU< , within the double number extensions wordset. Other standard words for operating on unsigned double numbers in Forth are desired to be added to standard Forth (Forth 20xx standard), e.g. a word to print an unsigned double. A consistent naming convention , compatible with commonly used practice is highly desirable to alleviate the burden on the programmer from having to remember multiple conventions when working with future standardized words.


Solution:
---------

A consistent naming convention for unsigned double number words presents two options currently in use: 1) DU<x> or 2) UD<x> , where <x> represents an operation. Based on existing practice and comments made on comp.lang.forth, the second convention, UD<x> , appears to be preferred. Several arguments may be made in favor of this convention: a) unsigned double numbers are typically represented in stack diagrams as ud1 ud2 ... etc, b) the term "unsigned double" is easier to associate with the desired data type than the term, "double unsigned", 3) implementation of non-standard words in existing Forth systems indicates a preference for UD<x>. 


Proposal:
--------

Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .

Reference Implementation:
------------------------

: UD< ( ud1 ud2 -- b )  DU< ;


Existing Practice:
---------------

Several Forth systems, e.g. Gforth and iForth, provide the presently non-standard  word UD. for printing an unsigned double to the console, which is inconsistent with the convention implied by the standard word DU< . SwiftForth provides DU. for the same purpose, which makes it consistent with the naming precedent set by DU< . 



Krishna Myneni

[toc] | [next] | [standalone]

#48703

On 7/2/2016 9:25 AM, krishna.myneni@ccreweb.org wrote:
> RfD: Unsigned Double Words Naming Convention
>
> v1 : 2 July 2016  km
>
>
> Problem:
> ---------
>
> ANS Forth presently provides a single word for operating on unsigned double length integers, DU< , within the double number extensions wordset. Other standard words for operating on unsigned double numbers in Forth are desired to be added to standard Forth (Forth 20xx standard), e.g. a word to print an unsigned double. A consistent naming convention , compatible with commonly used practice is highly desirable to alleviate the burden on the programmer from having to remember multiple conventions when working with future standardized words.
>
>
> Solution:
> ---------
>
> A consistent naming convention for unsigned double number words presents two options currently in use: 1) DU<x> or 2) UD<x> , where <x> represents an operation. Based on existing practice and comments made on comp.lang.forth, the second convention, UD<x> , appears to be preferred. Several arguments may be made in favor of this convention: a) unsigned double numbers are typically represented in stack diagrams as ud1 ud2 ... etc, b) the term "unsigned double" is easier to associate with the desired data type than the term, "double unsigned", 3) implementation of non-standard words in existing Forth systems indicates a preference for UD<x>.
>
>
> Proposal:
> --------
>
> Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .
>
> Reference Implementation:
> ------------------------
>
> : UD< ( ud1 ud2 -- b )  DU< ;
>
>
> Existing Practice:
> ---------------
>
> Several Forth systems, e.g. Gforth and iForth, provide the presently non-standard  word UD. for printing an unsigned double to the console, which is inconsistent with the convention implied by the standard word DU< . SwiftForth provides DU. for the same purpose, which makes it consistent with the naming precedent set by DU< .
>
>
>
> Krishna Myneni
>
Makes sense, good luck on the proposal.


-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#48712

On Saturday, July 2, 2016 at 5:25:37 PM UTC+3, krishna...@ccreweb.org wrote:

[...]

> Proposal:
> --------
> 
> Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .


I'm against this variant because to be consistent with this convention you also need to rename:

  'D0<' into '0D<'
  'D2*' into '2D*'
  'D2/' into '2D/'


See my message in "Double Number Words and Nomenclature" thread.

It is better to change representation ud into du in stack diagrams (the only one worth argument).


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#48729

On 7/2/2016 3:43 PM, ruvim.pinka@gmail.com wrote:
> On Saturday, July 2, 2016 at 5:25:37 PM UTC+3, krishna...@ccreweb.org wrote:
>
> [...]
>
>> Proposal:
>> --------
>>
>> Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .
>
>
> I'm against this variant because to be consistent with this convention you also need to rename:
>
>   'D0<' into '0D<'
>   'D2*' into '2D*'
>   'D2/' into '2D/'

I don't follow your reasoning at all.  I don't see how the issue of 
double unsigned which is a type has anything to do with the notation of 
a double precision zero value used for a comparison.


> See my message in "Double Number Words and Nomenclature" thread.
>
> It is better to change representation ud into du in stack diagrams (the only one worth argument).
>
>
> --
> Ruvim
>


-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#48738

On Sunday, July 3, 2016 at 8:05:48 AM UTC+3, rickman wrote:

> >> Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .
> >
> >
> > I'm against this variant because to be consistent with this convention you also need to rename:
> >
> >   'D0<' into '0D<'
> >   'D2*' into '2D*'
> >   'D2/' into '2D/'
> 
> I don't follow your reasoning at all.  I don't see how the issue of 
> double unsigned which is a type has anything to do with the notation of 
> a double precision zero value used for a comparison.

Short answer: the unified name convention. It doesn't matter what the types at all. The matter is to apply the same rule (the rule how to compose one name from another name) for all the names from double-number words set.


> > See my message in "Double Number Words and Nomenclature" thread.

The mentioned message: https://groups.google.com/d/msg/comp.lang.forth/A3BgYVoamZk/GzAM4bo1BwAJ

Rick, did you have a chance to look at the reasoning in those message?

Please let me know if the reasoning is still unclear — I will try to explain.


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#48758

On 7/3/2016 3:31 AM, ruvim.pinka@gmail.com wrote:
> On Sunday, July 3, 2016 at 8:05:48 AM UTC+3, rickman wrote:
>
>>>> Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard word DU< and deprecate the use of DU< .
>>>
>>>
>>> I'm against this variant because to be consistent with this convention you also need to rename:
>>>
>>>   'D0<' into '0D<'
>>>   'D2*' into '2D*'
>>>   'D2/' into '2D/'
>>
>> I don't follow your reasoning at all.  I don't see how the issue of
>> double unsigned which is a type has anything to do with the notation of
>> a double precision zero value used for a comparison.
>
> Short answer: the unified name convention. It doesn't matter what the types at all. The matter is to apply the same rule (the rule how to compose one name from another name) for all the names from double-number words set.

So what is the rule?


>>> See my message in "Double Number Words and Nomenclature" thread.
>
> The mentioned message: https://groups.google.com/d/msg/comp.lang.forth/A3BgYVoamZk/GzAM4bo1BwAJ
>
> Rick, did you have a chance to look at the reasoning in those message?
>
> Please let me know if the reasoning is still unclear — I will try to explain.

Yes, it is unclear.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#48769

krishna.myneni@ccreweb.org wrote:
> HAA writes:
> ...
> > Agreed.  All the 'D' words in ANS begin with .... D.  UD. would break that convention.
>
>
> Consider the following words from the floating point wordset:
>
>   DF@  DF!  SF@  SF!
>
> By your argument, these words should be named
>
>   FD@  FD!  FS@  FS!
>
> The current naming of these words in the standard means that D and S are modifiers for
> the type float. Putting the operations, @ and ! , next to F seems the most sensible
> thing to do.
>
> Similarly, U is a modifier for the type double in UD< .
>
> I wonder if our difference in preferences are not linguistic in origin, i.e. preferring
> UD<x> to DU<x> is due to the normal order of expressions in the English language. In
> other languages, modifiers follow the noun. Actually, one could argue that the latter
> is more Forth-like, but I think it presents problems as in the hypothetical case of
> renaming DF@ to FD@ (purely for the sake of argument here).

I use both DU< and UD.  Academically they may be inconsistent but so
is human language and its users don't even notice.  Learnt when children,
language inconsistencies vanish as memory and instant recall kick in.
It's the same with DU< and UD.  Both have been around so long that
Forth users only need to see the words and their respective actions
automatically pop into mind.  We don't change human language simply
to satisfy an academic principle.  IMO neither should we do it for Forth.

[toc] | [prev] | [next] | [standalone]

#48772

HAA writes:
...
> We don't change human language simply 
to satisfy an academic principle.  IMO neither should we do it for Forth. 

In this case, we have the opportunity to impose consistency because there is only one word in the standard following the convention DU<x>. And the proposal does not call for removing the word DU< , so if you're used to it, fine -- it will still work portably. If there were several standard words which used the convention DU<x> and we proposed to add more words to the standard for unsigned double operations, as expected, then the opportunity arises for use to be consistent. In fact, the plan is to propose more standard words of the form UD<x>, which have been implemented independently and found to be useful in several Forth systems. For the RfD at hand, imposing consistency makes sense to me.

Krishna

[toc] | [prev] | [next] | [standalone]

#48857

krishna.myneni@ccreweb.org wrote:
> HAA writes:
> ...
> > We don't change human language simply
> to satisfy an academic principle.  IMO neither should we do it for Forth.
>
> In this case, we have the opportunity to impose consistency because there is only one
> word in the standard following the convention DU<x>.

Consistency is not making changes willy-nilly.  DU< has been standard
for over 30 years.  UD. never has been and there are no doubles in the
Standard that begin with UD .

The reason I wouldn't put UD. in the Standard isn't because the name is
inconsistent with DU< but because it's largely useless.  Forth applications
frequently need more than the simple typed numeric output offered by
Standards.  Most Forth systems have things like (D.) and if yours doesn't
they're easy to create and Forth expects that you will.  IMO posting a library
of output routines would serve Forth better than filling the Standard with
limited-use functions.

[toc] | [prev] | [next] | [standalone]

#48987

HAA writes:
...
> DU< has been standard 
for over 30 years.  UD. never has been and there are no doubles in the 
Standard that begin with UD . 

If the only need for working with unsigned doubles was a missing UD. then I would agree with you. But other primitives are needed also, as mentioned in an earlier thread: UD>F , UD/MOD , UD.R . Hence, the preference for a consistent naming convention. The tendency for excessive minimalism to the point of uselessness in the Forth standard, particularly with the disastrous floating point wordset in ANS Forth, makes it difficult to consider using Forth but for some limited problem domains.

> The reason I wouldn't put UD. in the Standard isn't because the name is 
inconsistent with DU< but because it's largely useless. 

Your statement is purely based on your experience, and the way in which you use Forth. Recently I needed UD. for calculations in the interpreter. Not all computing requires formatted output. The fact that several Forth systems have already implemented UD. or an equivalent is evidence that your statement is wrong.

Krishna

[toc] | [prev] | [next] | [standalone]

#49004

krishna.myneni@ccreweb.org wrote:
> HAA writes:
> ...
> > The reason I wouldn't put UD. in the Standard isn't because the name is
> inconsistent with DU< but because it's largely useless.
>
> Your statement is purely based on your experience, and the way in which you use Forth.
> Recently I needed UD. for calculations in the interpreter. Not all computing requires
> formatted output. The fact that several Forth systems have already implemented UD. or
> an equivalent is evidence that your statement is wrong.
>
> Krishna

My statements are based on experience.  Sending ascii data including numbers to a file
is a common task in computing.  No Forth Standard to date has included numeric string
words.  Do I think they have been negligent in that respect?  No, for the reason I previously
gave.  OTOH I would see as puzzling a Forth system that didn't already provide numeric
string functions - because under the classic Forth model the string form is the basis for
the Standard numeric output words.

My observation is systems that provide UD. usually come with other numeric output
functions including string.  For example F83 from the 1980's provides:

    (U.) U. U.R (.) . .R (UD.) UD. UD.R (D.) D. D.R

The system is providing users with a library of output functions which they can access
if/when they need it.  One of the issues with UD. (and D.) is that they're not always
convenient.  If I'm displaying decimal I may want commas after each thousand; if hex
I might want padding with '0's and a point '.' after each four characters.  That's why
I say UD. is not that useful.

I'll leave it there.  There must be others who have a comment.

[toc] | [prev] | [next] | [standalone]

#49010

HAA writes:
...
> One of the issues with UD. (and D.) is that they're not always 
convenient.  If I'm displaying decimal I may want commas after each thousand; if hex 
I might want padding with '0's and a point '.' after each four characters.  That's why 
I say UD. is not that useful.


I agree that UD. is, in general, less convenient than other output words such as UD.R and that other variants such as leading zero padding can also be quite useful. I believe a general purpose Forth system should still provide UD. though.

Krishna

[toc] | [prev] | [next] | [standalone]

#48770

ruvim.pinka@gmail.com wrote:
> On Saturday, July 2, 2016 at 5:25:37 PM UTC+3, krishna...@ccreweb.org wrote:
>
> [...]
>
> > Proposal:
> > --------
> >
> > Introduce a synonym, UD< , into the Forth 20xx standard for the existing standard
> > word DU< and deprecate the use of DU< .
>
>
> I'm against this variant because to be consistent with this convention you also need to
> rename:
>
>   'D0<' into '0D<'
>   'D2*' into '2D*'
>   'D2/' into '2D/'

Agreed.  All the 'D' words in ANS begin with .... D.  UD. would break that convention.

> It is better to change representation ud into du in stack diagrams (the only one worth
> argument).

I've not heard of anyone confusing a word name with a type designator.  The existing
conventions have been around a very long time.

[toc] | [prev] | [next] | [standalone]

#48776

HAA writes:
...
> Agreed.  All the 'D' words in ANS begin with .... D.  UD. would break that convention. 


Consider the following words from the floating point wordset:

  DF@  DF!  SF@  SF!

By your argument, these words should be named

  FD@  FD!  FS@  FS!

The current naming of these words in the standard means that D and S are modifiers for the type float. Putting the operations, @ and ! , next to F seems the most sensible thing to do.

Similarly, U is a modifier for the type double in UD< . 

I wonder if our difference in preferences are not linguistic in origin, i.e. preferring UD<x> to DU<x> is due to the normal order of expressions in the English language. In other languages, modifiers follow the noun. Actually, one could argue that the latter is more Forth-like, but I think it presents problems as in the hypothetical case of renaming DF@ to FD@ (purely for the sake of argument here).

Krishna

[toc] | [prev] | [next] | [standalone]

#48778

Ruvim writes:
...
> I'm against this variant because to be consistent with this convention you also need to rename: 

  'D0<' into '0D<' 
  'D2*' into '2D*' 
  'D2/' into '2D/' 


I fail to see the logic in splitting the 0< operator and inserting a D in the middle. There is no sensible corresponding operator for unsigned doubles, i.e. UD0< would always return false.

Also, note that 2* and 2/ are arithmetic shift operators, i.e. they preserve the sign bit. Such operations which keep track of a sign bit are not sensible for unsigned doubles.

I responded to your earlier argument against the UD<x> naming convention on your claim that DU<x> is more logical, appearing in a different thread. I don't agree with that claim. The choice boils down to whether or not we wish to think of the data type as "unsigned double" or "double unsigned".

Krishna

[toc] | [prev] | [next] | [standalone]

#49028

Just test for special symbols.
Right arrow: →
Union: ∪
Left right double arrow: ⇔
Subset of: ⊂

[toc] | [prev] | [next] | [standalone]

#49029

Hope my below explanation will close all listed questions.

On Monday, July 4, 2016 at 7:09:32 AM UTC+3, krishna...@ccreweb.org wrote:
> Ruvim writes:
> ...
> > I'm against this variant because to be consistent with this convention you also need to rename: 
> 
>   'D0<' into '0D<' 
>   'D2*' into '2D*' 
>   'D2/' into '2D/' 
> 
> 
> I fail to see the logic in splitting the 0< operator and inserting a D in the middle. There is no sensible corresponding operator for unsigned doubles, i.e. UD0< would always return false.
> 
> Also, note that 2* and 2/ are arithmetic shift operators, i.e. they preserve the sign bit. Such operations which keep track of a sign bit are not sensible for unsigned doubles.
> 
> I responded to your earlier argument against the UD<x> naming convention on your claim that DU<x> is more logical, appearing in a different thread. I don't agree with that claim. The choice boils down to whether or not we wish to think of the data type as "unsigned double" or "double unsigned".
> 
> Krishna



Note 1. The term "word set" is used here in more general sense than in the Standard. Namely, any somehow defined group of words is word set, while in the Standard the number of word sets and their content are fixed.

Note 2. A word set that consists of the words (or names) "A", "B", "C" is denoted as { A B C }.

Note 3. The term "word" often used in sense of "name of the word". 



01. There are many rules of choosing names in Forth culture.

02. One widely used rule is short: take a base name and use some  prefix to compose the new name. Where the base name is name of some another known or defined word, and prefix is arbitrary.
Let Rule1 denote this rule.

Some examples of this rule usage are: "U<", "U.", "U/", "D<", "D+".

We can define Rule1 as function of two arguments using the well-known string interpolation notation (or pattern):

Rule1 : (prefix, base-name) → "{prefix}{base-name}"

Examples:
Rule1("D", "<") = "D<"
Rule1("C", "@") = "C@"


03. We can define bijection for any particular literal prefix "x" in Rule1 as the following function:
base_name → Rule1( "x", base_name )
⇔ (which is equivalent to)
base_name → "x{base_name}"
⇔ (and using short notation for the template)
"x{}"

So "x{}" is function (namely bijection) that represents Rule1 with prefix 'x'.

For example:

Rule1_U : base-name → "U{base-name}"
In short notation: "U{}"

Rule1_D : base-name → "D{base-name}"
In short notation: "D{}"

Examples:
Rule1_U("<") = "U<"
Rule1_U("/") = "U/"
Rule1_D("+") = "D+"
Rule1_D("ABS") = "DABS"


04. Let's consider the following two word sets

Y = { U< U> }
Z = { 0< 0> }

it is obvious that they both are constructed from X = { < > }
using rules "0{}" and "U{}" respectively.

So we can say that the word set X is basis for Y and Z, while Y and Z are derived from X.
Namely:
Y is constructed from X using rule "U{}",
Z is constructed from X using rule "0{}".

05. Let S = ( X ∪ Y ∪ Z ) 
⇒ S = { < > U< U> 0< 0> }

The word set S belongs to single-number word family, word set Y belongs to unsigned-single-number word family.

Obviously that unsigned-single-number-word-family belongs to single-number-word-family.


06. We need to construct the double-number word family.
Let's find rules to construct a word set D corresponding to the word set S.
I.e. with some bijection between D and S.

07. The obvious and simple way (I): use the single rule "D{}".
Applying this rule to each word from S we get
D = { D< D> DU< DU> D0< D0> }

In this case the word set D is entirely derived from word set S.

08. Another variant (II): use the image from point 05. Construct the basic word set DX and extend it with DY and DZ.

DX is constructed from X using rule "D{}", DX = { D< D> }

DY is constructed from DX using rule "U{}", DY = { UD< UD> }
DZ is constructed from DX using rule "0{}", DZ = { 0D< 0D> }

D = ( DX ∪ DY ∪ DZ )

In this case only some part of D is derived from S directly, namely DX from X.
But also relationships between the parts of D are conformable to relationships between the corresponding parts of S (see p.04).


09. Yet another variant (III): use different rules for different parts.

DX is constructed from X using rule "D{}", DX = { D< D> }
DY is constructed from DX using rule "U{}", DY = { UD< UD> }
DZ is constructed from Z using rule "D{}", DZ = { D0< D0> }

D = ( DX ∪ DY ∪ DZ )

In this case we have no logic why for one part we use one rule and for another part — another rule  (except logic of euphony).


10. Conclusion.
 (I) is the simplest and still consistent convention.
 (II) is consistent convention but is not so simple.
 (III) is not simple and is not consistent convention.


Let me know if some point is not clear enough.

--
Ruvim

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web