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

251–260 of 593 posts

Re: 1/0 = 0

#251

Post by rubatuga »

abakker wrote: post #222

I am not really a programmer or mathematician, so take this for what it is, but to me, the statement makes linguistic sense, if you read it out like a first grader. If I divide one thing into zero groups, how many items do I have in each group? Zero. Edited per comment below. If I were really pedantic, I'd say that in the above, it's almost like the input "1" is not being divided, but grouped. The funny thing then, i…

I think you mean if I divide one thing into zero groups, how many items do I have in each group

Re: 1/0 = 0

#252

Post by nostrademons »

simias wrote: post #183
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

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…

Real example: I'm collecting some quality signals from a corpus, most of which are some form of ratio, average, weighted average, or scaled average of counting various quantities within the documents. If the elements being counted are missing, I want the term involving that quality signal to disappear from the final ranking calculation.

Defining x / 0 = 0 gets this behavior for free, while leaving zero as an exception means it has to be caught for every single signal calculation, which is a pain when there are potentially dozens of different signals, all of which are counting different things (and have different divisors). I've actually defined a helper function to do this automatically, which also lets me change the default "null object" easily if I choose a different representation or want to apply some baseline value.

Re: 1/0 = 0

#253

Post by octalmage »

huehehue wrote: post #236
simias wrote: post #183

Earlier quoted context omitted.

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…

Practically, it's quite common to not immediately know the divisor. In cases where the divisor is initially unknown but takes an imperceptible amount of time to compute it's better to render 0%. Otherwise you might get a flash of a full progress bar (for example) while the divisor is determined. Of course, it's context dependent. As others mention, your code might be full of stuff like X / (divisor || 1) .

I’ve run into this a bit with progress related stuff. I bet if you looked at progress bar libraries they’d have similar logic built in.

Re: 1/0 = 0

#254

Post by Jach »

eggnet wrote: post #243
jwilk wrote: post #208

Earlier quoted context omitted.

To clarify, in Javascript 1/0 is Infinity, not NaN.

You are correct. But it really should be NaN, since 1/ε is positive infinity, whereas 1/-ε is negative infinity. Oh well :)

JS just assumes the limit direction for you, so 1/0 is Infinity, but -1/0 is -Infinity. 0/0 at least is correctly NaN. (Edit: And I just verified against my memory, Matlab (or at least Octave) does the same thing. While Matlab might get characterized as being for the ivory tower, at least it's had a long history of being used for practical math applications within the tower. Edit2: And anyway this is the defined behavior for IEEE floats. Men of industry use industrial standards. :))

Re: 1/0 = 0

#255

Post by skybrian »

throwawaymath wrote: post #242

"Mathematics does not give us truths, it gives us consequences." I'd like to point out that, as I stated in another comment in this thread, the author's supposed refutation of the inconsistency inherent in division by zero within fields is incorrect. Their refutation is as follows: The problem is in step (3): our division theorem is only valid for c ≠ 0, so you can’t go from 1/0 0 to 1 * 0/0. The “denominator is nonz…

It seems like he covered that in the article. There is no multiplicative inverse of zero.

But that isn't the same as defining a division operation.

Re: 1/0 = 0

#256

Post by ChrisRackauckas »

spooneybarger wrote: post #196
skybrian wrote: post #181

Earlier quoted context omitted.

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

I can't really comment. I don't know how they are doing it and why they made that choice. I assume that Julia was already boxing integers in some fashion at which point this 100% makes sense to me. Also, given the performance profile that you are seeking to allow programmers to achieve, I think boxing all integers makes sense, then you can give folks protection from integer overflow and underflow and otherwise make h…

Julia doesn't box integers, that would destroy speed. It also doesn't protect from overflow/underflow. It specializes on Vector{Int} so that's it's just a standard vector of integers. Then Vector{Union{Int,Missing}} is stored in memory as a vector of integers with a bitarray declaring missings. Indexing operations are expanded to ifelse a check for the existence and then return the value if it exists or a missing. Then branches are added by the compiler to handle the small unions. This keeps pure integer use without overhead, and gives a small penalty when using missing (which doesn't turn out to be all that bad due to how pipelining is usually done), but it's safe and any type can have missing values.

Re: 1/0 = 0

#257

Post by spooneybarger »

simonbyrne wrote: post #244
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…

What about I64.min_value() / (-1)? Why does that give 0? If you're doing wrap-around arithmetic it should give I64.min_value(). https://tio.run/##K8jPq/z/PzG5JL9IwTcxM49LAQjyUssVkotSE0tSNV...

That might be an LLVM bug.

`I64.max_value() + 1` gives the expected result.

I'm going to have to look into that.

Thanks.

Re: 1/0 = 0

#260

Post by ghayes »

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.

Couldn’t you alternatively introduce total operators that just grow the memory size as necessary instead of overflowing? For me if you’re handling wrapped types, I’d always prefer the numbers to grow into extra memory instead of overflowing or raising exceptions. Erlang, for instance, does this well. Obviously, division may still not be total, though you could define an operator like `//` that is.
Post reply on HN