Inconsistent expression calculation between programming languages

This is solely due to differences in the / and % operators:

  # int/int -> int
  POSTGRESQL = 8291561284461.33301440
  SQUILU = 8291561284461.3
  JAVA = 8.291561284461331E12
  D = 8.29156e+12

  # int/int -> float
  LUA = 11665910614443
  PYTHON3 = 11665910614443.387

  # int/int -> float, UNIQUE: pos%neg -> neg
  JAVSCRIPT = 8036090802426.098
  MYSQL = 8036090802312.071      # single-precision FLOAT

  # int/int -> int, UNIQUE: negint/posint -> negint (the floor)
  PYTHON2 = 1.1107636287e+13
  RUBY = 11107636286950.146

  # int/int -> int, UNIQUE: negfloat%posint -> negint (the ceil)
  SQLITE = 8290383058308.3

  # int/int -> float, UNIQUE: negfloat%posint -> negint (the ceil)
  PHP = 8035491468054

So, we have (at least) different evaluation orders, different meanings of the % operator (How are negative numbers handled?), different meanings of the / operator (is 10/3=3 or 3.3333 — notice that Python3 joins the 8.29e+12 fold!). This shows two things: 1) Even though it is syntactically correct in N different languages, it does not necessarily mean the same thing, and 2) floating-point math has many traps. Neither should be news to the HN readership.

After removing all modulo operations and transforming all numbers to floating point:

====

EXPR = (((((((788.0)(8.46))))+8342.01.803-1.0))4186.4(15.0))(((22.0/((7530.0/((2.0)(((((25.0))-421))))))*597.0)+7283.8-9.60+167.0))+(8871.0)

SQUILU = 8259816920615.1

LUA = 8259816920615.1

JAVASCRIPT = 8259816920615.111

SQLITE = 8259816920615.11

POSTGRESQL = 8259816920615.11377654520912550160000

MYSQL = 8259816920615.113

AMPL = 8.25982e+12

PHP = 8259816920615.1

RUBY = 8259816920615.111

PYTHON = 8.25981692062e+12

====

Other than nerdsniping, what is the point of this expression?

If you wanted to show how different languages treat modulo, type conversions, division, etc., you could just show individual examples. That would be significantly clearer.

Was there some practical reason behind creating this expression, or is it just obfuscation?

Fairly early on in my career I was on a team writing a GUI programming environment (think old school flow charts) that generated ASP (classic) or Java backends. We allowed simple expressions in assignments with the basic arithmetic operators and functions. We parsed them into a tiny AST and output Java or ASP code for them with lots of explicit parens and casts. After fiddling with minor differences in precedence, associativity and implicit casts we still had some cases that did not match. Pairing with a more senior dev we wrote a C program to generate and compare a large number (tens of millions) of random expressions trying to explore the important variables (small and large floats. Floats that cause funny rounding. Long sequences of almost the same precedence etc).

We got all three languages to agree to full precision for almost every case but in each run there were stubbornly alway a few dozen we couldn’t get to match for non obvious and seeming random reasons.

This was a prototype that never saw real production use and we spent a couple of weeks on it… it always bothered me that we never understood that last 0.00001%

You can't hold a language responsible for "mistakes" if you don't understand how the language works. Quotes intentional.

Different languages have different rules around some math operators, notably around order of operations and how % and / handle floating point values. There are much simpler expressions that will yield differences.

Also, you appear to be using Python 2, the results are different with any modern version of Python.

It's hardly incorrect that different languages have different semantics, especially considering the mix of types and use of % in that expression. You could just as well complain that they don't all print floating point numbers in the exact same way.

A big part of the oft-overlooked notion of Information Architecture are the twin concepts of Source of Truth and System of Record. Many systems mix or conflate the two or don't consider them at all, other than subconsciously when wrestling with issues of code duplication (split SoT).

If the result of a calculation is that important to the functioning of your code, then having three implementations in multiple languages is just madness. You need to pick one to believe, or constantly deal with random catastrophes. Personally I enjoy very much not being woken up at 7 am EST to solve production issues. Almost as much as I hate other people getting kudos for problems that we should have not signed up for in the first place. Arsonist-firefighters exist in every dark corner of the programming world, and in much greater numbers than actual arsonist-firefighters.

From a technology selection standpoint, all of this info is extremely important, because it will inform both my choice of tools and my immediate task list to deal with any answers I don't like. But if you're wrestling with this every day, you've already fucked up.

And after removing all modulo operations:

====

EXPR = (((((((788)*(8.46))))+8342*1.803-1))*4186.4*(15))*(((22/((7530/((2)*(((((25))-421))))))*597)+7283.8-9.60+167))+(8871)

SQUILU = 8515287402650.3

SQLITE = 8515287402650.34

POSTGRESQL = 8515287402650.347200

D = 8.51529e+12

JAVA = 8.515287402650345E12

MYSQL = 8259816920501.086

JAVASCRIPT = 8259816920615.111

PHP = 8259816920615.1

LUA = 8259816920615.1

AMPL = 8.25982e+12

GAMS = 8.25982E+12

RUBY = 7701542593121.873

PYTHON = 7.70154259312e+12

====

This kind of thing can bite you even when operating purely on integers. E.g., for a long time (it's been fixed for over a dozen years by now though), Python implemented x%n with an intermediate cast to float, with predictably bad results on inputs larger than typical test cases. I had the damnedest time tracking down the culprit since I assumed it had to be serialization, hashing, or one of the standard culprits --- not that integer math was broken.

Haskell: =====

(%) = Data.Fixed.mod'

expr :: Double = 8.036090802426098e12

expr :: Rational = 630330872315297185317 % 78437500

fromRational (expr :: Rational) :: Double = 8.0360908024261e12

And making all operands to modulo operator "%" integer:

=====

EXPR = (((((((788)*(8.46))))+8342*1.803-1))*4186.4*(15))*(((22%284/((7530/((2)*(((((25))-421))))))*597%2663)+7283.8-9.60+167%((3))))+(8871)

D = 8.29038e+12

JAVA = 8.290383058308305E12

MYSQL = 8034912576159.046

POSTGRESQL = 8290383058308.307200

SQLITE = 8290383058308.3

SQUILU = 8291561284461.3

JAVASCRIPT = 8034912576273.071

PHP = 8035491468054

AMPL = 8.03491e+12

GAMS = 8.03491E+12

PYTHON = 1.11064580608e+13

RUBY = 11106458060797.121

LUA = 11664732388290

====

Try to edit your post and add a \ before each * so it is not interpreted as italics here.

Have you tried to simplify it? My guess is that the problem is not in the last "+(8871)".

https://en.wikipedia.org/wiki/False_friend

For Go, we get compilation error

./prog.go:8:129: invalid operation: 167.864 % 3 (operator % not defined on untyped float)

Julia 1.3.1: 8.036090802426098e12

In BYOND (Dream Maker/.dm):

8035491119104

(single floats on all numbers, unsure of negmod behavior)

You couldnt come up with a simpler example? Youve got at least 12 operations there. Pretty much a single division operation wouldve worked about the same

And that is why people still use FORTRAN.

These are some shocking differences. How did you come up with this expression?