Немного удивлен :) Решил поделиться и задать НЕ риторический вопрос. - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я же говорю - начинающие... Понимание с опытом придет.
Хороший аргумент. Ничего не скажешь. :)
С начинающим вы погорячились. Мы сейчас о чем начинаем спорить? :)
Откройте для себя математику. :)
==
Дополню - может кто-то займется ... смотреть начинать надо тут
http://en.wikipedia.org/wiki/%E2%84%9A
и тут http://demonstrations.wolfram.com/RationalNumberExplorer/
и тут http://www.solarix.ru/for_developers/cpp/boost/rational/ru/rational.shtml
Смайлы в последующих Ваших постах будут вырезаны. Учитывайте это.
Особых преимуществ перевод цен в целочисленные не дает. Да, оно эффективно уменьшает объемы, но во много раз теряет скорость из-за неибежного перекодирования в double. Именно неизбежного, ибо не получится сделать абсолютно всю систему целочисленной, вычислимую математику все равно придется делать в double(точности которого даже не хватает).
Поддерживаю. Поэтому и написал ранее:
P.S. В цифрах у вас явная неточность: не может история в INT занимать 2.1Gb, а в DOUBLE - 7Gb. Разница должна быть всегда ровно в 2 (USHORT не хватит) раза. Переход на целочисленную арифметику с ценами дает значительное преимущество, когда в советнике вся логика может быть заменена на целочисленную. Это случается не часто.
У меня в наитупейшей наичастнейшей, но наибыстрейшей считалке все на целых, потому как там только операции сложения, вычитания и сравнения. Переход от INT к DOUBLE, соответветственно, не нужен.
Вообще, алгоритмическая оптимизация в частных случаях всегда дает преимущество в скорости выполнения (не написания) перед универсальным подходом. Поэтому, например, если советник использует автооптимизацию своих параметров, то вопрос скорости автооптимизации очень важен. И разумно создавать либо в DLL, либо прямо на MQL5 свою максимально алгоритмически оптимизированную считалку. И не использовать для случаев автооптимизации MT5-оптимизатор. К сожалению, MT5-оптимизатор для советников с автооптимизацией годится для сильно ограниченных случаев.
Поддерживаю. Поэтому и написал ранее:
У меня в наитупейшей наичастнейшей, но наибыстрейшей считалке все на целых, потому как там только операции сложения, вычитания и сравнения. Переход от INT к DOUBLE, соответветственно, не нужен.
Вообще, алгоритмическая оптимизация в частных случаях всегда дает преимущество в скорости выполнения (не написания) перед универсальным подходом. Поэтому, например, если советник использует автооптимизацию своих параметров, то вопрос скорости автооптимизации очень важен. Поэтому разумно создавать либо в DLL, либо прямо на MQL5 свою максимально алгоритмически оптимизированную считалку. И не использовать для случаев автооптимизации MT5-оптимизатор. К сожалению, встроенный оптимизатор для советников с автооптимизации годится для ограниченных случаев.
Приведите пример когда не обойтись без перевода в double?
Встречный пример например надо вычислить процент чего либо или вероятность.
В первом случае мы принимаем пункт за 0.0001 процента и тогда 1.2345% будет 12345 пунктов.
С вероятностью тоже самое.
Всегда надо понимать, что разрядность даже double ограничена и всегда есть такое понятие как скрытые пункты.
Приведите пример когда не обойтись без перевода в double?
Встречный пример например надо вычислить процент чего либо или вероятность.
В первом случае мы принимаем пункт за 0.0001 процента и тогда 1.2345% будет 12345 пунктов.
С вероятностью тоже самое.
Всегда надо понимать, что разрядность даже double ограничена и всегда есть такое понятие как скрытые пункты.
Ну надо же, какая засада! Человечество развивает науку о числах в ложном направлении. Совершенно напрасно придуманы вещественные числа, и тем более, комплексные. - очень просто некоторые, оказывается, обходятся рядом целых чисел!
Примера не вижу?