Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

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.

View on HN

> 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.

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.

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.

Reply on news.ycombinator.com