Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1/0 = 0

hillelwayne.com

Post reply on HN
Print view View original

181–190 of 593 posts

Re: 1/0 = 0

#181

Post by skybrian »

spooneybarger wrote: post #152
c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

Hi, I'm on the Pony core team and I generally agree with you. The problem is, if you want to allow people to write high performance code, you are penalizing them becaues, for floating point: 1.0/0.0 is infinity. That's not C# being clever. That's C# following the floating point standard and using the math that the computer provides. To not use that standard means that you make every use of division slower, even if th…

I'm curious, what do you think about Julia's approach with its special "missing" value? Does this approach make sense outside the context of data analysis?

https://julialang.org/blog/2018/06/missing

Re: 1/0 = 0

#182

Post by tigershark »

MereInterest wrote: post #113
wodenokoto wrote: post #101

Earlier quoted context omitted.

I always thought division by zero was, at best, + and - infinity, depending on the path, which is why we leave it undefined. How would a path lead to 17?

Take the limit as x goes to 0 of (17*x)/(x). Both numerator and denominator go to 0, so this is a representation of 0/0. The limit is then equal to 17.

This just means that 0/0 = 1. It doesn’t mean that any number / 0 tends to 17.

Re: 1/0 = 0

#183

Post by simias »

bunderbunder wrote: post #94
whack wrote: post #72

My problem with "1/0 = 0" is that it's essentially masking what's almost always a bug in your program. If you have a program that's performing divide-by-zeroes, that's almost surely something you did not intend for. It's a corner case that you failed to anticipate and plan for. And because you didn't plan for it, whatever result you get for 1/0 is almost surely a result that you wouldn't want to have returned to the…

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

I'm reading the "Pony" tweet quoted in TFA and your comment and I'm left very puzzled: is that really that common to want x / 0 == 0 ? In practice where does that crop up?

You say that you frequently have to write your little shim but honestly I don't remember writing code like that in recent memory.

You talk about progress bars, I suppose it makes sense if you somehow try to copy 0 elements for instance, and you end up dividing by zero when computing the progress, like:

    pos_percent = (copied_elems * 100) / total_elems
And both copied_elems and total_elems are zero. But in this case wouldn't you want the computation to return 100% instead of zero?

It's also a bit odd because it introduces a discontinuity: as the divisor goes towards zero the result of the operation gets greater until it reaches exactly zero and it yields 0. Wouldn't it make more sense to return INT_MAX (for integers) or +inf for floats? If you're writing a game for instance it might work better.

I guess it just goes to show that it probably makes a lot of sense to leave it undefined and let people write their own wrapper if necessary to do what works best for them in their given scenario.

Re: 1/0 = 0

#184

Post by wan23 »

ggggtez wrote: post #139
emileokada wrote: post #119

Earlier quoted context omitted.

This is not true if you say division by 0 is undefined or +inf either. It really is totally fine.

No, you are assuming that 1/0= "undefined" where "undefined" is a magical value. It's not. It literally means 'That operation has no definition, and there is no reasonable result to return'. Many languages handle this in a practical way by creating a special value "undefined", "NaN", or others that has special properties. But let's be clear that "0" is a normal number in the real number space, as so expectations abou…

When there is no reasonable result to return does it really matter what result is returned? 1 / 0 == 0 is about the same as 1 / 0 == 3. To avoid this just don't do 1 / 0 in your program.

Re: 1/0 = 0

#185

Post by mlthoughts2018 »

drb91 wrote: post #129
avip wrote: post #122

Earlier quoted context omitted.

It’s common for 1/0 = 0 to be exactly what you want. Array average for example. That said raising exception would be the only consistent behavior if a language supports that.

Common compared to what? Taking an average of an empty array is nonsensical.

I disagree. It’s similar to computing NaN-mean or NaN-sum for an array of all NaN values (which returns 0).

Let’s say some program calculates the mean of an array and then adds that mean to some accumulator.

For purposes of updating the accumulator, the mean of an empty array is perfectly well-defined: it should add nothing to the accumulator (add 0).

