> But for other applications, like in numerical analysis, researchers might need to square their precision. To achieve such an improvement, they might have to square the running time of gradient descent, making the calculation completely intractable
There is an easy way to counteract this. Let’s say your original runs in 1000 seconds. Squaring that would give 1000000 seconds. That’s a jump from under 17 minutes to over 11 days.
The fix: measure everything in hours. Your original runs in 0.278 hours. Squaring that gives 0.077 hours. Squaring the precision now makes it run 3.6 times faster.
I assume this is a joke, but for those not aware: the correct calculation would be to take a measure of the original running time in terms of CPU cycles or some equivalent unitless value, and square that. You don't want to be squaring values with units attached, because squared hours (or squared seconds) are very much not simple units of time.
CPU cycles isn't right either - this article is about theoretical CS not about a real machine (squared cycles is meaningless too). It seems the author is saying the algorithm running time is O(n^2) where n is precision. This is approximately cn^2 where c is a constant. Without knowing c we cannot say what squaring the running time precisely means.
There is an easy way to counteract this. Let’s say your original runs in 1000 seconds. Squaring that would give 1000000 seconds. That’s a jump from under 17 minutes to over 11 days.
The fix: measure everything in hours. Your original runs in 0.278 hours. Squaring that gives 0.077 hours. Squaring the precision now makes it run 3.6 times faster.