Самый быстрый способ определить, является ли квадратный корень целого числа целым числом

Я довольно поздно на вечеринку, но я надеюсь дать лучший ответ; короче и (при условии, что мой benchmark правильно) тоже много быстрее.

long goodMask; // 0xC840C04048404040 computed below
{
    for (int i=0; i<64; ++i) goodMask |= Long.MIN_VALUE >>> (i*i);
}

public boolean isSquare(long x) {
    // This tests if the 6 least significant bits are right.
    // Moving the to be tested bit to the highest position saves us masking.
    if (goodMask << x >= 0) return false;
    final int numberOfTrailingZeros = Long.numberOfTrailingZeros(x);
    // Each square ends with an even number of zeros.
    if ((numberOfTrailingZeros & 1) != 0) return false;
    x >>= numberOfTrailingZeros;
    // Now x is either 0 or odd.
    // In binary each odd square ends with 001.
    // Postpone the sign test until now; handle zero in the branch.
    if ((x&7) != 1 | x <= 0) return x == 0;
    // Do it in the classical way.
    // The correctness is not trivial as the conversion from long to double is lossy!
    final long tst = (long) Math.sqrt(x);
    return tst * tst == x;
}

первый тест ловит большинство не-квадратов быстро. Он использует таблицу 64-item, упакованную в длинную, поэтому нет стоимости доступа к массиву (косвенная проверка и проверка границ). Для равномерно случайного long, есть 81,25% вероятность окончания здесь.

второй тест ловит все числа, имеющие нечетное число двоек в их факторизации. Метод Long.numberOfTrailingZeros очень быстро, поскольку он получает JIT-ed в одну инструкцию i86.

после удаления конечных нулей третий тест обрабатывает числа, заканчивающиеся 011, 101 или 111 в двоичном формате, которые не являются идеальными квадратами. Он также заботится о отрицательные числа и 0.

окончательный тест возвращается к double арифметика. As double только 53 бита мантиссы, преобразование из long to double включает округление для больших значений. Тем не менее, тест верен (если только доказательство - это неправильно).

попытка включить идею mod255 не увенчалась успехом.

вам придется сделать некоторые бенчмаркинг. Лучший алгоритм будет зависеть от распределения входных данных.

Ваш алгоритм может быть почти оптимальным, но вы можете сделать быструю проверку, чтобы исключить некоторые возможности, прежде чем звонить корень квадратный рутины. Например, посмотрите на последнюю цифру вашего числа в hex, сделав немного "и"."Идеальные квадраты могут заканчиваться только на 0, 1, 4 или 9 в базе 16, поэтому для 75% ваших входов (если они равномерно распределены) вы можно избежать вызова квадратного корня в обмен на очень быстрое вращение бита.

Кип сопоставил следующий код, реализующий шестнадцатеричный трюк. При тестировании чисел от 1 до 100 000 000 Этот код выполнялся в два раза быстрее оригинала.

public final static boolean isPerfectSquare(long n)
{
    if (n < 0)
        return false;

    switch((int)(n & 0xF))
    {
    case 0: case 1: case 4: case 9:
        long tst = (long)Math.sqrt(n);
        return tst*tst == n;

    default:
        return false;
    }
}

когда я тестировал аналогичный код на C++, он на самом деле работал медленнее, чем оригинал. Однако, когда я устранил оператор switch, шестнадцатеричный трюк снова делает код в два раза больше быстрый.

int isPerfectSquare(int n)
{
    int h = n & 0xF;  // h is the last hex "digit"
    if (h > 9)
        return 0;
    // Use lazy evaluation to jump out of the if statement as soon as possible
    if (h != 2 && h != 3 && h != 5 && h != 6 && h != 7 && h != 8)
    {
        int t = (int) floor( sqrt((double) n) + 0.5 );
        return t*t == n;
    }
    return 0;
}

устранение оператора switch мало повлияло на код c#.

Я думал об ужасных временах, которые я провел в курсе численного анализа.

и затем я помню, что была эта функция, кружащая вокруг " сети из исходного кода Quake:

float Q_rsqrt( float number )
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;  // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 ); // wtf?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

  #ifndef Q3_VM
  #ifdef __linux__
    assert( !isnan(y) ); // bk010122 - FPE?
  #endif
  #endif
  return y;
}

который в основном вычисляет квадратный корень, используя аппроксимационную функцию Ньютона (не могу вспомнить точное имя).

он должен использоваться и может быть даже быстрее, это из одной из игр феноменального программного обеспечения id!

это написано на C++ но не должно быть слишком сложно повторно использовать ту же технику в Java, как только вы получите идею:

Я изначально нашел его на: http://www.codemaestro.com/reviews/9

метод Ньютона объясняется в Википедии:http://en.wikipedia.org/wiki/Newton%27s_method

вы можете перейти по ссылке для более подробного объяснения того, как это работает, но если вам все равно, то это примерно то, что я помню из чтения блога и из принятия Курс численного анализа:

