05-09-2025, 09:25 PM
Hi
interesting behaviour, I think of this is a copy of CINT issue (also that hidden into INT keyword)
I run your demo but for my weakness I need to add the name at the column of data showed.
![[Image: immagine-2025-05-09-225828179.png]](https://i.ibb.co/7xZv34tz/immagine-2025-05-09-225828179.png)
we can observe that i as INTEGER variable takes the value of X that is a single variable.
So I expect that i takes the unity loosing the digits after the point . as we can get with i=fix(x), instead x has been transformed into integer like i = cint(X) and for this reason it works following the financial math rule for rounding.
(I think to know WHY financial rounding works in this manner, the first rounding is down the second is up and again this cycle for infinite times.
Talking about money to give or to take, in the first turn the excess of money has been taken, in the second turn it has been given. The bank always wins! Before take and after give
)
What do I find weird in this output?
1.
the output of .8 and .9 in the X column. (.8000001 and .9000001) ????
2.
the 11th row in which X = 1 (I assume 1.00) and i = 1 so i vs x gives EQUAL (1 = 1.00) instead x vs i gives Rounded down (1.00 vs 1), while at the first row X = 0 (I assume 0.00) and i = 0 so i vs x gives EQUAL and x vs i gives EQUAL
3.
i vs x gives always EQUAL
the BUGWARD compatibility is the price to pay
As showed by Jack also Freebasic uses the same BUGWARD rule.
interesting behaviour, I think of this is a copy of CINT issue (also that hidden into INT keyword)
I run your demo but for my weakness I need to add the name at the column of data showed.
![[Image: immagine-2025-05-09-225828179.png]](https://i.ibb.co/7xZv34tz/immagine-2025-05-09-225828179.png)
we can observe that i as INTEGER variable takes the value of X that is a single variable.
So I expect that i takes the unity loosing the digits after the point . as we can get with i=fix(x), instead x has been transformed into integer like i = cint(X) and for this reason it works following the financial math rule for rounding.
(I think to know WHY financial rounding works in this manner, the first rounding is down the second is up and again this cycle for infinite times.
Talking about money to give or to take, in the first turn the excess of money has been taken, in the second turn it has been given. The bank always wins! Before take and after give

What do I find weird in this output?
1.
the output of .8 and .9 in the X column. (.8000001 and .9000001) ????
2.
the 11th row in which X = 1 (I assume 1.00) and i = 1 so i vs x gives EQUAL (1 = 1.00) instead x vs i gives Rounded down (1.00 vs 1), while at the first row X = 0 (I assume 0.00) and i = 0 so i vs x gives EQUAL and x vs i gives EQUAL
3.
i vs x gives always EQUAL
the BUGWARD compatibility is the price to pay
As showed by Jack also Freebasic uses the same BUGWARD rule.