Эффективность обнаружения палиндрома
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
7 ответов
Учитывая только один палиндром, необходимо будет сделать это в O (N), да. Можно получить больше эффективности с многопроцессорными системами путем разделения строки, как Вы сказали.
Теперь говорят, что Вы хотите сделать точное соответствие DNA. Эти строки являются тысячами символов в длину, и они являются очень повторяющимися. Это дает нам возможность оптимизировать.
Говорят, что Вы разделяете длинную строку с 1000 символами на 5 пар 100 100. Код будет похож на это:
isPal(w[0:100],w[-100:]) and isPail(w[101:200], w[-200:-100]) ...
и т.д... В первый раз, когда Вы делаете эти соответствия, необходимо будет обработать их. Однако можно добавить все результаты, которые Вы сделали в хеш-таблицу, отображающую пар на булевские переменные:
isPal = {("ATTAGC", "CGATTA"): True, ("ATTGCA", "CAGTAA"): False}
и т.д.... это возьмет слишком много памяти, все же. Для пар 100 100, карта хеша будет иметь 2*4^100 элементы. Скажите, что Вы только храните два 32-разрядных хеша строк как ключ, Вам будет нужно что-то как 10^55 мегабайты, который смешон.
, Возможно, при использовании меньших строк проблема может быть послушной. Затем у Вас будет огромный hashmap, но по крайней мере палиндром для скажем, 10x10 пары возьмут O (1), таким образом проверяя, являются ли 1 000 строк палиндромом, возьмет 100 поисков вместо 500, выдерживает сравнение. Это все еще O (N), хотя...
Очевидно, Вы не собираетесь быть способными поправиться, чем O (n) асимптотическая эффективность, так как каждый символ должен быть исследован, по крайней мере, однажды. Можно получить лучшие мультипликативные константы, все же.
Для единственного потока, можно получить ускорение с помощью блока. Можно также добиться большего успеха путем исследования данных в блоках, больше, чем байт за один раз, но это может быть хитро из-за соображений выравнивания. Вы сделаете еще лучше для использования SIMD, если можно исследовать блоки, столь же большие как 16 байтов за один раз.
, Если Вы хотели параллелизировать его, Вы могли бы разделить строку на части N и иметь процессор i, сравнивают сегмент [i*n/2, (i+1)*N/2) с сегментом [L-(i+1)*N/2, L-i*N/2).
Нет, если Вы не делаете нечеткое соответствие. Который является тем, что они, вероятно, делают в DNA (я сделал EST , ищущий в DNA с кузнецом-лодочником, но это, очевидно, намного тяжелее затем соответствует для палиндрома или обратного дополнения в последовательности).
Они находятся оба в O (N), таким образом, я не думаю, что существует какая-то конкретная проблема эффективности с любым из этих решений. Возможно, я не являюсь достаточно творческим, но я не вижу, как было бы возможно сравнить элементы N на меньше, чем шагах N, таким образом, что-то как O (регистрируют N) определенно не возможно, по моему скромному мнению.
Pararellism мог бы помочь, но он все еще не изменит большой о разряд алгоритма, так как это эквивалентно выполнению его на более быстрой машине.
С Python короткий код может быть быстрее, так как он создает нагрузку в более быстрые внутренности VM (И существует целый кэш и другие такие вещи)
def ispalin(x):
return all(x[a]==x[-a-1] for a in xrange(len(x)>>1))
Another variant of your second function. We need no check equals of the right parts of normal and reverse strings.
def palindrome_reverse(s):
l = len(s) / 2
return s[:l] == s[l::-1]
Сравнение из центра всегда намного эффективнее, так как вы можете быстро выйти из строя при промахе, но оно всегда позволяет вам выполнять более быстрый поиск максимального палиндрома, независимо от того, ищете ли вы максимальный радиус или все неперекрывающиеся палиндромы.
Единственная реальная параллелизация - это если у вас есть несколько независимых строк для обработки. Разделение на куски будет тратить много времени на каждый промах, и промахов всегда намного больше, чем попаданий.