Crystal: Make Math.sqrt turn BigInt into BigFloat instead of Float64?

[hanyuone]

I have this code:

require "big_int"
Math.sqrt(BigInt.new("10000"))

When run on crystal play, it outputs 100, which is the expected result, but the type of the output is Float64.

If I want to work with larger numbers and square-rooting these numbers, I want to have arbitrary precision for those as well. Wouldn't it make sense to make Math.sqrt turn a BigInt into a BigFloat?

The only problem with this proposal is when to stop calculating the square root of the number - I'm not really sure how to address that, but simply using Float64 seems restrictive.

[straight-shoota]

Currently Math has no special implementations for big numbers. Math.sqrt(BigInt) just converts big int to float. That's why the return value is also Float64.

[hanyuone]

Also, would it make more sense to have .to_f on a BigInt turn into a BigFloat instead of an Float64?

[straight-shoota]

Well, I just wanted to state that, so everybody knows about the context. And I think if this feature is to be implemented, the other math methods should also be implement for big numbers, Though perhaps better not directly in Math but Math::Big or something.

About to_f: This method should return float on every type, never big float. To convert to a big float, there is to_big_f.

[RX14]

I think the math methods should take Bigs. We have method overloads so no need for an entirely new namespace, just add Math overloads at the end of big_int.cr (or separate it into a new file per type, which might be cleaner).

[straight-shoota]

I just thought it might be easier to separate in a different namespace, because Math is in core but big numbers not. It would feel a bit weird if requiring math/big (for example) adds methods to Math which are normally not there. Of course, in Crystal it is common to reopen types and add specific methods because some other file was included (for example json defines a bunch of JSON methods). But when you require math/big it makes more sense to have them in Math::Big.
But having overloads for the normal Math methods is also nice. And perhaps the big math extensions could be automatically required with big_float, big_int and bit_rational?

[ysbaddaden]

Read #RX14 statement again: add math overloads when big is required, not in math directly. Just like we have json methods injected only when json is required, for example.

[ysbaddaden]

Having a Math:: Big namespace with juste the same set of methods from Math would: be a duplication, as well as unexpected.

[akzhan]

It's simple to extend big arithmetics as I do with #4653.

But GMP have no methods to get BigFloat sqrt from BigInt. See https://gmplib.org/manual/Integer-Roots.html#Integer-Roots

Looks like you need to_big_f.sqrt.

[MakeNowJust]

I think this is related to #4160. You can read this with replacing Complex to BigInt and BigFloat.

[akzhan]

I think that that issue should be closed.

[asterite]

We should simply add overloads to Math when requiring "big".

[iSarCasm]

Should we close this one since #5113 is merged? @asterite

[asterite]

Yes, thanks! You can uses "fixes #nnn" to let github do this automatically next time.