Мт4 Конец поддержке. - страница 29
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Главное минус: ООП заставляет идти по пути дробления кода на множество функций.
Для человека легче воспринимать раздробленный код, но раздробленность противопоказана любому механизму.
Все верно, только какой же это минус ???
Это же и есть самый главный плюс ! Именно потому, что человеку легче воспринимать раздробленный код !
Компьютер должен подстраиваться под человека, а никак не человек под компьютер.
Все верно, только какой же это минус ???
Это же и есть самый главный плюс ! Именно потому, что человеку легче воспринимать раздробленный код !
Компьютер должен подстраиваться под человека, а никак не человек под компьютер.
Увы, разработчик должен в первую очередь думать об эффективности своего механизма, а не о своем комфорте.))
Иначе механизм будет "хромать".
Разработчик должен подстраиваться под компьютер.
Если котировки приходят с одного сервера, то разницы какой инструмент нет. Ведь на каждом инструменте бары открываются одновременно.
Другое дело, если источники котировок находятся в разных частях света. Для минуток это не имеет значения, но с более старшими таймфреймами может быть проблема. Возможно, нужно более подробно изучить временные функции и сделать точную корректировку по времени. Но это уже следующий этап развития этого решения...
Нужно сделать калибровку для этой функции...
Сначала я хотел прочесть всё что написано без меня, вдруг уже и вопрос и ответ был, но боюсь сложно будет потом найти пост который надо процитировать.
Пока только 1 вопрос: Как всем известно, новый бар не появится пока не будет первый тик в новом временном интервале. Соответственно если по миллисекундам бар должен быть, а его нет, то и показания индикатора можно получить с не того бара.
На второй вопрос надеюсь найду ответ, его задал Артём.
Сначала я хотел прочесть всё что написано без меня, вдруг уже и вопрос и ответ был, но боюсь сложно будет потом найти пост который надо процитировать.
Пока только 1 вопрос: Как всем известно, новый бар не появится пока не будет первый тик в новом временном интервале. Соответственно если по миллисекундам бар должен быть, а его нет, то и показания индикатора можно получить с не того бара.
На второй вопрос надеюсь найду ответ, его задал Артём.
Да, мы это вчера обсудили.
Раньше я имел дело с другой платформой, и там бары формировались по времени, независимо от прихода котировок (посмотрите в TWS).
Мне сказали, что в МТ это не так.
Я добавлю проверку прихода котировки для подтверждения события появления нового бара.
Я уже ответил, что бары открываются независимо от прихода котировок. Если нет котировки, цена нового бара будет ценой закрытия предыдущего. Факт нового бара будет зафиксирован независимо от прихода котировок, самими счетчиками, которые работают на таймере.
Конкретный таймфрейм не имеет значения, потому что это просто счетчик, который достигает своей величины и устанавливается событие нового бара этого таймфрейма. Это просто метод синхронизации с появлением новых баров разных таймфреймов. СИНХРОНИЗАЦИИ.
Инструмент тоже значения не имеет. Если котировки из одного сервера, то значит, время появления новых баров у них одно. Поэтому, не важно какой инструмент, пока эти инструменты из одной точки земного шара.
Я закончу то, что сказал и займусь другим вещами. Хорошего по-немногу.)
А чем объяснить тот факт, что закрытие пятницы, предыдущий бар любого периода равен 1.20333 а открытие понедельника так-же любого периода равно 1.20142
Это конечно котировки одного брокера, у другого может чуток отличаться, но разница есть у всех.
А чем объяснить тот факт, что закрытие пятницы, предыдущий бар любого периода равен 1.20333 а открытие понедельника так-же любого периода равно 1.20142
Это конечно котировки одного брокера, у другого может чуток отличаться, но разница есть у всех.
Это объясняется гэпом. При открытии сессии такое случается.
Я не большой специалист в трейдинге, так что не судите строго мое мнение.)
И то, что происходит на форексе мне известно еще меньше.))
Увы, разработчик должен в первую очередь думать об эффективности своего механизма, а не о своем комфорте.))
Иначе механизм будет "хромать".
Разработчик должен подстраиваться под компьютер.
Ну нет.
Это пусть компьютер под меня подстраивается. У меня и других проблем хватает. Разработчик может подстраиваться только там, где компьютер "не вытягивает", скажем, в "узких местах", где не хватает быстродействия или памяти. Тогда, да, очередь подстраиваться разработчику. Но, я пока ни разу не натыкался на места, где бы ООП давало такую существенную дополнительную нагрузку на компьютер, что приходилось бы как-то ее уменьшать.
ну что-то вроде того (код для MQL5):
Но я повторюсь - я сторонник ООП.
Просто, действительно, неудачный пример для того, чтобы показать, что невозможно сделать при процедурном программировании.
Когда я это затеял, я не предполагал показать что что-то возможно\невозможно сделать, а всего лишь удобней для использования в дальнейшем при написании своих кодов.
Но получилось, как говорил В.С., хотел как лучше, а получилось как всегда.
Ну нет.
Это пусть компьютер под меня подстраивается. У меня и других проблем хватает. Разработчик может подстраиваться только там, где компьютер "не вытягивает", скажем, в "узких местах", где не хватает быстродействия или памяти. Тогда, да, очередь подстраиваться разработчику. Но, я пока ни разу не натыкался на места, где бы ООП давало такую существенную дополнительную нагрузку на компьютер, что приходилось бы как-то ее уменьшать.
Нагрузку на компьютер дает халатное отношение разработчика к вопросу слаженности своего механизма. Желание экономить силы на совершенствовании системы. Неразумный расход ресурсов компьтера во имя облегчения своей работы.
Пока компьютер успешно справляется с неэффективно написанным кодом, разработчик будет и дальше "паразитировать" на вычислительных мощностях. Это тупиковый путь.
Рано или поздно, неэффективный механизм прекратит развиваться и будет заменен более совершенным аналогом.
Время и силы человека будут потрачены зря, а его детище окажется в мусорном баке.
В мире конкуретной борьбы этот риск существует постоянно.
Конструируя механизмы, мы должны думать об их характеристиках в первую очередь, а о комфорте и удобстве проведения своих рабочих часов - во вторую.))
Нагрузку на компьютер дает халатное отношение разработчика к вопросу слаженности своего механизма. Желание экономить силы на совершенствовании системы. Неразумный расход ресурсов компьтера во имя облегчения своей работы.
Пока компьютер успешно справляется с неэффективно написанным кодом, разработчик будет и дальше "паразитировать" на вычислительных мощностях. Это тупиковый путь.
Рано или поздно, неэффективный механизм прекратит развиваться и будет заменен более совершенным аналогом.
Время и силы человека будут потрачено зря, а его детище окажется в мусорном баке.
В мире конкуретной борьбы этот риск существует постоянно.
Конструируя механизмы мы должны думать об их характеристиках в первую очередь, а о комфорте и удобстве проведения своих рабочих часов - во вторую.))
Это называется преждевременная оптимизация. Разработчику кажется, что он оптимизирует что-то, но в итоге оказывается, что оптимизировать нужно было совсем в другом месте. До момента окончания написания программы такие места точно указать невозможно. Поэтому сначала пишется правильно работающий (и удобочитаемый любым другим разработчиком) код, а только потом уже оптимизируется, если там вообще есть, что оптимизировать.