Prev: Public review - new intrinsic procdures
Next: Public review - CRITICAL and BLOCK
From: James Giles on 5 Jul 2008 02:38
LEADZ and TRAILZ

The intrinsic functions LEADZ and TRAILZ should be called
LEFTZ and RIGHTZ resprectively.

It's true that if you look far enough you can find uses of
"lead" and "trail" that conform to the meaning you intend in
the present proposed document. However, you don't have to
look far afield to find uses that aren't consistent with
your intent. In fact, the description of TRANSFER talks
about the "leading parts" of source values and results. If
I look at actual implementations that support more than one
INTEGER KIND, I find no compilers available to me where those
"leading parts" aren't the least significant parts.

You don't have to look afield at all to find "left" and
"right" used in the sense I propose. In fact, many new
intrinsics in the F2008 document (shifts and masks) use
the terms quite consistently. The BIT model also defines
the left bits to be the most significant and the right to
be the least significant. I've never seen anyone use
"left" and "right", with respect to the bits of a number,
differently.

Aside from the issue of clarity, there are no other criteria
in which the two naming conventions differ. They even
require the same number of characters to write out. The
most mnemonic should be the naming convention chosen.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra


From: James Van Buskirk on 5 Jul 2008 10:58
"James Giles" <jamesgiles(a)worldnet.att.net> wrote in message
news:rFEbk.95941$102.52752(a)bgtnsc05-news.ops.worldnet.att.net...

> You don't have to look afield at all to find "left" and
> "right" used in the sense I propose. In fact, many new
> intrinsics in the F2008 document (shifts and masks) use
> the terms quite consistently. The BIT model also defines
> the left bits to be the most significant and the right to
> be the least significant. I've never seen anyone use
> "left" and "right", with respect to the bits of a number,
> differently.

Using left and right to specify more significant and less significant
bits of a number is a bad idea because it introduces yet another
arbitrary polarity to remember. LEADZ and TRAILZ are unambiguous
and if the standard uses left and right in other contexts it may be
worthwhile to change its wording to more polarity-free possibilities.

For example if you print out the bytes of 123456789 on a little-
endian machine you get 15 CD 5B 07 in that order. If you shift left
8 bits you don't get CD 5B 07 00 as a result.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: James Giles on 5 Jul 2008 15:28
James Van Buskirk wrote:
> "James Giles" <jamesgiles(a)worldnet.att.net> wrote in message
> news:rFEbk.95941$102.52752(a)bgtnsc05-news.ops.worldnet.att.net...
>
>> You don't have to look afield at all to find "left" and
>> "right" used in the sense I propose. In fact, many new
>> intrinsics in the F2008 document (shifts and masks) use
>> the terms quite consistently. The BIT model also defines
>> the left bits to be the most significant and the right to
>> be the least significant. I've never seen anyone use
>> "left" and "right", with respect to the bits of a number,
>> differently.
>
> Using left and right to specify more significant and less significant
> bits of a number is a bad idea because it introduces yet another
> arbitrary polarity to remember. [''']

You mean like shiftl and shiftr, maskl and maskr, and the defintion
of the BIT model do? This isn't "yet another" arbitrary polarity.
It's the *same* arbitrary polarity that the standard already consistently
uses throughout. In fact, it's the same arbitrary polarity that people
use for digits of numbers (whether in computing or not) world wide.
I've never seen any other choice than to put the least significant
digits on the right and the most significant digits on the right. Even
people whose natural language is written right-to-left write their
numbers with the least significant digits on the right and the most
significant on the left. It's the arbitrary polarity that all of humanity
seems already to have chosen.

It's LEADZ and TRAILZ that try to establish yet another arbitrary
polarity. One that's used nowhere else in the standard (except one
place where the polarity is actually *opposite* the one intended
by the new intrinsics). One that opposite a lot of other people's
use of the terms lead and trail. It's *NOT* a convention that
even most of humanity has already chosen.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra


From: tholen on 5 Jul 2008 15:43
> I've never seen any other choice than to put the least significant
> digits on the right and the most significant digits on the right.

I have: July 5, 2008.

> Even
> people whose natural language is written right-to-left write their
> numbers with the least significant digits on the right and the most
> significant on the left.

I prefer to write dates as 2008 July 5 to be consistent with other
numerically-ordered quantities (which makes dates easier to sort
chronologically, especially after changing character months to
numerical months).
From: Gordon Sande on 5 Jul 2008 16:43
On 2008-07-05 16:43:34 -0300, "tholen(a)antispam.ham"
<tholen(a)ifa.hawaii.edu> said:

>> I've never seen any other choice than to put the least significant
>> digits on the right and the most significant digits on the right.
>
> I have: July 5, 2008.
>
>> Even
>> people whose natural language is written right-to-left write their
>> numbers with the least significant digits on the right and the most
>> significant on the left.
>
> I prefer to write dates as 2008 July 5 to be consistent with other
> numerically-ordered quantities (which makes dates easier to sort
> chronologically, especially after changing character months to
> numerical months).

Dates are a well known example of TWO standards in use which causes
much trouble.

Does 1/3/2008 mean 1 March 2008 or January 3, 2008? Depends on who
you associate with.



 |  Next  |  Last
Pages: 1 2 3
Prev: Public review - new intrinsic procdures
Next: Public review - CRITICAL and BLOCK