• the * (long*) &y - это в основном функция быстрого преобразования в длинную, поэтому целочисленные операции могут применяться к необработанным байтам.
• the 0x5f3759df - (i >> 1); line-предварительно вычисленное начальное значение для аппроксимационной функции.
• the * (float*) &i преобразует значение с плавающей точкой.
• the y = y * ( threehalfs - ( x2 * y * y ) ) строка bascially повторяет значение над функцией снова.

функция приближения дает больше точные значения тем больше вы повторяете функцию над результатом. В случае Quake одна итерация "достаточно хороша", но если бы не вы... затем вы можете добавить столько итераций, сколько вам нужно.

это должно быть быстрее, потому что это уменьшает количество операций деления, выполняемых в наивном квадратном укоренении, до простого деления на 2 (на самом деле a * 0.5F операция умножения) и замените его на несколько фиксированных операций умножения.

Я не уверен, что это будет быстрее или даже точно, но вы можете использовать магический квадратный корень Джона Кармака, алгоритм решения квадратного корня быстрее. Вероятно, вы могли бы легко проверить это для всех возможных 32-битных целых чисел и проверить, что вы действительно получили правильные результаты, так как это только appoximation. Однако теперь, когда я думаю об этом, использование двойников также приближается, поэтому я не уверен, как это войдет в игру.

если вы делаете двоичную отбивную, чтобы попытаться найти" правильный " квадратный корень, вы можете довольно легко обнаружить, если значение у вас есть достаточно близко, чтобы сказать:

(n+1)^2 = n^2 + 2n + 1
(n-1)^2 = n^2 - 2n + 1

Итак, из расчета n^2 параметры:

• n^2 = target: сделал, возвращает true
• n^2 + 2n + 1 > target > n^2: вы близки, но это не идеально: возврат false
• n^2 - 2n + 1 < target < n^2: то же самое
• target < n^2 - 2n + 1 : бинарная отбивная на нижнем n
• target > n^2 + 2n + 1 : бинарный Чоп на более высоком n

(к сожалению, это использует n как ваше текущее предположение, и target для параметра. Прошу прощения за путаницу!)

я не знаю, будет ли это быстрее или нет, но стоит попробовать.

EDIT: двоичный ЧОП не должен принимать весь диапазон целых чисел, либо (2^x)^2 = 2^(2x), поэтому, как только вы нашли верхний бит набора в своей цели (что можно сделать с помощью трюка с битами; я забыл, как именно) вы можете быстро получить ряд потенциальных ответов. Имейте в виду, что наивный двоичный ЧОП по-прежнему будет занимать до 31 или 32 итераций.

я провел свой собственный анализ нескольких алгоритмов в этом потоке и пришел к некоторым новым результатам. Вы можете увидеть эти старые результаты в истории редактирования этого ответа, но они не точны, так как я допустил ошибку и потратил время на анализ нескольких алгоритмов, которые не близки. Однако, извлекая уроки из нескольких разных ответов, у меня теперь есть два алгоритма, которые сокрушают "победителя" этой темы. Вот суть того, что я делаю не так, как все. еще:

// This is faster because a number is divisible by 2^4 or more only 6% of the time
// and more than that a vanishingly small percentage.
while((x & 0x3) == 0) x >>= 2;
// This is effectively the same as the switch-case statement used in the original
// answer. 
if((x & 0x7) != 1) return false;

однако эта простая строка, которая большую часть времени добавляет одну или две очень быстрые инструкции, значительно упрощает switch-case оператор в один оператор if. Однако он может добавить к среде выполнения, если многие из проверенных чисел имеют значительную мощность двух факторов.

ниже приведены следующие алгоритмы:

• интернет - Кип опубликовал ответ
• Durron - мой измененный ответ использование ответа с одним проходом в качестве базы
• DurronTwo - мой измененный ответ, используя двухпроходный ответ (@JohnnyHeggheim), с некоторыми другими небольшими изменениями.

вот пример выполнения, если числа генерируются с помощью Math.abs(java.util.Random.nextLong())

 0% Scenario{vm=java, trial=0, benchmark=Internet} 39673.40 ns; ?=378.78 ns @ 3 trials
33% Scenario{vm=java, trial=0, benchmark=Durron} 37785.75 ns; ?=478.86 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=DurronTwo} 35978.10 ns; ?=734.10 ns @ 10 trials

benchmark   us linear runtime
 Internet 39.7 ==============================
   Durron 37.8 ============================
DurronTwo 36.0 ===========================

vm: java
trial: 0

и вот пример выполнения, если он выполняется только на первом миллионе длин:

 0% Scenario{vm=java, trial=0, benchmark=Internet} 2933380.84 ns; ?=56939.84 ns @ 10 trials
33% Scenario{vm=java, trial=0, benchmark=Durron} 2243266.81 ns; ?=50537.62 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=DurronTwo} 3159227.68 ns; ?=10766.22 ns @ 3 trials

benchmark   ms linear runtime
 Internet 2.93 ===========================
   Durron 2.24 =====================
DurronTwo 3.16 ==============================

vm: java
trial: 0

