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

- =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> Jun 20 2004
- Norbert Nemec <Norbert.Nemec gmx.de> Jun 20 2004
- "Walter" <newshound digitalmars.com> Jun 20 2004

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

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

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