ECL says: THROW: The catch RAT-ERR is undefined

[Richard_L]

Calling ...simplify_trig() results in a traceback, somewhat elided here:

Traceback (most recent call last):

  ....  

  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/manifolds/differentiable/metric.py", line 692, in inverse
    self._inverse._restrictions[dom] = rst.inverse() # forces the
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/manifolds/differentiable/metric.py", line 2281, in inverse
    val = chart.simplify(gmat_inv[i-si,j-si], method='SR')
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/manifolds/calculus_method.py", line 236, in simplify
    return self._simplify_dict[method](expression)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/manifolds/utilities.py", line 597, in simplify_chain_real
    expr = expr.simplify_trig()
  File "sage/symbolic/expression.pyx", line 10015, in sage.symbolic.expression.Expression.simplify_trig (build/cythonized/sage/symbolic/expression.cpp:56590)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 657, in __call__
    return self._obj.parent().function_call(self._name, [self._obj] + list(args), kwds)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 578, in function_call
    return self.new(s)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 347, in new
    return self(code)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 282, in __call__
    return cls(self, x, name=name)
  File "/home/rllozes/Development/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 697, in __init__
    raise TypeError(x)
TypeError: ECL says: THROW: The catch RAT-ERR is undefined.

I don't find anything directly relevant on the bug list at maxima.sourceforge.net.
Anyone else stumble on this? I've seen various mentions of ECLIB throw/catch errors, but not for RAT-ERR.
Work-arounds?

I'm running trac #22801 on top of SageMath 8.1.rc3, which includes Maxima 5.39.0.

I attach the notebook worksheet exported ("Save worksheet to a file...") as .sws

Thanks,
 - Richard

[Ralf Stephan]

On Sunday, November 26, 2017 at 12:54:04 AM UTC+1, Richard_L wrote:

Calling ...simplify_trig() results in a traceback, somewhat elided here:

So what's behind that ellipsis?

You see, we have doctests for simplify_trig() that are constantly checked by our patchbots so we would know if simplify_trig() per se would suddenly fail.

Please give the full command that causes the error. Always.

Regards,

[Ralf Stephan]

Since this is dependent on #22801 this ticket needs a followup bugfix ticket.

[Dima Pasechnik]

There is a worksheet attached, it can be used to reproduce the error; however, I indeed recommend to supply the plain *.sage

file instead; it's much less prone to various quirks of binary formats). There is a "Text" button that can be used to show the plain text version of the worksheet; one can copy/paste it into an editor, and remove few things like extra `\ and ... to obtain

a working file that one can load() into a terminal Sage session.

