what to do with setrounding?

[simonbyrne]

Although marked as experimental in the docs, it still triggers a lot of issues (#17926, #26801, #26934). Perhaps we should unexport it, or deprecate it all together (functionality could be moved to a package).

cc: @dpsanders

[dpsanders]

Moving it to a package sounds reasonable.
We have effectively almost removed the dependence on setrounding in IntervalArithmetic.jl, at least for Float64, which was possibly its biggest consumer?

[dpsanders]

Basically rounding seems to be completely broken on Windows.

[JeffreySarnoff]

(a) unexport setrounding (b) eventually favor rounding mode savvy mathops

[JeffreySarnoff]

Earlier this year, I wrote DirectedRoundings.jl. This is a small package that intends to make making good use of directing rounding directions. The approach there lets setrounding do much of this governed crunching ... leaving to us the higher order engagements. With the apparent sidelining of reliable and portable and subtype specific setrounding, do we have any winning way waiting?

[dpsanders]

I recently realised that this has negative consequences for MPFR, where the rounding is done in software and so works on any machine.

Perhaps it is enough to have MPFR.setrounding for that case?

[JeffreySarnoff]

I have found MPFR (as seen through our BigFloat) to be unreliable in the last digit. Using setrounding with BigFloat may be not entirely ok. I have not done any testing on that -- I have done some to see that the last digit is not always rounded to nearest (when no other setrounding is in use). It has made verifying development code in the new Arb package difficult.

[simonbyrne]

@JeffreySarnoff do you have an example?

[simonbyrne]

@dpsanders I intentionally kept setrounding to work for MPFR. But we could move it to the module.

[dpsanders]

@simonbyrne Thanks, I just realised that setrounding still worked for BigFloat.
It would seem sensible to move it to the module. Maybe it would make sense to change the module name to BigFloats?

[JeffreySarnoff]

I have no example, and no specific details. I was testing some extended precision trig or arctrig functions and using BigFloat values for comparison -- one test failed and I tracked it back to BigFloat's value after redoing the work in Maple. At the time, frustration and recordkeeping/filesaving were at odds. The only detail I recall is 3 days of yuck.