Как видите, DurronTwo делает лучше для больших входных сигналов, потому что он получает использовать фокус очень очень часто, но получает удар по сравнению с первым алгоритмом и Math.sqrt потому что цифры намного меньше. Между тем, чем проще Durron является огромным победителем, потому что он никогда не должен делить на 4 много много раз в первом миллионе чисел.

здесь Durron:

public final static boolean isPerfectSquareDurron(long n) {
    if(n < 0) return false;
    if(n == 0) return true;

    long x = n;
    // This is faster because a number is divisible by 16 only 6% of the time
    // and more than that a vanishingly small percentage.
    while((x & 0x3) == 0) x >>= 2;
    // This is effectively the same as the switch-case statement used in the original
    // answer. 
    if((x & 0x7) == 1) {

        long sqrt;
        if(x < 410881L)
        {
            int i;
            float x2, y;

            x2 = x * 0.5F;
            y  = x;
            i  = Float.floatToRawIntBits(y);
            i  = 0x5f3759df - ( i >> 1 );
            y  = Float.intBitsToFloat(i);
            y  = y * ( 1.5F - ( x2 * y * y ) );

            sqrt = (long)(1.0F/y);
        } else {
            sqrt = (long) Math.sqrt(x);
        }
        return sqrt*sqrt == x;
    }
    return false;
}

и DurronTwo

public final static boolean isPerfectSquareDurronTwo(long n) {
    if(n < 0) return false;
    // Needed to prevent infinite loop
    if(n == 0) return true;

    long x = n;
    while((x & 0x3) == 0) x >>= 2;
    if((x & 0x7) == 1) {
        long sqrt;
        if (x < 41529141369L) {
            int i;
            float x2, y;

            x2 = x * 0.5F;
            y = x;
            i = Float.floatToRawIntBits(y);
            //using the magic number from 
            //http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf
            //since it more accurate
            i = 0x5f375a86 - (i >> 1);
            y = Float.intBitsToFloat(i);
            y = y * (1.5F - (x2 * y * y));
            y = y * (1.5F - (x2 * y * y)); //Newton iteration, more accurate
            sqrt = (long) ((1.0F/y) + 0.2);
        } else {
            //Carmack hack gives incorrect answer for n >= 41529141369.
            sqrt = (long) Math.sqrt(x);
        }
        return sqrt*sqrt == x;
    }
    return false;
}

и мой эталонный жгут: (требуется Google суппорт 0.1-rc5)

public class SquareRootBenchmark {
    public static class Benchmark1 extends SimpleBenchmark {
        private static final int ARRAY_SIZE = 10000;
        long[] trials = new long[ARRAY_SIZE];

        @Override
        protected void setUp() throws Exception {
            Random r = new Random();
            for (int i = 0; i < ARRAY_SIZE; i++) {
                trials[i] = Math.abs(r.nextLong());
            }
        }


        public int timeInternet(int reps) {
            int trues = 0;
            for(int i = 0; i < reps; i++) {
                for(int j = 0; j < ARRAY_SIZE; j++) {
                    if(SquareRootAlgs.isPerfectSquareInternet(trials[j])) trues++;
                }
            }

            return trues;   
        }

        public int timeDurron(int reps) {
            int trues = 0;
            for(int i = 0; i < reps; i++) {
                for(int j = 0; j < ARRAY_SIZE; j++) {
                    if(SquareRootAlgs.isPerfectSquareDurron(trials[j])) trues++;
                }
            }

            return trues;   
        }

        public int timeDurronTwo(int reps) {
            int trues = 0;
            for(int i = 0; i < reps; i++) {
                for(int j = 0; j < ARRAY_SIZE; j++) {
                    if(SquareRootAlgs.isPerfectSquareDurronTwo(trials[j])) trues++;
                }
            }

            return trues;   
        }
    }

    public static void main(String... args) {
        Runner.main(Benchmark1.class, args);
    }
}

обновление: Я создал новый алгоритм, который быстрее в одних сценариях, медленнее в других, я получил разные критерии, основанные на разных входах. Если вычислить по модулю 0xFFFFFF = 3 x 3 x 5 x 7 x 13 x 17 x 241, мы можем исключить 97.82% чисел, которые не могут быть квадратами. Это можно (вроде) сделать в одной строке, с 5 побитовыми операциями:

if (!goodLookupSquares[(int) ((n & 0xFFFFFFl) + ((n >> 24) & 0xFFFFFFl) + (n >> 48))]) return false;

