modBy crashes if given a zero

[boxed]

modBy 0 x crashes with a Debug.crash (

core/src/Gren/Kernel/Math.js

Line 14 in 098cca8

var _Math_modBy = F2(function (modulus, x) {

).

I suggest that there be two functions:

modBy : Int -> Int -> Maybe Int

which returns Nothing on a zero input, and:

modByWithDefault : Int -> Int -> Int -> Int
modByWithDefault modulus default x  =

which does returns a default value on zero.

The reason for the second method is that there is some overhead from the Maybe handling which would be a problem in performance sensitive code, as @robinheghan pointed out on zulip. The docs should point out the performance characteristics.

I think this is a fairly easy change, but I am a bit scared of touching kernel code of course :P

[robinheghan]

I started a discussion on the elm #language-design channel about this. It seems several other languages specialcase n / 0 == 0. Would that be an option? modBy would then follow the same behaviour.

I was also made aware that Roc has Checked versions of such functions. So divChecked or modByChecked, which would return a Maybe. Would that work?

Are there math-functions, other than div and modBy, that we should look at as well?

[boxed]

I find it very annoying that I get crashes for divide by zero in python but I also think that just returning zero would cause even more subtle bugs that would be difficult to track down.

I would for example also like to be able to set it so that any production of NaN in python would raise instead. Much nicer than a garbage value that pollutes the execution flow dowstream some arbitrary amount until it is (hopefully!) caught.

Same here with divide by zero and mod. Yea it's annoying but the right thing and the easy thing should be aligned. That's why I would be against "checked" versions: it makes it opt in to do the right thing. You could call that broken by default too.

[GabrielBoehme13]

I would like to propose the following…

intDivBy : Int -> Int -> Maybe Int

modBy : Int -> Int -> Maybe Int

remainderBy : Int -> Int -> Maybe Int

unsafeIntDivBy : Int -> Int -> Int

unsafeModBy : Int -> Int -> Int

unsafeRemainderBy : Int -> Int -> Int

…with the unsafe variants available for use in performance-sensitive code. This correctly promotes the safe behavior as the default, and highlights the unsafe nature of the high-performance options.

The unsafe variants would either crash upon division by zero (my preference), or return an undocumented integer result for performance reasons. Either approach (program crash, data corruption) seems reasonable, since the programmer is opting into the unsafe behavior.

It seems several other languages specialcase n / 0 == 0. Would that be an option?

Please, no. I was bitten by an unexpected n // 0 == 0 in an Elm project. I would prefer to have Gren crash on any integer divide-by-zero operation (or even have the // operator removed from the language), rather than getting unexpected zeroes silently corrupting my results. 🙂

[michi-zuri]

It may be worth looking at how Julia deals with dividing by zero etc., that language has been pretty good with dealing with numbers correctly (https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/).

The ^ operator should be looked at as well, as currently in Elm and Gren the following can happen:

b : Int
b = 2
-> 2 : Int

b ^ -1
-> 0.5 : Int

based on the wrong assumption/simplification that Int ^ Int -> Int

[GabrielBoehme13]

The ^ operator should be looked at as well, as currently in Elm and Gren the following can happen:

b : Int
b = 2
-> 2 : Int

b ^ -1
-> 0.5 : Int

based on the wrong assumption/simplification that Int ^ Int -> Int

Oof! I'd never noticed this problem until you pointed it out here – obvious in hindsight. 🤦

Too bad we don't have a UInt type – if we did, then at least Int ^ UInt -> Int would be true.