Новая версия платформы MetaTrader 5 build 1640: создание и тестирование собственных финансовых инструментов - страница 14

Новый комментарий
 
Renat Fatkhullin:
Попробуйте, но второй вариант должен быть лучше, так как у нас специализированная эффективная упаковка ценовых данных.

Попробовал, лучше. Правда, MqlTick-структура - самое плохое для хранения.

Обнаружил три бага

void OnStart()
{  
  const string SymbolCustom = "TEMP3_custom";  
  MqlTick Ticks[];
  
  if ((SymbolInfoInteger(SymbolCustom, SYMBOL_CUSTOM) || CustomSymbolCreate(SymbolCustom)) &&
      (CopyTicks(_Symbol, Ticks, COPY_TICKS_INFO, 0, 1e6) > 0))
  {
    FileSave(SymbolCustom + ".bin", Ticks);
    CustomTicksReplace(SymbolCustom, Ticks[0].time_msc, Ticks[ArraySize(Ticks) - 1].time_msc, Ticks);
    
//    CustomTicksReplace(SymbolCustom, 0, INT_MAX, Ticks);  // Возвращает ноль
//    CustomTicksReplace(SymbolCustom, 0, LONG_MAX, Ticks); // Создает огромные tkc-файлы
    
//    if (SymbolSelect(SymbolCustom, true))
//      CustomTicksAdd(SymbolCustom, Ticks); // Подвешивает терминал - размер массива
  }
}
А так же CustomTicksReplace возвращает всегда ошибку, если tkc-файл удалить.
 
Renat Fatkhullin:
Попробуйте, но второй вариант должен быть лучше, так как у нас специализированная эффективная упаковка ценовых данных.

Вот ещё бы в файлах .hcc сделали эффективную упаковку, было бы замечательно.  А то они тоже занимают огромный объём (по сути вся история хранится в виде кэша), что это совершенно нерационально, поскольку в работе участвуют лишь некоторые из них (по которым открыты графики или идёт обращение из советников), а основная часть этих файлов просто лежит мёртвым грузом на диске.  А это десятки гигабайт.  Почему бы не упаковывать неиспользуемые файлы?  Ведь это дало бы 5-10 кратную экономию дискового пространства.  Некоторые из них мы возможно никогда больше не откроем, так зачем тратить на них столько места.  

Мне вот лично приходится регулярно вычищать историю из папки.  Легче потом заново подгрузить с сервера (а это не долго, т.к. подкачка идёт в упакованном виде), чем впустую терять столько места на SSD.

Раньше тоже пытался сжимать архиватором, но он даёт лишь двухкратный выигрыш, что особой погоды не делает, лишняя морока только.

 

Это же развернутый кеш для быстрого доступа.

Если данные постоянно разворачивать на лету, то будут дичайшие тормоза. Плюс оперативки не хватит.

При работе с массивными и детальными данными нужно смириться с потребностями в десятках гигабайт диска. Мы в 2017 году, где 10 гб SSD стоят 10 долларов.

Терминал сам внимательно следит за неиспользуемыми символами и стирает их историю. Также чистит и каталоги тестера.


Как я повторял уже сто раз, вот подтверждение, почему мы сделали MQL5 несовместимым с MQL4 по модели доступа к данным. У Метатрейдера 5 насколько огромные объемы данных, что к ним категорически нельзя обращаться по плоской модели типа Close[x] на всем пространстве истории. Банально памяти не хватит.

 
Alexey Navoykov:

Вот ещё бы в файлах .hcc сделали эффективную упаковку, было бы замечательно.  А то они тоже занимают огромный объём (по сути вся история хранится в виде кэша), что это совершенно нерационально, поскольку в работе участвуют лишь некоторые из них (по которым открыты графики или идёт обращение из советников), а основная часть этих файлов просто лежит мёртвым грузом на диске.  А это десятки гигабайт.  Почему бы не упаковывать неиспользуемые файлы?  Ведь это дало бы 5-10 кратную экономию дискового пространства.  Некоторые из них мы возможно никогда больше не откроем, так зачем тратить на них столько места.  

