Saxon

I don't think there's any non-conformance here: the specification is explicit that this is implementation-defined. See F+O §4.2:

...for division and modulus operations, the returned result should be accurate to at least M digits of precision. The actual precision is ·implementation-defined·. If the number of digits in the mathematical result exceeds the number of digits that the implementation retains for that operation, the result is truncated or rounded in an ·implementation-defined· manner.

So that leaves the question whether we have made the best choice here, and if not, whether it is better to change it or to leave it alone in the interests of stability. I'm inclined towards the stability argument: if the result is implementation-defined then people shouldn't be writing code that depends on the outcome, but if they do write code that depends on the outcome, we shouldn't change it without a strong reason.

XPath 1.0, despite its brevity, is very careful to say that round() does round-half-towards-positive-infinity, so I suspect James Clark was fully aware that "round up" was ambiguous. Why they made that choice, I don't know. I'm afraid I know very little about accounting standards in different countries.

Of course it's easy to achieve round-half-away-from-zero with a bit of conditional logic testing if the number is negative.

One last question. if Saxon 12.4 calculated round(-9552.255, -2) shouldn't be the result -9500?

-9600 seems right to me.

Thanks, Michael, yes, I realized now that -9600 is correct.

I assume there is no round-half-away-from-zero method in XPatch or Saxon to fulfil the German VAT rounding requirements by law. Added the function and made it the default of round(). In addition, tried to avoid binary floating points as much as possible and be as precise as possible therefore I enhanced the precision from 18 to 34.

Moved all changes (via git interactive) into a single patch to make it easier to review: https://github.com/svanteschubert/Saxon-HE-enhanced-accuracy/commit/64aef1958a2475485ad4229fefebbe3850aef234

I would call it the Saxon extreme-accuracy mod ;-) You might consider enabling all the above by configuration - but I am not aware if there is a market for that. At least I hereby donate every change - the complete above repo - back to Saxonica if this might help you in any kind. :-)

Have a nice weekend, Michael - TGIF

PS: My favourite GitHub feature is, to be able to point at a Code line and provide the URL. It is yet not possible to use with: https://github.com/Saxonica/Saxon-HE/blob/main/12/source/saxon12-4source.zip ;-) I have found the tests neither. ;-)

Thanks. I'm afraid this is the kind of area where implementing the core feature - a different rounding mode - is trivial, but designing the APIs or configuration facilities to enable users to exploit the feature is a much bigger project. I will see whether there is any appetite in the qt4cg to add support for rounding modes, either on round() itself, or on decimal divide.