Convert symbolic relations to/from SymPy

[rws]

sage: (x>0)._sympy_()
...
NotImplementedError: relation

Reversely in SymPy:

In [9]: x >= 0
Out[9]: x ≥ 0

In [10]: _._sage_()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-10-7149a2430cab> in <module>()
----> 1 _._sage_()

AttributeError: 'GreaterThan' object has no attribute '_sage_'

In [11]: Eq(x, 3)
Out[11]: x = 3

In [12]: _._sage_()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-12-7149a2430cab> in <module>()
----> 1 _._sage_()

AttributeError: 'Equality' object has no attribute '_sage_'

This functionality is needed both by #22322 and #23923. Needed is a fix to SympyConverter in expression-conversions.pyx

The reverse patch in SymPy is added here, see the PR ​https://github.com/sympy/sympy/pull/13420

[rws]

New commits:

​9462954

23990: Convert symbolic relations to SymPy

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​07f4744

23990: handle unequality

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0ed659f

23990: do not evaluate

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​5f023ea

23990: convert relations from SymPy to Sage, with test

[charpent]

8.1.beta7 + #23990 passes ptestlong on Debian testing running on core i5 + 8 GB RAM with no error whatsoever.

==>positive_review

PS : You need to put your name in "Authors"

PPS : Thank you very much ! Solving inequations is a domain where Sage and Maxima are currenty weak. This is a nice step in the right direction.

[rws]

Thanks!

[rws]

P.S. Don't forget to reinstall SymPy before compiling Sage.

[rws]

Sorry, I forgot to increase the SymPy patchlevel, and the patch does no apply anyway.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0f596bb

23990: fix patch

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​479e206

23990: sympy patchlevel bump

[charpent]

Replying to rws:

Sorry, I forgot to increase the SymPy patchlevel, and the patch does no apply anyway.

Ah ! I thought that the reverse conversion (which I saw on the sympy site) was reserved for another Sage patch...

[charpent]

sage: var("a,b")
(a, b)
sage: sympy.sympify(a==b)._sage_()
a == b
sage: sympy.sympify(a==b).sage()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-14-25de6a4c8f0a> in <module>()
----> 1 sympy.sympify(a==b).sage()

AttributeError: 'Equality' object has no attribute 'sage'

Is that the intended behaviour ? Or to you plan to overhaul a .sage() method for various Sympy objects ?

It is not obvious to me why (e. g.) Mathematic objects can be converted back to Sage objects via the (exposed) .sage() method, whereas one has to use the (unexposed) ._sage_() methods for Sympy objects...

[rws]

_sage_() is just the SymPy convention, every convertible object has it. They have a lot of other underscore member functions, try grep 'def _' sympy/*/*/*. Are Mma objects not Sage objects? Should we enforce coding conventions between projects?

Please don't forget to set back positive.

[charpent]

Replying to rws:

_sage_() is just the SymPy convention, every convertible object has it. They have a lot of other underscore member functions, try grep 'def _' sympy/*/*/*.

Indeed. No quarell here.

Are Mma objects not Sage objects?

They are by definition Sage objects, but have no meaning for interacting with Sage "native" objects ; a conversion is needed for that.

Should we enforce coding conventions between projects?

I think that's almost what I was thinking about (syntax consistency rather than coding conventions).

Note that the non-Sympy interfaces are not that consistent : compare, for example, interfaces to mathematica, giac, R, maple and fricas... Unifying them would represent a lot of work second-intention consistency is hard...

Another reason was that, unless I'm mistaken, the docs I read when I was starting to learn Sage (about 2-3 years ago) recommended to "end users" to use only "exposed" methods, leaving the unexposed ones to internal Sage use. I certainly had this recommendation in mind when I asked my question.

Has this recommendation changed ?

Please don't forget to set back positive.

Of course ;-).

And, BTW, this was only a question, not a criticism...

[rws]

The problem is that you seem to want a way to know how to convert a Python object from a different namespace by asking for its methods. But Sage has no control over them because Python does not allow adding methods on-the-fly. It may be an idea to just provide a Sage global function to_sage(...) that knows these members and calls them without you having to know. Please open a ticket or a discussion and cite me as much as you want. This ticket has fulfilled its purpose.

[rws]

Replying to rws:

...because Python does not allow adding methods on-the-fly...

I'm a Python noob. I didn't know about MethodType.