How to handle division by zero in a language that doesn't support exceptions? • Hacker News Board

Re: How to handle division by zero in a language that doesn't support exceptions?

#61

Post by Tloewald » Sun, Jul 13, 2014, 4:20 PM UTC

grkvlt wrote: post #59

klodolph wrote: post #35

Earlier quoted context omitted.

No, this is wrong. In order to work with infinitesimals in any reasonable way, you have to define how they work. There is a reasonable way to extend the real numbers in a larger field containing infinitesimals. Such a field is non-Archimedean and has very surprising properties: for example, you can construct a geometry in which Euclid's fifth postulate is false, and yet the angles on a triangle still always add up to…

But in an environment manipulating symbols where one of them 'x' has the property that multiplying by zero gives ten, I don't think the above sequence could happen, or at least the symbolic evaluator would arrange things so that the first time it sees '0 * x' it replaces that with 10. So to evaluate the truth of the expression '(a+b) * x = 10' with 'a' and 'b' equal to zero, we just need to ensure the 'a+b' is evalua…

Right, the same kind of arguments are the basis for calculus, and limit proofs work without being able to prove 1 = pi.

Re: How to handle division by zero in a language that doesn't support exceptions?

#62

Post by Someone » Sun, Jul 13, 2014, 4:55 PM UTC

keeperofdakeys wrote: post #45

Someone wrote: post #43

NaNs are an incredibly good idea, but it turns out we really need only one. Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN. 16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. Yo…

2's complement (the binary representation of numbers in a cpu) has one awesome feature, if you add two signed numbers, even if one or both are negative, you get the right answer. This means that you can add two numbers without checking if one is negative, saving time and scarce circuit space. In order to add a NaN, you'd need a check for NaN. This would basically double the amount of time an add would take, and add m…

"If we use a single bit dedicated to signalling NaN, the overhead might be worth it. Of course, we lose half of our range in doing so."

You don't need to lose half your range; you can also add a bit. You only need to add a sticky overflow bit to each register, keep the arithmetic hardware as-is, and modify loads to set the sticky overflow when reading the NaN pattern, and modify writes to write 0b1000...000 when writing a register whose sticky overflow bit is set.

Hardware cost would, I think, be very small, as you would only need a bit per register, and keep memory as-is.

Given that Apple has non-wrap around ints in Swift and designs its own CPUs, it wouldn't surprise me if they added something similar or their CPUs, just as I expect them to add instructions for loading from tagged pointers (https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-bui...)

Re: How to handle division by zero in a language that doesn't support exceptions?

#63

Post by derefr » Sun, Jul 13, 2014, 5:11 PM UTC

goblin89 wrote: post #42

anon4 wrote: post #24

I liked the ternary operator where you provide an alternate value in case the denumerator is 0. One more idea I didn't see is to mark the variable as "invalid". A general "this variable doesn't have a value because the program did something bad", which carries a full stack trace with itself. Then, if you ever use that value anywhere, the result is again invalid, with the new operation attempted on top (i.e. if the in…

> One more idea I didn't see is to mark the variable as "invalid". A general "this variable doesn't have a value because the program did something bad", which carries a full stack trace with itself. A simple way to handle exceptions like that (and I didn't see it mentioned among the answers) is to return 2-tuple from the function: result value and error information. The latter could be empty, but both could be presen…

Yep. You’d think that in, say, Haskell, the division operator would return Maybe Num. It’s much more obvious when you’ve got Nothing than when you’ve got NaN.

Re: How to handle division by zero in a language that doesn't support exceptions?

#64

Post by thegeomaster » Sun, Jul 13, 2014, 5:50 PM UTC

jl6 wrote: post #57

thegeomaster wrote: post #18

Earlier quoted context omitted.

Well, this was a server, and it was also multithreaded, so many synchronization bugs that didn't happen in debug builds did happen in release ones because of timing. Without assertions, though, none of these was caught on time, so I was left with mystical crashes, garbage data sent out to clients, etc etc. I spent hours and hours in valgrind and gdb, and only then realized that none of the assertions worked. When I r…

With total respect to what you're saying, I'd just like to say that I care about games and other non-mission-critical software. I am continually disappointed by buggy glitchy unreliable applications which have clearly been rushed out to meet a release window. It's as if we've all been trained to accept poor quality, based on the excuse that "it's not handling payments or running a nuclear reactor so it's OK to be slo…

I am sorry, but you have completely missed my point. All software has bugs, period. With games, you can omit assertions so that these bugs cause glitches in the game (or cause no visible change at all), or you can keep them in, slowing down the engine because of numerous runtime checks and crashing the whole game if a single bug occurs. That's way more sloppy design than the former.

Re: How to handle division by zero in a language that doesn't support exceptions?

#65

Post by jrockway » Mon, Jul 14, 2014, 12:48 AM UTC

Riesling wrote: post #47

jrockway wrote: post #30

result, err := x / y if err != nil { do something }

Since you are using go syntax... I don't think that this will work in go, because division by zero will cause the function to panic.

Actually, it doesn't even compile in go, because / doesn't return two arguments. But he's writing his own language, not using go, so this limitation need not apply.

Re: How to handle division by zero in a language that doesn't support exceptions?

#66

Post by klodolph » Tue, Jul 15, 2014, 4:31 AM UTC

grkvlt wrote: post #59

klodolph wrote: post #35

Earlier quoted context omitted.

No, this is wrong. In order to work with infinitesimals in any reasonable way, you have to define how they work. There is a reasonable way to extend the real numbers in a larger field containing infinitesimals. Such a field is non-Archimedean and has very surprising properties: for example, you can construct a geometry in which Euclid's fifth postulate is false, and yet the angles on a triangle still always add up to…

But in an environment manipulating symbols where one of them 'x' has the property that multiplying by zero gives ten, I don't think the above sequence could happen, or at least the symbolic evaluator would arrange things so that the first time it sees '0 * x' it replaces that with 10. So to evaluate the truth of the expression '(a+b) * x = 10' with 'a' and 'b' equal to zero, we just need to ensure the 'a+b' is evalua…

You're turning something which is merely wrong into a total nightmare. Suddenly, 0+0 is not 0, because you have to wait to see if you multiply it by x first before you can evaluate 0+0! Now there are multiple distinct values for 0! Chaos and disharmony abound! In your system, 0+0=0+0, and 1+1=1+1. You can't simplify any of your equations! In your system, 1+1=2 is FALSE!

No, seriously. Quit while you're ahead. Now that you know that dividing by zero and getting a result is not a logically consistent proposition, you can stop trying. That's the awesome thing about logic: once you PROVE something is impossible, you're done.