0

I've come up with a method to tell if a number of arbitrary size is a perfect square and was curious..

1) Is there a practical benefit for knowing IF an integer is a perfect square?

2) What is the expected time frame for an integer, N, based on current known methods?

I would love to test this with a list of mixed perfect and non perfect squares for speed and accuracy. This method is instant for any N, so far with a size of 47000+ digits and has nothing to do with digital roots. I think I can extend this to other figurate series such as triangle numbers, and to the Fibonacci numbers.

Troy W
  • 97
  • 1
    here is a discussion of the issue. – lulu Nov 19 '17 at 13:11
  • Hmm, do you mean it's "instant" on a computer or that it actually has O(1) complexity? – naslundx Nov 19 '17 at 13:12
  • I mean it takes the same time to tell if 9 is a perfect square as it does for a number with (so far) ~47000 digits. – Troy W Nov 19 '17 at 13:14
  • 1
    That would be valuable, if it could decide the question in all cases. But if it's something like "Look at the last digit. If it's 2,3,7, or 8, the number is definitely not a perfect square; otherwise we're still not sure" that is much less valuable. I should add that the chance you have discovered something new and simple is very small; people have been studying perfect squares seriously for at least 3500 years. – MJD Nov 19 '17 at 13:25
  • Just print the code, describe the algorithm. As you can see from the Overstock link I provided in my first comment, that's the way things are done. – lulu Nov 19 '17 at 13:41
  • I'm not posting the code. This is tied to work that I've been doing for months. Posting the code would ruin that. I just want to test it with an independent source in order to prove the method works. – Troy W Nov 19 '17 at 13:43
  • Or just provide an answer. If the (current) expected time complexity is related to N or the square root of N, then that's what I'm wondering about. – Troy W Nov 19 '17 at 13:46
  • 1
    Why would it be anywhere near that complex? Binary search to find the greatest integer $m$ with $m^2≤N$ is $O(\log N)$ and then checking whether or not $m^2=N$ is again $\log N$ so the naive method is $O\left(( \log N)^2\right)$ – lulu Nov 19 '17 at 13:53
  • I apologize, I need a test case. How long would it take under currently known methods to find out if a number with 47000 digits is a perfect square? In minutes or hours? Just an approximation. – Troy W Nov 19 '17 at 13:58
  • I gave you the link. Run the code yourself. – lulu Nov 19 '17 at 13:59
  • Thanks for your time. – Troy W Nov 19 '17 at 14:00
  • @lulu I don't think the thread you linked to is really pertinent. The question only asks about numbers up to 64 bits. OP wants to know about tests that work for 140000-bit numbers. – MJD Nov 19 '17 at 15:16
  • 2
    P. Zimmermann's Karatsuba Square Root https://hal.inria.fr/inria-00072854/en/ (for a implementation see GMP, https://gmplib.org/manual/Square-Root-Algorithm.html) will compute the complete square root and remainder for numbers of order $10^{47000}$ in milliseconds. Note that this is the worst case, a function which uses some modular pre-tests will be much faster. – gammatester Nov 19 '17 at 15:18
  • @gammatester.. Thanks, the paper you linked to has a table (figure 1 in the paper) which states "Table giving the number of milliseconds needed to multiply two numbers of w 32 bit words", the last of which is a ~2.5 million digit number with 33000 milliseconds in computation time for the fft_mul algorithm. How many of those operations would it take for a number of that size to determine whether or not it is a perfect square? I clearly lack an understanding here, I appreciate the help – Troy W Nov 19 '17 at 17:30
  • Or, is that the answer. That or would take 33000 milliseconds to determine if an integer of that size is a perfect square, in which case testing 1000 integers of that size would take a little over 9 hours? – Troy W Nov 19 '17 at 18:06
  • 1
    The time to test 1000 numbers depends on the distribution. 33 s is the time to compute the square root (worst case). So yes, if you test 1000 squares with 2.5 mio digits the time would be 9 h. But if you test whether 1000 random numbers are square or not, the time would be much less because you have the modular pre-tests: Using one mask with 127 and two 32bit mods you get a cumulative pre-test rejection rate of 99.9976%. Remember: Squares are very rare and chances are good that for your 'small' values of with 47000 digits you will not find any within 1000 random numbers. – gammatester Nov 19 '17 at 18:51
  • That gives me a good benchmark that seems reflective of the current state of the art. Exactly what I was looking for, thank you very much. – Troy W Nov 19 '17 at 18:56
  • 1
    If you benchmark, you should remember that the 33 s are measured with a 366 MHz Pentiun II in 1999! Even with my suboptimal own Pascal routines without FFT I need only 2.2 s on my old Win7/64 Core i3-2350M for a number with 2.5 mio decimal digits. – gammatester Nov 19 '17 at 20:32
  • Good point of course. Based on my preliminary results, I was able to test a 2.5 mil digit number and was around 18 seconds. That being said, I believe there is probably room for optimization. – Troy W Nov 19 '17 at 20:52

0 Answers0