Ошибка в функции MathCeil() или в логике округления данных - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да. Ошибка присутствует, но не в функции MathCeil().
В оптимизаторе кода нашего компилятора операция деления на константу заменялась на операцию умножения на преобразованную константу (1.0 / <initial_const>). За счёт этого в приведённом примере потерялась точность в выражении d1/7000.
Спасибо за поднятый вопрос. В ближайшее время будет доступен новый билд с исправлениями.
MathCeil() - функция, теоретически разрывная в целых точках. Практически в языке она может терпеть разрыв, как только аргумент попадает в эпсилон-окрестность целого (об эпсилон см. выше). Ни о каких гарантиях точности вычисления в этой окрестности говорить нельзя. Prival, кстати, в твоем примере нет вычисления этой функции.
Не знаю что там за эпсилон. Вот сделал округления в большую и меньшую сторону
Просто с завидной регулярностью, возникают вопросы связанные с типами данных и операциями над ними. И вместо того, что бы трейдер проверял возникшие идеи торговой системы, львиную долю он тратит на отлов ошибок в коде программы. Я понимаю что города не сразу стояться, но стремиться надо к правильному языку, тот что ближе к человеку, а не машине.
To Integer согласен что это языки программирования классифицируются таким образом (высокого и низкого уровня). Для меня язык низкого уровня неправильный (хотя есть задачи, которые вообще можно выполнить только в машинных кодах, когда то программировал и на них).
Я исхожу из понятия эффективности, минимума времени затраченного на проверку идеи. Ведь цепочка временных затрат следующая идея + изучения языка + написание кода + отладка + проверка идеи.
И если смотреть всю цепочку, все время потраченное на проверку идеи то может быть и так, что на отладку алгоритма человек тратит месяцы, и алгоритм проводит расчеты за 1 сек, а можно написать за час и рассчитать за 1 мин. Ответ очевиден, что эффективнее, тем более тут вопрос времени выполнения расчетов не стоит так остро. Если кто то использует Close часы, то до прихода новых данных у него вагон времени и маленькая тележка.
Просто ради примера есть функция OrderSend() и её трейдер долго и упорно дорабатывает допустим до OrderSendReliable(). У меня ушло около 2 лет на это, и то думаю это еще не окончательный вариант. Вон программисты и по круче меня до сих пор все не отловили 'Тестирование функции IsConnected()'
ИХМО не дело тратить 90% времени на проверку возможных ошибок в коде, а 10% на проверку идеи. Нужна обратная пропорция 10% на отладку, остальное изучение и тестирование идей, торговых систем.
ИХМО не дело тратить 90% времени на проверку возможных ошибок в коде, а 10% на проверку идеи. Нужна обратная пропорция 10% на отладку, остальное изучение и тестирование идей, торговых систем.
Так не получится, даже при всем желании, реальность такова, ошибки есть везде, даже в самом продуманном коде, по простой причине человек не автомат и человек может пропустить неточность в связи с тем же эмоциональным состоянием, он просто ее не увидит как бы явно выражена она не была. Чтобы избавится от ошибок нужно избавится от эмоций и рутины, смесь которых пораждает ошибки в творениях человеческих. Иногда нужен свежий взгляд одного человека, на то, что написано другим человеком. В работе например команды еще сложнее, все обладают разным опытом и один может совершить ошибку, которая для него не ошибка, а другой ее просто незаметит, в связи с чем образуется цело звено в команде, разработчики, кодеры, контролеры и т.д.
Кстати, Prival, переменная d1 в примере - какого типа? Целочисленное-то деление в MQL4 корректно, здесь вопросов нет. А вот если специально сделать ее нецелочисленной - какой будет результат? Или в маткаде так низзя?
Маткад сам определяет тип переменной и корректоно выполняет с ней операции, как они это сделали незнаю, но это очень удобно, см. пример выше. число комлексное результат тоже комплексный, матрица действеут как с матрицами.
ИХМО не дело тратить 90% времени на проверку возможных ошибок в коде, а 10% на проверку идеи. Нужна обратная пропорция 10% на отладку, остальное изучение и тестирование идей, торговых систем.
Так не получится, даже при всем желании, реальность такова, ошибки есть везде, даже в самом продуманном коде, по простой причине человек не автомат и человек может пропустить неточность в связи с тем же эмоциональным состоянием, он просто ее не увидит как бы явно выражена она не была. Чтобы избавится от ошибок нужно избавится от эмоций и рутины, смесь которых пораждает ошибки в творениях человеческих. Иногда нужен свежий взгляд одного человека, на то, что написано другим человеком. В работе например команды еще сложнее, все обладают разным опытом и один может совершить ошибку, которая для него не ошибка, а другой ее просто незаметит, в связи с чем образуется цело звено в команде, разработчики, кодеры, контролеры и т.д.
Вы невнимательны, я не говорил про то что отладки не должно быть вообще, она есть и будет, т.е. всегда есть ошибки. Но тратить такое огромное количество времни 90% от всего времени это плохо. Пожет так будет проще показать про что я говорю, создать МА в машинных кодах дольше, чем на СИ, в свою очередь решить систелу линейных уравнений, на Си дольше чем в Маткаде и это связанно именно с отладкой с поиском ошибок в коде.
Не знаю что там за эпсилон. Вот сделал округления в большую и меньшую сторону
Просто с завидной регулярностью, возникают вопросы связанные с типами данных и операциями над ними. И вместо того, что бы трейдер проверял возникшие идеи торговой системы, львиную долю он тратит на отлов ошибок в коде программы. Я понимаю что города не сразу стояться, но стремиться надо к правильному языку, тот что ближе к человеку, а не машине.
To Integer согласен что это языки программирования классифицируются таким образом (высокого и низкого уровня). Для меня язык низкого уровня неправильный (хотя есть задачи, которые вообще можно выполнить только в машинных кодах, когда то программировал и на них).
Я исхожу из понятия эффективности, минимума времени затраченного на проверку идеи. Ведь цепочка временных затрат следующая идея + изучения языка + написание кода + отладка + проверка идеи.
И если смотреть всю цепочку, все время потраченное на проверку идеи то может быть и так, что на отладку алгоритма человек тратит месяцы, и алгоритм проводит расчеты за 1 сек, а можно написать за час и рассчитать за 1 мин. Ответ очевиден, что эффективнее, тем более тут вопрос времени выполнения расчетов не стоит так остро. Если кто то использует Close часы, то до прихода новых данных у него вагон времени и маленькая тележка.
Просто ради примера есть функция OrderSend() и её трейдер долго и упорно дорабатывает допустим до OrderSendReliable(). У меня ушло около 2 лет на это, и то думаю это еще не окончательный вариант. Вон программисты и по круче меня до сих пор все не отловили 'Тестирование функции IsConnected()'
ИХМО не дело тратить 90% времени на проверку возможных ошибок в коде, а 10% на проверку идеи. Нужна обратная пропорция 10% на отладку, остальное изучение и тестирование идей, торговых систем.
Аллилуя!!! Я потратил полгода своей жизни на изучение mq4 с нуля. Сначало все шло хорошо, пока не появилась идея написать в коде и протестировать то что я делал руками и головой.. и тут началось... Респект за OrderSendReliable() !.. Думаю у каждого из тех кто работает на mq4 ета функция своя, отточеная со Sleep(125) или с шаманами и бубнами... только б заработало.. Как только ми освоили или даже нашли ету функцию методом тика и перепроверок, а действительно ли открилась позиция.. а действительно ли по етому тикету.. а действительно ли одна открилась.. и т.д... После етого ми переходим к осваиванию уравнений.. тоесть.. если надо что то с чем то сравнить,. начинаеться.. что double=1, ето уже на самом деле не 1... а 1,000000001 или как там... а потом оказиваеться.. что если сделать 1+1 то не всегда получиться 2... Может хватит издеваться.. или нужно в каждой строке применять NormalizeDouble().. или все переводить в int .. даже цену! А знаете сколько времени я потратил на поиск таких вот ТУПИХ ошибок.. или пардон.. особенностей програмирования... Или надо присвятить полжизни етому .. что б понять.. что в програмировании 1+1 ето не то же что у нас в голове... И даже если такие ошибки присутствуют.. пардон... особенности програмного языка -) ... почему я об етом узнаю не из учебника! а сидя по ночям в поисках ошибки в трех соснах! простите за емоции.. накатило просто... вот сижу и думаю.. а может все действительно переводить в int .. всегда.. ИЛИ ТАМ ТОЖЕ ЕСТЬ СВОИ ОСОБЕННОСТИ ?!)