Unexpected behaviour of the modulo operator
I've noticed that the % methods on builtins behaves quite unfortunate (imo) when applied to negative numbers
Now, i am aware that mathematically it is undefined how it should behave with negative numbers, however basically every language i have worked in agreed that -1 % 10 should evaluate to 9.
This has the benefit that, when e.G. calculating a random ISize in a range 0 to 100, one would get away with rand.isize() % 100 rather than the more awkward rand.usize().isize() % 100 or (rand.usize() % 10).isize()
Similarly, when moving on a taurus positions could be calculated simply by something like
primitive Up fun apply(x, y): (ISize, ISize) => (x, (y - 1) % 10)
compared to the more verbose
primitive Up
fun apply(x, y): (ISize, ISize) =>
if y <= 0 then
(x, 10)
else
(x, y - 1)
end
So I'm wondering if pony has any good reason for deviating from this behavior and choosing to return the negative remainder instead?
Posted Mar 29, 2018, 9:50 AM UTC
you'll get a quicker response on github issue tracker.
This doesn't feel like an appropriate question to open an issue for. It's not necessarily a wrong implementation as much as one that I just didn't expect.
I assume this is feasible for the rfc-tracker instead, but I wanted to hear if there are any obvious statements (like there are for /0) about it that I had missed before going that route.
It's also not exactly troubling to write an interface which overrides this behaviour, so I figured an open discussion would be better suited for it, if that makes sense.
check the main site for the irc info
I know about the IRC channel, but the question seemed a bit too long for it. It is also awkward to share code-samples there without relying on a gist or w/ever
Edit: typo
I mean you already posted it here, you can just link it now.