Мне вот лично приходится регулярно вычищать историю из папки.  Легче потом заново подгрузить с сервера (а это не долго, т.к. подкачка идёт в упакованном виде), чем впустую терять столько места на SSD.

Раньше тоже пытался сжимать архиватором, но он даёт лишь двухкратный выигрыш, что особой погоды не делает, лишняя морока только.


Про hcc не скажу, а тиковая история по сотне активных символов (EURUSD и FOREX-подобные на "LMAX") за год в виде CSV сжатыми 7zip занимает ~10Gb. Надо торрент, обновляемый раз в неделю, мутить. Раз уж такая лафа с кастомными символами.

 
Renat Fatkhullin:

Это же развернутый кеш для быстрого доступа.

Если данные постоянно разворачивать на лету, то будут дичайшие тормоза. Плюс оперативки не хватит.

Почему постоянно?  Речь же идёт о неиспользуемых символах.  Соответственно это будет происходит лишь при изредка.  А развёрнутый кэш абсолютно всего - это абсурд, вам не кажется?   Сама суть кэширования - разворачивать наиболее часто используемые фрагменты.   Зачем кэшировать то, что редко используется?

При работе с массивными и детальными данными нужно смириться с потребностями в десятках гигабайт диска. Мы в 2017 году, где 10 гб SSD стоят 10 долларов.

Ок, ну а 100 Гб - это уже 100 долларов... и можно дальше продолжить цепочку.  Вы считаете, что пользователь должен выкидывать эти деньги в угоду неэффективности вашего ПО?
И коль зашла речь о развитии технологий, то посчитайте также, какая скорость интернета в 2017 году.  Я в прошлом сообщении уже написал, что проще подождать несколько секунд, заново выкачав с сервера всю историю по конкретному символу (поскольку, как я понимаю, там она передаётся эффективно упакованной, а потом распаковывается на лету).  И это мне не будет стоить ни копейки.  Чем выбрасывать на помойку десятки гигабайт. А кому-то и сотни гигабайт (смотря на скольких брокерах открыты счета).

Терминал сам внимательно следит за неиспользуемыми символами и стирает их историю.

Это не соответствует действительности.  Специально проверил в папках истории, там есть символы, по которым уже несколько месяцев не обновлялась история (символ торгуемый, просто обращения к истории не было). И ничего не стёрто.

Да и почему вообще стирание-то?  Если можно упаковать их, получив 10-кратную экономию.  А когда снова возникнет потребность в них, то быстренько распаковать и поместить в кэш.  С диска это будет сделать на порядок быстрее, чем выкачивать по сети.

 
fxsaber:

Про hcc не скажу, а тиковая история по сотне активных символов (EURUSD и FOREX-подобные на "LMAX") за год в виде CSV сжатыми 7zip занимает ~10Gb. Надо торрент, обновляемый раз в неделю, мутить. Раз уж такая лафа с кастомными символами.

Да CSV - это вообще нерациональный способ хранения.  Помимо избыточного объёма, это ещё и очень медленный доступ к данным.  А сколько она занимает в несжатом виде?

Ведь исторические данные можно очень эффективно паковать своими силами.  Чем мельче таймфрейм, тем эффективней будет кодирование.  А уж на тиках вообще красота, можно сжимать в десятки раз.

 
Alexey Navoykov:

Почему постоянно?  Речь же идёт о неиспользуемых символах.  Соответственно это будет происходит лишь при изредка.  А развёрнутый кэш абсолютно всего - это абсурд, вам не кажется?   Сама суть кэширования - разворачивать наиболее часто используемые фрагменты.   Зачем кэшировать то, что редко используется?

Не кажется.

Потому что именно мы занимаемся разработкой эффективных и быстрый решений уже много лет. То есть, масса подходов и оценок уже проверены за многие годы.

Это вы сейчас тут в форуме заявляете про "редко используется", хотя на самом деле все что у вас закачано и развернуто, было запрошено вами.


