On Tue, 16 Feb 2010 13:38:06 -0500, Walter Bright
<newshou...@digitalmars.com> wrote:
Steven Schveighoffer wrote:
What I meant by that statement is that the behavior goes against common
sense -- when it doesn't have to. It only makes sense to advanced
programmers who understand the inner workings of the CPU and even in
those cases, advance programmers easily make mistakes.
Where you and I disagree is I don't feel that 2s-complement arithmetic
is in any way an advanced programming topic. Nor is it an inner working
of a CPU - it's an exteriorly visible behavior, well documented in the
CPU manuals. (Inner behavior would be things like the microcode.) As I
mentioned before, how that works was often the very first topic in an
introductory book on programming.
I agree that 2's complement as a whole is not an advanced topic. What I
disagree with is the interpretation the result of this one operation. To
interpret it as an unsigned value is lunacy. The result should be
interpreted as a negative value and not assignable to an unsigned value.
There are much more sane and unambiguous alternatives to doing this. Even
advanced programmers expect when they negate something it most likely
becomes negative. It's a surprise when it *always* flips back to positive.
No comprehension of the fundamentals computer arithmetic will lead to
failure after failure as a programmer; no language can paper that over.
There is no escaping it or pretending it isn't there.
You assume that to understand 2s complement is to understand *and*
mentally parse why negating a positive value in a computer for unsigned
types *always* results in a positive value. I think you can understand 2s
complement arithmetic and the limitations, and *still* make the mistake of
assigning the result of negating an unsigned value to an unsigned value.
There have been already very smart, computer literate, 2s complement
knowledgeable people who have said on this very newsgroup they have been
bitten by this error. This is not a fix to help just newbies.
When the result of an operation is 99.999% of the time an error (in
fact the exact percentage is (T.max-1)/T.max * 100), disallowing it is
worth making the rare valid uses of it illegal.
It conforms to the simple rules of 2s-complement arithmetic, so I
disagree with calling it an error.
We're not working in Assembly here. This is a high level language,
designed to hide the complexities of the underlying processor. The
processor has no idea whether the data in its registers is signed or
unsigned. The high level language does. Please use that knowledge to
prevent stupid mistakes, or is that not one of the goals of the compiler?
I can't believe this is such a hard point to get across.
It's not like I'm proposing to change everything about 2s complement math
*except* in this one small situation: Negation on an unsigned value *and*
(this part is the most important) assigning it to (or passing it as) an
unsigned value. Any time you see that, it is an error or a misguided
attempt to be clever.
The case I'm talking about is the equivalent to doing:
x = x / 0;
Even mathematicians don't know what to do about divide by zero. But 2's
complement arithmetic is well defined. So the situations are not
comparable.
Sure they do, the result is infinity. It's well defined. In fact, I
think some math-based programming languages allow divide by zero.
Again, not arguing against 2s complement here, just the one particular
situation which is always an error.
-Steve