результирующий индекс либо 1) остаток, 2) остаток + 0xFFFFFF, или 3) остаток + 0x1FFFFFE. Конечно, нам нужно иметь таблицу поиска для остатков по модулю 0xFFFFFF, что составляет около 3 МБ файла (в этом случае хранится в виде ASCII текст десятичных чисел, не оптимальных, но явно улучшаемых с помощью ByteBuffer и так далее. Но поскольку это предварительные расчеты, это не так важно. вы можете найти файл здесь (или создайте его самостоятельно):

public final static boolean isPerfectSquareDurronThree(long n) {
    if(n < 0) return false;
    if(n == 0) return true;

    long x = n;
    while((x & 0x3) == 0) x >>= 2;
    if((x & 0x7) == 1) {
        if (!goodLookupSquares[(int) ((n & 0xFFFFFFl) + ((n >> 24) & 0xFFFFFFl) + (n >> 48))]) return false;
        long sqrt;
        if(x < 410881L)
        {
            int i;
            float x2, y;

            x2 = x * 0.5F;
            y  = x;
            i  = Float.floatToRawIntBits(y);
            i  = 0x5f3759df - ( i >> 1 );
            y  = Float.intBitsToFloat(i);
            y  = y * ( 1.5F - ( x2 * y * y ) );

            sqrt = (long)(1.0F/y);
        } else {
            sqrt = (long) Math.sqrt(x);
        }
        return sqrt*sqrt == x;
    }
    return false;
}

я загружаю его в boolean массив такой:

private static boolean[] goodLookupSquares = null;

public static void initGoodLookupSquares() throws Exception {
    Scanner s = new Scanner(new File("24residues_squares.txt"));

    goodLookupSquares = new boolean[0x1FFFFFE];

    while(s.hasNextLine()) {
        int residue = Integer.valueOf(s.nextLine());
        goodLookupSquares[residue] = true;
        goodLookupSquares[residue + 0xFFFFFF] = true;
        goodLookupSquares[residue + 0x1FFFFFE] = true;
    }

    s.close();
}

пример выполнения. Он бил Durron (версия одна) в каждой пробной версии, которую я запускал.

 0% Scenario{vm=java, trial=0, benchmark=Internet} 40665.77 ns; ?=566.71 ns @ 10 trials
33% Scenario{vm=java, trial=0, benchmark=Durron} 38397.60 ns; ?=784.30 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=DurronThree} 36171.46 ns; ?=693.02 ns @ 10 trials

  benchmark   us linear runtime
   Internet 40.7 ==============================
     Durron 38.4 ============================
DurronThree 36.2 ==========================

vm: java
trial: 0

Это должно быть намного быстрее использовать метод Ньютона вычислить Целочисленный Квадратный Корень, затем квадрат это число и проверить, как вы делаете в текущем решении. Метод Ньютона является основой решения Кармака, упомянутого в некоторых других ответах. Вы должны иметь возможность получить более быстрый ответ, так как вас интересует только целочисленная часть корня, что позволяет быстрее остановить алгоритм аппроксимации.

еще одна оптимизация, которую вы может попробовать: если Цифровой Корень числа не заканчивается 1, 4, 7, или 9 число не идеальный квадрат. Это можно использовать как быстрый способ устранить 60% ваших входов перед применением более медленного алгоритма квадратного корня.

Я хочу, чтобы эта функция работала со всеми положительные 64-разрядные целые числа со знаком

Math.sqrt() работает с двойниками в качестве входных параметров, поэтому вы не получите точных результатов для целых чисел больше, чем 2^53.

просто для записи другой подход-использовать простое разложение. Если каждый фактор разложения четный, то число является идеальным квадратом. Итак, вы хотите увидеть, можно ли разложить число как произведение квадратов простых чисел. Конечно, вам не нужно получать такое разложение, просто чтобы увидеть, существует ли оно.

сначала постройте таблицу квадратов простых чисел, которые ниже 2^32. Это намного меньше, чем таблица всех целых чисел до этот предел.

решение было бы таким:

boolean isPerfectSquare(long number)
{
    if (number < 0) return false;
    if (number < 2) return true;

    for (int i = 0; ; i++)
    {
        long square = squareTable[i];
        if (square > number) return false;
        while (number % square == 0)
        {
            number /= square;
        }
        if (number == 1) return true;
    }
}

Я думаю, это немного загадочно. То, что он делает, проверяет на каждом шаге, что квадрат простого числа делит входное число. Если это так, то он делит число на квадрат, насколько это возможно, чтобы удалить этот квадрат из простого разложения. Если по этому процессу мы пришли к 1, то входное число было разложением квадрата простых чисел. Если квадрат становится больше числа сам по себе, то нет никакого способа этот квадрат, или любые большие квадраты, может разделить его, поэтому число не может быть разложением квадратов простых чисел.

учитывая, что в настоящее время sqrt выполняется в аппаратном обеспечении и необходимость вычисления простых чисел здесь, я думаю, что это решение намного медленнее. Но это должно дать лучшие результаты, чем решение с sqrt, которое не будет работать над 2^54, Как говорит mrzl в своем ответе.

целочисленная задача заслуживает целочисленного решения. Таким образом

выполните двоичный поиск по (неотрицательным) целым числам, чтобы найти наибольшее целое число t такое, что t**2 <= n. Затем проверьте, есть ли r**2 = n точно. Это занимает время O (log n).

Если вы не знаете как двоичный поиск положительных чисел, потому что набор неограничен, это легко. Вы начинаете с вычисления возрастающей функции f (выше f(t) = t**2 - n) по степеням двух. Когда вы видите, что это становится положительным, вы нашли верхняя граница. Затем вы можете выполнить стандартный двоичный поиск.

