Implement sqrt function

[Pzixel]

Related to rust-num/num-bigint#55

Should it be implemented on top of BigInts or some better approach is possible?

Ratio will be trickier to deal with precision, because you probably don't want to just round √(a/b) by operating on the numerator and denominator separately. That is, ⌊√a⌋/⌊√b⌋ would be quite lossy.

[cuviper]

I'm not really sure what's the right answer here. Approximating irrational numbers as a rational requires some level of control over how much accuracy is desired -- we can't be perfect, but we can get arbitrarily close, especially with BigInt that can grow as much as you like.

I have some code I was playing with for #32, to generate the most accurate approximations for a few interesting constants, given any particular Ratio<T> limit. For √2 it looks like:

# √2 ≈ 1.4142135624, f64 error 9.667e-17
================================
    type |      error | rational
---------|------------|---------
      i8 |   7.215e-5 | 99/70
      u8 |  -1.238e-5 | 239/169
     i16 |  -1.840e-9 | 27720/19601
     u16 | -3.158e-10 | 47321/33461
     i32 | -2.055e-19 | 1855077841/1311738121
     u32 | -2.055e-19 | 1855077841/1311738121
     i64 |  1.493e-38 | 6882627592338442563/4866752642924153522
     u64 | -2.561e-39 | 16616132878186749607/11749380235262596085
    i128 | -7.878e-77 | 133984184101103275326877813426364627544/94741125149636933417873079920900017937
    u128 | -1.352e-77 | 228725309250740208744750893347264645481/161733217200188571081311986634082331709

These values and their errors were computed based on 100 digits of the constant from Wolfram Alpha. It's possible to derive that basis mathematically, but I didn't bother because I was doing this for a variety of constants.

Note that even the 32-bit ratios are more accurate than f64 can represent! Which makes some sense, since a pair of 32-bit values has 64 significant bits together, or 62 w/ signs, vs. a 53-bit mantissa in f64.

And yet, it's probably not so useful to have ratios that are so near their type limits, since a lot of arithmetic requires multiplication that would overflow. That's not a problem for BigRational, of course.

[Pzixel]

I actually tried to implement superpi using this crate. However, it wasn't a big success: https://github.com/Pzixel/superpi-rs

It gives 3.1410... for 10 iterations (should give 10^2 correct digits). It's not directly related but it provides some experience.

P.S. It also shows how much clones you need to implement some algorithms.

https://github.com/Pzixel/superpi-rs/blob/2b8874c0bff2f480cdf299bb8e17d58218f2dc18/src/main.rs#L24-L29

It also seems having almost O(exp(n)) complexity:

[cuviper]

let new_b = BigRat::new(new_b_square.numer().sqrt(),new_b_square.denom().sqrt());

That's exactly the ⌊√a⌋/⌊√b⌋ which I said would be lossy.

I think even your initial ratio b for 1/√2 might be too inaccurate. I don't have experience with this algorithm, but it doesn't appear to be good at self-correcting for errors. If I set the initial b using the u32 ratio I gave above, your code then converges on 3.1415591..., or with my u64 ratio it gives 3.141592653787... (vs the true 3.141592653589...)

Maybe it would fare better with a Ratio::sqrt that doesn't round as much, but I'm not sure.

[cuviper]

P.S. It also shows how much clones you need to implement some algorithms.

You can do most operations by reference, e.g. let new_t = t - &p * &a_diff * a_diff;

[Pzixel]

That's exactly the ⌊√a⌋/⌊√b⌋ which I said would be lossy.

Yep, I know, but I don't know any better approach. Error is too high to make this algorithm work fine, because it should work with any precision, while we have only 11 right digits on u128. It's even worse than f64 which often has 16 significant digits.

You can do most operations by reference, e.g. let new_t = t - &p * &a_diff * a_diff;

Thank you for pointing that out, gonna try that.

[cuviper]

We could just use that sqrt-by-parts as an initial guess for the Babylonian method, but the question remains of how many iterations to compute. Maybe even just one, because the ratio part will quickly get large!

[Pzixel]

@cuviper maybe sqrt just should take some kind of precision as parameter?..

[ExpHP]

I don't get it, what is the use case of having a square root function on a rational that does approximations?

[cuviper]

Any sqrt that's not represented symbolically will be an approximation, including those for floating point. A rational sqrt has a chance to improve accuracy. (Whether that's needed is a separate question.)

[ExpHP]

But as already noted in the discussion, there are many problems with this:

• The problem is ill specified; rationals are not closed under the square root operation
  • Nor is there the existence of a "nearest" rational, under any possible rounding scheme (at least integers have that!)
• If you get a big denominator on a fixed-size integer type, then you can't perform virtually any math on it at all without getting an integer overflow. So what on earth are you going to do with it?

The fact that Rational32 can represent sqrt(2) more accurately than f64 doesn't mean much if any further operation you perform on it causes the world to explode.

This seems like a very niche problem that would be better serviced by a niche solution. Something that e.g. gives approximate rational roots to any rational polynomial.

(or at the very least, please don't call it sqrt!)

[ExpHP]

N.B. why I care so much:

Just earlier today, working on a diophantine equation solver, I almost wrote the following:

trait SqrtExt {
    /// Compute the (exact) square root, or panic if there isn't one
    fn sqrt(self) -> Self;
}

impl SqrtExt for Rational64 {
    ...
}

but then stopped and decided to make it a free function instead when I considered that it could get overridden by an inherent method.

[Pzixel]

I have been talking with guys on Math.StackOverflow and they convinced me it doesn't make sense to perform any kind of sqrt for rationals.

That's highly inefficient, because you'll end up with very large integers a,b, that may be far larger than needed for the desired precision level; and it'll be imprecise, because of the ⌊√a⌋/⌊√b⌋ problem mentioned.

So we probably need to implement arbitrary-sized fixed-point arithmetic in new repo like num-fp and implement all such operations there. I with to help if I can.

[cuviper]

For fixpoint, consider existing crates like https://crates.io/crates/bigdecimal

[liborty]

Or you could implement continued fractions, whereby all square roots of rationals are known to have repeating continued fraction terms. So you only need to evaluate the continued fraction of the square root up to where you detect repetition and the rest of arbitrary precision you get for free.

[1011X]

Maybe the sqrt method could return an Option<Ratio> instead, where if the numerator and denominator are perfect squares it returns their square root and None otherwise?