6

I have a math problem consisting of two questions:

  • can we find a number N knowing only the decimal part of its square root up to a precision (only an approximation of the decimal part because the decimal part never ends)
  • is the answer unique? which mean that we won't find two integer whose square root decimal values are equal (the first 50 for example) .

Example:

if we have 0,4142135623730950488016887242097, can we find that it's the decimal part of square root of 2 or 0,418286444621616658231167581 for 1234567890 The answer for the second question is pretty easy because, let's say we have 50 decimals, the number of possible integer's square root is much more than the 10^50-1 possible values of the decimals parts, so there whill be more than one answer.

I am very grateful for your help or any research track.

duffymo
  • 305,152
  • 44
  • 369
  • 561
Rachid
  • 69
  • 1
  • 2
    ".000" as decimal part is pretty much non-unique: 4, 16, 25 etc fit the bill. –  Aug 05 '14 at 11:32
  • 6
    I think this question is better asked at math.stackexchange.com; it doesn't appear to be a (particular) programming problem. –  Aug 05 '14 at 11:32
  • 1
    I think its tie-in with floating-point arithmetic and the need for an algorithm make it a legitimate question here. – Matt Phillips Aug 05 '14 at 11:35
  • Do you perhaps mean "fractional part" rather than "decimal part"? It's all decimal as displayed above, and all binary inside a computer. – Hot Licks Aug 05 '14 at 11:53
  • 2
    For the record, except in the case of perfect squares, the fractional part (with *infinite* precision) *does* determine the original number uniquely. If N and M (N != M) have the same fractional part then sqrt(N) and sqrt(M) belong to the same quadratic extension of the rationals, and it follows that N = q^2 * M for some rational number q, so sqrt(N) = q * sqrt(M) for some rational q. From that and the fact that sqrt(N) - sqrt(M) is an integer, you can deduce that sqrt(N) is rational, hence N and M are both perfect squares. – Mark Dickinson Aug 05 '14 at 12:16
  • 1
    For recovering N from the fractional part of sqrt(N): look into the LLL algorithm. Essentially, given `x = frac(sqrt(N))`, you want to look for (almost) linear relationships between `1`, `x` and `x**2`. – Mark Dickinson Aug 05 '14 at 12:24
  • and yes, you'd get better answers from math.stackexchange.com; this is a standard topic in computational number theory. – Mark Dickinson Aug 05 '14 at 12:38
  • thanks a lot, for the answers. @ hotlicks @MarkDickinson i'll use the fractional part as an intermediate step (because i have the decimal form which is aproximative and will never match to the real fractional form which has the square root in it. as you will notice in this example of 13 : http://upload.wikimedia.org/math/8/9/a/89a0fa5a5ea94b5fd6146e9bc2fe2260.png. And i think too i'll ask in math.stackexchange.com. thank you again for your time – Rachid Aug 05 '14 at 14:26
  • @Rachid: It's a great question! Just not really suitable for this site, unfortunately. BTW, LLL and PSLQ and similar algorithms should work just fine with approximations (that's part of their value). Some may require extended precision for intermediate calculations, but for small `N` I'd expect PSLQ to just work with standard double-precision floating-point. – Mark Dickinson Aug 05 '14 at 14:35

1 Answers1

0

You answered the second question yourself already. No there is no unique solution.

For the first question i don't know a quick mathematical solution, but some non-performant programming solutions:

  • Option A: The brute force method: iterate over all integers, and compare the square root of each with your number.

  • Option B: More tricky brute force method, which is more performant, but still slow:

    • Iterate the integers from 1 to M
    • Add your decimal part to each of them
    • Take the power of two and see how close the next integer value is
    • if the next integer value is very close, take the square root of it to counter check the result
    • stop as soon as you found the correct integer

  • Option C: caching:

    • precalculate your decimal parts for all integers and store them in a HashMap.
    • use the HashMap to find the results quickly
    • Consider: since you have a very big amount of data, different decimal parts could result in the same hash value, which would break this option.
Waog
  • 7,127
  • 5
  • 25
  • 37
  • thank you, the brut force or the hashmap will use either a great time to generate or to store because we are multiplying the number of integers by 10 for every decimal (50 decimals means 10^50 records in the RAM or the database or hours of computation) – Rachid Aug 05 '14 at 14:32