Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Теперь у меня задачка. Нужно сделать эффективную сортировку массивов с большой "стоимостью" копирования элементов (т.е. элементы которого - объёмистые, "тяжелые" структуры, объекты классов, длинные строки и т.п.). Здравый смысл подсказывает, что нужно оставлять их на месте, а сортировать вместо них своего рода указатели - индексы ячеек их оригинального расположения. Далее цитата отсюда :https://www.mql5.com/ru/forum/6476#comment_178318Оставим пока уважаемых разработчиков терминала с их многочисленными текущими задачами, и реализуем это на mql5.
Всё уже украдено до нас :)
Электронные таблицы на MQL5
на вход нужно подавать копию сортируемого массива, коментарии раскоментировать, ненужное закоментировать
Всё уже украдено до нас :)
Электронные таблицы на MQL5
на вход нужно подавать копию сортируемого массива, коментарии раскоментировать, ненужное закоментировать
Злой ты! Песню испортил... Вернее - попытался. :)
// Понятно, что есть хорошие приближения. Я с тем же успехом мог из стандартной библиотеки вытащить образец. :)
Образцы есть. И даже замечательные. И всё же. Тут важно всё прописать и отладить до рабочего состояния отдельного юзабельного продукта. Притом (почему это посылаю сюда) - максимально скорострельного. Т.е. предлагаю выжать всё возможное быстродействие до сотых долей процента включительно. :)
Это первое. Второе - для объектов напрашивается количество индексных массивов равное количеству критериев сортировки, которых может быть в общем случае несколько, + (желательно) функция вставки в отсортированный по нескольким критериям проиндексированный массив.
Злой ты! Песню испортил... Вернее - попытался. :)
// Понятно, что есть хорошие приближения. Я с тем же успехом мог из стандартной библиотеки вытащить образец. :)
Образцы есть. И даже замечательные. И всё же. Тут важно всё прописать и отладить до рабочего состояния отдельного юзабельного продукта. Притом (почему это посылаю сюда) - максимально скорострельного. Т.е. предлагаю выжать всё возможное быстродействие до сотых долей процента включительно. :)
Это первое. Второе - для объектов напрашивается количество индексных массивов равное количеству критериев сортировки, которых может быть в общем случае несколько, + (желательно) функция вставки в отсортированный по нескольким критериям проиндексированный массив.
Всё тот же ответ Электронные таблицы на MQL5
там всё это есть. Токма таблицу набок поверни. ну под конкретную задачу можно переделать под манипулирование не столбцов а строк, там сделаны столбцы для того чтоб можно было объявить их разными типами. Если тип таблицы один то всё можно переиграть.
Сделал инклюдник с сортировкой индексов для базовых типов.
Сортировка по умолчанию "по убыванию", для сортировки по возрастанию нужно установить флаг направления сортировки в false.
Результаты теста: // индексирование массивов double[], int[], string[]; Последовательно : сырой массив, по убыванию, по возрастанию
Библиотека и тест в прицепе.
Инклюдник положить в папку "MQL5\Include\Indexes\"
Вот, заготовка класса для работы с OCL. Кое что конечно не доделано и коряво, но может кому нибудь пригодится.
ЗЫ Чуток переделал инициализацию, теперь можно запускать многомерные расчеты.
Отличная тема!
Как раз сейчас столкнулся с оптимизационной проблемой алгоритма поиска ценового экстремума (минимума). Условия такие, есть бар, n баров слева и справа от которого ниже (выше) его максимума:
n - свободная произвольно выбираемая величина. Период n всегда нечетный, так как сумма двух отрезков справа и слева всегда будет четным числом, к которому прибавляется центральный бар собственно ценового экстермума.
Над первой версией алгоритма я особенно не задумывался и написал самый очевидный код. Сейчас я пишу на C# в рамках платформы WealthLab, но думаю вы без труда сможете понять суть проблемного алгоритма, вот его самая проблемная часть:
Вся проблема во втором цикле. Он одновременно обрабатывает левую и правую ветки от потенциального экстремума, а потому перебирает лишь (N - 1)/2 баров, но этого не достаточно. Иземерения показывают, что время затраченное на поиск экстремума в арифметической прогрессии зависит от периода N, а это очень, очень плохо:
Перебор периодов будет занимать по времени сумму арифметической прогрессии, а это очень большая величина.
Одно из возможных решений, это ввести доп. переменную. Ведь если экстремум обнаружен, то справа от него гарантированно нет ни одного бара на протяжении (N - 1)/2, значит поиск нового экстремума можно начинать с бара: current_bar + (N - 1)/2. Но вместе с экстремумами требуется найти и минимумы, а новый минимум может быть обнаружен до бара current_bar + (N - 1)/2. Поэтому потребуется разделить поиск экстремумов и минимумов на два прохода, что сведет на нет, выигрышь в производительности. На C# без проблем можно разделить два прохода на два потока обрабатываемых одновременно на двух ядрах, но хотелось бы в первую очередь найти оптимальный алгоритм и уже оптимизировать его. Жду помощи знатоков.
Ну это не оптимизационная проблема.
Перебор периодов будет занимать по времени сумму арифметической прогрессии, а это очень большая величина.
Поиск экстремума - вроде проблема порядка О(n), где n - число данных. Как можно сделать эту асимптотику хуже, т.е. O(n^2) - даже не представляю. Или ты путаешься в терминах.
Простейший алгоритм - сортировка ArraySort(), встроенная достаточно быстра, что-то в районе O(n * ln( n ) ). Но она, вероятно, избыточна для этой задачи.
Можно придумать что-нибудь рекурсивное, которое будет быстрее.
Сколько времени у тебя ищется минимум и для какого кoличества барoв? Ну не верю, что на 100 барах ты ищещшь максимум полторы секунды.
Простейший алгоритм - сортировка ArraySort(), встроенная достаточно быстра. Но она, вероятно, избыточна для этой задачи.
Лучшая сортировка -- O(n*log(n)). Точно избыточна.
Можно придумать что-нибудь рекурсивное, которое будет быстрее.
Медленнее. Рекурсия чаще всего зло. Рекуррентное? Тут наверное тот случай, когда как ни делай, скорость будет примерно одинаковой.
По коду:
Циклы по мин и макс надо однозначно разделять. И выходить из цикла сразу при невыполнении.
В принципе да. Но все равно не больше О(n).
OCL тут поможет. Асимптотика останется такой же, конечно. Но скорость вполне можно в сотню раз увеличить.