Фичи и баги OWEN Logic

[Sergej_]

На самом деле там скорее всего что-то типа 24.99999 при таком раскладе лоджик округляет до 25, а откидывая 0.99999 после TO INT получается 24, это легко проверить в симуляции.

О том и речь, и capzap доходчиво объяснил причину. . В силу специфики предсавления ОЛ держит в "уме" 24,99999 , а показывает на холсте 25.Хотя математически, то истинное число 25 как не считайте. Причем ошибка возникает не всегда . Стало интересно, по быстрому провел небольшой эксперимент например (float)1,2+08 ->(uint)120000008. (float)4,2+08 ->(uint)419999968 . В результате эта ошибка " кочует" дальше по всей цепочке. И возникает она далеко не всегда. И если бы преобразование это учитывало, то было бы все окейно, но это не так.

[СергейНовосиб]

Привет! У меня после обновления ОЛ появился баг: иногда исчезает надписи с экрана, мигает где-то на 0,5-1сек. Закономерности пока не уловил. Все происходит спонтанно.

Уже на трех ПР200-х это происходит. Последняя версия ОЛ.

[Sergej_]

Странно почему не отображаются знаки после запятой, но смысл такой, если значение например 24,8 после преобразования будет 24, если 25,5 то на выходе 25, я думаю это и наблюдаем.

Наблюдаем как раз обратное. До преобразования 25, или более , если предположить что не отображается дробная часть (а это не так ,получается ровно25) , после преобразования должно быть 25. а не 24. Это глюк ол ,причем в макросе conv4-20 нет округления, а косяк вылазит после него только.

[capzap]

это не совсем глюк ОЛ, это общая проблема, но разработчики могли бы учесть такое с константами owen.png
как только константы окажутся без приведения к типу округление будет равно 25
owen.png


такое преобразование решит проблему
owen.png

[Евений]

Всем Спасибо! Воспользуюсь примером от capzap.

[capzap]

Всем Спасибо! Воспользуюсь примером от capzap.

возможно хватит просто умножить на 0.5 и конвертировать в целочисленное. Я исходил из того, что число 24.9999 уже отображается в научном формате как 25, поэтому начал с дискретного округления до трех знаков, поэтому код такой сложный

[Евений]

возможно хватит просто умножить на 0.5 и конвертировать в целочисленное. Я исходил из того, что число 24.9999 уже отображается в научном формате как 25, поэтому начал с дискретного округления до трех знаков, поэтому код такой сложный

Хорошо попробую

[Sergej_]

это не совсем глюк ОЛ, это общая проблема, но разработчики могли бы учесть такое с константами owen.png
как только константы окажутся без приведения к типу округление будет равно 25
owen.png


такое преобразование решит проблему
owen.png

Cпасибо, разъяснили . Вам ОВЕН должен. Т.е проблема возникает в 6-7 разряде после запятой, иногда в плюс, иногда в минус, когда в минус, то такая ошибка проявляется при преобразовании. Тут очевидно ,что если нельзя устранить саму причину возникновения ошибки в силу объективных причин, то преобразовать из float в int можно например предварительно округлением в 5 разряде после запятой. Ведь при отображении значений float на холсте так и происходит.И это наверное разработчики ОЛ должны исправить, а не пользователи .

[capzap]

Все не так, в пр используется формат вещественных чисел IEEE 754, а отображение ол написано стандартным средствами и там скорее всего float64 или Double, поэтому и идёт расхождение в представлении числа, а ни как не в самой арифметике. И напомню что это частный случай, если разработчики сделают подобные округления повсеместно, то прога будет работать намного медленнее, а что то сделать в конкретной ситуации этим должен заниматься автор проекта

[Sergej_]

Все не так, в пр используется формат вещественных чисел IEEE 754, а отображение ол написано стандартным средствами и там скорее всего float64 или Double, поэтому и идёт расхождение в представлении числа, а ни как не в самой арифметике. И напомню что это частный случай, если разработчики сделают подобные округления повсеместно, то прога будет работать намного медленнее, а что то сделать в конкретной ситуации этим должен заниматься автор проекта

Пока писал ,не видел этого Вашего сообщения, понятно, что дело не в ошибках арифметики, но эта особенность гипотетически может привести к какам -то ошибкам. А этот "частный случай" еще и засечь нужно, автор вопроса скорей всего случайно обнаружил. А если не обнаружил, то как это сказалось бы на результате? может и никак ,а может и сказалось . В описании ОЛ про это ничего нет. Теперь будем хотя бы знать, спасибо.