было указано, что последний d цифры идеального квадрата могут принимать только определенные значения. Последний d цифры (в базу b) в то же самое, что и остальные, когда n делится на bd, ie. в языке C n % pow(b, d).

это можно обобщить на любой модуль m, ie. n % m можно использовать, чтобы исключить некоторый процент чисел из идеальных квадратов. Модуль вы используете в настоящее время составляет 64, что позволяет 12, т. е.. 19% остатков, как можно больше квадратов. С небольшим кодированием я нашел модуль 110880, который позволяет только 2016, т. е. 1,8% остатков как возможные квадраты. Поэтому в зависимости от стоимости операции модуля (т. е. деление) и поиск таблицы по сравнению с квадратным корнем на вашем компьютере, используя этот модуль может быть быстрее.

кстати, если Java имеет способ хранить упакованный массив битов для таблицы поиска, не используйте его. 110880 32-битные слова не так много ОЗУ эти дни и получение машинного слова будут быстрее, чем получение одного бита.

для исполнения, вы очень часто приходится делать некоторые compromsies. Другие выразили различные методы, однако, вы отметили, что Хак Кармака был быстрее до определенных значений N. тогда вы должны проверить "n", и если он меньше этого числа N, используйте Хак Кармака, иначе используйте какой-то другой метод, описанный в ответах здесь.

Это самая быстрая реализация Java, который я мог придумать, используя комбинацию методов, предложенных другими в этой теме.

• Mod-256 test
• неточный тест mod-3465 (позволяет избежать целочисленного деления за счет некоторых ложных срабатываний)
• квадратный корень с плавающей запятой, круглый и сравните с входным значением

Я также экспериментировал с этими модификациями, но они не помогли производительность:

• дополнительный тест mod-255
• деление входного значения на степени 4
• быстрый обратный квадратный корень (для работы с высокими значениями N требуется 3 итерации, достаточно, чтобы сделать его медленнее, чем аппаратная функция квадратного корня.)

public class SquareTester {

    public static boolean isPerfectSquare(long n) {
        if (n < 0) {
            return false;
        } else {
            switch ((byte) n) {
            case -128: case -127: case -124: case -119: case -112:
            case -111: case -103: case  -95: case  -92: case  -87:
            case  -79: case  -71: case  -64: case  -63: case  -60:
            case  -55: case  -47: case  -39: case  -31: case  -28:
            case  -23: case  -15: case   -7: case    0: case    1:
            case    4: case    9: case   16: case   17: case   25:
            case   33: case   36: case   41: case   49: case   57:
            case   64: case   65: case   68: case   73: case   81:
            case   89: case   97: case  100: case  105: case  113:
            case  121:
                long i = (n * INV3465) >>> 52;
                if (! good3465[(int) i]) {
                    return false;
                } else {
                    long r = round(Math.sqrt(n));
                    return r*r == n; 
                }
            default:
                return false;
            }
        }
    }

    private static int round(double x) {
        return (int) Double.doubleToRawLongBits(x + (double) (1L << 52));
    }

    /** 3465<sup>-1</sup> modulo 2<sup>64</sup> */
    private static final long INV3465 = 0x8ffed161732e78b9L;

    private static final boolean[] good3465 =
        new boolean[0x1000];

    static {
        for (int r = 0; r < 3465; ++ r) {
            int i = (int) ((r * r * INV3465) >>> 52);
            good3465[i] = good3465[i+1] = true;
        }
    }

}

следующее упрощение решения maaartinus, похоже, сбривает несколько процентных пунктов от времени выполнения, но я недостаточно хорош в бенчмаркинге, чтобы создать тест, которому я могу доверять:

long goodMask; // 0xC840C04048404040 computed below
{
    for (int i=0; i<64; ++i) goodMask |= Long.MIN_VALUE >>> (i*i);
}

