www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - .sign(s) of rash design or just my head?

reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Pardon the pun. When doing the example to follow up the suggestion 
Walter gave me in response my latest lament about the D language, the 
lack of a separate unsigned keyword, I ran into a bit of a problem - 
namely the .sign property of integral and real number primitive types.

The docs cover these with the first for integral types and the second 
for floating point types:

	.sign		should we do this?

and

	.sign		1 if -, 0 if +

This is fairly arbitrary, as far as I can see, but perhaps Walter has 
some intent behind this. Consider that a disclaimer. It would seem far 
more reasonable to me that .sign returns the signed unit of a number:

-1 or -1.0 and +1 or +1.0

In addition, while a 0 *may* be considered signed positively or 
negatively, even though the sign for the number 0 is meaningless 
(afaik). In that case I'd think it best that .sign was 0 or 0.0.

I wrote a function for the example source I posted, I'll paste it here 
for those who dislike verbosity:

int getSign(int number)
{
	if (number < 0)
	{
		return -1;
	}
	else if (number == 0)
	{
		return 0;
	}
	else if (number > 0)
	{
		return 1;
	}
}

Doing it this way has to advantage of .sign being useful in arithmetic, 
letting you for example do aNumber * aNumber.sign to get the absolute 
value of a number, or aNumber * -aNumber.sign to get the negative of the 
absolute value of a number.

Cheers,
Sigbjørn Lund Olsen
Jun 20 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sigbjørn Lund Olsen wrote:

 The docs cover these with the first for integral types and the second
 for floating point types:
 
 .sign         should we do this?
 
 and
 
 .sign         1 if -, 0 if +
 
 This is fairly arbitrary, as far as I can see, but perhaps Walter has
 some intent behind this.
I would assume that for floats, .sign is meant as part of the decomposition SIGN/MANTISSA/EXPONENT of IEEE floating point numbers. It is not meant as the mathematical signum function (usually abbreviated "sgn"). This would also explain why it might be questionable to have .sign for integers. On the other hand, signed integers also have a clear "sign" bit, so why not decompose them too?
Jun 20 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
I see what you're saying, but normal practice when dealing with sign in
computer arithmetic is to regard it as '1' for negative values and '0' for 0
and positive values. To break with this would be surprising.

"Sigbjørn Lund Olsen" <sigbjorn lundolsen.net> wrote in message
news:cb4kil$11tf$1 digitaldaemon.com...
 Pardon the pun. When doing the example to follow up the suggestion
 Walter gave me in response my latest lament about the D language, the
 lack of a separate unsigned keyword, I ran into a bit of a problem -
 namely the .sign property of integral and real number primitive types.

 The docs cover these with the first for integral types and the second
 for floating point types:

 .sign should we do this?

 and

 .sign 1 if -, 0 if +

 This is fairly arbitrary, as far as I can see, but perhaps Walter has
 some intent behind this. Consider that a disclaimer. It would seem far
 more reasonable to me that .sign returns the signed unit of a number:

 -1 or -1.0 and +1 or +1.0

 In addition, while a 0 *may* be considered signed positively or
 negatively, even though the sign for the number 0 is meaningless
 (afaik). In that case I'd think it best that .sign was 0 or 0.0.

 I wrote a function for the example source I posted, I'll paste it here
 for those who dislike verbosity:

 int getSign(int number)
 {
 if (number < 0)
 {
 return -1;
 }
 else if (number == 0)
 {
 return 0;
 }
 else if (number > 0)
 {
 return 1;
 }
 }

 Doing it this way has to advantage of .sign being useful in arithmetic,
 letting you for example do aNumber * aNumber.sign to get the absolute
 value of a number, or aNumber * -aNumber.sign to get the negative of the
 absolute value of a number.

 Cheers,
 Sigbjørn Lund Olsen
Jun 20 2004