Ок, ну а 100 Гб - это уже 100 долларов... и можно дальше продолжить цепочку.  Вы считаете, что пользователь должен выкидывать эти деньги в угоду неэффективности вашего ПО?

Речи о 100 гб не идет.

Но вывод абсолютно правильный. Если у вас нет 10 долларов на место в диске, то вы зря этим делом занялись. Объем решаемых задач в аналитике 2017 года таков, что требуется достаточно ресурсов.

Причем эти требования мы максимально держим(и держали) на низком уровне, обеспечивая огромную эффективность при реально скромных запросах. Чтобы вы понимали - в платформе нет лимитов практически ни на что. Данные выдаются автоматически и на полную запрошенную глубину. Десятки миллионов тиков, сотни тысяч баров и тд.

Про неэффективность вы сможете говорить, когда продемонстрируете свою квалификацию и собственные проекты, подтверждающие эту квалификацию. Я утверждаю, что у нас очень эффективная система. И наши разработчики знают, что я главный, кто требует эффективность.


И коль зашла речь о развитии технологий, то посчитайте также, какая скорость интернета в 2017 году.  Я в прошлом сообщении уже написал, что проще подождать несколько секунд, заново выкачав с сервера всю историю по конкретному символу (поскольку, как я понимаю, там она передаётся эффективно упакованной, а потом распаковывается на лету).  И это мне не будет стоить ни копейки.  Чем выбрасывать на помойку десятки гигабайт. А кому-то и сотни гигабайт (смотря на скольких брокерах открыты счета).

Давайте я посчитаю.

Ибо ваше "не будет стоить ни копейки" означает, что брокер заплатит из своего кармана за ваш трафик и трафик десятков тысяч других пользователей. И если вы думаете, что сидя в России вы "ничего не платите", то разочарую вас. Всегда кто-то платит, даже в России.

Например, в Юго-Восточной Азии брокеры (да и все остальные поставщики) платят 1 доллар за 10 гб отданного трафика. И чем более неэффективен софт, тем больше трафика он потребляет, нагружает каналы и заставляет платить брокеру.

Поэтому мы все 17 лет экономного относимся к трафику, сжимаем все максимально и делаем эффективные решения.


Это не соответствует действительности.  Специально проверил в папках истории, там есть символы, по которым уже несколько месяцев не обновлялась история (символ торгуемый, просто обращения к истории не было). И ничего не стёрто.

Да и почему вообще стирание-то?  Если можно упаковать их, получив 10-кратную экономию.  А когда снова возникнет потребность в них, то быстренько распаковать и поместить в кэш.  С диска это будет сделать на порядок быстрее, чем выкачивать по сети.

Данные стираются, когда становится ясно, что к ним нет явных или неявных обращений долгий период времени.

Про упаковку вы не совсем понимаете, оперируя 10 кратным сжатием. Возьмите 7z как один из самых эффективных упаковщиков и посмотрите, насколько сожмутся данные и на какое время компьютер будет в просадке при сжатии хотя бы 1 гб данных.

 

Я так понимаю, по размеру диска припекает исключительно от того, что у человека:

  1. VPS с мизерным диском
  2. VPS экстремально дешевый и не хочется заплатить дополнительные 5 долларов в месяц за диск побольше
  3. трафик для него бесплатен по сути

Именно этот набор ограничений привел к попыткам учить, как писать софт и "неэффективностям". Плевать на всех остальных, главное самому вписаться в 20 гб виртуалки за 5-10 долларов.

Ровно такая же тема поднималась и раньше. И тоже замалчивалось по максимуму, что это на VPS происходило.

 
Alexey Navoykov:

Да CSV - это вообще нерациональный способ хранения.  Помимо избыточного объёма, это ещё и очень медленный доступ к данным.  А сколько она занимает в несжатом виде?

Вот такие CSV

2017-10-02 00:05:22.672,1.17961,1.17973
2017-10-02 00:05:22.813,1.17960,1.17974
2017-10-02 00:05:24.969,1.17961,1.17973