This might be a major operating requirement for the mean function, such that rather than guarding or pattern-matching on an empty array and handling a failure is far worse than having a better 0-length convention.

Consider the difference between the “head” function of some List type, which has to either raise an exception or wrap the return value in some Maybe structure, because it’s literally not definable, vs the “length” function which has an obvious natural definition for empty arrays that is often highly preferred to some design where length(empty_list) throws an exception and everyone has to handle it in little bits of custom code to specify 0.

To me this topic is all about usability and not about some parochial claim that some operation is nonsensical.

Re: 1/0 = 0

#186

Post by alkonaut »

Any division either works and returns a result, or doesn't work and doesn't return a result. This is similar to any other function that maybe returns a result (returns an Option/Maybe or even Result).

Perhaps it's not a good design to have division as an operator a programming language? Just like

Maybe i = ParseInt("foo")

one should also do this for division:

Maybe q = Div(n, d)

Is there any language that does this (returns an option for default division?)

Obviously, this is also the case for ALL other operations on finite number types because of overflow. But overflow is MUCH rarer than division by zero issues, at least in my experience.

Re: 1/0 = 0

#187

Post by tikhonj »

c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

This kind of type becomes really tedious to use unless there is some sort of viable "subtyping"—you certainly want to be able to use a non-zero number where any number works and, ideally, you want to be able to recover a non-zero number when you write a function that takes in a normal number and always returns a positive value. If you're forced to use a bunch of explicit conversion functions to achieve this you add a lot of noise to your code and, generally, the most common function is going to be along the lines of "I know this is positive, so throw an error if it's 0"—which is exactly what we get anyway.

Explicit might be better than implicit most of the times, but it is possible to be too explicit.

That said, we can achieve this, although it's probably a bit trickier than you'd think at first. The best option I know is called "refinement typing", which basically allows you to specify types as subsets (ie "the set of integers which are not 0") and automatically verifies whether your functions actually return a value in the subset.

Liquid Haskell[1] is an example of a system you can use today to play with the idea. It uses an automatic logic solver (Z3) under the hood to automatically prove that your refinements hold. (For example, I believe it should be able to automatically verify that the function f x = abs x + 1 will never be 0.)

[1]: https://ucsd-progsys.github.io/liquidhaskell-blog/

Re: 1/0 = 0

#188

Post by DoctorOetker »

phyzome wrote: post #118
wodenokoto wrote: post #101

Earlier quoted context omitted.

I always thought division by zero was, at best, + and - infinity, depending on the path, which is why we leave it undefined. How would a path lead to 17?

x=170, y=10 x=17, y=1 x=1.7, y=0.1 x=0.17, y=0.01 The answer keeps being 17, even as x and y both get vanishingly close to zero. I encourage you to play around with a 3D graphing calculator and see all the different paths you can take along that surface to reach the singularity. They all "reach" it at different heights.

you are explaining why 0 / 0 can approach 17, this is much less controversial, and is often considered the bottom element...

Re: 1/0 = 0

#189

Post by School-Cotton »

leereeves wrote: post #12
luso_brazilian wrote: post #7

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks It actually does break something, the symmetry between division and multiplication and the many pieces of code that assume that (x / y) * y equals x. Here is a naive and non practical example, but it is not impossible to find a real world example where this simplified code manifests itself accidentally or by de…

> (x / y) * y equals x Even without Pony's assumption, that's only true when y != 0.

Yeah, (x/y)*y = x is true whenever it's a meaningful statement. x/y has no meaning in standard mathematics when y=0. 1/0 isn't infinity or anything else in standard math, it's literally un-grammatical nonsense.

Re: 1/0 = 0

#190

Post by EugeneOZ »

nepeckman wrote: post #50
EugeneOZ wrote: post #8

Oh, so 0*0=1 ?

> So it is _not_ a theorem that a * (b / 0) = b * (a / 0) As the article explains, the whole issue about dividing by 0 is the lack of multiplicative inverse. If you define division for 0 as something other than multiplication by the multiplicative inverse, there is no longer an issue doing the division. Hope that helps.

Then it will be not math.
Post reply on HN