Symbolic functions break the __hash__ contract

[vbraun]

Equal objects must have the same hash if they are hashable (​http://docs.python.org/2/reference/datamodel.html#object.__hash):

sage: my_func = function('func',nargs=1)
sage: f = my_func(0)
sage: bool(f == f.simplify())
True
sage: hash(f) == hash(f.simplify())
False

As reported on ​http://ask.sagemath.org/question/2587/simplify-shenanigans, hash lookup errors then leads to undesirable behavior:

sage: ex = my_func(0) + my_func(1)
sage: ex.subs(my_func(0)==1)
func(1) + 1
sage: ex.simplify().subs(my_func(0)==1)
func(0) + func(1)

[vdelecroix]

Within Sage it is impossible to satisfy "equal objects must have the same hash if they are hashable" because equality is too laxist.

sage: RIF(2) == 2
True
sage: hash(RIF(2))
6400019251
sage: hash(2)
2

Or

sage: bool(pi == RR(pi))
True
sage: hash(pi)
2650685528
sage: hash(RR(pi))
1826823505

You can not hope to solve this problem with one ticket (because the Symbolic ring contains all Sage objects) !

[vdelecroix]

see also ​http://wiki.sagemath.org/EqualityCoercion.

[ncohen]

(cc me)

[rws]

See also #18092.

The problem with simplify+substitute is probably another symptom of NewSymbolicFunctions not being preserved when going through Maxima and, if so, is restricted to user-defined functions. See e.g.

sage: ex = sin(x)+exp(pi)
sage: ex.subs(sin(x)==1)
e^pi + 1
sage: ex.simplify().subs(sin(x)==1)
e^pi + 1

[nbruin]

Now that we've decided to sacrifice readability for reducing the chance of name collisions with variables in conversion from SR to maxima:

sage: x._maxima_()
_SAGE_VAR_x

we could ensure that name translation for functions from SR to maxima is injective as well. Theoretically, we could have

sage: function('f')._maxima_()
_SAGE_FUNC_NAME_f
sage: function('f',nargs=1)._maxima_()
_SAGE_FUNC_NARGS_1_NAME_f

or something similar. Since LISP uses interned strings for symbols, it wouldn't even be inefficient in the "enhanced" interface to maxima_lib: once the dictionaries are seeded, the strings wouldn't be parsed. The strings-based interface would of course have a bit of a penalty, because it does all kind of regex stuff, so string length actually affects performance (but you'd probably have to work very hard to notice it)

Note that this issue came up again on ​ask sagemath.

[egourgoulhon]

Replying to nbruin:

Note that this issue came up again on ​ask sagemath.

There is a recent discussion of this issue on ​sage-devel.