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

151–160 of 593 posts

Re: 1/0 = 0

#151

Post by recursive »

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…

So what type is `integer - integer`? It might be zero, but the type system doesn't statically know whether it is or not. If the result of every arithmetic expression is possibly zero, then you're back to run-time checks for every value. I don't see how this is practically useful.

Re: 1/0 = 0

#152

Post by spooneybarger »

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 the programmer has in some way assert and otherwise knows that that they won't be dividing by zero.

Note that 1/0 is integer math and for that there is no standard and its undefined behavior. You can't return NaN or Infinity for that without boxing numbers which is a performance hit and would be penalizing programmers who want/need to go as fast as possible.

Re: 1/0 = 0

#153

Post by banachtarski »

legohead wrote: post #146
phyzome wrote: post #60

Some people say "oh, that's easy, 1/0 is +Infinity". So the real fun is at 0/0. The limit of x/y as x and y go to zero depends on which path across the xy plane you take towards the singularity. Along one approach, the limit is 0, along another approach the limit diverges to infinity, along yet another the limit is 17. I'm not kidding! Go to https://www.geogebra.org/3d and enter "x/y" and spin the graph around. The "…

I would argue 1/0 is infinity. Not with mathematics, just logically. By using the wording "how many times does 0 go into 1?" You bring up 0/0. But 0/ is already defined, it's 0. So 0/infinity = 0 Programmatically, I think I've always wanted X/0 to be 0. For example: progress bars, currency, or damage in a video game. It wouldn't be very helpful to have infinity be an answer there.

Your argument is flawed because your zero is positively biased.

Why infinity and why not negative infinity.

Re: 1/0 = 0

#154

Post by genezeta »

cryptonector wrote: post #108
banachtarski wrote: post #32

This article grinds my gears. He quotes a number of mathematicians that correctly state the undefined nature of 1/0. Then proceeds to interpret that this means that we can choose any specific value to represent as 1/0 that we want. NO. We have "NaN" for a reason and it is an important signal to the programmer that a mistake was made. The language that assigns it to 0 silently is bunk as is this article.

Are we reading the same FA? In the section titled "The Real Mathematicians" the author has quotes of mathematicians saying that defining division by zero as zero is OK.

Not all of them, though.

I find particularly interesting Leslie Lamport's comment that "Since 0 is not in the domain of recip, we know nothing about the value of 1 / 0", which I think is the most correct mathematical stance.

Then again, I think it is all a red herring. This (Pony's decision) is not about the mathematical definition of division. This is about the trade-offs computational systems do to manage the situation.

Re: 1/0 = 0

#155

Post by ajanuary »

ggggtez wrote: post #57

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks a=x/N b=y/N If a==b, then x==y No longer true, with this change. Essentially a variety of mathematical properties of numbers in the Real space don't hold when you allow division by 0.

“Nothing breaks” in that it isn’t unsound, in that you can’t use it to prove a falsehood. Not that you can’t use the nice little shortcuts you’re used to.

In practical terms, that _does_ have an impact, because people might use those shortcuts without realising the system they’re operating under doesn’t allow it.

But you picked the wrong quote to make that point under.

Re: 1/0 = 0

#156

Post by thanatos_dem »

spooneybarger wrote: post #103

Hi, I'm on the Pony core team. I will be writing in more detail about this decision. A few short notes until then: 1) no one on the team has ever been happy with ending up here, understanding why the decision was made involved understand how partial functions (one that can produce errors like division by zero) are handled in Pony and interesting ergonomic issues that can result that is a large part of what my post wi…

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value.

Oh jeeze... to me that almost nullifies all of the points in the article. It does an alright job explaining how 1/0 = 0 is at least consistent with other notions in the language, but to hear that the same logic can’t be applied to floats is just... well, objectively it’s a mess.

Re: 1/0 = 0

#157

Post by gopalv »

spooneybarger wrote: post #131
bunderbunder wrote: post #94

Earlier quoted context omitted.

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

We will be introducing two sets of integer math operators in Pony. The current which are non-partial and can over/underflow + division by zero == 0 AND new ones that will be partial functions that cause an error on under/overflow and division by zero.

> new ones that will be partial functions that cause an error on under/overflow and division by zero.

A "strict" mode is usually always an afterthought once we have errors & people run it in strict mode and facepalm.

One of the first "utilities" I wrote for PHP was something called "pecl/scream", which turned off all the "unchecked" operations across the whole VM.

And in general, this works out poorly for code quality.

Re: 1/0 = 0

#159

Post by kazinator »

avip wrote: post #122
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…

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.

It is not valid to extrapolate an average of 0 from no data at all.

For example, if we examine a sample of zero elephants, then we end up estimating the average elephantine mass as being zero.

This shows to be wildly off as soon as we upgrade our statistical wherewithal to work with a sample size of one.

A center of mass is a kind of average. If we have an empty object made of no particles of matter at all, can we arbitrarily pin its center of mass to the (0, 0, 0) origin of the coordinate system we are using?

Re: 1/0 = 0

#160

Post by SamReidHughes »

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…

Error handling your infinite results would dramatically slow down your programs. And C# doesn't think it's being clever, it's following IEEE float behavior implemented in the hardware.
Post reply on HN