Need help! Не решается задача, упираюсь в ограничения железа - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У нас в памяти фрагмент файла, идём по нему и формируем выборку нужной для расчёта критерия длины, отбирая только сделки, принадлежащие к той же последовательности. Затем по этой выборке рассчитываем критерий. Кстати, возможности для использования рекурсии при отборе по идее есть.
Или я не понял вопрос?
P.S. Конечно по файлу при формировании выборки нужно назад идти.
У нас в памяти фрагмент файла, идём по нему и формируем выборку нужной для расчёта критерия длины, отбирая только сделки, принадлежащие к той же последовательности. Затем по этой выборке рассчитываем критерий. Кстати, возможности для использования рекурсии при отборе по идее есть.
Или я не понял вопрос?
P.S. Конечно по файлу при формировании выборки нужно назад идти.
проблема со вставкой новых данных - решите ее хоть как-то.
зачем много раз проходить и выбирать белые носки, если проще идти и разбрасывать белые в одну корзину черные в другую, а потом поинтересоваться кто там и в каком количестве.
Читается кусок. Размер куска определяется кол-вом сделок до ИскомойДаты, которые были в конкретной последовательности.
проблема со вставкой новых данных - решите ее хоть как-то.
зачем много раз проходить и выбирать белые носки, если проще идти и разбрасывать белые в одну корзину черные в другую, а потом поинтересоваться кто там и в каком количестве.
Слишком много данных тоже плохо :)
Проблема в том, что здесь отбираются не белые и черные, а те, что локально побелее. Поэтому расчёт глобальной степени черноты не спасает. Я кстати, начинал в этой ветке как раз с предложения сплошного расчёта критерия.
P.S. Кстати, никто не мешает обрабатывать несколько файлов совместно - просто кэш для каждого придётся меньше делать. Но по размеру кэша запас кажется есть.
То есть новые данные можно просто в другом файле накапливать.
P.P.S. Кстати, нарезание файла на несколько поменьше проблему сортировки облегчит.
1. Если бы Критерий был статичным... А если его параметры меняются?
2. Да, потом будет торговля. Но пересчет нужен будет только для самых свежих данных, всю историю колбасить не надо.
3. Это один инструмент...
4. Именно.
1. Исходя из выше сказанного "Критерием пусть будет средняя прибыль за последние 20 сделок последовательности.", это надо понимать один критерий, скользящее мат.ожидание прибыли. Какие есть еще?
В БД генерировать таблицу с идентификатором последовательности и соответствующими скользящими средними. Не подходящие под условия последовательности удалить сразу. Это делаться должно процедурой в concurrent режиме на уровне СУБД, по запросу от робота, с отображением статуса процесса в роботе.
Скажем так, процедра FilterAvgProfit (pProfitValue, pTrades, pDeviation),
где pProfitValue - желаемый профит, pTrades - кол-во сделок для скользящего среднего профита, pDeviation - допустимое отклонение от pProfitValue.
Результат - заполненная таблица с ID последовательностей и средние значения профита.
Аналогично можно написать хранимые процедуры для каждого из критериев.
2. Если частично данные откинуть (использовать "свежие данные", а не 1млн) это даст прирост производительности.
3. Из постановки было не совсем ясно. Теперь ок.
4. Я так понимаю, если смотреть в сторону подбора стратегии, то данная операция не должна выполняться слишком часто (скажем на каждом баре или непосредственно перед открытием ордера). Разумно использовать такой подход в случае если текущая стратегия приносит N убыточных сделок подряд - тогда можно выбрать другую, и придется потратить время на "вынос решения", тут никуда не деться. Или же, выполнять такой подбор раз в неделю (на выходных, когда маркет закрыт), и, либо подтверждать текущую выбранную стратегию, либо переходить к другой. Можно вывести для трейдера - список оптимальных рекомендуемых стратегий, в данных условиях. Тогда с открытием маркета и со свежей головой (в понедельник), трейдер сам подтвердит выбор (или раньше, до открытия маркета... оповещение по e-mail и т.п.).
Ну где-то так.
Память выделяется однократно для массива структур последовательностей.
В структуру последовательности входит: №, Массив структур всех сделок последовательности [Х], Значение Критерия, Позиция Файлового Указателя.
Дальше идет только заполнение элементов структуры (в т.ч. массивов сделок). Сделки в массиве смещаются, таким образом в памяти всегда только Х сделок каждой последовательности.
Вы выделяете память под массив структур и получаете:
массив №,
массив массивов структур всех сделок последовательности [Х],
массив Значение Критерия,
массив Позиций Файлового Указателя.
Зачем вам массив Значение Критерия и массив Позиций Файлового Указателя? (один критерий и последнюю сделку хранить не думали?)
Правильно ли понял:
Первый проход - ищете на интервале от 0 до ИскомойДаты
затем находите лучший критерий и ИскомаяДата = Времени закрытия сделки + 1
теперь вы ищете на интервале от "Времени закрытия сделки" до ИскомаяДата ???
и надо что бы в тот интервал поместилось Х сделок для расчета критерия для каждой последовательности?
Делюсь результатами исследований.
Бинарный кэш-файл размером 7529 МБ читается:
Вывод: ускорение на чтении одного большого файла с использованием RAM-диска - около 2.5 раз.
Странные результаты.
Вот с нашей рабочей серверной системы под нагрузкой:
Без рам дисков в разы дольше проекты собираем.
Странные результаты.
Вот с нашей рабочей серверной системы под нагрузкой:
Без рам дисков в разы дольше проекты собираем.
На мой взгляд, решение задачи заключается в кодировании исходных данных.
Если нельзя уйти от многократного чтения исходных данных, то их нужно преобразовать в приемлемый формат для многократного чтения.
Один из возможных вариантов - преобразовать каждую запись в 16-ти разрядное число. Каждому полю исходной записи выделить определенной количество бит в числе. Например:
старший разряд числа:
- "0" означает отрицательный результат сделки;
- "1" означает положительный результат сделки.
младший разряд числа:
- "0" означает сделку BUY;
- "1" означает сделку SELL.
и так далее.
Таким образом, вместо многократного чтения исходного файла со многими полями, работа сводится к многократному чтению одного числового поля, что должно дать значительное ускорение.
По большому счету, исходный файл можно сразу формировать в кодированном формате, правда информация в нем, будет выглядеть в невизуальном виде.
Только не в "16-ти" разрядное, а в 64-разрядное, у Андрея процессор x64, следовательно минимальная единица объема при обращении к памяти - 64 бита. Хоть один байт считывай из памяти, процессор все равно будет читать 8 байт (два двойных слова).
Да, в таком виде задача параллелится - при каждом изменении ИскомойДаты можно запускать одновременный поиск лучшего Критерия по разным частям совокупности последовательностей. Например, разделить их на 20 частей и раздать задачи 20 советникам. А они пусть читают файл, находят сделку, и передают назад только лучшую последовательность (№№, Критерий и файловую позицию).
Всем огромное спасибо!
Ну вот, другое дело ))