More mpmath questions

[edbennett]

@LupoA A couple of issues probably mostly demonstrating my ignorance about mpmath. Looking at https://github.com/LupoA/rhos/blob/feature/GP/rhos/core.py

• Obviously (given your comment on line 50), the syntax using mp. operations for every arithmetic operation is very cumbersome. What's the reasoning behind using that syntax? Based on my skim-read of the documentation, if a and b are both mpf objects (which most of your code is careful to ensure), then a - b should give the same result as mp.fsub(a, b). Being able to use standard arithmetic notation would make this vastly more readable.
• Is there a reason that on e.g. line 14, you use mp.fadd(mpf(i), mpf(j)) rather than mpf(i + j), given that i and j are both integers so addition is exact?

[LupoA]

You are right about the second point. About the first one too, but there my motivation for insisting on mp.fsub is that while I tried to ensure every variable is of the mpf type, I didn't do it systematically, I did not have assertions or other means of ensuring the mpf type was enforced everywhere (although it would be cool to have one)

In other words it was a precaution, from which we can move away if we check nothing is breaking.

[edbennett]

Some alternatives would be

1. Have some guards in place, via assert or otherwise
2. Use type annotations to specify this requirement and verify it with mypy (see Type annotations #40)
3. Accept things that aren't mpf objects and convert them to mpfs if needed.

(My preference would probably be 3, but there may be downsides to this that I'm not aware of.)

[LupoA]

For 3 a problem I see is that it's not easy to know a priori when a conversion is needed or when it's not, so one would need to convert everything to mpf, for instance, at the beginning of each function

def func(a,b):
  a = mpf(a)
  b = mpf(b)
  return a+b

which does not look great. I guess we could do as you first suggested: once we are sure all inputs are mpf (which should not be too hard to check because of the input class) we can roll with standard arithmetic notation

[edbennett]

There's probably a middle ground where for the most user-friendly functions we do the conversion, but for the inner core functions we use type annotations and set mypy to be strict about it.

There's also an argument that functions like your func should not force mpf, for duck typing reasons—in that case we would need to work out the correct place to verify that the types are correct. However, you could say that e.g. lambda func2 a, b: a - b would be correct to coerce the arguments to mpf, since otherwise you could introduce a large imprecision if a $\approx$ b. Something to think carefully about before making changes.