`Roger Hale wrote:`

One set of cases that doesn't seem to have come up in discussion:

(1, 3, 2) >>-<< (83, 84, 81, 80, 85)

Should this give

(-82, -81, -79, -80, -85)

From an arithmetic point of view it should be exactly that. The implementation might need to morph the code though, see below.

as by hallucinating $neutral - $x == $x? This latter $neutral in fact doesn't exist among ordinary numbers, and I would call it algebraically unnatural: for all (other) $n,

$n - ($a + $b) == ($n - $a) - $b

or, as you increase $a by $b, $n - $a decreases by $b (a sort of contravariance), but

$neutral - ($a + $b) == $a + $b == ($neutral - $a) + $b

! This violates algebraic relations I would prefer to rely on, both in my own reasoning and that of the compiler and other program-handling programs.

Me too! The thing is that the field of the real numbers is build on the operators + and * which are associative and commutative. The neutral elements are 0 and 1 respectively. The non-associative operators - and / are defined in terms of the inverse elements. Thus $a - $b == $a + (-$b) and $a / $b == $a * (1/$b) if $b != 0. We could also bring in $b**-1 as another way to find the multiplicative inverse. But that just pulls in yet another operator and the question which axioms apply to it and how it is hyperated.

For user-defined numerical types---that is ones that provide +, *, -, /, **, etc---I would hope that these axioms hold. Actually I hope that there is a set of roles that define the standard numerics and enforce sanity as far as that is possible via the class composition mechanics.

So coming back to your example, operator Â-Â would call -Â on the RHS and call Â+Â with the result. But I've no idea to which extent operator Â Â is a special runtime operator versus a term re-writing at compile time. -- TSa (Thomas SandlaÃ)