public boolean isSquare(long x) {
    // This tests if the 6 least significant bits are right.
    // Moving the to be tested bit to the highest position saves us masking.
    if (goodMask << x >= 0) return false;
    // Remove an even number of trailing zeros, leaving at most one.
    x >>= (Long.numberOfTrailingZeros(x) & (-2);
    // Repeat the test on the 6 least significant remaining bits.
    if (goodMask << x >= 0 | x <= 0) return x == 0;
    // Do it in the classical way.
    // The correctness is not trivial as the conversion from long to double is lossy!
    final long tst = (long) Math.sqrt(x);
    return tst * tst == x;
}

стоило бы проверить, как опустить первый тест,

if (goodMask << x >= 0) return false;

будет влиять на производительность.

вы должны избавиться от 2-power части N с самого начала.

2-е изд Магическое выражение для m ниже должно быть

m = N - (N & (N-1));

а не как написано

конец 2-го редактирования

m = N & (N-1); // the lawest bit of N
N /= m;
byte = N & 0x0F;
if ((m % 2) || (byte !=1 && byte !=9))
  return false;

1-я правка:

незначительное улучшение:

m = N & (N-1); // the lawest bit of N
N /= m;
if ((m % 2) || (N & 0x07 != 1))
  return false;

конец 1-го редактирования

теперь продолжайте, как обычно. Таким образом, когда вы доберетесь до плавающей точкой часть, вы уже избавились от всех чисел, чья 2-силовая часть нечетна (около половины), а затем вы рассматриваете только 1/8 того, что осталось. Т. е. вы запускаете часть с плавающей запятой на 6% чисел.

это переделка из десятичного в двоичный старого алгоритма калькулятора Марчанта (извините, у меня нет ссылки), в Ruby, адаптированная специально для этого вопроса:

def isexactsqrt(v)
    value = v.abs
    residue = value
    root = 0
    onebit = 1
    onebit <<= 8 while (onebit < residue)
    onebit >>= 2 while (onebit > residue)
    while (onebit > 0)
        x = root + onebit
        if (residue >= x) then
            residue -= x
            root = x + onebit
        end
        root >>= 1
        onebit >>= 2
    end
    return (residue == 0)
end

вот работа чего - то подобного (пожалуйста, не голосуйте за стиль/запахи кодирования или неуклюжий O/O-это алгоритм, который считается, и C++ не является моим родным языком). В этом случае, мы ищем остаток == 0:

#include <iostream>  

using namespace std;  
typedef unsigned long long int llint;

class ISqrt {           // Integer Square Root
    llint value;        // Integer whose square root is required
    llint root;         // Result: floor(sqrt(value))
    llint residue;      // Result: value-root*root
    llint onebit, x;    // Working bit, working value

public:

    ISqrt(llint v = 2) {    // Constructor
        Root(v);            // Take the root 
    };

    llint Root(llint r) {   // Resets and calculates new square root
        value = r;          // Store input
        residue = value;    // Initialise for subtracting down
        root = 0;           // Clear root accumulator

        onebit = 1;                 // Calculate start value of counter
        onebit <<= (8*sizeof(llint)-2);         // Set up counter bit as greatest odd power of 2 
        while (onebit > residue) {onebit >>= 2; };  // Shift down until just < value

        while (onebit > 0) {
            x = root ^ onebit;          // Will check root+1bit (root bit corresponding to onebit is always zero)
            if (residue >= x) {         // Room to subtract?
                residue -= x;           // Yes - deduct from residue
                root = x + onebit;      // and step root
            };
            root >>= 1;
            onebit >>= 2;
        };
        return root;                    
    };
    llint Residue() {           // Returns residue from last calculation
        return residue;                 
    };
};

int main() {
    llint big, i, q, r, v, delta;
    big = 0; big = (big-1);         // Kludge for "big number"
    ISqrt b;                            // Make q sqrt generator
    for ( i = big; i > 0 ; i /= 7 ) {   // for several numbers
        q = b.Root(i);                  // Get the square root
        r = b.Residue();                // Get the residue
        v = q*q+r;                      // Recalc original value
        delta = v-i;                    // And diff, hopefully 0
        cout << i << ": " << q << " ++ " << r << " V: " << v << " Delta: " << delta << "\n";
    };
    return 0;
};

вызов sqrt не совсем точен, как уже упоминалось, но интересно и поучительно, что он не сдувает другие ответы с точки зрения скорости. В конце концов, последовательность инструкций языка ассемблера для sqrt крошечная. Intel имеет аппаратную инструкцию, которая не используется Java, я считаю, потому что она не соответствует IEEE.

Так почему же он медленный? Потому что Java фактически вызывает процедуру C через JNI, и на самом деле это медленнее, чем вызывать подпрограмма Java, которая сама по себе медленнее, чем выполнение ее inline. Это очень раздражает, и Java должна была придумать лучшее решение, т. е. при необходимости создавать вызовы библиотеки с плавающей запятой. Ну что ж.

в C++ я подозреваю, что все сложные альтернативы потеряют скорость, но я не проверил их все. То, что я сделал, и то, что люди Java найдут полезным, - это простой хак, расширение специального тестирования, предложенного A. Rex. Использовать одно длинное значение в качестве битового массива, который не проверен. Таким образом, у вас есть 64-битный логический поиск.

typedef unsigned long long UVLONG
UVLONG pp1,pp2;

void init2() {
  for (int i = 0; i < 64; i++) {
    for (int j = 0; j < 64; j++)
      if (isPerfectSquare(i * 64 + j)) {
    pp1 |= (1 << j);
    pp2 |= (1 << i);
    break;
      }
   }
   cout << "pp1=" << pp1 << "," << pp2 << "\n";  
}


inline bool isPerfectSquare5(UVLONG x) {
  return pp1 & (1 << (x & 0x3F)) ? isPerfectSquare(x) : false;
}

рутинную isPerfectSquare5 работает в около 1/3 времени сердечником2 машина дуэта. Я подозреваю, что дальнейшие настройки по тем же линиям могут сократить время в среднем дальше, но каждый раз, когда вы проверяете, Вы меняете больше тестирования на большее устранение, поэтому вы не можете идти слишком далеко по этой дороге.

конечно, вместо того, чтобы иметь отдельный тест отрицательный, можно проверить высокие 6 бит таким же образом.

обратите внимание, что все, что я делаю, это устранение возможных квадратов, но когда у меня есть потенциальный случай, я должен вызвать исходный, встроенный isPerfectSquare.

процедура init2 вызывается один раз для инициализации статических значений pp1 и pp2. Обратите внимание, что в моей реализации на C++ я использую unsigned long long, поэтому, поскольку вы подписаны, вам придется использовать оператор>>>.

нет внутренней необходимости ограничивать проверку массива, но Java оптимизатор должен разобраться в этом довольно быстро, поэтому я не виню их за это.

проект Эйлер упоминается в тегах, и многие из проблем в нем требуют проверки чисел >> 2^64. Большинство оптимизаций, упомянутых выше, не работают легко, когда вы работаете с 80-байтовым буфером.

Я использовал java BigInteger и слегка модифицированную версию метода Ньютона, которая лучше работает с целыми числами. Проблема заключалась в том, что точные квадраты n^2 сходились к (n-1) вместо n, потому что n^2-1 = (n-1) (n+1), а конечная ошибка была всего на один шаг ниже окончательный делитель и алгоритм завершается. Это было легко исправить, добавив один к исходному аргументу перед вычислением ошибки. (Добавьте два для кубических корней и т. д.)

одним из приятных атрибутов этого алгоритма является то, что вы можете сразу сказать, является ли число идеальным квадратом - конечная ошибка (не коррекция) в методе Ньютона будет равна нулю. Простая модификация также позволяет быстро вычислить floor(sqrt (x)) вместо ближайшего целого числа. Это удобно с несколькими Euler проблемы.

мне нравится идея использовать почти правильный способ на некоторых входных данных. Вот версия с более высоким "смещением". Код, кажется, работает и проходит мой простой тестовый случай.

просто заменить:

if(n < 410881L){...}

код с этим:

if (n < 11043908100L) {
    //John Carmack hack, converted to Java.
    // See: http://www.codemaestro.com/reviews/9
    int i;
    float x2, y;

    x2 = n * 0.5F;
    y = n;
    i = Float.floatToRawIntBits(y);
    //using the magic number from 
    //http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf
    //since it more accurate
    i = 0x5f375a86 - (i >> 1);
    y = Float.intBitsToFloat(i);
    y = y * (1.5F - (x2 * y * y));
    y = y * (1.5F - (x2 * y * y)); //Newton iteration, more accurate

    sqrt = Math.round(1.0F / y);
} else {
    //Carmack hack gives incorrect answer for n >= 11043908100.
    sqrt = (long) Math.sqrt(n);
}

Я проверил все возможные результаты, когда последние n бит квадрата наблюдается. Путем последовательно рассматривать больше битов, до 5/6th входных сигналов можно исключить. Я фактически разработал это для реализации алгоритма факторизации ферма, и он очень быстрый.

public static boolean isSquare(final long val) {
   if ((val & 2) == 2 || (val & 7) == 5) {
     return false;
   }
   if ((val & 11) == 8 || (val & 31) == 20) {
     return false;
   }

   if ((val & 47) == 32 || (val & 127) == 80) {
     return false;
   }

   if ((val & 191) == 128 || (val & 511) == 320) {
     return false;
   }

   // if((val & a == b) || (val & c == d){
   //   return false;
   // }

   if (!modSq[(int) (val % modSq.length)]) {
        return false;
   }

   final long root = (long) Math.sqrt(val);
   return root * root == val;
}

последний бит псевдокода можно использовать для расширения тестов, чтобы исключить больше значений. Вышеперечисленные тесты для k = 0, 1, 2, 3

учитывая общую длину бита (хотя я использовал конкретный тип здесь), я попытался создать упрощенный algo, как показано ниже. Простая и очевидная проверка для 0,1,2 или

int main()
{
    unsigned int c1=0 ,c2 = 0;  
    unsigned int x = 0;  
    unsigned int p = 0;  
    int k1 = 0;  
    scanf("%d",&p);  
    if(p % 2 == 0) {  
        x = p/2; 
    }  
    else {  
        x = (p/2) +1;  
    }  
    while(x) 
    {
        if((x*x) > p) {  
            c1 = x;  
            x = x/2; 
        }else {  
            c2 = x;  
            break;  
        }  
    }  
    if((p%2) != 0)  
        c2++;

    while(c2 < c1) 
    {  
        if((c2 * c2 ) == p) {  
            k1 = 1;  
            break;  
        }  
        c2++; 
    }  
    if(k1)  
        printf("\n Perfect square for %d", c2);  
    else  
        printf("\n Not perfect but nearest to :%d :", c2);  
    return 0;  
}  

Если скорость вызывает беспокойство, почему бы не разделить наиболее часто используемый набор входов и их значений в таблицу поиска, а затем сделать любой оптимизированный магический алгоритм, который вы придумали для исключительных случаев?

должно быть возможно упаковать "не может быть идеальным квадратом, если последние X цифр N" намного эффективнее, чем это! Я буду использовать java 32-битные ints и производить достаточно данных, чтобы проверить последние 16 бит числа - это 2048 шестнадцатеричных значений int.

...

Ok. Либо я столкнулся с какой-то теорией чисел, которая немного выше меня, либо в моем коде есть ошибка. В любом случае, вот код:

public static void main(String[] args) {
    final int BITS = 16;

    BitSet foo = new BitSet();

    for(int i = 0; i< (1<<BITS); i++) {
        int sq = (i*i);
        sq = sq & ((1<<BITS)-1);
        foo.set(sq);
    }

    System.out.println("int[] mayBeASquare = {");

    for(int i = 0; i< 1<<(BITS-5); i++) {
        int kk = 0;
        for(int j = 0; j<32; j++) {
            if(foo.get((i << 5) | j)) {
                kk |= 1<<j;
            }
        }
        System.out.print("0x" + Integer.toHexString(kk) + ", ");
        if(i%8 == 7) System.out.println();
    }
    System.out.println("};");
}

и вот результаты:

(ed: elided для плохой работы в prettify.js; просмотр истории ревизий для просмотра.)

вот самый простой и краткий способ, хотя я не знаю, как он сравнивается с точки зрения циклов процессора. Это отлично работает, если вы только хотите знать, если корень-целое число. Если вам действительно интересно, если это целое число, вы также можете понять это. Вот простая (и чистая) функция:

public static boolean isRootWhole(double number) {
    return Math.sqrt(number) % 1 == 0;
}

Если вам не нужна микро-оптимизация, этот ответ лучше с точки зрения простоты и ремонтопригодности. Если вы будете получать отрицательные числа, возможно, вы захотите используйте математику.abs () о аргументе числа как Математике.функция sqrt (аргумент).

на моем процессоре Intel i7-4790 3,6 ГГц запуск этого алгоритма на 0-10,000,000 занял в среднем 35-37 наносекунд на расчет. Я сделал 10 последовательных запусков, печатая среднее время, затраченное на каждый из десяти миллионов вычислений sqrt. Каждый суммарный пробег занял чуть более 600 мс.

Если вы выполняете меньшее количество вычислений, более ранние вычисления занимают немного длиннее.

Если вы хотите скорость, учитывая, что ваши целые числа имеют конечный размер, я подозреваю, что самый быстрый способ будет включать (a) разбиение параметров по размеру (например, на категории по наибольшему набору битов), а затем проверку значения на массив совершенных квадратов в этом диапазоне.

Что касается метода Кармака, кажется, что было бы довольно легко просто повторить еще раз, что должно удвоить количество цифр точности. В конце концов, это чрезвычайно усеченный итерационный метод-метод Ньютона с очень хорошей первой догадкой.

Что касается вашего текущего лучшего, я вижу две микро-оптимизации:

• переместите чек против 0 после проверки с помощью mod255
• переставьте разделительные полномочия четырех, чтобы пропустить все проверки для обычный (75%) случае.

то есть:

// Divide out powers of 4 using binary search

if((n & 0x3L) == 0) {
  n >>=2;

  if((n & 0xffffffffL) == 0)
    n >>= 32;
  if((n & 0xffffL) == 0)
      n >>= 16;
  if((n & 0xffL) == 0)
      n >>= 8;
  if((n & 0xfL) == 0)
      n >>= 4;
  if((n & 0x3L) == 0)
      n >>= 2;
}

еще лучше может быть простой

while ((n & 0x03L) == 0) n >>= 2;

очевидно, было бы интересно узнать, сколько номеров отбирается на каждом контрольно-пропускном пункте-я скорее сомневаюсь, что проверки действительно независимы, что делает вещи сложными.

" Я ищу самый быстрый способ определить, является ли длинное значение идеальным квадратом (т. е. его квадратный корень-другое целое число)."

ответы впечатляют, но я не смог увидеть простой чек:

проверьте, является ли первое число справа от длинного его членом множества (0,1,4,5,6,9). Если это не так, то он не может быть 'лучше' .

например.

4567 - не может быть идеальный квадрат.

Не уверен, что это самый быстрый способ, но это то, на что я наткнулся (давно в средней школе), когда мне было скучно и я играл с калькулятором во время урока математики. В то время я был очень удивлен, что это сработало...

public static boolean isIntRoot(int number) {
    return isIntRootHelper(number, 1);
}

private static boolean isIntRootHelper(int number, int index) {
    if (number == index) {
        return true;
    }
    if (number < index) {
        return false;
    }
    else {
        return isIntRootHelper(number - 2 * index, index + 1);
    }
}

Не знаю о самом быстром, но самый простой-взять квадратный корень обычным способом, умножить результат на себя и посмотреть, соответствует ли он вашему исходному значению.

поскольку мы говорим о целых числах здесь, голодание, вероятно, будет включать в себя коллекцию, где вы можете просто сделать поиск.