Refactor names of BigFloat precision functions

[dpsanders]

This reduces the number of exported names from Base by 3 and makes them more flexible to be used with other types with different precisions.
Fixes #13225.

Changes:

• get_bigfloat_precision() -> precision(BigFloat)
• set_bigfloat_precision(prec) -> setprecision(BigFloat, prec) and setprecision(prec)
• with_bigfloat_precision(f, prec) -> setprecision(f, BigFloat, prec) and setprecision(f, prec)

The idea of reusing setprecision instead of with_bigfloat_precision is due to @simonbyrne

Also, for consistency,

• with_rounding(f, T, rounding_mode) -> setrounding(f, T, rounding_mode)
• set_rounding(T, rounding_mode) -> setrounding(T, rounding_mode)
• get_rounding(T) -> rounding(T)

[simonbyrne]

I'm not really sold on setprecision!: to me, ! denotes that it mutates one of the arguments, whereas this function mutates a global variable. I have no strong feelings on underscores.

One other thing I've been thinking about is that withprecision functionality could be served by setprecision (in analogy to open).

[StefanKarpinski]

+1 to no underscores
-1 to ! at end of setprecision

[tkelman]

mutating a global fits with the "not safe to do from multiple threads" interpretation of the ! convention

[ScottPJones]

That's the first time I've heard of that multiple thread convention, is it documented somewhere?
Also, would it even hold here?
Should state like precision, rounding, etc. be thread specific, or across all threads in the process?
It also seems like neither @StefanKarpinski or @simonbyrne knew about that convention.

[simonbyrne]

I think getrounding is more descriptive than rounding.

[ScottPJones]

then, for consistency, should precision be deprecated and replaced by getprecision?

[simonbyrne]

Yes, that too.

[dpsanders]

I'm happy with getprecision and getrounding. I'll change this when I have a moment (not for a while, I fear).

[StefanKarpinski]

I really dislike prefixing these with get. Any function that returns a value "gets" that value. Should we prefix all functions that return anything besides nothing with "get"?

[tbreloff]

Agree with Stefan. I cringed when I just read getprecision and getrounding.

On Tue, Oct 13, 2015 at 2:32 PM, Stefan Karpinski [email protected]
wrote:

I really dislike prefixing these with get. Any function that returns a
value "gets" that value. Should we prefix all functions that return
anything besides nothing with "get"?

—
Reply to this email directly or view it on GitHub
#13232 (comment).

[dpsanders]

I also prefer without the get in fact.
I don't think that rounding(BigFloat) can be construed as much else than the current rounding mode of the BigFloat type. And 3 + precision(x) reads easily as "3 plus the precision of x", whereas 3 + getprecision(x) is difficult to parse.

[ScottPJones]

Then rounding and precision will be fine - but what's not good would be for them to be inconsistent.

[ScottPJones]

This line is a duplicate

[dpsanders]

Thanks for the detailed review, @ScottPJones

[simonbyrne]

Okay, I'm on board with rounding/precision. @dpsanders If you can fix the duplicate issues, then rebase, I would be happy to merge this.

[dpsanders]

Sure, should be able to this weekend.

[dpsanders]

After some git frustration, I have fixed @tkelman's comments (thanks!), squashed and rebased to current master.
I believe this is now ready to be merged.

[tkelman]

I think this needs one last run of genstdlib? Otherwise lgtm

[dpsanders]

I'm trying to get the docs fixed, but after several rounds of to-ing and fro-ing, I get

ERROR: LoadError: duplicate setrounding(T, mode) .. function:: setrounding(T, mode)

even though I don't see where there's a duplicate.

[dpsanders]

I believe that this is now, finally, ready to be merged.

[tkelman]

Yep 👍 thanks for bearing with a few more rounds than usual.

[dpsanders]

Thanks to all for the comments and help.