Некорректно переводит float в integer

[acidzone]

Всем доброго времени суток. Пытаюсь написать макрос счетчика для приборов учета воды, столкнулся с некорректным переводом из float в int, на скриншоте из режима эмуляции видно, что 56 float переводится в 55 integer. 2,11 разделяется как 2 и 10, 2,15 - корректно, 2 и 15. 2,05 - 2 и 4. Прошу пояснить, с чем это связано и что я делаю не так? Также интересует вопрос, как можно сохранить значения счетчиков в энергонезависимой памяти при обновлении программы? Цель данной части проекта - учитывать дистанционно показания приборов учета, поэтому при обновлении программы неприемлема потеря данных. Спасибо.

[acidzone]

А нельзя ли ссылку на тему? Поиском не нашел. И про сохранение данных есть какое-то решение? За решение с преобразованием спасибо, все заработало.

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

А нельзя ли ссылку на тему? Поиском не нашел. И про сохранение данных есть какое-то решение? За решение с преобразованием спасибо, все заработало.

Вижу только вариант, переписать значения и после обновления внести эти значения, хотя не очень понятно, зачем обновлять то, что уже работает.

[acidzone]

Например, расширение функционала, исправление багов. В будущем хотелось бы видеть возможность менять программу без удаления значений в энергонезависимой памяти, по галочке какойнибудь. Вот как быть с реализацией - это вопрос.

[dan75]

Ннуу, ващета, на мой взгляд, это и правда баг ОвенЛоджика. Тему старую не нашёл. Поменял порядок действий так, чтобы максимум операций выполнялось с числами в формате int. Вроде заработало. Что делает часть программы со счётчиками, не вникал; в своей тестовой версии просто заменил её константой 100.
57273

По поводу сохранения значений. Пытался сделать вариант с резервным копированием переменных из мастера в слейв и наоборот. И, соответственно, последующим восстановлением после обновления программы. Но до практической реализации, увы, не дошло. Пока действую, как говорит Юрий: бумажка, карандашик и вперёд.

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

Ннуу, ващета, на мой взгляд, это и правда баг ОвенЛоджика.

Нужно просто учесть, что X->I не делает округление, он просто отбрасывает все что после запятой, для него что 5.1 что 5.9 на выходе 5.

[dan75]

Нужно просто учесть, что X->I не делает округление, он просто отбрасывает все что после запятой, для него что 5.1 что 5.9 на выходе 5.

Я это знаю, да. Фокусы почему-то начинаются при экспоненциальном представлении числа.
57287

[Сергей0308]

В начальной школе это называется стандартным видом числа:
https://math-prosto.ru/ru/pages/standard_form_number/standard_form_number/
В какой-то теме уже обсуждали этот вопрос!

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

Я это знаю, да. Фокусы почему-то начинаются при экспоненциальном представлении числа.
57287

Да, это интересно, я проверил на старой версии такая же история. Все становится понятно если умножить значение на 1000, видимо отображение на холсте отличается от представления в логике, там проходит 0.559

[Сергей0308]

и как эта ссылка отвечает на вопрос почему 56.0 превращается в 55?

Неужели это может быть непонятным?
Потому, что в таком представлении в ОЛ значение округляется, если быть точным это происходит при округлении в большую сторону, даже целочисленные значения округляются(если значения большие). Так в программе сделано, чтобы сократить длину(количество занимаемых знаков), насколько я понимаю! И это много раз обсуждалось. Вы уж точно видели подобные обсуждения! Например в константе значение 1000000001 округлится до 10 в 9-ой степени!

57297

И 999999999 до 10 в степени 9:

57298

Да, про ссылку забыл, ссылка лишь намекает, что лучше ёжика называть ёжиком, а не сусликом или ещё там как, чтобы всем понятно было, что Вы хотите сказать, для этого и разные слова придумали, иначе было бы достаточно одно слово придумать и называй им всё попало!

Это, как раз наш случай!

[Сергей0308]

да, не понятно, каким образом статья про стандартный вид числа отвечает на вопрос, что в неком приложении ОвенЛоджик округление вещественных чисел идет по одним правилам, а экспоненциальная запись совершенно по противоположным правилам
И даже если взять как бы первоисточник
https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D 1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0 %B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C
про округление там ни чего не сказано

Если Вы прослеживаете какую-то взаимосвязь, не томите народ, поделитесь вашими открытиями! Я такой лабудой голову не забиваю!

[Филоненко Владислав]

Итак, реальное число 59.95, отображение с одним знаком после запятой - 60, преобразование работает не с отображением а с реальным числом и даёт 59
Всё просто, никакой ошибки.

[Сергей0308]

так и я про то же и сделал Вам замечание, зачем давать с пафосом ссылки если они не на что не отвечают
, голову включать надо

Так объясните, не надо пустословием заниматься, что не так со стандартным видом числа? Он позволяет сократить до минимума число используемых знаков, при этом само значение остается в легко понимаемом виде!

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

реальное число это в примере 2.56, обрезав целую часть и умножив на сто в каком языке программирования будет 55? Что бы не считать это ошибкой

При чем тут 2.56?57302

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

57303 наглядно, пример который я обычно привожу про не стыковки вещественных чисел, не проходит проверку
а этот пример должен работать и в ОЛ тоже, но этого не происходит,

Да я уже увидел, до этого я как-то не обратил внимание что там вычитание, думал умножение на 2

[keysansa]

Тему почистили что-ли? Не вижу сообщений, которые процитированы...

[capzap]

нашел я подобный разговор, про округление именно чисел формата ieee754 https://owen.ru/forum/showthread.php?t=12264&p=353358&viewfull=1#post353358
Был не прав, разность 2.56 - 2 подпадает под эту же проблему, решение на последнем скрине из приведенной сылки