Разница между советником для реальной торговли и на демо счёте. Где заканчивается миф и начинается реальность? - страница 5

 
artmedia70:
Андрей, это по-детски.
по детски это защищать лок
 
Yoschik:
по детски это защищать лок

Я его защищаю?

Я знаю как в свою пользу с выгодой использовать положительный лок.

Отрицательный лок - мазохизм.

 
artmedia70:

Я его защищаю?

Я знаю как в свою пользу с выгодой использовать положительный лок.

Отрицательный лок - мазохизм.

))
 
artmedia70:

1. в конце вместо троеточия нужно вспвить му****в ?

2. так вы совсем зелёненький... комиссия программно считывается, а не в настройках вписывается... и не только комиссия

  я разве гдето утверждал что я программист?

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

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

 

Yoschik:
Я понял , понял , спокойно . Нет больше счета , как и предрекали. 

есть .куда ж ему деться то.  поставил галочку "личный" чтоб тестовый месяц   запустить заново

пс https://www.mql5.com/ru/signals/18792#!tab=history&page=1 вот сигнал- на демке метаквотов- в  истории сделок графа- комисии- пустая. нет там комисов. при  повторении того же на реале- комисии сожрали бы не только прибыль но и само депо за достаточно короткое время. 

Торговые сигналы: Skalpertest
Торговые сигналы: Skalpertest
  • 2013.11.11
  • Sergei Mindru
  • www.mql5.com
Торговый Сигнал Skalpertest для MetaTrader 5: копирование сделок, мониторинг счета, автоматическое исполнение сигналов и социальный трейдинг
 
papaklass:

 Советников для тестера НЕТ. Все советники делаются только для реала. Разделение на тестерных и для реала - это скрытое поднятие цены и маскировка исполнителем своей некомпетентности.

Тестер - это игрушка, слабо напоминающее реал. Перечислю некоторые различия, которые существенно влияют на итоговые результаты:

- время исполнения торговых заявок в тестере всегда = 0. На реале - от сотен миллисекунд до нескольких минут;

- в тестере нет проскальзываний, на реале проскальзывания обычное явление;

- в тестере все лоты испоняются по заявленной цене, на реале все зависит от объема открываемой позиции;

- в тестере торговое окружение всегда актуально, на реале - имеет временной лаг (запаздывание).

Можно еще продолжать о различиях, но и этого, думаю, хватит. 

Это лентяи-программисты (не все программисты лентяи) придумали это разделение. Программист (нормальный) обязан включать в код обработку ошибок.

Если за работу (выпонение советника на заказ) взялся либо лентяй, либо делитант, то такой, вместо включения в код обработку ошибок, будет рассуждать об области применения советника. Не слушайте этих проходимцев. Хороший программист всегда обрабатывает ошибки. Советников для тестера нет. Если Вам задают вопрос о том, где Вы собираетесь использовать советника (тестер/реал) бросайте этого исполнителя потому, чтоБ в этом случаеБ Вы имеете дело либо с делетантом, либо с лентяем.

 Советник должен быть исполнен только для реала, но это совершенно не исключает погонять его в тестере.

Вы сейчас, сами того не осознавая, написали бред. Причём тут обработка ошибок? Вы в своём уме? Обработки ошибок сервера обязаны быть и там, и там, равно как и учёт в расчётах ограничений ДЦ. Или вы считаете, что только в этом и заключается разница? Разница совсем в другом:

Для тестерного варианта, некоторые торговые ошибки можно не обрабатывать - их там попросту быть не может никогда, а значит и не будет лишних условий и их обработки. От этого уменьшается время тестирования и (главное) оптимизации со огромным количеством проходов. Или вы не считаете логические операции одним из главных тормозов?

Далее: многие просто просят по-быстрому проверить свою идею (если у вас таких не было - вы мало работали на заказ). Им пишешь недорогой, но шустрый код. Если его прогон в тестере устроил, тогда он может заказать и полновесный советник. Нафига ему для тестера писать отсылку push-сообщений или на e-mail? Нафига для проверки его идеи я буду озадачиваться тем, чтобы советник был отказоустойчив? (если тестер подвис, то и советник вместе с ним, и в любом случае перезапускать тест). А вот на реале, после вынужденного перезапуска, советник обязан продолжить работу так, как будто и не было перезапуска. Как минимум он должен найти и восстановить по истории ту картину и то состояние, которое было до его перезапуска. При этом ему придётся и по циклам побегать и пересчитать данные (уровни какие-нибудь), да много чего ему нужно будет по-новой найти и восстановить (тут всё от ТС зависит).
В тестере всего этого не нужно делать. Многие данные, которые советник обязан искать и рассчитывать при работе на реале, в тестере он может просто хранить в переменных и из них считывать.

Вам ещё примеров?

Документация по MQL5: Основы языка / Операции и выражения / Логические операции
Документация по MQL5: Основы языка / Операции и выражения / Логические операции
  • www.mql5.com
Основы языка / Операции и выражения / Логические операции - Документация по MQL5
 
trora:

  я разве гдето утверждал что я программист?

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

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

 

Yoschik:
Я понял , понял , спокойно . Нет больше счета , как и предрекали. 

есть .куда ж ему деться то.  поставил галочку "личный" чтоб тестовый месяц   запустить заново

пс https://www.mql5.com/ru/signals/18792#!tab=history&page=1 вот сигнал- на демке метаквотов- в  истории сделок графа- комисии- пустая. нет там комисов. при  повторении того же на реале- комисии сожрали бы не только прибыль но и само депо за достаточно короткое время. 

Значит два выхода:

  1. менять ДЦ, что мало поможет;
  2. менять стратегию

Насчёт "зелёненького" - я не со зла, не обижайтесь. Некоторые вон, лохами, да ламерами обзываются... :)

Учесть комиссию, своп и пр. - не затратно, так что - они есть при расчётах внутри советника. Если хотите сами вводить комиссии - можно же сделать опционально.

 

Ну, я ламер, я ввел это разделение. Ну и что? )

Могу согласиться с Артемом - иногда нужно просто проверить идею, и нет смысла сохранять рабочее состояние на диск (если его невозможно восстановить иначе). Но это отдельно оговаривается, писать такое можно только для прогона в тестере.

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

 

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

Делить один заказ на "для реала/для тестера" приходится редко. Скорее, для реала "до 10К/после 100К", тогда дополнительная паранойя включается ;)

 
artmedia70:

Учесть комиссию, своп и пр. - не затратно, так что - они есть при расчётах внутри советника. Если хотите сами вводить комиссии - можно же сделать опционально.

Есть комиссии, о которых терминал не знает (узнает постфактум).

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

 
komposter:

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

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

Скорее, это как раз я как мог более вежливо отбивался от нападок Андрея ;)

 
artmedia70:

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

Не могу придумать такой задачи.

Если что-то нужно хранить - пусть хранится (в переменных и массивах), а "для реала" нужно просто добавить запись в файл и чтение при загрузке. 

Готов обсудить конкретную задачу с примерами кода. 

Документация по MQL5: Файловые операции / FileWrite
Документация по MQL5: Файловые операции / FileWrite
  • www.mql5.com
Файловые операции / FileWrite - Документация по MQL5
Причина обращения: