https://trac.sagemath.org/ticket/29050 for the Sympy translation issue, we
can open another one if necessary if that doesn't fix things.
On Sunday, January 19, 2020 at 12:50:37 PM UTC-5, Nils Bruin wrote:
>
> 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.
>
>
>
> On Sunday, January 19, 2020 at 6:46:50 AM UTC-8, mendes wrote:
>
>> 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.
>>
>>
>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-support/36e53b7d-3e70-4b76-93ed-d686c19a8637%40googlegroups.com.
