Ошибки, баги, вопросы - страница 681

 
Renat:
Как-то недалеко рассуждаете.

Боитесь сами тратить время на расчет дополнительных характеристик бара для очень редких (близко к нулю %) случаев, но радостно требуете чтобы именно мы в 100% случаев готовили массу данных, тормозили при этом и в разы больше потребляли память.

Некоторые методично дают такие красивые советы убиться об стену, что впору говорить о вредителях.

Стратегов такого рода видно сразу.

 Если тщательно проанализировать все мои посты на эту тему и несколько предыдущих, а потом поиграться мультитаймфреймовым индикатором графической ТА-разметки на фракталах, сразу расхочется спорить со мной на эту тему, как после ведра ледяной воды. Но проблема в том, что индикатор не до конца оптимизирован (данной темы это не касается) и не дописан местами функционально. Поэтому-то я трачу ресурсы на ерунду, а не на допиливание и выкладывание релиза.

 Там графических объектов - прорва. А их ещё и чистить нужно... Проблем хватает.

 
Это и есть частный случай.
 
Renat:
Это и есть частный случай.
 Живую авторазметку хотят чуть менее, чем все, кто торгует руками. Кто пишет МТС/АТС на осцилляторах, скользящих и им подобных - пусть себе пишут, я бы тоже приспособил этот индикатор для автоторговли "от вон той вон линии", но MQL сам по себе не видит никаких линий, тут опять надо самому вгрызаться в планиметрию, тягать корни из гипотенузы, заполнять матрицу квадратов Сетки Ганна и натравливать эксперт на такой индикатор. Тогда ресурсам можно будет сказать вообще гудбай, тут и 16 Гиг покажется насмешкой.
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов - Документация по MQL5
 
Yedelkin:

Чую, будет голосовалка :)

Или убивалка кого-то об стену :)
 

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

 Иначе никогда бы ничего ни во что не развилось... 

 
abolk:
Или убивалка кого-то об стену :)

Это более вероятный исход.

А я чую, что на мой вопрос так и не ответят и придется писать в СД... :(

 
MetaDriver:

2.  Я видел. И что? Много пропущенных баров? У меня и нет иллюзий на этот счёт. У меня запрос есть. Совсем не оригинальный и отнюдь не "исключительно частный". А именно: автоматически (!!) поддерживаемый изготовителем терминала режим доступа (и отображения!) к котировкам (включая, да-да!, низколиквидные) в котором все внутрисессионные дыры в котировках  заполнены доджами с параметрами {Volume=0, Open=High=Low=Close=[цена закрытия предшествующего непустого бара]}.  Как вы думете, это востребованный режим? Или я большой оригинал?  Только честно, Ренат. Положа правую руку на левое сердце.

Мой опыт четко указывает, что заполнение пустот - это бред и самообман, который тут же раскроется, как только получишь эту заполненную историю.

Этот вопрос поднимался многократно за последние 10 лет.

 
x100intraday:
 Живую авторазметку хотят чуть менее, чем все, кто торгует руками. Кто пишет МТС/АТС на осцилляторах, скользящих и им подобных - пусть себе пишут, я бы тоже приспособил этот индикатор для автоторговли "от вон той вон линии", но MQL сам по себе не видит никаких линий, тут опять надо самому вгрызаться в планиметрию, тягать корни из гипотенузы, заполнять матрицу квадратов Сетки Ганна и натравливать эксперт на такой индикатор. Тогда ресурсам можно будет сказать вообще гудбай, тут и 16 Гиг покажется насмешкой.

То есть, Вы хотите тяжелый предрасчет состояний для своего решения переложить на нас, считая, что наступит счастье.

То есть, Вы даже не оцениваете последствий того, что в результате мы в 100% случаев угробим производительность терминала и потратим гораздо больше памяти. Это и есть вредительский совет.

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

 
Renat:

То есть, Вы хотите тяжелый предрасчет состояний для своего решения переложить на нас, считая, что наступит счастье.

То есть, Вы даже не оцениваете последствий того, что в результате мы в 100% случаев угробим производительность терминала и потратим гораздо больше памяти. Это и есть вредительский совет.

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

 Кеши должны располагаться, конечно же, на диске, а не где-нибудь... в оперативке? То есть файловые операции чтения/записи? Но, во-первых, это не удобнее, чем если вы будете в БД складывать значения exact_times[] за счёт терминала. Хорошая среда разработки должна всем своим пользователям предоставлять те готовые средства, которые под силу изобрести каждому пользователю самостоятельно, но напрягать каждого пользователя в отдельности одной и той же задачей - это беспощадно. Это к вопросу о частности. Нет никакой частности и не предвидится, это иллюзия. Я и сам-то на форуме скорее из-за рацпредложений и привнесения новых идей, а уж потом только для задания вопросов по уже встроенным возможностям (при желании можно самому изучить справку). А во-вторых, я напоминаю про несуразность анализа силами MQL-кодеров - это напоминает вытаскивание из архива не какого-то одного точно выбранного файла, а раскурочивание всего архива ради одного конкретного файла. Если вы сделаете предварительный расчёт точных времён экстремумов, на это несомненно уйдёт время и машинные ресурсы, но! не меньше ресурсов уйдёт на наш самостоятельный анализ. Что-то мне подсказывает, что C работает чуть быстрее, чем MQL... Домысел или факт? А самое жуткое - это периодические проверки на актуальность состояния отображаемых в текущий момент объектов, то бишь частичные перерасчёты. Чтобы их не было, нужно забирать ранее расчитанные данные из кеша, но это уже из предыдущего "во-первых".
 
 В конце концов, это встраивается в терминал как фича, чтобы можно было выбрать опционально, рассчитывать ли терминалом точные времена баров или нет. Это стандартная практика, пусть пользователь сам выбирает между точностью и временем. Ну а треволнение о том, что MQL-программисты предлагают переложить на плечи разработчиков терминала предрасчёт дополнительных атрибутов баров - это и странно, и несерьёзно. Конечно, мы тоже можем многое, но нужно чётко видеть и распределять роли между разработчиками терминала и MQL-программистами, стараясь быть объективными.
Причина обращения: