Hacker News Reader

Comment by masklinn | Hacker News Reader

FWIW there's an entire paper on the subject of these operations: https://core.ac.uk/download/pdf/187613369.pdf

(well a report in TOPLAS really, but that's pretty close)

There are technically 5 different versions of this operation, though only 2 (possibly 3) are in common use. Common Lisp seems to implement all of them except, somewhat oddly, the euclidean version (the "actual modulo"), its mod function is instead a flooring division.

edit: it looks like Python also follows flooring, not euclidean, meaning the quotient is rounded downwards, and per "a = nq + r" the remainder has the sign of the divisor:

    >>> 5 % -2
    -1
    >>> divmod(5, -2)
    (-3, -1)

The C version is the "truncating" division, meaning the quotient is truncated (rounded towards 0).

View on HN

Somewhere out there in the universe, there's an nightmare that starts with "Well, zero is kind of an unusual number, so for safety sake we've defined our division to always round away from zero. This resulted in an interesting mod operation..."

Ponylang.io - There is a similar operation (toward zero)

https://stdlib.ponylang.io/builtin-Integer/#div_unsafe

and, in Ponylang, i/0 usually results in 0.

I think this is a bit different. Pony's div is total, and in order to be total div by 0 is 0, which is not a particularly absurd idea.

That said, I do feel that Pony should have added a 'panic' concept and then forced actors to handle panics, but that's me.

> which is not a particularly absurd idea

It's not completely untenable, but it's still kinda janky. I've never heard of any mathematical argument that justifies division by zero yielding 0; contrast 0^0, which at least has an argument for yielding 1: http://mathscitech.org/articles/zero-to-zero-power

From programming perspective, there's nothing sufficiently preposterous in the idea of dividing by zero that would require bringing the whole world to a low-level halt just for attempting that by default. You tried to calculate the average value of what turned out to be an empty list? Go suffer the most severe exception, like the ones reserved for those reading from nonexistant memory.

Another common case is adjusting some value according to a spatial vector's magnitude, like normalizing a vector or scaling gravitational attraction according to the distance between two points.

In the majority of these cases the most reasonable answer is 0.

> I've never heard of any mathematical argument that justifies division by zero yielding 0

0/x = 0 for all x except zero; defining 0/0=0 removes that exception.

x/x = 1 for all x except 0; defining 0/0 = 1 removes that exception.

Split the difference, 0/0 = 0.5

It gets worse: differentiation would be 0/0 if you went straight to the limit rather than just approaching it, so 0/0 can be any differentiable function, not just a value.

(Caveat: I’m probably being slightly imprecise with my language here)

I think it's worth all getting on the same page on the fact that math is fake and stupid. If it's more useful for 0/0 to == 0, that's justification enough imo.

https://www.hillelwayne.com/post/divide-by-zero/

Maybe the best argument is that the average of zero items should be zero?

But then why should the average of zero items be zero? It still seems like just an arbitrary choice to me.

Toward zero is a fairly intuitive way to do it, I think. Intuitively, if a you were, say, discretizing a length (L) with a number of steps (n) of some size (d) and went for d=L/n, you might want to always end up with d*n <= L even if L is negative, right? Although, having an integer for d may not make sense, or you might want to take |L| beforehand anyway...

Good paper—it was the primary source we looked at when implementing these operations in Julia. Specifically, Julia implements all versions and overloads `div` and `rem` to take a rounding mode argument. It also gives special names to a few of them and they come in pairs: `div` & `rem`, `fld` & `mod` (`fld` stands for “floored divide” as opposed to `div` which rounds towards zero). The `%` operator does remainder like C, which was a tough call, but we figured being compatible with C was worthwhile for people porting code. It’s also less useful in Julia due to default 1-based indexing of arrays; for that there is a `mod1` function that returns a value between 1 and n.

> The `%` operator does remainder like C, which was a tough call, but we figured being compatible with C was worthwhile for people porting code. It’s also less useful in Julia due to default 1-based indexing of arrays; for that there is a `mod1` function that returns a value between 1 and n.

After thinking about this, what I really want is a way to access an array with an unadjusted number and tell the array to do whatever modulizing is necessary. e.g. instead of

    a[small]
    a[mod1(big)]

I'd like to have something more like

    a{small}
    a[big]

Hmm. This means we'd have to do mod every time we accessed an array which seems not great, right? But probably it could be optimized away for the common/easy cases.

In WUFFS if you've got a 40 item array of things, an unsigned 8-bit integer n and you want to access things[n] the compiler will conclude n's type must be base.u8[0..40]

Now, having refined the type this way, when you try elsewhere in the code to read some unknown byte into n, WUFFS will reject that because who knows if it exceeds 40? To make the code compile, you need to actually write code that ensures n is always less than 40.

Of course you aren't going to write big general purpose software under this sort of constraint, it's like having a two year old following you everywhere insisting on a detailed explanation of why you are doing every single thing and asking the most irritating "But why?" questions after each explanation, exhausting. But if you're processing untrusted data it's exactly what you needed to stay safe.

Julia already has bounds checking at runtime on array access, so you could do the mod operation only if the bounds check fails.

But I don't get how this would practically work. Would each array have a preferred n that is used for the mod operation? For most situations where that makes sense, using a 2d array seems more logical.

I assume n would be size(a)

Oh yeah - I got mixed up on this and thought we wanted to access sub arrays within a.

The parent comment has brace-syntax as well as the square brackets.

I assume the braces are there for "I want to skip doing the wrapping"

I was thinking that, but they didn't mention it, so I assumed it was just a typo. Could be, though.

I kind of get what you are saying syntactically, but the semantics are weird to me as the C version is only defined for integers in the first place so saying that the operator is truncating something is an awkward mental model.

> I kind of get what you are saying syntactically, but the semantics are weird to me as the C version is only defined for integers

Why? Mathematically, dividing two integers yields a real. If you want the result to be an integer, you need to define some rounding operation on the real result to produce an integer.

That is the source of the divergence between C and Python here, C rounds by truncation (towards 0), Python rounds by flooring (towards -inf).

> Mathematically, dividing two integers yields a real

not true. if you define 'divide' as inverse multiplication over the reals then that is closer to being true (zero is an integer, dividing an integer by zero doesn't yield a real). in that case every real can be expressed as n = a/b where a and b are integers and b != 0 then yes n is a real.

But 'divide' could just as well be defined along the lines of divisibility in number theory (the study of integers) where every integer can be expressed as n = q*b + r, where n,q,b,r are all integers and r >= 0 > b. then you could say that n divide b = q, with r as remainder, and n mod b = r. These are my preferred definition of mod and integer division.

sorry, rational, not real.

Depends on your definition of division. It you choose a definition which is closed (e.g. you’re working in number theory) then division of integers can only produce other integers.

> Mathematically, dividing two integers yields a real

Rational, more specifically.

Oh, I'm dumb. Sorry. (I got the terms for quotient, dividend, and divisor mixed up.)

> Oh, I'm dumb.

We both know that's not true.

> Sorry. (I got the terms for quotient, dividend, and divisor mixed up.)

No big, brainfarts happen.

Just don't divide by zero. That's how you get black holes!

Mathematically, Euclidean division of two integers yields an integer. You don't need to define reals or rounding. Children learn how to do it before they learn about rational numbers.

I invite you to ask your child how he would share three cookies with you. I've been asking variations of that question to all three of my children since they could talk.

Of interesting mathematical consequence, each of my children converged on the same solution at different ages. Them: three cookies. Daddy: zero cookies.

If it's not truncating, how do you describe its behavior when e.g. an odd number is divided by 2?

(Read the rest of the thread and look for my username.)

Also this TR: https://www.microsoft.com/en-us/research/wp-content/uploads/...

This one is very concise, great as a reference, you can remind yourself of which negatives go where in an instant.

Reply on news.ycombinator.com