Oddity of CINT - revisited

[Dimster]

I'm just trying to get my mind around the necessary coding to account for the Banker's Rounding described back in Feb.

Code: QB64: [Select]

1. a = 1.49
2. PRINT "  a @ 1.49 =  "; CINT(a)
3. b = 1.5
4. PRINT "  b @ 1.5 =   "; CINT(b)
5. c = 2.49
6. PRINT "  c @ 2.49 =  "; CINT(c)
7. d = 2.5
8. PRINT "  d @ 2.5 =   "; CINT(d)
9. e = CINT(2.5)
10. PRINT "CINT (2.5) is "; e
11. f = 2.51
12. PRINT "  f @ 2.51 is "; CINT(f)
13. g = 3.5
14. PRINT "  g @ 3.5 is  "; CINT(g)
15. h = CINT(3.5)
16. PRINT "CINT (3.5) is "; h

So if the result of the math formula I am using in my program produces the exact value of ".5", I would need to keep a count of how often the final figure ended exactly at .5 - then if that count is odd, then CINT will round up. If that count is even then CINT will round down? The code here 1.5 and 3.5 rounded up whereas 2.5 rounded down. Have I got that right? And in terms of negative numbers - same applies (or is it the reverse) and rounding up means closer to zero whereas rounding down means further from zero.

[Dimster]

Think I will avoid using CINT. Seems the difficulty only arises if the decimal value is exact .5 so I think I'm better off using _Ceil and _Round rather than trying to catch the number of times Cint encountered .5 .

Something like     b = a - INT(a) : If b = .5 then c = _Ceil(a) else c = _Round(a):

Gotta love those Bankers

[bplus]

Code: QB64: [Select]

1. x = .5
2. PRINT INT(x), _CEIL(x), _ROUND(x)

Not what you'd expect from _ROUND() is it. Never did like bankers and this is not the way stores round tax.