3 ms·

Good paper—it was the primary source we looked at when implementing these operations in Julia. Specifically, Julia implements all versions and overloads `div` a

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.

thaumasiotes 5y ago
> 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]
- bee_rider 5y ago
  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.
  - dmurray 5y ago
    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.
    - half-kh-hacker 5y ago
      I assume n would be size(a)
      - dmurray 5y ago
        Oh yeah - I got mixed up on this and thought we wanted to access sub arrays within a.
  - half-kh-hacker 5y ago
    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"
    - bee_rider 5y ago
      I was thinking that, but they didn't mention it, so I assumed it was just a typo. Could be, though.
  - tialaramex 5y ago
    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.

thaumasiotes 5y ago

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

bee_rider 5y ago
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.
- dmurray 5y ago
  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.
  - half-kh-hacker 5y ago
    I assume n would be size(a)
    - dmurray 5y ago
      Oh yeah - I got mixed up on this and thought we wanted to access sub arrays within a.
- half-kh-hacker 5y ago
  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"
  - bee_rider 5y ago
    I was thinking that, but they didn't mention it, so I assumed it was just a typo. Could be, though.
- tialaramex 5y ago
  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.