Meaningful error messages for coercion failure

[Jonathan Kliem]

Could we have meaningful error messages somehow for coercion failure?

E.g. when I couldn't coerce two quadratic number fields, I needed help finding the method composite fields.

In https://trac.sagemath.org/ticket/28774 I tried to point the user somehow to this method and there might be other places where this might be helpful.

- E.g. when we don't want to coerce, but conversion is nevertheless possible.

- Or x acts on y but not from the right. Instead of raising an error immediately, we could show this only at coercion failure (and not force coercion failure to show the message).

One thing we could do is store coercion warnings somewhere and at a coercion failure we hint the user to this thing, e.g. `coercion_model.recent_failures()`. This could be useful, but of course only if people populate that thing. It would definitely by more useful than

sage: K.<sqrt5> = QuadraticField(5)                                                                                                                                                
sage: sqrt5 + AA(2)                                                                                                                                                                
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-13-264954f0d9bf> in <module>
----> 1 sqrt5 + AA(Integer(2))

~/Applications/sage/local/lib/python3.7/site-packages/sage/structure/element.pyx in sage.structure.element.Element.__add__ (build/cythonized/sage/structure/element.c:10980)()
   1230         # Left and right are Sage elements => use coercion model
   1231         if BOTH_ARE_ELEMENT(cl):
-> 1232             return coercion_model.bin_op(left, right, add)
   1233
   1234         cdef long value

~/Applications/sage/local/lib/python3.7/site-packages/sage/structure/coerce.pyx in sage.structure.coerce.CoercionModel.bin_op (build/cythonized/sage/structure/coerce.c:11304)()
   1246         # We should really include the underlying error.
   1247         # This causes so much headache.
-> 1248         raise bin_op_exception(op, x, y)
   1249
   1250     cpdef canonical_coercion(self, x, y):

TypeError: unsupported operand parent(s) for +: 'Number Field in sqrt5 with defining polynomial x^2 - 5 with sqrt5 = 2.236067977499790?' and 'Algebraic Real Field'

Maybe a user could get some hint that number fields can be specified with fixed embedding and that conversion works either way.

[Nils Bruin]

On Saturday, August 15, 2020 at 11:38:17 AM UTC-7, Jonathan Kliem wrote:

Could we have meaningful error messages somehow for coercion failure?

[...]

TypeError: unsupported operand parent(s) for +: 'Number Field in sqrt5 with defining polynomial x^2 - 5 with sqrt5 = 2.236067977499790?' and 'Algebraic Real Field'

 [...]

Maybe a user could get some hint that number fields can be specified with fixed embedding and that conversion works either way.

 

I think the message is very meaningful: it exactly describes what goes wrong. The fact that the message follows a fixed pattern is actually helpful in recognizing the problem for people with some experience with sage.

It may be the case that there is room for generating helpful suggestions for inexperienced users. Basically, something that matches traceback/imput patterns to FAQ items. WIth the current state of machine learning and language processing, this might actually be something that can be made to perform to some satisfactory degree, but it would take into account much more than just the place where the error arises. Alternatively, we may be able to get a similar result by writing a really good FAQ and let Google index it, so that we get to borrow their language processing. 

There are places in sage where managing complexity of the error message is worthwhile, and I think the coercion system is one: there are places where sage tries several possibilities and catches the errors. Sage even has specific "lazy" error messages for that, so that the message doesn't get expanded unless the string is actually called for. If I'm not mistaken, this particular message is an example of that. These parent representations can have a real cost to them, so that you don't want to risk generating them in a time-critical part of the code (where the string is thrown away anyway).

So, I suspect that there's a real cost to making coercion error messages more expensive to generate. That gives another argument against doing so.

[Jonathan Kliem]

Thanks for your feedback.

I'll close that ticket then as invalid.

You're right that the error message contains usually everything you need to know to solve your problem.