@newbie-02 : BANKERSROUND() Yes, love it! Most people probably think this stuff is pretty boring, but these ideas might explain why the bank and credit card companies make so much more money than the rest of us. Something to think about …
Quoting @newbie-02: “…, it could make LO calc more ‘financially sound’ as an additional datatype … imho … your sample … would you mind rechecking, e.g col P, size and ‘direction’ of the ‘add help’ seems strange to me”
Sorry. I simply didn’t undserstand this.
Now I tried again, and still did not understand, but thoroughly looking at the formula used in some columns of my example sheet I found errors resulting (among all the other wrong results) in the bad result for your examptle. .
But why should I worry about errors in my formulas if clever users find them anyway?
I will remove the bad example, and replace it with a better one if I find the time.
@Lupp: it’s been two points:
- imho IEEE 754-2008 could serve better for decimal (and financial!) calculations,
- probably “=INT(($A5+10^-$J5/2)*10^$J5)*10^(-$J5)” (observe ‘-’ sign in 10^-$J5/2) could serve better for your col P, the result for -1,5 could still be discussed,
a good paper on rounding:, the graph there: gave one idea, OP’s expression ‘down nearest’ could possibly be meant as ‘nearest downwards’, which - i didn’t find it in the text, just concluded from the graphic - could be an abreviation for “next and if ambiguous down” … ???
Yes. For the columns H and P I had missed to enhance the “primitive” version I had started with, and in column P the missing ChangeSign
was an obvious cursoriness. This was fixed soon, but there also was missing the implementation of the “usual” way of rounding “toward or offward” zero where I tried to find a “more cleverer” way. Since I didn’t find one this also was fixed the standard way. After all I had used such rounding in advance - for principal reasons.
I didn’t yet post the result because I still consider If I should add two or more columns concerning the uncommon rounding “to even final digit if ambiguous”.
Do you actually know if FPU are capable of rounding the dyadic representation (IEEE 754 Double) this way? I don’t know a compiler setting to that effect, and would doubt if there can be a sufficiently efficient implementation if not the FPU supports it with native means.
And decimals? …