sage 9.0: mismatch in sr-to-maxima translation

[mendes]

Dear all,

In previous versions of Sagemath, I  was able to do perfectly  the (symbolic) integration of  functions like  unit_step( ), for example when doing  symbolic convolutions.
But in the latest versions of Sagemath (like 8.9 and the updated  9.0) the following message appears:
RuntimeError: Encountered operator mismatch in sr-to-maxima translation

I wonder if the problem is related with the change in python (now in python3).

I would be very grateful if anyone could  hep me on the subject.

The complete error message is:

File "/home/sc_serv/sagecell/interact_sagecell.py", line 122, in
update_interact_msg

    update_interact(interact_id, name, content["values"][name], not content["update_last"])

  File "/home/sc_serv/sagecell/interact_sagecell.py", line 112, in update_interact
    interact_info["function"](control_vals=kwargs)

  File "/home/sc_serv/sagecell/interact_sagecell.py", line 422, in adapted_f
    returned = f(*args, **control_vals)

  File "<ipython-input-1-b01a4322b3e5>", line 22, in _
    fg = integrate(f(t=x)*g(t=t-x),x,Integer(0),t).simplify_full().expand()

  File "sage/symbolic/expression.pyx", line 4738, in sage.symbolic.expression.Expression.expand (build/cythonized/sage/symbolic/expression.cpp:28851)
    x = self._gobj.expand(0)

  File "sage/symbolic/function.pyx", line 1226, in sage.symbolic.function.BuiltinFunction._evalf_or_eval_ (build/cythonized/sage/symbolic/function.cpp:13413)
    return self._eval0_(*args)

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/symbolic/integration/integral.py", line 205, in _eval_
    A = integrator(*args)

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/symbolic/integration/external.py", line 46, in maxima_integrator
    result = maxima.sr_integral(expression, v, a, b)

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 790, in sr_integral
    return max_to_sr(maxima_eval(([max_integrate],[sr_to_max(SR(a)) for a in args])))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 790, in <listcomp>
    return max_to_sr(maxima_eval(([max_integrate],[sr_to_max(SR(a)) for a in args])))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 1621, in sr_to_max
    [sr_to_max(o) for o in expr.operands()]))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 1621, in <listcomp>
    [sr_to_max(o) for o in expr.operands()]))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 1621, in sr_to_max
    [sr_to_max(o) for o in expr.operands()]))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 1621, in <listcomp>
    [sr_to_max(o) for o in expr.operands()]))

  File "/home/sc_serv/sage/local/lib/python3.7/site-packages/sage/interfaces/maxima_lib.py", line 1617, in sr_to_max
    raise RuntimeError("Encountered operator mismatch in sr-to-maxima translation")

RuntimeError: Encountered operator mismatch in sr-to-maxima translation

[Nils Bruin]

On Saturday, January 18, 2020 at 7:19:03 AM UTC-8, mendes wrote:

RuntimeError: Encountered operator mismatch in sr-to-maxima translation

The error indicates that the sage-to-maxima dictionary used in sr_to_max is in an inconsistent state. Its state is a mix of preinitialization and caching translations as it goes along, so inconsistent state indicates there's a fragile initialization somewhere. the py2/py3 switch has all kinds of small effects, so it could change the enumeration order of a set somewhere, so that the initialization happened to go right in py2 but now ends up going wrong in py3.

Concerning your hint of a bug:

integrate(unit_step(x),x,-1,1)

works just fine for me (it leaves the integral unevaluated). Without a piece of code that reliably reproduces the error you encounter it's virtually impossible to find what's wrong.

[kcrisman]

Since it looks like you had a Sage cell instance do this, you should be able to link to the code even, using the "Share" button on Sage cell server.  Thanks, that will help our team!

[mendes]

Thank you Bruin and Kcrisman, for your attention.

The following  codes are examples of the problem:

# fg denotes  the convolution product f*g. The expected result is f*g = 0, if t < 1 and f*g = t^2/2-t+1/2, if t > 1.

# For 0 < t < 1, it runs ok:

var('x,t')

assume(0<t,t<1)

f=unit_step(t-1)

g=t

fg = integrate(f(t=x)*g(t=t-x),x,0,t).simplify_full().expand()

show(fg)

forget()  

#But, for t>1, there is a RuntimeError: mismatch in sr-to-maxima

var('x,t')

assume(1<t)

f=unit_step(t-1)

g=t

fg = integrate(f(t=x)*g(t=t-x),x,0,t).simplify_full().expand()

show(fg)

forget()

#In previous versions of Sage the answer, in the case piecewise functions like  f*g,   could employ the functions like sign()  or abs(),  but  no Error messages appeared 

#The following alternative raises no Error, but does not evaluate the f*g function to  t^2/2-t+1/2, as desired:

var('x,t')

assume(1<t)

f=unit_step(t-1)

g=t

fg = integrate(f(t=x)*g(t=t-x),x,0,t,hold=False)

show(fg)

forget()

Thank you again.

[Nils Bruin]

You should file a ticket. Symbols are getting mixed up. Recently there were some changes to the order in which different integration algorithms are used, and I suspect that this happens as a side effect.

I can tell you what I see happen:

This is what the actual "unit_step" function should be.

sage: type(unit_step)
<class 'sage.functions.generalized.FunctionUnitStep'>

When you run into the error:

RuntimeError: Encountered operator mismatch in sr-to-maxima translation

we have a function "op" with the following properties:

ipdb> p op
unit_step
ipdb> p type(op)
<class 'sage.symbolic.function_factory.NewSymbolicFunction'>

so that's a function with the same print-name as "unit_step", but it's a different function. The sage-to-maxima (and vice versa) dictionaries know how to translate the original `unit_step`, but at this point it is noticed that this "new" function `unit_step` would cause a name clash at the maxima side. Hence the error. It seems to me the maxima interface is operating as it should. The error is probably that the expression was manipulated (by integrate) before that point by some interface; problably the sympy one; which confused the system.

Smoking gun:

sage: type(unit_step(x).operator())
<class 'sage.functions.generalized.FunctionUnitStep'>
sage: type(unit_step(x)._sympy_()._sage_().operator())
<class 'sage.symbolic.function_factory.NewSymbolicFunction'>

Even if this is not the source of the bug you're experiencing this is something that needs to be fixed: sympy needs to be taught about unit_step.

[kcrisman]

https://trac.sagemath.org/ticket/29050 for the Sympy translation issue, we can open another one if necessary if that doesn't fix things.

[Nils Bruin]

On Sunday, January 19, 2020 at 6:46:50 AM UTC-8, mendes wrote:

#But, for t>1, there is a RuntimeError: mismatch in sr-to-maxima

var('x,t')

assume(1<t)

f=unit_step(t-1)

g=t

fg = integrate(f(t=x)*g(t=t-x),x,0,t).simplify_full().expand()

show(fg)

forget()

In the meantime, you can, as a workaround, use f=heaviside(t-1). That does not give an error. Unfortunately, it gives a nonsensical result: it returns "sage4", which is undoubtedly a symbol that somewhere was supposed to be bound to the actual result, but which didn't get bound. Looks like it needs another ticket :-):

sage: var("b")
sage: assume(b>0)
sage: integrate(heaviside(x),x,0,b)

sage4