Подсветка переменных записываемых в конце цикла

[Валенок]

Вроде понял, что Вы хотите

Не совсем

В смысле всегда использовать один макрос DINT(INT32)_TO_FLOAT.

Не только. Особенность целочисленных вычислений - абсолютная точность.
В целых никогда не будет x = (x + y) если y <> 0

Если надо преобразовать INT(INT16),

int16 может только извне прилететь. А внутренним вычислениям все равно.

чаще всё-таки INT(INT16) встречается, а DINT(INT32) намного реже.

Да? А что тогда здесь udint а не uint? Нету противоречий?
В 16-ти битах было тесно даже 50лет назад. А необходимость 64-х битов даже сейчас - экзотика.

чем ваше промежуточное преобразование в DINT(INT32).

Оно есть только в 1 случае - если извне пришло int16. И оно 1 раз. Далее нет никакой необходимости выбирать между 16 и 32 и думать - влезут ли промежуточные вычисления в 16 бит. А к моменту когда вычисления не влезают в 32 бита, float уже давно положил на точность.

Вам надо всё равно знать, что это INT(INT16),

И Вам все равно надо это знать. Давайте не будем общую (мою и Вашу) часть проблем называть моей проблемой?

И, мне кажется в FBD проще значение INT(INT16) сразу преобразовать во FLOAT,

Вам кажется. Любое целое во флоат везде одинаково просто. Касаемо ST - я приводил выше эти 5 строк.

Если Вы говорите в ST это проще, поверю Вам на слово(я в ST не шарю), но это получается частный случай, не более!

Я понимаю что ссылки по Вашим ссылкам доходят до "времен Очакова и покоренья Крыма" (практически буквально) - но ST какой никакой уже есть. Что касается частных случаев, то всё на ФБД и т.п графическом является частным случаем текстовых языков а не наоборот.

[Сергей0308]

Не совсем

Не только. Особенность целочисленных вычислений - абсолютная точность.
В целых никогда не будет x = (x + y) если y <> 0


int16 может только извне прилететь. А внутренним вычислениям все равно.


Да? А что тогда здесь udint а не uint? Нету противоречий?
В 16-ти битах было тесно даже 50лет назад. А необходимость 64-х битов даже сейчас - экзотика.


Оно есть только в 1 случае - если извне пришло int16. И оно 1 раз. Далее нет никакой необходимости выбирать между 16 и 32 и думать - влезут ли промежуточные вычисления в 16 бит. А к моменту когда вычисления не влезают в 32 бита, float уже давно положил на точность.


И Вам все равно надо это знать. Давайте не будем общую (мою и Вашу) часть проблем называть моей проблемой?


Вам кажется. Любое целое во флоат везде одинаково просто. Касаемо ST - я приводил выше эти 5 строк.


Я понимаю что ссылки по Вашим ссылкам доходят до "времен Очакова и покоренья Крыма" (практически буквально) - но ST какой никакой уже есть. Что касается частных случаев, то всё на ФБД и т.п графическом является частным случаем текстовых языков а не наоборот.

Так не надо так глубоко копать, так не мудрено дойти и до царя Гороха!
Короче, вот добавил в макрос преобразование INT в DINT и обратно и вход выбора типа данных, диапазона INT/DINT.
Если на входе выбрали INT, то на дополнительном выходе(что я добавил) преобразуется в DINT и обратно, если на входе выбрать DINT, то на выходе преобразуется в INT, если диапазон не превышать! Надеюсь, понятно объяснил?

INT_TO_FLOAT_11.PNG

INT_TO_FLOAT_5.owle

[Сергей0308]

В обратно особой надобности нету.


.. то при любых* вычислениях с int32, младшее слово всегда содержит int16 (а биты 16..31 (int32-ого) всегда повторяют 15-й)
*Даже если какие-то промежуточные выходили за рамки int16 (но были в рамках int32)

a : int16 = 1000;
b : int16 = -1000
c : int16 = 10000

x := (a * b) / c
//(1000 * -1000) / 10000 = -100 (int16)

В рамках int16
1000 * -1000 => -16960
-16960 / 10000 => -1

В рамках int32
1000 * -1000 => -1000000
-1000000 / 10000 => -100 (FFFFFF9C) int32 => (FF9C) int16 => -100

На форуме много раз говорили, что математические действия с переполнением будут верными, рискнул так сделать, тогда функция упростится, станет одной для разных действий, короче, вроде правильно считает(сильно не проверял), заодно и "причесал":

INT-DECOD_1.png

INT-DECOD_2.png

INT-DECOD_1.owle