Фичи и баги OWEN Logic

[Sergej_]

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


такое преобразование решит проблему
Вложение 54467

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

[Ревака Юрий]

Так вроде на входе блока INT целое 25 а на выходе 24?

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

[capzap]

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

[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 . В результате эта ошибка " кочует" дальше по всей цепочке. И возникает она далеко не всегда. И если бы преобразование это учитывало, то было бы все окейно, но это не так.

[Sergej_]

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

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

[stesel]

В макросе BM_in из менеджера компонентов ошибка - константа (та что подписана - Сдвиг) должна быть 7, а не 8

[stesel]

В макросе BM_in из менеджера компонентов ошибка - константа (та что подписана - Сдвиг) должна быть 7, а не 8

А нет, не так, в первом бите не нужно просто добавлять ни чего, это ж нулевой бит, а не первый.

[capzap]

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

Ещё раз говорю, это не проблема ОЛ, на любом языке какой знаете, сложите два 32-битных числа 0.3 и 0.4 и проверьте на равенство с 0.7

[ErsaFap]

OL 1.19.268
Windows 7 64
При объявлении переменных в макросе отображение имен переменных в списке переменных не совпадает с реальными, если открыть таблицу перменных.
Screenshot_95.png
Screenshot_97.png
Screenshot_96.png

При сохранении макроса, его закрытии и последующем открытии отображается верно.

[b-s-a]

В версии 1.19.268.0 не работает синхронизация входов/выходов макросов со схемой (кнопочку нажимал). Создаешь макрос, группируешь входы, а в схеме они перемешаны в хаотичном порядке. Даже удаление макроса из схемы и добавление заново не помогает. Мне вообще не понятно, зачем автоматически менять порядок входов макросов? Я бы понял, если бы можно было поменять вручную на схеме.