Жмутся в 10 раз.

Ведь исторические данные можно очень эффективно паковать своими силами.  Чем мельче таймфрейм, тем эффективней будет кодирование.  А уж на тиках вообще красота, можно сжимать в десятки раз.

CSV - для примера, чтобы показать что 100 символов даже с тупым форматом занимают 10 Гб за год - тики.

 
Renat Fatkhullin:

Не кажется.

Потому что именно мы занимаемся разработкой эффективных и быстрый решений уже много лет. То есть, масса подходов и оценок уже проверены за многие годы.

Именно вы?  А другие не занимаются?

Вот для начала, что такое кэширование:  

 Кэш — промежуточный буфер с быстрым доступом, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удаленного источника, однако её объём существенно ограничен по сравнению с хранилищем исходных данных.

Жирным выделил ключевые моменты.  Вы же заявляете, что вам не кажется абсурдом держать в кэше вообще все данные, даже которые редко используются. Именно такой вопрос я вам задавал. Из песни слов не выкинешь. Поэтому, к сожалению, ваши самовосхваления совершенно беспочвенны.  Т.к. противоречат принятым понятиям об эффективности и рациональности.

Это вы сейчас тут в форуме заявляете про "редко используется", хотя на самом деле все что у вас закачано и развернуто, было запрошено вами.

Речь о том, что это было запрошено давно.   Вот например у меня есть папка USDJPY, где лежат файлы 2016.hcc, 2017.hcc.  И дата обновления последнего из них:  14.06.2017.  При этом по другим символам дата обновления свежая.  Т.е. по USDJPY уже 4 месяца ничего не запрашивалось.  Это, по вашему, не редко?  
 

Данные стираются, когда становится ясно, что к ним нет явных или неявных обращений долгий период времени.

И чему же равен этот период?  

Речи о 100 гб не идет.

Почему не идёт?  Десятки гигабайт - это лишь по одному брокеру.  А их ведь далеко не один, как правило.   Ну так что в итоге, терять 100 Гб SSD - это нормально или как?

Давайте я посчитаю.

Ибо ваше "не будет стоить ни копейки" означает, что брокер заплатит из своего кармана за ваш трафик и трафик десятков тысяч других пользователей. И если вы думаете, что сидя в России вы "ничего не платите", то разочарую вас. Всегда кто-то платит, даже в России.

Например, в Юго-Восточной Азии брокеры (да и все остальные поставщики) платят 1 доллар за 10 гб отданного трафика. И чем более неэффективен софт, тем больше трафика он потребляет, нагружает каналы и заставляет платить брокеру.

И к чему всё это?  Меня то, как пользователя, каким боком это касается?  Кто там за что платит... Я то не плачу, и это главное, всё остальное уже не мои проблемы.

Это ж вы сами создаёте такую ситуацию, что мне предпочтительней гонять трафик брокера, чем захламлять место на жёстком диске. 

Про упаковку вы не совсем понимаете, оперируя 10 кратным сжатием. Возьмите 7z как один из самых эффективных упаковщиков и посмотрите, насколько сожмутся данные и на какое время компьютер будет в просадке при сжатии хотя бы 1 гб данных.

Чего я не понимаю, если я лично сам реализую такое сжатие (и даже больше) в своих решениях.  Конечно не на каждом символе такие показатели. Зависит от волатильности и точности котирования.

А сравнивать с архиваторами - это вообще нелепо. Они ничего не знают о формате и содержании хранимых данных. Поэтому о какой эффективности тут вообще говорить?  Пока они будут выискивать те закономерности, которые нам известны заранее (например что цена кратна размеру тика и т.д.), мы уже успеем несколько раз запаковать/распаковать наши данные.   Я вижу, что вы очень далеки от понимания эффективной упаковки и хранения данных.

Давайте, чтобы не заниматься пустой болтовнёй, перейдём к конкретике. Выберем какой-то символ, и поспорим, смогу ли я его ужать во столько то раз.

1...789101112131415161718192021...53
Новый комментарий
Причина обращения: