Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Проще наверное, просто считать в дополнительном коде...
PS Большое отрицательное число - это еще не переполнение, просто в старший разрад попала единичка. То есть до переполнения еще полпути.
Так-то оно так, но советник уже перестал работать в штатном режиме. Принтинг переменных показал это число. Советник ожидал постоянное наращивание, что текущее будет больше предыдущего, а тут раз и наоборот. Советник и я вместе с ним такого не ожидали. Теперь есть опыт)))
может есть смысл мерять разность по модулю ?
Ну дак я так и хотел... Но для этого надо снова смоделировать полупереполнение и удостовериться, что отрицательное число по модулю растёт. Алексей (Meat) выше писал, что отрицательно число будет по модулю уменьшаться, то есть двигаться к нулю.
Ну вот можно так смоделировать:
Может примерно так сделать:
Думаю тут без приведения к double не обойтись. По крайней мере если рассматривать общий случай, когда между соседним замерами может пройти количество тиков превышающее 0x7FFFFFFF.
Вот набросал такой вариант приведения:
Ну либо приводить уже непосредственно при подсчёте разницы:
Может примерно так сделать:
if (nTickNew ^ nTickOld) {это следующий тик}
Эмм запустите этот код:
И прекратите эту бессмысленную дискуссию.
Думаю тут без приведения к double не обойтись. По крайней мере если рассматривать общий случай, когда между соседним замерами может пройти количество тиков превышающее 0x7FFFFFFF.
Эмм запустите этот код:
И прекратите эту бессмысленную дискуссию.
Вы правы, действительно в обычных случаях не стоит заморачиваться. Дополнительные манипуляции нужны только если дельта между x1 и x2 будет больше 0x7FFFFFFF. Т.е. разговор нужно было вести не о переполнении счётчика, а о переполнении дельты.