Алгоритм сравнения множеств?

А само сравнение, то как должно происходить для каждого "х" со значение "y" найти идеентичное "y" на ЛЮБОЙ точке "х" других графиков?

Therapyx: Ну мы сравниваем множества одинакового размера, поэтому x везде одинаковые - это просто порядковый номер, от 0 до 100 например. Т.е. мы сравниваем x[0] у всех множеств, потом x[1] у мех множеств, множества у которых совпали Y у всех Х это абсолютно одинаковые, равные друг другу множества. А если x[0] != x[0] в другом множестве то надо куда-то записать величину разности, т.к. например x[0] = 599 и x[0] = 600 очень похожи, если макс. значение 650 а вот x[0] = 5 x[0] = 10 очень не похожи если максимальное значение всего 10. Но заранее минимальное значение Y известно это 0, а вот максимальное не известно.

kot-samolet: чего? Ты вообще определение множества знаешь?

kot-samolet: ну а в чем проблема тогда просто перебирать обычным линейным поиском? Ибо тут надо же все комбинации проверять, это не бинарный поиск в сортированном массиве.
А при поиске просто задавать нужные коеффициенты разницы в %. Проблема тут в том, что тебе надо найти "все" возможные совпадения, а не остановится на одном.
График можно представить как тот же map, где ключ это время, а величина это значение, а дальше сделать (массив, вектор, эррейлист) этих map'ov итерируя друг с другом.
Или ты ищешь какие-то специфические методы или библиотеки для такой задачи?

Денис Загаевский: неудивительно что Яндекс так деградировал в последнее время )))

Therapyx: нет я именно ищу алгоритмы и любые методы, напишу сам, библиотеки не нужны. Меня интересует только одно: есть ли классическое решение, классический алгоритм (как например расстояние левенштейна при поиске похожих слов) а то я буду писать свой велик а потом окажется что он не оптимальный и всё уже придумано до нас (скорее всего в данном случае так и есть, т.к. задача распространённая)

kot-samolet: понимаешь, в этой ситуации прямая взаимосвязь (NxM) или по другому O(n^2), и если обычно алгоритмы можно оптимировать на какой-нибудь O(log(N)), то тут никак. Тебе нужны "ВСЕ" возможные комбинации.
Можно конечно схитрить конечно, но это опять же "предработа". Например как я уже и говорил разложить каждый х и y как пару, и отсортировать ее по value. И только тогда, когда они будут все отсортированны - то можно будет использовать например индексацию, бинарное дерево. Что конечно же сократит время поиска. Только вот поиск будет происходить не х(1) для всех х(y), а рандомно х(100), х(352), х(2).. Но такой подход все равно проверит все возможные комбинации ))
Надеюсь понятно выразился, а то сижу с полузакрытыми глазами уже.

И да, на сколько огромное кол-во данных с этих графиков?

Therapyx: спасибо, надо попробовать, смотря для чего применять )) Есть области где немного, а есть области где в одном графике 620 элементов и таких графиков миллионы

kot-samolet: тут много нюансов может быть. Мы ж тут не видим всех данных. А эт дело такое... на словах наилучший вариант не выбрать )
То из того, что ты привел в пример, вот и первое, что пришло в голову. Но опять же. Нюансы по типу, ищутся ли сначала первые 100, а потом добавляются еще 100 и надо сравнивать их всех, или после каждого поиска они уже становятся не нужными и удаляются, или или или... И от таких факторов и будут делать выводы в пользу того или иного подхода )
Но это так, может и вправду для таких задач есть свои специальные алгоритмы. Если проблема или сама задача довольно распространенная, то навернка что-то уже более оптимально придумали ))