Need help! Не решается задача, упираюсь в ограничения железа - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
Есть много однотипных последовательностей сделок, каждая последовательность отсортирована по времени.
Одна последовательность влезет в память?
Можно написать эксперта. Эксперт на запуске загружает последовтельность №(параметр в окне своств) и торгует по этой последовательности. Оптимизируем №.
Задача не совсем ясна, а нафанатзировать можно много разного.
Одна последовательность влезет в память?
Можно написать эксперта. Эксперт на запуске загружает последовтельность №(параметр в окне своств) и торгует по этой последовательности. Оптимизируем №.
Задача не совсем ясна, а нафанатзировать можно много разного.
Если объем 20Гб (21 474 836 480 байт), в котором 1 миллион последовательностей, то получим примерно 21 475 байт в среднем одна последовательность (~21 Кб). Думаю что в памяти должна поместиться, даже в телефоне ))
О. Кстати, а как на счет распределенных вычислений? надо бы и в эту сторону подумать...
Еще раз сорри за паузу, экспериментировал с RAM-диском (пока не очень успешно). Отвечаю всем по порядку.
Но последовательности же независимы друг от друга? Тогда почему нельзя сделать сразу цикл по датам на один раз загруженной последовательности? Здесь, кстати, как раз может появиться возможность перейти к какому-нибудь эффективному рекуррентному алгоритму, но это как повезёт. Размерность миллион на миллион останется, а файл один раз будет читаться.
Вообще конечно задача, в которой на следующей итерации число шагов остаётся прежним (то есть зона поиска по мере расчётов не сужается), не выглядит особо робастной. Но это субъективно конечно.
Независимы. А как встать в цикл сразу по всем последовательностям, не загружая их в память?
Число шагов можно сокращать, если придумать как читать последовательности с нужного места (последние Х сделок от текущей анализируемой даты).
Вся база вписуется в 10 лям строк или нет? все файлы совокупно
1 файл на миллион последовательностей (я для удобства каждую в 9 строк записываю).
Ну, или миллион файлов, не принципиально.
Правильно ли мной было понято следующее:
1) Файл размером 20 гб состоит из около миллиона отсортированных по времени последовательностей
2) Размер каждой последовательности может отличаться и зависит от количества сделок, которые содержит в себе последовательность
3) В среднем размер последовательности 20/10^6 = 20 Мб, то что загрузим полностью одну последовательность мы можем гарантировать?
4) Коэффициент К зависит только от сделок внутри данной последовательности
5) Для каждой последовательности мы должны найти К (в общем счете 10^6 штук) и выбрать 10 лучших
Пока не было таких объемов, просто загружал все в память и гонял в цикле, считая все необходимое.
Лучшую последовательность нужно выбирать в каждой точке перебираемой нами истории (лучшая - последовательность с лучшим Критерием на текущий момент, критерий рассчитывается по последней закрытой сделке.
A если создать еще один файл с значениями расстояний между последовательностями.
Этого и следующего не понял.
Кстати да, можно загружать сразу пачки последовательностей.
Не спасет, нужны все.
Не понимаю где то.
Вот есть критерий - все - в интервале от Даты1 до Даты2.
Т. е., читается следующая.
Почему не разбить файл на много интервальных от Даты1 до Даты2? Отработанные последовательности же будут, которые можно закрыть?
Интервал "Дата1 - Дата2" на данный момент охватывает все сделки всех последовательностей.
А идея разбить его не несколько маленьких - вполне здравая. Правда, тогда придется читать информацию с диска при каждом изменении параметров.. Но это уже что-то.
Видимо одним из результатов прохода с одной датой является новая дата.
Да, но думаю можно найти точку, в которой не будет сделок ни у одной последовательности и сделать разрыв.
Тогда будет переход к следующему интервалу. Попробую.
если задача такая:
дан ряд 1 2 3 4 5 6 7 8 9
дана ширина например 4, нужно двигаясь с этой шириной по по всему ряду находить какое-то там значение внутри ширины (на пример минимум):
вначале нужно найти в 1 2 3 4 потом 2 3 4 5 потом 3 4 5 6 потом 4 5 6 7 потом .... итд.
Если бы Х (кол-во сделок) был фиксированным (4 в вашем примере) и не было других параметров - да. А так - нет.
Я бы поразмыслил над этой задачей
Условия изложил выше, велкам в наши ряды ;)
Поскольку задача довольно академическая (смахивает на вопрос при приеме программера на работу) и многие проявили к ней интерес, почему бы не сформулировать её более строго в плане формата описания исходных данных, и все желающие могли бы себе нагенерить 20 Гигов тестовых данных и представить свое практическое решение?
Не вопрос.
Нагенерируйте последовательности случайных сделок (в хронологическом порядке, пусть за 1 год) со всеми их атрибутами: дата и время открытия, цена открытия, СЛ, ТП, дата и время закрытия, цена закрытия. Пронумеруйте последовательности от 1 до миллиона.
Задача - составить из всех сделок всех последовательностей новую серию сделок, следующих друг за другом (не пересекающихся по времени), и выбранных по определенному критерию.
Критерием пусть будет средняя прибыль за последние 20 сделок последовательности.
Пример результата:
так понимаю, речь идет о самопальном тестере/оптимизаторе?
Да, что-то вроде того.
не, там что то другое.
видать база сделок какого-то брокера/провайдера досталась. :)
Если бы =)
повторю задачу упрощенно
Нет, не так. Я привел конкретный пример, его можно считать максимально приближенным к реальной задаче.
Типично для БД. Но тут без агрегирования данных никак... Можно в отдельную таблицу записать уникальные атрибуты последовательности (даты с-по), среднее значение профита К и дисперсию D, потом искать топ 10 последовательностей, близких к нужным критериям. При наличии индексов по этим полям, поиск будет не так долго выполняться (даже в миллионе записей). Далее, получив нужные 10 последовательностей, можно и в исходных данных порыться, но это уже не будет перебор миллиона, т.к. мы имеем ограничение по датам.
Если бы Критерий был статичным...
А если его параметры меняются?
До сих пор остается загадкой - что нужно искать? каким должен быть результат всех операций? Если речь о принятии решения в плане открытия/закрытия ордера, то любая обработка такого объема будет занимать достаточно большое кол-во времени.
Да, потом будет торговля. Но пересчет нужен будет только для самых свежих данных, всю историю колбасить не надо.
Другой момент еще. Раз речь идет о сделках, может быть есть смысл выделить отдельно сделки по каждому инструменту? И написать однотипных роботов, заточенных под EURUSD, USDJPY и т.д.
Это один инструмент...
Сдается мне таким образом можно выявить лишь стратегию, которая использовалась для торговли (или набор параметров робота) данной последовательности, и перейти к ней в определенной ситуации на рынке.
Именно.
Одна последовательность влезет в память?
Можно написать эксперта. Эксперт на запуске загружает последовтельность №(параметр в окне своств) и торгует по этой последовательности. Оптимизируем №.
Влезет.
Но результат нам нужен не один (финальный), а в каждой точке времени.
В принципе, можно задействовать облако, подавая в качестве параметра номер последовательности и дату, до которой считать. Но это вряд ли быстрее пересчитывания файла будет )
О. Кстати, а как на счет распределенных вычислений? надо бы и в эту сторону подумать...
Что будем считать параллельно? Значение критерия для разных последовательностей?
Но их нужно в память для этого загрузить. И не важно, из одного процесса (советника, терминала) или из нескольких. Разве что получить вместо 4Гб - 8 (или 12, 16, 20). Но потом же все равно "склеивать" результат надо..
Что будем считать параллельно? Значение критерия для разных последовательностей?
По идее можно разбить все истории скажем на 100 групп и для каждой группы вычислять оптимальный подбор отдельно.
Затем для каждой группы оставлять только те истории которые входят в оптимальный набор группы и приступать к следующему шагу, с меньшим количеством истории. Тогда теоретически параллелится в 100 раз.
И по памяти все отлично, размер группы можно регулировать
По идее можно разбить все истории скажем на 100 групп и для каждой группы вычислять оптимальный подбор отдельно.
Затем для каждой группы оставлять только те истории которые входят в оптимальный набор группы и приступать к следующему шагу, с меньшим количеством истории. Тогда теоретически параллелится в 100 раз.
И по памяти все отлично, размер группы можно регулировать
Если параллельно загрузить 100 из 100 частей, не хватит памяти =)
А если загружать последовательно (каждый раз запоминая один лучший вариант), то где распараллеливание? И файл все равно будет читаться при каждом подходе к станку.
Я думаю, что можно изобрести хитрый механизм частичной загрузки, но его надо придумать.
Например, при первом чтении найти для каждого прохода последнюю сделку, закрытую перед Начальной датой, вернуться назад и прочитать Х предшествующих сделок, запомнить точку файла, на которой эта сделка заканчивается.
После этого найти первую сделку, попадающую в результаты, и дальше работать только со свежими данными: читать файл с нужной точки до новой актуальной даты, и каждый раз смещать сделки в массиве (получится фиксированный размер массива - Х элементов).
Это решит и проблему с многократным чтением (оно просто не нужно), и с памятью (только если сможем разместить Х миллионов сделок).
Буду двигаться в этом направлении.
Переход на бинарные файлы, кстати, выигрыша в размере практически не дал.
Оптимизированный мной текстовый формат был очень компактным: дата запоминалась одна на проход (открытия первой сделки), а все остальные (и открытия и закрытия) запоминались как смещение от предыдущей даты; СЛ, ТП и ЦенаЗакрытия тоже сохранялись как смещение от цены открытия.
А при переходе на бинарный формат смысл в этой оптимизации отпал: смещение в секундах (uint) занимает столько же места, сколько полноценная дата (я отказался от long-а, мне 2030 года хватит), а ushort-а уже маловато (всего 18 часов максимальное смещение). Аналогично с ценами - смещение можно было перевести в ushort, но тогда пришлось бы добавлять проверки на переполнение (если, например, СЛ = 0), а выигрыш был бы всего 6 байт на всех 3-х ценах. Решил не делать.
Зато убрал немного лишней информации, в итоге процентов 20 все-таки отвоевал. Прогнозируемый размер исходного файла (который был 20Гб) - 7-8 Гб, через пару часов сконвертирует.
Ну, и процессорного времени, которое на преобразование строк шло, выиграл.