I don’t remember if it is on by default or not, but there’s some mxcsr flag to make division by zero return an INF, I’m pretty sure.
Division by zero returning a zero is a pretty bad and confusing result mathematically.
Division by zero returning a zero is a pretty bad and confusing result mathematically.
How about 5 - 8 = 0? Sensible result for the natural numbers.
X + 7? Surely you meant addition modulo 2^64.
What's the count leading zeros on zero? Is it zero, 64, random noise found in a register?
What's X shifted by word size? Zero? Minus one? X?
These are all choices. Some are familiar. But knowing integer divide zero is wrong is a tenant of faith.
It isn't nonsense. 7/2 represents a real number. You can round a real number up or down. So you can round 3.5 to 3. 7/0 doesn't represent a real number. It doesn't even make sense to do anything to an undefined number.
All rational numbers are real numbers.
> Why not a complex number?
What?
> That you especially like the real numbers is particularly unfortunate
It's not a matter of me liking or disliking real numbers. It's just that the topic at hand is about real numbers.
> when they are so poorly represented in essentially all programming languages.
Not essentially all programming languages. In every single one. It's the nature of real numbers. It's also not just 'programming languages', it's hardware as well.
Indeed, which is why decent languages don't do that. Different symbol like // for truncating division if that's what you want.
> How about 5 - 8 = 0? Sensible result for the natural numbers.
Nah. Similarly, don't call that operation -; - underflowing should be an error.
> X + 7? Surely you meant addition modulo 2^64.
Surely you didn't. If your language does that, get a better language.
> What's the count leading zeros on zero?
What's the "count leading zeros" on anything? Numbers don't have leading zeroes (or rather, a number with leading zeroes is equivalent to one without them).
> What's X shifted by word size? Zero? Minus one? X?
No, it's X shifted by word size. (Which is a value bigger than a word, sure).
If you want weird bit-twiddly operations because they're what your hardware implements efficiently, by all means have them. But don't use the standard mathematical symbols for operations that don't have the standard mathematical behaviour. And that includes a "divide" operation that silently accepts 0 and returns some normal value.
Making sure you don't divide by zero is just one of those things programmers learn... like making sure you don't derefence null or go beyond the size of your array, or overflowing... not clear to me that masking that helps, maybe the ship wouldn't strand but instead it'd run into a bridge.
Disagree. The whole point of calling it '/' is to tell the reader that it is mathematical division.
> Making sure you don't divide by zero is just one of those things programmers learn... like making sure you don't derefence null or go beyond the size of your array, or overflowing... not clear to me that masking that helps, maybe the ship wouldn't strand but instead it'd run into a bridge.
In all of those cases it's much better for your program to explode quickly and loudly than silently continue (e.g. you'd hope dereferencing null triggered an error rather than just letting your program continue). Defining x/0 = 0 is masking the error and continuing, which tends to lead to corrupt data and silent wrong results.
Well, we call a different operation "+", and there's a decent chance that either wraps a uint_max, or triggers arbitrary undefined behaviour when it goes past a limit, or that it maps to a floating point operation where x + 1 == x for large x. That's not especially like "mathematical addition", whatever you have in mind for that definition.
I'm saying we shouldn't, and good languages won't. Using + for modulo addition is maybe acceptable, that's a reasonably standard usage in mathematics and has most of the behaviour you'd expect from addition, but using + to denote something that has undefined behaviour or suddenly shifts to floating point is certainly wrong.