Наилучшая производительность алгоритма в уравнении многих значений

С учетом сказанного ваша общая идея верна. Вопрос в том, может ли он теперь быть оптимизирован каким-то образом?

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

if(x > cxy[z][0] && x < (cxy[z][0]+sensivity) && y > cxy[z][1] && y < (cxy[z][1]+sensivity))

Итак, что это для вас делает: эта оптимизация позволяет вам сохранить общий объем данных, но избавиться от 2 математических операций за проверку. Учитывая, что ваши входные параметры являются плавающими точками, это может сэкономить немало времени.

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

дальнейшая оптимизация теперь может быть, если вы захотите потратить больше ОЗУ для повышения производительности, вы можете вместо 1 точки на регион, у вас может быть верхняя левая и нижняя правая точки для каждого региона. Это заставит ваш оператор if выглядеть примерно так:

if(x > tlxy[z][0] && x < brxy[z][0] && y > tlxy[z][1] && y < brxy[z][1])

where tlxy is the array of top-left points, brxy is the array of bottom-right points
and z is still the "region" you are checking against

Как это помогает: как вы можете видеть в приведенном выше примере if, это теперь абсолютно не имеет явных математических операций. Чтобы поддержать этот алгоритм, вы должны быть готовы потратить в 2 раза больше памяти, чем исходный массив cxy.

Теперь в вашем цикле вы проходите ВСЕ 24 региона. Если вы ЗНАЕТЕ В ОТНОШЕНИИ ОТНОШЕНИЙ, что ни одна из ваших областей не перекрывается, тогда точка может действительно только упасть в 1 регионе за раз. Вы можете сэкономить некоторое время на большинстве входных точек xy, вырвавшись из цикла for в точке, где вы также увеличиваете точки. Это выглядит следующим образом:

public void checkCoordinate(float x, float y){
    for(int z = 0; z < 24; z++){
        if(x > tlxy[z][0] && x < brxy[z][0] && y > tlxy[z][1] && y < brxy[z][1]){
            points += 1; 
            break;
        }
    }
}

Вышесказанное будет ТОЛЬКО РАБОТАТЬ IFF, который вы знаете наверняка, что нет перекрывающихся областей (даже не краев.

По окончательной оптимизации, я вижу, может иметь потенциал. В зависимости от того, как выглядят ваши регионы, вы можете предварительно разделить все регионы на квадранты. Таким образом, вы можете проверить точку x на левой или правой стороне экрана, а затем проверить, что y-точка находится в верхней или нижней части. Если распределение ваших регионов довольно ровное, это может иметь потенциал сократить время тестирования на 4, так как вам не нужно будет тестировать только регионы в квадранте (если это статистическое распределение - это то, что я сказал). В худшем случае все регионы лежат в одном квадранте, и все точки, которые вы тестируете, находятся в этом квадранте, и в этом случае проблема с точки зрения сложности не хуже, чем раньше. Он просто добавляет тест установки на ваш вход x и y.

Надеюсь, это даст вам достаточно информации, по крайней мере, на вашем пути!