3 ms·

This thread is showing once again that reading comprehension is not our strong-suit here on HN. The author does not once say that Pony's choice is a good one,

This thread is showing once again that reading comprehension is not our strong-suit here on HN. The author does not once say that Pony's choice is a good one, only that whether it is a good or bad one should be settled by engineering consequences, and that there is no purely mathematical argument that precludes it. I can't help but think it _is_ a bad idea, because it's easier to overlook a 0 appearing than a NaN. That argument isn't math, though.

rcoveson 8y ago
The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats). Most integer representations have no space for such a value, so the only choices available to language developers are: 1. Throw an exception or otherwise consider it an error 2. Define the result to be 0 or 1 or some other integer value (0 being the only good choice) 3. Use a non-standard integer representation Most languages opt for option 1, Pony chose 2, and I've never seen 3, perhaps due to it requiring so much software interference and precluding inter-operation with other languages.
- spooneybarger 8y ago
  It sounds like from what I have learned elsewhere on here that Julia is doing something interesting here. https://news.ycombinator.com/item?id=17737308 https://news.ycombinator.com/item?id=17737308 https://news.ycombinator.com/item?id=17737158 https://news.ycombinator.com/item?id=17737158
- mcguire 8y ago
  Pony requires special handling of partial functions. Option 1 means all integer divisions by other than constants would be partial. That seems sub-optimal.
- otabdeveloper2 8y ago
  > 0 being the only good choice Devil's advocate: why not a maximum integer like 18446744073709551615 or 9223372036854775807? 0 looks like a valid number, while 18446744073709551615 is an obvious NaN for any programmer looking at the output.
  - spooneybarger 8y ago
    Pony core team member here. In some domains it might be. In others it might not. It's no more right or wrong in my mind. I think the size of the integer needs to be considered in your thinking as well: If you have unsigned 8 bit integers, the max value is 255, is that really going seem NaN? How about 127 for a signed 8 bit integer? And, should the result of division by zero vary based on the bit size of the integer? That's a discussion unto itself.

rcoveson 8y ago

The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats). Most integer representations have no space for such a value, so the only choices available to language developers are: 1. Throw an exception or otherwise consider it an error 2. Define the result to be 0 or 1 or some other integer value (0 being the only good choice) 3. Use a non-standard integer representation Most languages opt for option 1, Pony chose 2, and I've never seen 3, perhaps due to it requiring so much software interference and precluding inter-operation with other languages.

spooneybarger 8y ago
It sounds like from what I have learned elsewhere on here that Julia is doing something interesting here. https://news.ycombinator.com/item?id=17737308 https://news.ycombinator.com/item?id=17737308 https://news.ycombinator.com/item?id=17737158 https://news.ycombinator.com/item?id=17737158
mcguire 8y ago
Pony requires special handling of partial functions. Option 1 means all integer divisions by other than constants would be partial. That seems sub-optimal.
otabdeveloper2 8y ago
> 0 being the only good choice Devil's advocate: why not a maximum integer like 18446744073709551615 or 9223372036854775807? 0 looks like a valid number, while 18446744073709551615 is an obvious NaN for any programmer looking at the output.
- spooneybarger 8y ago
  Pony core team member here. In some domains it might be. In others it might not. It's no more right or wrong in my mind. I think the size of the integer needs to be considered in your thinking as well: If you have unsigned 8 bit integers, the max value is 255, is that really going seem NaN? How about 127 for a signed 8 bit integer? And, should the result of division by zero vary based on the bit size of the integer? That's a discussion unto itself.