Need help! Не решается задача, упираюсь в ограничения железа - страница 17
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, в таком виде задача параллелится - при каждом изменении ИскомойДаты можно запускать одновременный поиск лучшего Критерия по разным частям совокупности последовательностей. Например, разделить их на 20 частей и раздать задачи 20 советникам. А они пусть читают файл, находят сделку, и передают назад только лучшую последовательность (№№, Критерий и файловую позицию).
Всем огромное спасибо!
Чтение с диска достаточно дорогая операция - запустив данный алгоритм на нескольких советниках все упрется в скорость чтения с диска + частями + с разных позиций и скорости скорее всего эта затея не даст.
можно и за одно чтение данных все рассчитать - главное желание
Чтение с диска достаточно дорогая операция - запустив данный алгоритм на нескольких советниках все упрется в скорость чтения с диска + частями + с разных позиций и скорости скорее всего эта затея не даст.
А кто сказал что распределенные вычисления должны выполняться на одной рабочей станции? нет таких ограничений )) Да и RAM-диск в помощь, как сказано выше было.
А чуть подумать и изменить алгоритм?
1. как скачать одним махом несколько последовательностей и как знать где они начинаются и где кончаются
2. как рассчитать для всех сделок в одной последовательности коэффициенты и в какой структуре данных хранить ответ
3. как сделать объединение двух ответов с прошлого пункта в новый чуть более полный
4. как поделить окончательный ответ с пункта 3 на нужные интервалы (речь про ИскомаяДата = Времени закрытия сделки + 1)
Можем получить немного другой алгоритм где выбирая на сколько дополнительных частей делить интервал ИскомаяДата
можем получать разные погрешности по сравнению с исходным авторским алгоритмом.
Разрядность числа, определяется уникальностью кода записи, а не разрядностью системы. Понятно, что она (разрядность числа) должна быть кратна 1 байту.
64 бита, на мой взгляд, явный перебор. :)
Если записей 1 000 000, то 16 разрядов будет маловато для уникального кода записи (максимум 65536 записей). Это раз.
Посмотрите архитектуру процессоров Intel (Itanium), AMD (я не говорил про операционную систему) 32-х разрядных и 64-х разрядных. 32/64 - разрешение шины адреса, но вместе с тем, за один машинный цикл считывается из памяти 32/64 бита (4/8 байт), даже при доступе к одному байту памяти.
Поэтому будет абсолютно неважно в плане производительности считывать 2 байта или 8 байт из памяти.
В принципе можно и Windows Service написать для подобного рода обработок файлов.
Но я все же склоняюсь к использованию СУБД.
А чуть подумать и изменить алгоритм?
1. как скачать одним махом несколько последовательностей и как знать где они начинаются и где кончаются
2. как рассчитать для всех сделок в одной последовательности коэффициенты и в какой структуре данных хранить ответ
3. как сделать объединение двух ответов с прошлого пункта в новый чуть более полный
4. как поделить окончательный ответ с пункта 3 на нужные интервалы (речь про ИскомаяДата = Времени закрытия сделки + 1)
Можем получить немного другой алгоритм где выбирая на сколько дополнительных частей делить интервал ИскомаяДата
можем получать разные погрешности по сравнению с исходным авторским алгоритмом.
По всем 4 пунктам - обработка данных на стороне СУБД.
На счет "немного другого" алгоритма не совсем ясно что Вы имеете ввиду. Но. Чтобы хоть каким-то образом просчитать погрешность этого "немного другого" алгоритма в сравнении с "авторским" - необходимо чтобы оба алгоритма были реализованы. А тема создана как раз в связи с технической проблемой реализации "авторского" алгоритма.
Учитывая этот факт, какую методологию Вы собираетесь применять для расчета погрешности о которой говорите?
можно и за одно чтение данных все рассчитать - главное желание
Чтение с диска достаточно дорогая операция - запустив данный алгоритм на нескольких советниках все упрется в скорость чтения с диска + частями + с разных позиций и скорости скорее всего эта затея не даст.
Скажем HDD самое медленное устройство, это факт. Однако речь не идет о запуске нескольких советников, использующих все эти расчеты. Как мне кажется, наиболее вероятное применение - генерация сигналов. Скажем cloud server на amazon с нужной производительностью + MT4 + данная разработка = поставщик сигналов.
По всем 4 пунктам - обработка данных на стороне СУБД.
На счет "немного другого" алгоритма не совсем ясно что Вы имеете ввиду. Но. Чтобы хоть каким-то образом просчитать погрешность этого "немного другого" алгоритма в сравнении с "авторским" - необходимо чтобы оба алгоритма были реализованы. А тема создана как раз в связи с технической проблемой реализации "авторского" алгоритма.
Учитывая этот факт, какую методологию Вы собираетесь применять для расчета погрешности о которой говорите?
у автора, на сколько я понял (вдруг что опять не так, так как внятного и полного объяснения что конкретно надо ни где нет), диапазон будет отсекаться выбранным с данного диапазона максимальным коэффициентом, в предложенном мной варианте - разбивать каждый такой диапазон на N поддиапазонов куда при слиянии может поместиться только одно значение коэффициента. Получится при N = 5 диапазон может быть разбит только на пропорции 0.2 0.4 0.6 0.8 1. А в авторском отсекаться любое значение от 0 до 1. Вот и погрешность 0.2 диапазона - это максимум при N = 5.
И все вокруг того на сколько верно были интерпретированы авторские посты, ведь полной ясности все равно нет.
у автора, на сколько я понял (вдруг что опять не так, так как внятного и полного объяснения что конкретно надо ни где нет), диапазон будет отсекаться выбранным с данного диапазона максимальным коэффициентом, в предложенном мной варианте - разбивать каждый такой диапазон на N поддиапазонов куда при слиянии может поместиться только одно значение коэффициента. Получится при N = 5 диапазон может быть разбит только на пропорции 0.2 0.4 0.6 0.8 1. А в авторском отсекаться любое значение от 0 до 1. Вот и погрешность 0.2 диапазона - это максимум при N = 5.
И все вокруг того на сколько верно были интерпретированы авторские посты, ведь полной ясности все равно нет.
Да, видимо проект МинФин заказывал, конкретной информации недостаточно. Однако, каждый для себя может найти что-то интересное из обсуждения. В этом я вижу позитив дискуссии.
Про дискретизацию диапазонов Ваша мысль понятна. А если N=100, 1000... (чисто математически ведь такое возможно) то такое дробление вызовет обратную реакцию в плане производительности и использования системных ресурсов. Помимо математики есть еще и физика )
У нас в памяти фрагмент файла, идём по нему и формируем выборку нужной для расчёта критерия длины, отбирая только сделки, принадлежащие к той же последовательности. Затем по этой выборке рассчитываем критерий. Кстати, возможности для использования рекурсии при отборе по идее есть.
Так нужно будет перебирать несколько миллионов сделок от других последовательностей! Я именно об этом.
проблема со вставкой новых данных - решите ее хоть как-то.
Пока проблемы нет, данных фиксированное количество.
Кстати если известно место начала каждой последовательности, нужные даты можно искать бинарным поиском, т.к. сделки упорядочены по времени.
+1, спасибо за идею.
1. Исходя из выше сказанного "Критерием пусть будет средняя прибыль за последние 20 сделок последовательности.", это надо понимать один критерий, скользящее мат.ожидание прибыли. Какие есть еще?
В БД генерировать таблицу с идентификатором последовательности и соответствующими скользящими средними. Не подходящие под условия последовательности удалить сразу. Это делаться должно процедурой в concurrent режиме на уровне СУБД, по запросу от робота, с отображением статуса процесса в роботе.
Скажем так, процедра FilterAvgProfit (pProfitValue, pTrades, pDeviation),
где pProfitValue - желаемый профит, pTrades - кол-во сделок для скользящего среднего профита, pDeviation - допустимое отклонение от pProfitValue.
Результат - заполненная таблица с ID последовательностей и средние значения профита.
1а. Какие еще критерии - не принципиально. Важно, что расчет происходит по серии сделок указанной длины.
1б. Как можно отбросить последовательность, только потому что на момент закрытия сделки N у нее плохое значение критерия? А если потом она станет лучшей?
Удалить можно будет только откровенно провальные последовательности, у которых критерий ни разу "не вылазил в плюс". А их должно быть не много.
4. Я так понимаю, если смотреть в сторону подбора стратегии, то данная операция не должна выполняться слишком часто (скажем на каждом баре или непосредственно перед открытием ордера). Разумно использовать такой подход в случае если текущая стратегия приносит N убыточных сделок подряд - тогда можно выбрать другую, и придется потратить время на "вынос решения", тут никуда не деться. Или же, выполнять такой подбор раз в неделю (на выходных, когда маркет закрыт), и, либо подтверждать текущую выбранную стратегию, либо переходить к другой. Можно вывести для трейдера - список оптимальных рекомендуемых стратегий, в данных условиях. Тогда с открытием маркета и со свежей головой (в понедельник), трейдер сам подтвердит выбор (или раньше, до открытия маркета... оповещение по e-mail и т.п.).
Ну, это вопрос идеологии. Сейчас не о нем ;)
Вы выделяете память под массив структур и получаете:
Зачем вам массив Значение Критерия и массив Позиций Файлового Указателя? (один критерий и последнюю сделку хранить не думали?)
Массив значений Критерия - для возможности сортировки и выбора нескольких лучших последовательностей (на будущее).
Позиции файлового указателя - чтоб продолжать поиск в каждой последовательности с нужного места (как иначе?).
Правильно ли понял:
Первый проход - ищете на интервале от 0 до ИскомойДаты
затем находите лучший критерий и ИскомаяДата = Времени закрытия сделки + 1
теперь вы ищете на интервале от "Времени закрытия сделки" до ИскомаяДата ???
и надо что бы в тот интервал поместилось Х сделок для расчета критерия для каждой последовательности?
1. Да, сначала от 0 до ИскомойДаты
2. Нет. ИскомаяДата сдвигается, и обрабатываем последовательность (добавляем сделки в массив) мы на интервале "ПредыдущаяОбработаннаяСделка - ИскомаяДата".
Странные результаты.
Вот с нашей рабочей серверной системы под нагрузкой:
Без рам дисков в разы дольше проекты собираем.
Начинаю комплексовать.
Наверное, нужно сделать тестовый скрипт и приложить файл, чтоб вы проверили на схожей задаче.
Винчестер у меня обычный - wdc wd1002FAEX-00Y9A0, судя по спецификациям, максимальная скорость - 126 MB/s:
Судя по обзору, примерно столько и можно выжать. Может, я что-то делаю не так?
Посмотрим на срипт..
о чем и говорил - читать большие файлы надо большими кусками, а то мелкими может быть до 10 и больше раз дольше.
Как читать большой кусок?
На мой взгляд, решение задачи заключается в кодировании исходных данных.
Как закодируйте полную информацию о сделке без потери информации?
Странные результаты.
Вот с нашей рабочей серверной системы под нагрузкой:
Без рам дисков в разы дольше проекты собираем.
Про память забыл написать.
DDR3, 1333 MHz:
Softperfect RAM Disk 3.4.5, правда я NTFS делал (есть разница?)
И еще деталь - РАМ-диск размером 12000 МБ, и свободной памяти (для работы) остается всего 1-2 Гб.