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

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?

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