Руслан .

Есть вот такой вариант, но он наверное слишком мощный для вас:
https://tech.yandex.ru/speller/

Вот тут интересная статья про трансформацию слов:
https://habr.com/ru/post/270845/
Возможно вам подойдет "Функция оценки похожести пары слов"

Это сложная задача, решение которой еще и от контекста в котором употребляется слово зависит.
Посмотрите вот эту ссылку для примера:
https://ru.wikipedia.org/wiki/%D0%9E%D0%BC%D0%BE%D...

Посмотрите вот эту статью:
https://habr.com/ru/post/281495/

Там в комментариях много интересных ссылок, например эта:
journal.stuffwithstuff.com/2011/03/19/pratt-parser...

Судя по нарисованному графу, тут есть два варианта пути:
1. х1-х2-х5
2. х1-х3-х4-х5
Из этих двух нужно выбрать меньший.

Ребро х2-х3 нужно исключить, т.к. в треугольнике х1-х2-х3 всегда выгоднее выбирать одну из сторон х1-х3 или
х1-х2, чем две стороны (х1-х2 + х2-х3 или х1-х3 + х3-х2).

Зная это, простым сложением по вашей таблице легко найти ответ.

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

Если я правильно понял, возможно вам вот это подойдет:
https://habr.com/post/314218/

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

Потому что если подставить в формулу N >= 10, то значение 2^N больше N^3.

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

В офф доке описано про поддержку gpu.
Подробнее можно вот тут изучить:
https://xgboost.readthedocs.io/en/latest/gpu/index.html

Можно попробовать генерировать GUID и брать нужное количество цифр с конца.
Если верить GIT, то последние 6 знаков в хэше коммита почти никогда не повторяются.

В Win есть АПИ, например это:
https://msdn.microsoft.com/ru-ru/library/windows/d...

Многие БД, если их планируете использовать из коробки умеют генерировтать GUID.

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

Для поиска наиболее удаленных точек, можно по координатам точек образующих контур вычислить геометрический центр масс фигуры и затем найти точки контура наиболее удаленные от нет по формуле Евклида.
Далее для каждой найденной точки строим луч из текущей точки через геометрический центр масс и ищем точку пересечения этого луча с контуром.
Исходная точка контура и найденная путем трассировки луча образуют отрезок, нужно найти и запомнить длину отрезка.
После этого имеем массив отрезков с длина, нужно выбрать самый длинный (или один из самых длинных, если есть несколько равных по длине).
Найденный отрезок и будет проходить через наиболее удаленные точки контура и перпендикулярно ему нужно строить линии разметки.

Я бы вначале отсортировал массив чисел по возрастанию.

Зачем для каждого элемента массива проверил бы, а нет ли в массиве числа большего чем данное (для этого сортировал массив, чтобы не перебирать каждый раз все элементы массива - это экономит время), которое делиться на данное, и если такое число есть, то текущее выбрасываем, т. к. оно уже входит в состав большего числа.
(Например в приведенном массиве есть число 3 и есть число 300, 3 можно выкинуть, т.к. 300 делится на 3.)

Зачем оставшиеся числа перемножаем (исключая дубли, если они будут).
(это позволит уменьшить количество чисел и тем самым избежать переполнения типа unsigned long на длинных массивах)

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

Например: есть число 100500 = 2*2*3*5*5*5*67, тогда словарь будет такой
{2: 2, 3: 1, 5: 3, 67:1}

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

А ключи отсортированы?
Десятки минут даже для Excel как-то медленно.
Это как будто для каждого ключа одного файла пробегать все ключи другого.
Если взять два отсортированных списка и пройтись по ним, то недостающие ключи можно за один проход найти - это секунды для 100000 записей.

Все зависит от точности, которую вы хотите получить.
Скорее всего вам нужно учитывать не только удаленность от дорог, но и загруженность дороги, т.е. условно есть МКАД от которого лучше жить километрах в 7 или маленькая дорога на въезде в микрорайон для которой и 50 м нормальное удаление. Также если на определенных участках дорог периодически случаются мощные пробки, то влияние такой дороги будет намного сильнее чем у просто загруженной магистрали.

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

Я бы попробовал так:
Если сравнить дорогу с проводником тока и загруженность дороги сравнить с силой тока, то можно попробовать воспользоваться вот этими формулами:
https://www.chem-astu.ru/chair/study/physics-part2...
Нужно только подобрать коэффициенты формулы исходя из условий вашей задачи.

Условную силу тока определять из указанных выше факторов.