New builtin function: Num.fracApproxEquals

[skyqrose]

The standard way to compare two Fracs is to check if their absolute difference is lower than some epsilon. This could be a builtin function.

fracApproxEquals : Frac -> Frac -> Frac -> Bool
fracApproxEquals \a, b, epsilon ->
  Num.absDiff a b < epsilon

(There's probably a better name than this, though.)

Pros:

• This will probably be commonly used.
• Forces the caller to provide an epsilon.
• Makes documentation and teaching easier if there's a specific function to point to when explaining that you can't use == of Fracs. Patches over what would otherwise feel like a hole in the language.

Cons:

• A function with 3 arguments of the same type but different meanings could easily trick people into passing the arguments in the wrong order. Unless Roc gets named function arguments, the easy solution is just to not have this and have everybody inline it instead.

See also: Issue about better compile errors for when you == two Fracs, which suggests the absolute difference approach, and could instead suggest an easier to use builtin function. https://github.com/roc-lang/roc/issues/5454

[bhansconnect]

Generally if we want named args, we use a record. {lhs, rhs, epsilon} or similar.

That said, I personally am against adding this function. If someone is going to compare floats, they should be required to think about how they want to do it. This is such a simple function to write out, that I think it is better explicit in user code. Not to mention, Dec is planed to become the default Frac type, and it has ==. So for many users, this function should not be needed.

As a direct example, If I were to use this at work while comparing the output of an ML model before and after optimizations, it would either have to have such a large epsilon that it is useless, or it would constantly fail and have false positives.

EDIT: this may be best discussed on zulip in the ideas stream: https://roc.zulipchat.com/#narrow/stream/304641-ideas