Время написания советника - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я могу скинуть один заказ который у него делал исходник,можете глянуть,кто разбирается,качественно сделал или нет он его,я просто не разбираюсь,качественно или нет,главное он работает по алгоритму,а как внутри я не шарю)0
большая часть кода лежит в библиотеке Trades.mqh которую он вам, как я пологаю, отправлял. Приложите ее для оценки качества.
По этому файлу мало о чем можно судить. Вроде как проверок и нормализаций нет там где должны быть, но они могут быть и во включаемом файле Trades.mqh.
Да и большая часть кода лежит там же.
А вот по блоку сигнала есть что сказать.
1) сравнение double между собой без какой либо нормализации.
2) пересечение ценой МА выполнено без учета ситуаций когда цена закрытия свечи равна цене МА. Это редко, но возможно.
Я не спорю,что сложно и да там куча ошибок всплыла,но 2 месяца назад было им заявлено,что ошибки известны,устраняемы и всё самое трудное позади,к сожалению не я этим занимаюсь,а тот кто детально знает все мелочи стратегии,а он согласился на почасовую и на просто отчёт о работе и я никак не мог ему доказать,что это плохо и неправильно
во фрилансе разве есть почасовая оплата?
то что можно решить вопросы через арбитраж, есть такое, там рассудят.
Давайте и я подключусь к обсуждению, раз пошла такая пьянка )))
Прежде всего конечно у 82Dmitry82 и у остальной его команды прошу прощения за такую задержку в разработке. Как я уже и сам обозначал их представителю, о том что пожалел что взялся за разработку, признаю что для меня это сложное задание. Задание было разбито на части, но сильное усложнение ТЗ выявилось на втором этапе, ну и по сути раз взялся, то решил довести до конца, но оказалось не так то просто.
Сейчас без раскрытия стратегии постараюсь изложить факт усложнения ТЗ, чтобы уже коллеги программисты реально оценили, на сколько данный факт усложняет разработку.
В основе лежит графическое построение уровней, от которых следует открывать ордера. С ходу на краю графика не обращаясь к истории эти уровни не построить, нужно ждать пока наберется история или просто сделать так чтобы советник сам обратился к истории и к краю графика пришел уже с какими то данными. Так и было решено сделать.
Изначально представлялось что мы бежим по свечкам, оцениваем 4 параметра (Open,Close,High,Low) и делаем построения опираясь на условия. Так и была сделана первая часть на старшем ТФ (ТЗ разбито на 3 части, 3 ТФ для каждого из которого разные построения и условия для этих построений). Когда перешли ко второму ТФ и начали тестировать по сути уже готовую вторую часть, выявились ошибки, и при общем обсуждении их оказалось что свечу в истории нужно отслеживать онлайн (то есть, так как будто она нулевая на краю графика) и делать перестроения когда свеча еще не закрыта, что при пробегании по истории не реально, тк по факту имеется 4 параметра Open,Close,Low,High.
Общим обсуждением было принято решение о том что свечу нужно углубляться и ращеплять ее до м1, чтобы по максимому отследить онлайн построение свечи (как будто она нулевая на краю графика). Предложение оставить построение истории как оно есть по 4 точкам, а правильную логику отслеживать уже на краю графика (когда Close[0] плавающий) было отклонено. Заказчики сами поняли что этот факт выявленный в процессе разработки значительно усложняет ТЗ. Уже на том этапе хотел отказаться от разработки, но тк первый этап был уже сделан, и не совсем это в моих принципах бросать разработку по центру решил продолжить. В процессе адаптации уже существующего алгоритма к тому что бежать нужно по М1, а отслеживать старшие ТФ ко мне начал приходить психоз, от того что убил на это огромное количество времени, в процессе того что не получалось срывался и писал заказчикам что нужно поднимать цену разработки, но когда отходил от компьютера и немного остывал от того что не получается продолжал править.
Предложил повременную оплату просто потому что сил тянуть проект за оговоренную сумму уже не было. Хотя предлагал отдать исходник, чтобы возможно нашли того кто доведет до ума.
По сути, если бы изначально знал что отслеживать нужно м1 внутри старшего тф, построил бы логику советника по другому.
Сейчас работаем по такому принципу, что мне присылают скрин с ошибкой в построении, я это правлю. Проверить самому все возможности реально нет, тк в стратегии огромное количество условий, которые по факту даже не помню. Согласовать их все, чтобы друг с другом не конфликтовали, вот главный трабл получается. Делалось все постепенно и сами заказчики признают что стратегия сложная для понимания, но в общем то сейчас уже почти все прописано, но спотря как это работает я даже не могу понять правильно или нет )))
Последнее на чем остановились, это тот случай, который не был учтен (даже по словам представителя заказчиков) и теперь нужно написать, вклинить и согласовать с десятком других условий еще одно. Поэтому переход на почасовую оплату со своей стороны считаю оправданным.
82Dmitry82, если хотите, можем лично с Вами пообщаться по советнику, контакты мои у вас есть. Другой советник я Вам делал, думаю оценили оперативность и поддержку, но с этим попрошу терпения, иногда откладываю работы по нему, просто потому что нет понимания с какой стороны к нему подойти, чтобы начать править очередное неверное построение уровней.
На данный момент в советнике более 1000 строк кода, и это только построение уровней, без всякой красивой мешуры и даже ордеров, до которых еще не дошли.
Давайте и я подключусь к обсуждению, раз пошла такая пьянка )))
Прежде всего конечно у 82Dmitry82 и у остальной его команды прошу прощения за такую задержку в разработке. Как я уже и сам обозначал их представителю, о том что пожалел что взялся за разработку, признаю что для меня это сложное задание. Задание было разбито на части, но сильное усложнение ТЗ выявилось на втором этапе, ну и по сути раз взялся, то решил довести до конца, но оказалось не так то просто.
Сейчас без раскрытия стратегии постараюсь изложить факт усложнения ТЗ, чтобы уже коллеги программисты реально оценили, на сколько данный факт усложняет разработку.
В основе лежит графическое построение уровней, от которых следует открывать ордера. С ходу на краю графика не обращаясь к истории эти уровни не построить, нужно ждать пока наберется история или просто сделать так чтобы советник сам обратился к истории и к краю графика пришел уже с какими то данными. Так и было решено сделать.
Изначально представлялось что мы бежим по свечкам, оцениваем 4 параметра (Open,Close,High,Low) и делаем построения опираясь на условия. Так и была сделана первая часть на старшем ТФ (ТЗ разбито на 3 части, 3 ТФ для каждого из которого разные построения и условия для этих построений). Когда перешли ко второму ТФ и начали тестировать по сути уже готовую вторую часть, выявились ошибки, и при общем обсуждении их оказалось что свечу в истории нужно отслеживать онлайн (то есть, так как будто она нулевая на краю графика) и делать перестроения когда свеча еще не закрыта, что при пробегании по истории не реально, тк по факту имеется 4 параметра Open,Close,Low,High.
Общим обсуждением было принято решение о том что свечу нужно углубляться и ращеплять ее до м1, чтобы по максимому отследить онлайн построение свечи (как будто она нулевая на краю графика). Предложение оставить построение истории как оно есть по 4 точкам, а правильную логику отслеживать уже на краю графика (когда Close[0] плавающий) было отклонено. Заказчики сами поняли что этот факт выявленный в процессе разработки значительно усложняет ТЗ. Уже на том этапе хотел отказаться от разработки, но тк первый этап был уже сделан, и не совсем это в моих принципах бросать разработку по центру решил продолжить. В процессе адаптации уже существующего алгоритма к тому что бежать нужно по М1, а отслеживать старшие ТФ ко мне начал приходить психоз, от того что убил на это огромное количество времени, в процессе того что не получалось срывался и писал заказчикам что нужно поднимать цену разработки, но когда отходил от компьютера и немного остывал от того что не получается продолжал править.
Предложил повременную оплату просто потому что сил тянуть проект за оговоренную сумму уже не было. Хотя предлагал отдать исходник, чтобы возможно нашли того кто доведет до ума.
По сути, если бы изначально знал что отслеживать нужно м1 внутри старшего тф, построил бы логику советника по другому.
Сейчас работаем по такому принципу, что мне присылают скрин с ошибкой в построении, я это правлю. Проверить самому все возможности реально нет, тк в стратегии огромное количество условий, которые по факту даже не помню. Согласовать их все, чтобы друг с другом не конфликтовали, вот главный трабл получается. Делалось все постепенно и сами заказчики признают что стратегия сложная для понимания, но в общем то сейчас уже почти все прописано, но спотря как это работает я даже не могу понять правильно или нет )))
Последнее на чем остановились, это тот случай, который не был учтен (даже по словам представителя заказчиков) и теперь нужно написать, вклинить и согласовать с десятком других условий еще одно. Поэтому переход на почасовую оплату со своей стороны считаю оправданным.
82Dmitry82, если хотите, можем лично с Вами пообщаться по советнику, контакты мои у вас есть. Другой советник я Вам делал, думаю оценили оперативность и поддержку, но с этим попрошу терпения, иногда откладываю работы по нему, просто потому что нет понимания с какой стороны к нему подойти, чтобы начать править очередное неверное построение уровней.
На данный момент в советнике более 1000 строк кода, и это только построение уровней, без всякой красивой мешуры и даже ордеров, до которых еще не дошли.
В общем, стало ещё запутаннее, чем было.
С того что понял, то нужно на старшем тайме проверять совпадение условий, и если оно не совпало, то ...
Если правильно понял алгоритм, то это не настолько сложно, максимум дня 2-3.
На данный момент в советнике более 1000 строк кода, и это только построение уровней, без всякой красивой мешуры и даже ордеров, до которых еще не дошли.
1000 строк это кстати средний размер любого советника выше простого.. Думаю проблема в том что вы пошли неправильным путем когда думали как обойти появившиеся проблемы. 90% успеха это сформулировать верно задачу, а ее реализовать это уже дело десятое
.
.
По сути, если бы изначально знал что отслеживать нужно м1 внутри старшего тф, построил бы логику советника по другому.
.
На данный момент в советнике более 1000 строк кода, и это только построение уровней, без всякой красивой мешуры и даже ордеров, до которых еще не дошли.
Давайте я вас поддержу.
У меня конечно не совсем такая, но похожая стратегия. Учитывает уровни поддержки/сопр., тренд, развороты, откат и много других вещей, без использования внешних(пользовательских) индикаторов.
Я по этой стратегии торговал руками 3 года. Всё это время думал как ее реализовать и запрограммировал в течение года. Получилось меньше 2000 строк.
Все разработчики, которые умеют торговать руками, то им легче когда на основу анализа берут какие-то бары.
Но бар, даже если это М1, то это уже прошлое. Строить на барах (тем более на старших) какую-то стратегию, это бессмысленно.
Надо все делать обрабатывая каждый тик.
Вот в моей программе нет ни одного массива (в абсолютном смысле), и не анализирую то, что было в прошлом. Но нужных контрольных точек конечно запоминаю в реальном времени (не в массивах).
Скажу короче: То что делается руками и так легко и красиво рисуется на графике, не всегда возможно запрограммировать.
Давайте и я подключусь к обсуждению, раз пошла такая пьянка )))
Прежде всего конечно у 82Dmitry82 и у остальной его команды прошу прощения за такую задержку в разработке. Как я уже и сам обозначал их представителю, о том что пожалел что взялся за разработку, признаю что для меня это сложное задание. Задание было разбито на части, но сильное усложнение ТЗ выявилось на втором этапе, ну и по сути раз взялся, то решил довести до конца, но оказалось не так то просто.
Сейчас без раскрытия стратегии постараюсь изложить факт усложнения ТЗ, чтобы уже коллеги программисты реально оценили, на сколько данный факт усложняет разработку.
В основе лежит графическое построение уровней, от которых следует открывать ордера. С ходу на краю графика не обращаясь к истории эти уровни не построить, нужно ждать пока наберется история или просто сделать так чтобы советник сам обратился к истории и к краю графика пришел уже с какими то данными. Так и было решено сделать.
Изначально представлялось что мы бежим по свечкам, оцениваем 4 параметра (Open,Close,High,Low) и делаем построения опираясь на условия. Так и была сделана первая часть на старшем ТФ (ТЗ разбито на 3 части, 3 ТФ для каждого из которого разные построения и условия для этих построений). Когда перешли ко второму ТФ и начали тестировать по сути уже готовую вторую часть, выявились ошибки, и при общем обсуждении их оказалось что свечу в истории нужно отслеживать онлайн (то есть, так как будто она нулевая на краю графика) и делать перестроения когда свеча еще не закрыта, что при пробегании по истории не реально, тк по факту имеется 4 параметра Open,Close,Low,High.
Общим обсуждением было принято решение о том что свечу нужно углубляться и ращеплять ее до м1, чтобы по максимому отследить онлайн построение свечи (как будто она нулевая на краю графика). Предложение оставить построение истории как оно есть по 4 точкам, а правильную логику отслеживать уже на краю графика (когда Close[0] плавающий) было отклонено. Заказчики сами поняли что этот факт выявленный в процессе разработки значительно усложняет ТЗ. Уже на том этапе хотел отказаться от разработки, но тк первый этап был уже сделан, и не совсем это в моих принципах бросать разработку по центру решил продолжить. В процессе адаптации уже существующего алгоритма к тому что бежать нужно по М1, а отслеживать старшие ТФ ко мне начал приходить психоз, от того что убил на это огромное количество времени, в процессе того что не получалось срывался и писал заказчикам что нужно поднимать цену разработки, но когда отходил от компьютера и немного остывал от того что не получается продолжал править.
Предложил повременную оплату просто потому что сил тянуть проект за оговоренную сумму уже не было. Хотя предлагал отдать исходник, чтобы возможно нашли того кто доведет до ума.
По сути, если бы изначально знал что отслеживать нужно м1 внутри старшего тф, построил бы логику советника по другому.
Сейчас работаем по такому принципу, что мне присылают скрин с ошибкой в построении, я это правлю. Проверить самому все возможности реально нет, тк в стратегии огромное количество условий, которые по факту даже не помню. Согласовать их все, чтобы друг с другом не конфликтовали, вот главный трабл получается. Делалось все постепенно и сами заказчики признают что стратегия сложная для понимания, но в общем то сейчас уже почти все прописано, но спотря как это работает я даже не могу понять правильно или нет )))
Последнее на чем остановились, это тот случай, который не был учтен (даже по словам представителя заказчиков) и теперь нужно написать, вклинить и согласовать с десятком других условий еще одно. Поэтому переход на почасовую оплату со своей стороны считаю оправданным.
82Dmitry82, если хотите, можем лично с Вами пообщаться по советнику, контакты мои у вас есть. Другой советник я Вам делал, думаю оценили оперативность и поддержку, но с этим попрошу терпения, иногда откладываю работы по нему, просто потому что нет понимания с какой стороны к нему подойти, чтобы начать править очередное неверное построение уровней.
На данный момент в советнике более 1000 строк кода, и это только построение уровней, без всякой красивой мешуры и даже ордеров, до которых еще не дошли.
из описания ясно ,что проработанного ТЗ не было и задание выглядит так: сделай мне вот эту стратегию и она так работать должна, попутно придумай как все это реализовать, алгоритма как такового нет.
В таком случае, это работа трудоемкая, как я писал выше, программист начинает думать, а цена размышлений у каждого своя. Поэтому цена может быть и оправданной.
разделение труда не зря придумали. В понимании заказчика программист это волшебник, который может переложить на код любую идею. По факту квалификация человека и компетенции всегда ограничены и в больших компаниях есть разделение на человека, который составляет алгоритмы, на архитектора и уже на программиста, у каждого своя специализация. Вот и получилась такая ситуация.
Давайте я вас поддержу.
У меня конечно не совсем такая, но похожая стратегия. Учитывает уровни поддержки/сопр., тренд, развороты, откат и много других вещей, без использования внешних(пользовательских) индикаторов.
Я по этой стратегии торговал руками 3 года. Всё это время думал как ее реализовать и запрограммировал в течение года. Получилось меньше 2000 строк.
Все разработчики, которые умеют торговать руками, то им легче когда на основу анализа берут какие-то бары.
Но бар, даже если это М1, то это уже прошлое. Строить на барах (тем более на старших) какую-то стратегию, это бессмысленно.
Надо все делать обрабатывая каждый тик.
Вот в моей программе нет ни одного массива (в абсолютном смысле), и не анализирую то, что было в прошлом. Но нужных контрольных точек конечно запоминаю в реальном времени (не в массивах).
Скажу короче: То что делается руками и так легко и красиво рисуется на графике, не всегда возможно запрограммировать.
запрограммировать то можно все что угодно, но для этого сначала нужно разработать алгоритм, а это большая часть работы. По сути нужно превратить то ,что видишь сначала в формулы и логику, а потом их запрограммировать. И вот первое очень часто недооценивается.
Давайте и я подключусь к обсуждению, раз пошла такая пьянка )))
....
По сути, если бы изначально знал что ....., построил бы логику советника по другому.
....
Знакомая ситуация. Перед тем как начать писать код заранее планируешь его структуру и логику работы, но когда уже после того как алгоритм готов и полностью функционирует к нему начинают добавлять какие те еще условия и новый функционал, то в конце концов возникает ситуация, что проще пересмотреть всю структуру и полностью заново переписать всю логику, чем дальше продолжать пытаясь впихнуть в старый алгоритм, какую то новую концепцию. Получается, что проще заново все переосмыслить с учетом новых функций и условий и переписать алгоритм, но на это требуется куча времени.
хорошая иллюстрация для "результат работы без проекта"
все друг-другом недовольны, выхлоп ноль..