Hello Luiz !
Thank you for the link !
But what still bugs me is the difference between heavily used
And after removing all modulo operations:
Really Too many extra parentheses (notably around constants) having no purpose in this test!
SQUILU = 8515287402650.3
SQLITE = 8515287402650.34
POSTGRESQL = 8515287402650.347200
D = 8.51529e+12
JAVA = 8.515287402650345E12
All the same, just different formatting (using 64-bit IEEE "double"): this should be tested in C/C++, but beware of portability of "float/double" in terms of precision, and also in terms of type promotion (notably when operands are integers, and not explicitly changed to double using ".0" at least in the constants: this impacts notably divisions, not just modulos; beware also of the current rounding mode: truncate towards 0 for operations on integers, but *normally* (by default in C/C++ compliant apps, and if not using IEEE control functions to change the rounding mode) rounding to the least significant bit to the nearest even for doubles; floats are always implicitly promoted to doubles in C/C++).
MYSQL = 8259816920501.086
PHP = 8259816920615.1
LUA = 8259816920615.1
AMPL = 8.25982e+12
GAMS = 8.25982E+12
PHP is not clear at all about what it does and when it performs rounding. In doubt, use intermediate storage variables to force the rounding in the stored value of the variable, which should then be used to compute the rest.
RUBY = 7701542593121.873
PYTHON = 7.70154259312e+12
Severe differences here caused by divisions (without implicit promotion to doubles). Note that parentheses play a role in terms of associativity and commutativity: permuting operands is not valid if this causes an operator to change the promotion of integer operands to doubles when the other operand may change from an integer to a double. Some languages may also change the priority of operators, and the associativity may be changed if the _expression_ is computed at runtime and not in the compiler itself (for constants) so that it may impact the precision of the result, but the compiler should have optimization hints to allow or disallow such change.
We could also speak about preprocessors for C/C++ (which have their own limits independant of the language they target, but usually preprocessors can only compute small integers for evaluating directives and offer a smaller valid range of values and operators, otherwise they treat expressions like strings without computing them, leaving the compiler of the target language evaluate them where needed).