1 ÷ 0 === 0. No, seriously...


  • Discourse touched me in a no-no place

    None of your new-fangled maths logic here!

    ".. what do you mean straw-men? No!! I don't have a wheat-field full of them...."

    Next we need to explain what we mean by “division”. But to do that, I need to introduce fields.
    [...]
    A field is a set of elements (S) along with an addition operator (+) and a multiplication operator (*) that follow some properties:
    <snip>
    The field definition does not include division, nor do our definitions of addition or multiplication. This means we are free to define division however we want. We want to define it in a way that mostly follows our intuition and is sound. [bold, mine; italics, his]


  • Java Dev

    @PJH

    In proper maths, subtraction is defined based on addition (x=a-b is defined such that x+b=a) and division is based on multiplication (x=a/b is defined such that x*b=a).



  • Divide by zero in Pony
    In Pony, integer division by zero results in zero. That's right, let x = I64(1) / I64(0) results in 0 being assigned to x. Baffling right? Well, yes and no. From a mathematical standpoint, it is very much baffling. From a practical standpoint, it is very much not.
    Similarly, floating point division by zero results in inf or -inf , depending on the sign of the numerator.

    Partial functions and math in Pony
    As you might remember from the exceptions portion of this tutorial, Pony handles extraordinary circumstances via the error keyword and partial functions. In an ideal world, you might imagine that a Pony divide method for U64 might look like:
    fun divide(n: U64, d: U64) ? =>
    if d == 0 then error end
    n / d
    We indicate that our function is partial via the ? because we can't compute a result for all inputs. In this case, having 0 as a denominator. In fact, originally, this is how division worked in Pony. And then practicality intervened.

    Death by a thousand trys
    From a practical perspective, having division as a partial function is awful. You end up with code littered with try s attempting to deal with the possibility of division by zero. Even if you had asserted that your denominator was not zero, you'd still need to protect against divide by zero because, at this time, the compiler can't detect that value dependent typing. So, as of right now (ponyc v0.2), divide by zero in Pony does not result in error but rather 0.

    So, all that "but fields!" talk is irrelevant: integer division by zero returns an integer because the language painted itself into a corner with its design choices.

    For the curious, the docs are here:

    The intro is... let's say, "interesting".


  • Discourse touched me in a no-no place

    @Zerosquare said in 1 ÷ 0 === 0. No, seriously...:

    The intro is... let's say, "interesting".

    :mlp_fear:


  • BINNED

    Yeah, great. It's "sound", in that you can define whatever you want if you don't introduce contradictions. But it's not useful, because now division is not the inverse of multiplication

    this does not give us an inverse of 0. 1/0 is not 0⁻.

    Pretty much everything assumes this is true, and now you're breaking things indirectly.

    It's only useful if you think that integer division by zero should fail silently, just like float division does (for the usual fp exception settings).



  • @Zerosquare At least they could have used a different return value, like INT_MAX, which would make bugs much clearer.



  • It’s pretty smug. I have very strong opinions about programming, but one rule I try to follow is do not mock other programmers.1 Programming is too big and I’m too small to understand everything. Disagreeing is fine, laying out why people are wrong is fine, making fun of them is not fine.

    Now I want to watch some flame wars between this person and @apapadimoulis



  • @sockpuppet7 : we should introduce him to Discourse, and see if he still thinks that way afterwards.


  • Considered Harmful

    @Zerosquare said in 1 ÷ 0 === 0. No, seriously...:

    @sockpuppet7 : we should introduce him to Discourse, and see if he still thinks that way afterwards.

    What's wrong with Discourse?


  • Discourse touched me in a no-no place

    @pie_flavor said in 1 ÷ 0 === 0. No, seriously...:

    @Zerosquare said in 1 ÷ 0 === 0. No, seriously...:

    @sockpuppet7 : we should introduce him to Discourse, and see if he still thinks that way afterwards.

    What's wrong with Discourse?

    Wrong thread.</blakey>


  • Resident Tankie ☭

    Yeah but... what's the actual utility of 1 ÷ 0 === 0? So that programmes do not crash when they encounter division by zero? But that's easily dealt in much saner ways. Apart from the fact that you should never have division by zero in the first place anyway.


  • Discourse touched me in a no-no place

    @admiral_p said in 1 ÷ 0 === 0. No, seriously...:

    Apart from the fact that you should never have division by zero in the first place anyway.

    Why not?

    Ignore the fact that, in the Real World™, the result of 1/0 is undefined - we're not in Kansas at the moment.

    Pretend it is actually 0, as the author of the linked blog post in the OP wants it to be.

    Why should you never have division by 0?


  • Resident Tankie ☭

    @PJH it has no mathematical or logical meaning. Especially if we force the result to be 0 (therefore, indistinguishable from actual 0s). Where can division by zero be actually useful?


  • Discourse touched me in a no-no place

    @admiral_p said in 1 ÷ 0 === 0. No, seriously...:

    Where can division by zero be actually useful?

    Now you're :moving_goal_post:, by introducing the concept of 'usefulness.' You'll be insisting on 'right' or 'correct' next...

    Anyway, since you ask (:rofl: ):

    https://news.ycombinator.com/item?id=17736728

    I almost want two different division operations: One where 1/0 = 0, exclusively for use in progress bars and stuff like that, and another one for everything else.

    Because frequently division by zero indicates a bug. But similarly frequently, I end up crapping out annoying little bits of code like

    if (foo == 0):
      return 0
    else:
      return bar / foo
    

    https://news.ycombinator.com/item?id=17738645

    An example well-defined use case is if you want to compute a harmonic mean, e.g.

    x = 2/(1/a +1/b)

    This is a form of average where you are giving increased importance to the smaller number. It frequently pops up in science/engineering, e.g. in hydrology when you are computing flow of water underground.
    <snip>


  • Resident Tankie ☭

    @PJH said in 1 ÷ 0 === 0. No, seriously...:

    @admiral_p said in 1 ÷ 0 === 0. No, seriously...:

    Where can division by zero be actually useful?

    Now you're :moving_goal_post:, by introducing the concept of 'usefulness.' You'll be insisting on 'right' or 'correct' next...

    Anyway, since you ask (:rofl: ):

    https://news.ycombinator.com/item?id=17736728

    I almost want two different division operations: One where 1/0 = 0, exclusively for use in progress bars and stuff like that, and another one for everything else.

    Because frequently division by zero indicates a bug. But similarly frequently, I end up crapping out annoying little bits of code like

    if (foo == 0):
      return 0
    else:
      return bar / foo
    

    https://news.ycombinator.com/item?id=17738645

    An example well-defined use case is if you want to compute a harmonic mean, e.g.

    x = 2/(1/a +1/b)

    This is a form of average where you are giving increased importance to the smaller number. It frequently pops up in science/engineering, e.g. in hydrology when you are computing flow of water underground.
    <snip>

    Which you can deal with "ugly bits of code" that are not ugly. Seriously, what's the problem with a few lines of code now? Sheesh. It's even clearer. Mind you,, I'm in favour of verbosity, make everything explicit, you write it once but you read it many more times, etc. By the way, what if you want 1 ÷ 0 === 0 to have a result other than 0? You're back to doing it anyway.



  • @admiral_p should you crash the program or give a wrong result?

    That's the choice we had before try...catch was a thing. For modern languages IMO the only right choice is to throw an exception.



  • @sockpuppet7 said in 1 ÷ 0 === 0. No, seriously...:

    should you crash the program or give a wrong result?

    Doesn't the IEEE floating point standard have a flag for "result of divide by zero"? I thought it did.



  • @blakeyrat oh, you're using floats, that's different :- )



  • @sockpuppet7 Well dividing integers rarely makes sense anyway.



  • @blakeyrat Yes, but this guy is trying to use raw unsigned ints.

    IMO, this just goes to show that you can't avoid having to handle and represent special cases. That's why they added NaN and ∞ to floating point, and why most programming language pointers have NULL, etc.


  • Discourse touched me in a no-no place

    @blakeyrat said in 1 ÷ 0 === 0. No, seriously...:

    Doesn't the IEEE floating point standard have a flag for "result of divide by zero"? I thought it did.

    For floating point division, 0.0 / 0.0 is the real horror, the thing that causes trouble (and NaN, which is how this sort of thing is marked when floating point exceptions are disabled); fortunately our system of floating point numbers copes with infinities so we've not got that many horrid cases to worry about.

    For integer division 0 / 0, an exception or signal is about all you can do, or indeed for anything divided by 0; all more numerically-plausible answers can't be finite integers and nobody's got the memory to store actual infinite integers. “Exceptions can arise; live with it” is about the best that you can do.


Log in to reply