NaN return values for (seemingly?) reasonable input values

[bluescarni]

Hi Fredrik,

I am using you excellent library as a backend to implement various arbitrary-precision special functions in a project of mine.

To be clear, my goal is not to provide guaranteed bounds, but to supplement MPFR's selection of available special functions with Arb's. To this end, my usual pattern is to invoke Arb's functions with arb_t instances in which the ball radius is zero, and then convert the midpoint of the result back to MPFR.

The problem is that I have encountered some situations in which Arb returns NaN results for input values which, to me, look relatively reasonable. A couple of examples:

• arb_log_hypot() returns NaN if x is infinity and y is not NaN (or vice-versa),
• arb_tan_pi() returns NaN if x is 1/2, 3/2, 5/2, ...
• arb_cot_pi() has a similar problem if x is an integral value,
• arb_sinc_pi() returns NaN if x is infinity.

So far it seems like the issues I have found involve either infinity in the arguments, or poles in the functions, so perhaps I am just exercising corner cases that are a bit outside Arb's main scope of usage?

At this time I am handling the special values in my project on an ad-hoc basis, but this can be a bit painful because it requires to be aware of the properties of the function I am wrapping (i.e., asymptotic behaviour, poles, etc.).

[fredrik-johansson]

In my view, the most important thing for the arb and acb functions is to distinguish between numbers and non-numbers. If I were to redesign the library today, I might even do away with the different special values and just have a single not-a-number value. To output [nan +/- inf] for any non-number is a lazy solution that somewhat accomplishes that goal.

If someone were interested in handling non-number values more systematically, I suppose I'd welcome patches. I can certainly see the benefit of handling limiting values of -inf, +inf for real functions (complex infinities are a bit more ugly). It's just that writing such code is a major time sink for (in my opinion) limited benefit.

In Calcium (http://fredrikj.net/calcium/ca.html), I am working in proper handling of infinities from the start, but the situation there is a bit different -- exact arithmetic makes life easier, and the set of special values (signed infinities + unsigned infinity + undefined + unknown) is IMHO more sound -- in the Arb model, I don't really know how to make sense of -inf + infI or 3 + [nan +/- inf]I.

[fredrik-johansson]

Related issue: #152

[bluescarni]

Ok, fair enough, I thought this may be the reason :) I'll keep the special-casing in my code, perhaps I'll open a couple of PRs about this in the future.

Thanks for the link to Calcium, it seems like a really interesting project! As a curiosity, you mention in the FAQ that you need fast multivariate arithmetic. What arithmetic operations do you need? Are +,- and * enough, or do you also need polynomial division?

[fredrik-johansson]

Yes, polynomial division (both exact division and division with remainder for reduction by an ideal) and GCD which all thankfully work really well in Flint now. Multivariate factorisation will be needed as well for some simplifications (this is currently sitting on a branch in Daniel Schultz's repo; I'm waiting for it to be merged into the mainline Flint).

[p15-git-acc]

The problem is that I have encountered some situations in which Arb returns NaN results for input values which, to me, look relatively reasonable. A couple of examples:

@bluescarni most of these are now fixed, with the exception of tan and cot. What did you expect these to return instead of NaN?

Do you have more examples of special values that you are handling painfully in an ad-hoc basis?

[bluescarni]

@p15-git-acc thanks! Don't mind tan and cot, I am pretty sure that was a brain fart on my part :)