(maybe there are even better ways to get this, I don't know).

Anyhow, this is the full trace (no need for #22801 to reproduce):

sage: ginv = g.inverse()

---------------------------------------------------------------------------

TypeError                                 Traceback (most recent call last)

<ipython-input-11-e4f0f160d75a> in <module>()

----> 1 ginv = g.inverse()

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/manifolds/differentiable/metric.pyc in inverse(self)

    690         # Is the inverse metric up to date ?

    691         for dom, rst in self._restrictions.items():

--> 692             self._inverse._restrictions[dom] = rst.inverse() # forces the

    693                                                     # update of the restriction

    694         return self._inverse

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/manifolds/differentiable/metric.pyc in inverse(self)

   2240                         for j in range(i, nsi):

   2241                             cinv_scal[(i,j)].add_expr(simplify_chain_real(

-> 2242                                                        gmat_inv[i-si,j-si]),

   2243                                                       chart=chart)

   2244                 for i in range(si, nsi):

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/manifolds/utilities.pyc in simplify_chain_real(expr)

    343     """

    344     expr = expr.simplify_factorial()

--> 345     expr = expr.simplify_trig()

    346     expr = expr.simplify_rational()

    347     expr = simplify_sqrt_real(expr)

/home/dima/Sage/sage-dev/src/sage/symbolic/expression.pyx in sage.symbolic.expression.Expression.simplify_trig (build/cythonized/sage/symbolic/expression.cpp:56589)()

  10013         # right otherwise!

  10014         if expand:

> 10015             return self.parent()(self._maxima_().trigexpand().trigsimp())

  10016         else:

  10017             return self.parent()(self._maxima_().trigsimp())

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/interfaces/interface.pyc in __call__(self, *args, **kwds)

    655 

    656     def __call__(self, *args, **kwds):

--> 657         return self._obj.parent().function_call(self._name, [self._obj] + list(args), kwds)

    658 

    659     def help(self):

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/interfaces/interface.pyc in function_call(self, function, args, kwds)

    576                                        [s.name() for s in args],

    577                                        ['%s=%s'%(key,value.name()) for key, value in kwds.items()])

--> 578         return self.new(s)

    579 

    580     def _function_call_string(self, function, args, kwds):

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/interfaces/interface.pyc in new(self, code)

    345 

    346     def new(self, code):

--> 347         return self(code)

    348 

    349     ###################################################################

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/interfaces/interface.pyc in __call__(self, x, name)

    280 

    281         if isinstance(x, string_types):

--> 282             return cls(self, x, name=name)

    283         try:

    284             return self._coerce_from_special_method(x)

/home/dima/Sage/sage-dev/local/lib/python2.7/site-packages/sage/interfaces/interface.pyc in __init__(self, parent, value, is_name, name)

    695                 self._name = parent._create(value, name=name)

    696             except (TypeError, RuntimeError, ValueError) as x:

--> 697                 raise TypeError(x)

    698 

    699     def _latex_(self):

TypeError: ECL says: THROW: The catch RAT-ERR is undefined.

sage: 

And this is the plain Sage code to get this error:

# trac 22801 on top of ...

version()

Parallelism().set(nproc=1)

var('rho12,rho13,rho23', domain='real')

assume(rho12>0, rho13>0, rho23>0)

var('r12,r13,r23', domain='real')

var('m1 m2 m3', domain='real')

var('mu12,mu13,mu23', domain='real')

assume(m1>0, m2>0, m3>0)

#m1=1; m2=1; m3=1

#

m3 = m2 #Extra constraint for 2 electrons

# N.B.: If all {m1,m2,m3} are in SR and no two are equal, G.simplify_full() will seg-fault.

#

mu12 = 1/m1+1/m2; mu13 = 1/m1+1/m3; mu23 = 1/m2+1/m3;

rho12 = r12^2; rho13 = r13^2; rho23 = r23^2

Ginv = matrix([[1/mu12, 1/m1*(rho12+rho13-rho23)/(2*r12*r13), 1/m2*(rho12+rho23-rho13)/(2*r12*r23)],

       [1/m1*(rho12+rho13-rho23)/(2*r12*r13), 1/mu13, 1/m3*(rho13+rho23-rho12)/(2*r13*r23)],

       [1/m2*(rho12+rho23-rho13)/(2*r12*r23), 1/m3*(rho13+rho23-rho12)/(2*r13*r23), 1/mu23]])

G = Ginv.inverse(); G.simplify_full()

(G*Ginv).simplify_full(); #(Ginv*G).simplify_full()    # Check 2

M = Manifold(3,'R^3',field='real',start_index=1)

# The following choice seems not to matter. The code always goes through manifolds/utilities.py where it calls simplify_trig(), which dives down the rat-hole.

###

# commented out the following line to remove dependence on #22801

# M.set_calculus_method('SR')    # N.B. 'sympy' fails w/ nproc>1 (above) 

###

U = M.open_subset('U')

Rho.<r12,r13,r23> = U.chart("r12:(0,+oo) r13:(0,+oo) r23:(0,+oo)")

Rho.add_restrictions([r23<r12+r13, r13<r12+r23, r12<r13+r23])

g = M.riemannian_metric('g');

g[:] = G[:].simplify_full()

#g.display()

Rho.domain(); Rho.parent()

# Check rij's

r12.is_real(); r12.is_positive(); bool(rho12==r12^2)

# Pekeris coordinates

Tau.<u1,u2,u3> = U.chart("u1:(0,+oo) u2:(0,+oo) u3:(0,+oo)")

Rho_Tau = Rho.transition_map(Tau, ((r12+r13-r23)/2, (r12-r13+r23)/2, (-r12+r13+r23)/2))

Tau_Rho = Rho_Tau.inverse()

U.set_default_chart(Tau)

U.set_default_frame(Tau.frame())

Rho_Tau.display(); Tau_Rho.display();

U.atlas(); Rho.frame(); Tau.frame()

ginv = g.inverse()

#-----

#Dima

[Richard_L]

Dima,

Thank you for your recommendations and for reproducing the bug.  Henceforth I will snip or attach *.sage and include the full traceback.

Indeed, #22801 is not required. But since that's the configuration I used, I pointed it out for completeness.

 - Richard

[Ralf Stephan]

The expression triggering the error has an output size of 59 pages.

It is attached and the crash can be confirmed by giving ex.simplify_trig().

Apart from the ECL problem clearly some optimization in manifolds

is in order, especially since the expression does not contain trig functions.

Regards,

[Richard_L]

Ralf,

Do we have a convention concerning calls to upstream packages like maxima? That is, which side of the interface is responsible for the scan to determine whether the main code invoked upstream should be executed: the caller (in this case manifolds.utilities) or the callee (in this case simplify_trig())?

Using the principle of least code, one would put the onus on simplify_trig to return immediately if it finds no trig functions.
Using the principle of most flexibility, one would put the onus on the manifolds.utilities.

The former usually results in more robust code, while the latter usually yields higher speed.

 - Richard

[rjf]

It would be helpful if the command line(s) sent to Maxima that resulted

in this message were posted, either here or on the Maxima newsgroup.

A Sage workbook 

Without knowing what was attempted, I will nevertheless suggest

that executing the command

gcd:subres

may fix the problem.

[Dima Pasechnik]

On Monday, November 27, 2017 at 12:08:38 AM UTC, rjf wrote:

It would be helpful if the command line(s) sent to Maxima that resulted

in this message were posted, either here or on the Maxima newsgroup.

see the attachment (all the ~59 screens) in https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/Bj-dcnIWAwAJ

I suppose that in order to feed it into Maxima one needs to replace '=' by ':' and add ';' at the end.

(and drop the 1st line)

[Nils Bruin]

On Monday, November 27, 2017 at 10:34:03 AM UTC+1, Dima Pasechnik wrote:

see the attachment (all the ~59 screens) in https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/Bj-dcnIWAwAJ

I suppose that in order to feed it into Maxima one needs to replace '=' by ':' and add ';' at the end.

(and drop the 1st line)

An easy way of getting a little closer to feeding this directly to maxima is by using a real expect interface, rather than the maxima_lib instance. By executing
sage: maxima(ex).trigsimp()
it gets fed into a proper maxima instance, without any of the special settings that go into the sage calculus version of maxima. We still get an error:

TypeError: Error executing code in Maxima
CODE:
    sage4 : trigsimp(sage0)$
Maxima ERROR:
   
Polynomial quotient is not exact
 -- an error. To debug this try: debugmode(true);

it seems something goes wrong in signalling and catching this error in maxima_lib. Perhaps we're missing a catch in our maxima_lib routine to execute maxima code?

[Dima Pasechnik]

On Monday, November 27, 2017 at 11:20:52 AM UTC, Nils Bruin wrote:

On Monday, November 27, 2017 at 10:34:03 AM UTC+1, Dima Pasechnik wrote:

see the attachment (all the ~59 screens) in https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/Bj-dcnIWAwAJ

I suppose that in order to feed it into Maxima one needs to replace '=' by ':' and add ';' at the end.

(and drop the 1st line)

An easy way of getting a little closer to feeding this directly to maxima is by using a real expect interface, rather than the maxima_lib instance.

hmm, the call in question is *._maxima_() rather than *._maxima_lib().

Isn't the former a pexpect call, rather than maxima_lib call?

[Nils Bruin]

hmm, the call in question is *._maxima_() rather than *._maxima_lib().

Isn't the former a pexpect call, rather than maxima_lib call?

given that maxima_lib(ex).simptrig() and maxma(ex).simptrig() give different errors (the first one agreeing with the originally reported error) I think it's clear that they use different maxima instances. Furthermore, the fact that it goes wrong in "proper" maxima as well indicates that there's actually a bug in maxima triggered by this example too.

[Ralf Stephan]

On Sunday, November 26, 2017 at 6:56:41 PM UTC+1, Richard_L wrote:

Do we have a convention concerning calls to upstream packages like maxima? That is, which side of the interface is responsible for the scan to determine whether the main code invoked upstream should be executed: the caller (in this case manifolds.utilities) or the callee (in this case simplify_trig())?

We don't need to worry because simplify_trig() is Sage Python and we can just put the scan there before the call to Maxima.

What's more, Sage symbolic expressions are C++ (the Pynac layer). In an experimental implementation of the ticket

https://trac.sagemath.org/ticket/24283

scanning the 59-page expression for any of sin/cos/tan/cot/sec/csc takes six milliseconds. Beauty of C++.

 

The former usually results in more robust code, while the latter usually yields higher speed.

With 6ms the placement of the scan is irrelevant.

Best, 

[Dima Pasechnik]

it appears to be a bug in our Lisp/Maxima version combo:

Maxima 5.39.0 http://maxima.sourceforge.net

using Lisp ECL 16.1.2

In fact in 

Maxima 5.40.0 http://maxima.sourceforge.net

using Lisp SBCL 1.3.18

I obtain an answer:

(%i3) trigsimp(eee);

                                     m1 m2

(%o3)                               -------

                                    m2 + m1

 

[Richard_L]

At this point it appears two tickets are warranted:

1. Modify simplify_trig() (and its siblings) to scan the input expression to see if there's any reason to call Maxima.
   
2. Incorporate a newer version of Maxima and its associated ECL/SBCL.

Anything else, for example, THROW/CATCH logic in maxima_lib(ex).trigsimpl()?