SymPy as optional symbolic method for manifolds

[mmancini]

The symbolic method used for manifolds and differentiable manifolds is "symbolic", the default in SageMath. In this ticket we introduce the use of SymPy? as an option when the Chart in the manifold is created.

At this point there is a dependence on Sympy ticket: "sympy to sage conversion : Abstract function." ​https://github.com/sympy/sympy/pull/12826

[mmancini]

New commits:

​b494a4f	Added sympy symbolic method for manifolds.
​3da5712	merged with develop

[git]

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

​3be4547

created the class ChartFunction which will replace the CoordFunction. also the singleton to manage symbolic method was created

[git]

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

​01bc664

Merge branch 'public/22801-manifold-sympy' of git://trac.sagemath.org/sage into public/22801-manifold-sympy

[git]

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

​b07e5fb

ChartFunction pass almost all tests

[git]

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

​9a1a1f2	added all test for sympy in chart_func
​4998a56	Changes in chart_func are propagated on all manifolds files.
​1e2dc01	Propagated changes in manifolds/differentiable and added many tests.

[git]

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

​7fcf258

passing all test if src/sage/symbolic/expression_conversions.py and changed as in #22802

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​068d495	Merge branch 'public/22802_sympy_abstact_function' of git://trac.sagemath.org/sage into public/22802_sympy_abstact_function
​078532f	docstring modifications
​67f7f46	integrated modifications to composition. But an error remains in french_book.recequadiff tests
​1b5227d	Error in french_book.recequadiff tests corrected
​018d753	Merge branch 'develop' into t/23496/public/23496_patch_sympy_abstact_function
​94af74b	#23496 : (temp) revert order in rsolve recequadiff.tex test
​d76caea	#23496 : add message for change in doctest
​bc21300	#23496 : fix a _sympy_init_ doctest
​0be1d90	Merge branch 'public/23496_patch_sympy_abstract_function' into 22802_sympy_abstract_function
​66f73df	Merge branch 'public/22802_sympy_abstract_function' of git://trac.sagemath.org/sage into public/22801-manifold-sympy

[git]

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

​fdb396b

Minor changes in chart_func

[git]

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

​8f20b54

Merge branch 'develop' into public/22801-manifold-sympy

[git]

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

​102a3e1

error in docstring

[tscrim]

There are a few things that need fixing.

• Not all methods have docstrings/tests
• There are a number of tests where the line before is informational, but it needs a blankline, e.g.:

  @@ -1641,6 +1641,19 @@ class TopologicalManifold(ManifoldSubset):
               F: U --> R
                  (x, y, z) |--> cos(y)*sin(x) + z
   
  +
  +        Same tests with ``sympy``::
  +            sage: c_xyz.set_calculus_method('sympy')
  +            sage: f = U.scalar_field(sin(x)*cos(y) + z, name='F'); f
  +            Scalar field F on the Open subset U of the 3-dimensional topological manifold M
  +            sage: f.display()
  +            F: U --> R
  +               (x, y, z) |--> cos(y)*sin(x) + z
  +
  +            sage: type(f.coord_function(c_xyz).expr())
  +               <class 'sympy.core.add.Add'>
  +
  +
  

• IMO, you are too liberal with your blanklines spacing things out that makes the code a little uneven to read.

[git]

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

​4800d97

Added better (I hope) docstring

[mmancini]

I hope that now the docstring is better (and less liberal)

[egourgoulhon]

Replying to mmancini:

I hope that now the docstring is better (and less liberal)

Thanks a lot for these improvements! I'll have a look at the code next week. Just a quick comment: as revealed by the patchbot, there are still some coverage issue, as well as a problem with sage/manifolds/chart_func.py when building the documentation. There are also some doctest failures.

[git]

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

​ae47c5d

Again changes in docstring

[egourgoulhon]

According to the patchbots, there are still failing doctests in tensorfield.py and the doc does not build.

[git]

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

​611f5de

docstring: again problems with sympy

[egourgoulhon]

The last commit fixes the doc build, but not the doctest failures in tensorfield.py.

[git]

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

​dd82a15

chart_func : changing again display depending on calculus method

[git]

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

​c1d9e4f

chart_func : changing again display depending on calculus method. All test passed

[mmancini]

Display for ChartFunction? has been changed: now the result is different for Sympy and SR. All test results have been modified.

[git]

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

​fb0fb7e

SymPy on manifolds: first reviewer tweaks (more to come)

[mmancini]

Replying to git:

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

​fb0fb7e

SymPy on manifolds: first reviewer tweaks (more to come)

I see in the difference the following one:

@@ -231,7 +225,7 @@ class DiffForm(TensorField):
         sage: a.display(eU)
         a = x*(y**2 + 2) dx/\dy
         sage: a.display(eV)
-        a = (-u**3/16 + u**2*v/16 + u*v**2/16 - u/2 - v**3/16 - v/2) du/\dv
+        a = (-u**3/16 + u*v**2/16 - u/2 - v**3/16 + v*(u**2 - 8)/16) du/\dv

I found is surprising : do you know where this difference comes from?

[egourgoulhon]

Replying to mmancini:

I see in the difference the following one:

@@ -231,7 +225,7 @@ class DiffForm(TensorField):
         sage: a.display(eU)
         a = x*(y**2 + 2) dx/\dy
         sage: a.display(eV)
-        a = (-u**3/16 + u**2*v/16 + u*v**2/16 - u/2 - v**3/16 - v/2) du/\dv
+        a = (-u**3/16 + u*v**2/16 - u/2 - v**3/16 + v*(u**2 - 8)/16) du/\dv

I found is surprising : do you know where this difference comes from?

It is due to a different setting: in the previous version, the transition map xy_to_uv was redefined, thereby causing a different handling of computations between SR and sympy. Note that the two expressions of a are mathematically equivalent, which is satisfactory.

[git]

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

​f985a2f

SymPy on manifolds: second reviewer tweaks (a slight more to come)

[egourgoulhon]

The above commit contains some polishing of the code (mostly layout) and improvements in the documentation. In particular, it restores the section the rubric Differences between chart fucntions and callable symbolic expressions of the previous class CoordFunctionSymb.

Two questions:

• Why is there an argument expression in method ChartFunction._simplify? I mean, if expression is not self.expr(method=calc_method), why not calling directly the simplify method of CalculusMethod on it?

• In the docstring of ChartFunctionRing._coerce_map_from_, there is a TODO section with There is a problem with coercion with rationals. What is that?

[mmancini]

Replying to egourgoulhon:

The above commit contains some polishing of the code (mostly layout) and improvements in the documentation. In particular, it restores the section the rubric Differences between chart fucntions and callable symbolic expressions of the previous class CoordFunctionSymb.

Thanks

Two questions:

• Why is there an argument expression in method ChartFunction._simplify? I mean, if expression is not self.expr(method=calc_method), why not calling directly the simplify method of CalculusMethod on it?

At a particular moment during development I introduced it but I don't remember its functionality. As it is used only internally to ChartFunction I will remove this argument.

• In the docstring of ChartFunctionRing._coerce_map_from_, there is a TODO section with There is a problem with coercion with rationals. What is that?

Look at this example:

M = Manifold(2, 'M', structure='topological')
X.<x,y> = M.chart()
f = X.function(x^2+3*y+1)
g = f+1/2

TypeError                                 Traceback (most recent call last)
<ipython-input-5-83503284e242> in <module>()
----> 1 g=f+Integer(1)/Integer(2)

/home/mmancini/Sage-last/sage/src/sage/structure/element.pyx in sage.structure.element.Element.__add__ (build/cythonized/sage/structure/element.c:10823)()
   1240         # Left and right are Sage elements => use coercion model
   1241         if BOTH_ARE_ELEMENT(cl):
-> 1242             return coercion_model.bin_op(left, right, add)
   1243 
   1244         try:

...
...
...

[git]

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

​c8b3bdc

ChartFunction: modification of _symplify

[git]

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

​e1052fa

Use of SymPy subs when relevant in ChartFunction.__call__

[egourgoulhon]

The above commit

• makes _simplify a mere shortcut to CalculusMethod.simplify in ChartFunction
• introduces the data member ._chart in class ChartFunction
• uses SymPy substitutions (instead of forcing a conversion to SR) in ChartFunction.__call__ when dealing with SymPy expressions
• makes sure that simplify_chain_real_sympy returns a SymPy object
• fixes the issue of coercion of QQ to ChartFunctionRing

[git]

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

​124c582

Improve SymPy documentation in sage/manifolds/scalarfield.py

[git]

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

​eea0070

Change in SymPy conversion function of CalculusMethod + use of SymPy variable in ChartFunction.diff when relevant

[git]

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

​07bef4d

Changing docstring for test results in Sympy

[git]

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

​e5ea40e

- Small error in inverse calculation resolved

[git]

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

​9462954	23990: Convert symbolic relations to SymPy
​07f4744	23990: handle unequality
​0ed659f	23990: do not evaluate
​5f023ea	23990: convert relations from SymPy to Sage, with test
​0f596bb	23990: fix patch
​479e206	23990: sympy patchlevel bump
​3e362ee	24006: SymPy --> Sage conversion completely inside Sage
​8dd5f88	24006: add missing file, fixes
​e0310dd	Merge branch 'u/rws/24006' of git://trac.sagemath.org/sage into public/22801-manifold-sympy
​80f6785	Resolved the problem of simplification in S2 Chart.set_inverse function

[rws]

Better base everything on #20204 as it contains all SymPy Interface improvements, ie abstract functions.

[git]

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

​a68d57f	23923: Interface cases function with SymPy's piecewise
​b80d98c	23923: fix typo
​2afa0ee	22566: interface SymPy's ceiling()
​9494f6c	22566: add test
​8215d37	Merge branch 'develop' into tmp05
​7899ea9	20204: convert SymPy abstract functions
​b261ec3	23923: fix doctest
​5010acf	Merge branch 'u/rws/23923' of git://trac.sagemath.org/sage into t/20204/20204
​952970d	Merge branch 'u/rws/20204' of git://trac.sagemath.org/sage into public/22801-manifold-sympy

[git]

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

​1ff225c

Added Subs._sage_. Now differentiation in manifold work. A problem in dispaly in diff_form.py appeared

[git]

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

​ff540a3

Corrected error in ChartFunction._lmul_ , _rmul_. Still a problem with sympy _eq_

[git]

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

​9962353	Changed __eq__ for chartfunction in sympy case
​14b1c52	20204: more doctests
​df57f9e	Merge branch 'u/rws/20204' of git://trac.sagemath.org/sage into public/22801-manifold-sympy
​9169924	Merge branch 'develop' into t/24006/24006
​d43419f	24006: bump sympy patchlevel
​d0cbda9	Merge branch 'u/rws/24006' of git://trac.sagemath.org/sage into public/22801-manifold-sympy

[rws]

I cannot confirm the one patchbot failure. Most of this was reviewed by Eric, and the rest by me, LGTM.

[egourgoulhon]

Thank you Ralf but I would like to check a few more things before the final positive review

[git]

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

​b1f6587

Allow for SymPy computation of metric determinant

[egourgoulhon]

The above commit fixes the computation of metric determinants when sympy is the calculus method. With it, most of the manifold tutorial passes with all calculations performed with SymPy: ​http://nbviewer.jupyter.org/github/sagemanifolds/SageManifolds/blob/master/Worksheets/v1.1/SM_tutorial_sympy.ipynb.

I have still to check a few extra things to complete the review.

[rllozes]

Grep finds a few mentions of 'manifolds.coord_func' in commentary:

differentiable/scalarfield.py: :class:~sage.manifolds.coord_func.CoordFunction:: differentiable/affine_connection.py: :class:~sage.manifolds.coord_func.CoordFunction (of the subclass differentiable/affine_connection.py: :class:~sage.manifolds.coord_func_symb.CoordFunctionSymb in the current differentiable/affine_connection.py: :class:~sage.manifolds.coord_func.CoordFunction differentiable/chart.py: (cf. :class:~sage.manifolds.coord_func.CoordFunction) differentiable/chart.py: (cf. :class:~sage.manifolds.coord_func.CoordFunction) differentiable/diff_map.py: :class:~sage.manifolds.coord_func.CoordFunction

[git]

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

​5e2da17

Purged references to sage.manifolds.coord_func.CoordFunction

[mmancini]

Replying to rllozes:

I removed the old references, thanks

Grep finds a few mentions of 'manifolds.coord_func' in commentary:

differentiable/scalarfield.py: :class:~sage.manifolds.coord_func.CoordFunction:: differentiable/affine_connection.py: :class:~sage.manifolds.coord_func.CoordFunction (of the subclass differentiable/affine_connection.py: :class:~sage.manifolds.coord_func_symb.CoordFunctionSymb in the current differentiable/affine_connection.py: :class:~sage.manifolds.coord_func.CoordFunction differentiable/chart.py: (cf. :class:~sage.manifolds.coord_func.CoordFunction) differentiable/chart.py: (cf. :class:~sage.manifolds.coord_func.CoordFunction) differentiable/diff_map.py: :class:~sage.manifolds.coord_func.CoordFunction

[git]

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

​92e508b	Fix LaTeX display of continuous maps with SymPy expressions
​31f56d2	Allow arithmetics of Components with SymPy numbers

[egourgoulhon]

With the above two commits, all the S² notebook passes with SymPy: ​http://nbviewer.jupyter.org/github/sagemanifolds/SageManifolds/blob/master/Worksheets/v1.1/SM_sphere_S2_sympy.ipynb except for the 3D graphics of the tangent vector field to the loxodrome (commented cell 193); this is because Sage's matrix constructor (sage.matrix.constructor.prepare) cannot take SymPy numbers (sympy.core.numbers.Float) as elements: it generates the error

TypeError: unable to find a common ring for all elements

The need for such a matrix arises from a change of basis in some tangent space to the sphere, where all tensor components are expressed in terms of SymPy floats (because of the sampling for the drawing). Probably some workaround can be found.

Besides, I am still checking a few other things...

[git]

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

​426f98c

Another series of reviewer tweaks for SymPy calculus on manifolds

[egourgoulhon]

The above commit mostly improves the documentation. In particular, it adds the missing item calc_method in some INPUT sections and slightly improves some doctests.

[git]

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

​8ffa9c4

Improve documentation for SymPy calculus on manifolds

[egourgoulhon]

I am almost done checking the documentation; shall finish tomorrow...

[rllozes]

On my 3-manifold, I observe the following timings:

# One thread takes 317s in Sage, 9311s in SymPy?\\

nabla = g.connection()

# One thread takes 95s in Sage, 1134s in SymPy?\\

LBpsi = nabla(nabla(psi).up(g)).trace(); LBpsi;

# One thread takes 872s in Sage, 36221s in SymPy?\\

Ric_g = g.ricci_scalar()

# One thread takes 482s in Sage, 24220s in SymPy?\\

Cot_g = g.cotton(); Cot_g.parent(); Cot_g.display()

I suggest we take a deeper look after getting the functionality released.

[egourgoulhon]

Replying to rllozes:

I also noticed that SymPy is slower than Sage's symbolic (in particular in the tutorial and S² notebooks mentioned in comment:56 and comment:61).

I suggest we take a deeper look after getting the functionality released.

I agree.

[rllozes]

The above attached notebook shows a failure when run with the multiprocessing directive

Parallelism().set(nproc=4)

while computing the Laplace-Beltrami operator acting on a scalar field

nabla(nabla(psi).up(g)).trace()

defined on a manifold having the 'sympy' option set

M.set_calculus_method('sympy')

When multiprocessing is turned off (nproc=1), this notebook completes without error.

I will try to find a quicker-running example.

[egourgoulhon]

Replying to rllozes:

The above attached notebook shows a failure when run with the multiprocessing directive

Can you resend the notebook? When I try to open it, I get the error

Unreadable Notebook: /home/eric/sage/8.1.beta8/22801_4threads_failure.ipynb NotJSONError("Notebook does not appear to be JSON:u'\\n{{{id=44|\\n# trac 22801 on top of .....",)

[git]

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

​7a49a78

Some tweak of documention of tensor fields with SymPy

[egourgoulhon]

I've finished to review the ticket. Marco, Ralf or Richard, if you agree with my changes, please set the ticket back to positive review (the parallelization issue raised in comment:68, if confirmed, could be dealt with in a separate ticket).

Thank you very much Marco for your work on this; it will be great to have the SymPy functionaly for manifolds in Sage 8.1!

[rllozes]

I will abstain, having not read through all the changes. I can say that I am able to successfully build and run all the doctests (ptestlong).

[mmancini]

Thanks to all for the review. I am going to treat the issue of parallelization (comment:68) which it seems not connencted to sympy.

[rllozes]

Showing failure with computations using sympy and parallelism (proc>1)

[rllozes]

Replying to egourgoulhon:

Replying to rllozes:

The above attached notebook shows a failure when run with the multiprocessing directive

Can you resend the notebook? When I try to open it, I get the error

Unreadable Notebook: /home/eric/sage/8.1.beta8/22801_4threads_failure.ipynb NotJSONError("Notebook does not appear to be JSON:u'\\n{{{id=44|\\n# trac 22801 on top of .....",)

Sorry - Please see second attachment. I will still try to find a simpler case.

[rllozes]

1) Please remove redundant word "curve" which occurs within the documentation of curve.py and integrated_curve.py. 2) Are we letting the TODO's remain undone for this release? 3) In vectorfield_module.py, two occurrences each of "from the North pole" and "from the South pole" were changed to "from North pole" and "from South pole", respectively, resulting in non-standard English.

[git]

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

​ce4acb4

Correct some typo in doc and renable trigonometric simplifications in SymPy calculus on manifolds

[egourgoulhon]

Replying to rllozes:

Sorry - Please see second attachment. I will still try to find a simpler case.

Sorry I still cannot read this file: when I run sage -n sagenb and try to open it, I get "500: internal server error".

[egourgoulhon]

Replying to rllozes:

1) Please remove redundant word "curve" which occurs within the documentation of curve.py and integrated_curve.py.

Done in the above commit.

2) Are we letting the TODO's remain undone for this release?

IMHO yes, because they require substantial work and do not hinder the functionality implemented here.

3) In vectorfield_module.py, two occurrences each of "from the North pole" and "from the South pole" were changed to "from North pole" and "from South pole", respectively, resulting in non-standard English.

Corrected in the above commit; thanks.

Besides the above typos, the last commit restores the trig simplification that was commented out in simplify_chain_generic_sympy and simplify_chain_real_sympy. On general grounds, the SymPy simplification chain should be improved in another ticket.

[rllozes]

Finished review of all changed code and docs. I concur with status of positive_review.

[rllozes]

Replying to egourgoulhon:

Replying to rllozes:

Sorry - Please see second attachment. I will still try to find a simpler case.

Sorry I still cannot read this file: when I run sage -n sagenb and try to open it, I get "500: internal server error".

I have just uploaded another copy, with a new name, after stripping the output and a few commented-out cells. It should open with the standard upload link in the Sage Notebook. It should run as is, and it should fail after changing Parallelism().set(nproc=1) from 1 to 2.

[mmancini]

I have the same error, looking into the file I don't see any sage command.

[egourgoulhon]

Replying to rllozes:

I have just uploaded another copy, with a new name, after stripping the output and a few commented-out cells. It should open with the standard upload link in the Sage Notebook. It should run as is, and it should fail after changing Parallelism().set(nproc=1) from 1 to 2.

This time, I can open the worksheet. Thank you. I am just running it.

[vbraun]

Merge conflict with #24062

[git]

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

​9c4119a	16801: Conversion of psi(x,y) to/from SymPy
​d5c60e3	24062: pkg version/chksum
​1cbc23e	24062: remove obsolote patches; adapt remaining
​94f359f	24062: doctest fixes
​e5de469	Merge branch 'u/rws/24062' of git://trac.sagemath.org/sage into public/22801-manifold-sympy

[mmancini]

The merge with #24062 done in the last commit. No problem for me

[git]

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

​6eb6bde	Improve simplifications in calculus on manifolds when derivatives of symbolic functions are involved
​1f55769	Merge branch of #22801 into that of #24199

[egourgoulhon]

The above commit simply fixes a conflict with #24199. So I am setting the ticket back to "positive review".

[git]

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

​7e5baa5	Reimplement simplifications in calculus on manifolds via the expression tree
​61d97c2	Remove unnecessary __init__ and slightly change in the treatment of 1/sqrt(...)
​ec105bb	Use of wildcards for pattern search in simplifications regarding calculus on manifolds
​87877f0	Solve merge conflict of #22801 in the dependency #24232

[egourgoulhon]

The above commit simply solves a new merge conflict that appeared after the replacement of #24199 by #24232 in the dependencies.

[dimpase]

See the following bug report, in case ​https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/U9v70LoDAwAJ

By the way, I wonder why you prefer using pexpect interface to maxima, instead of much faster maxima_calcuclus loadable library interface?

[egourgoulhon]

Replying to dimpase:

See the following bug report, in case ​https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/U9v70LoDAwAJ

As you pointed out in ​https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/U9v70LoDAwAJ , this bug is not related to this ticket.

By the way, I wonder why you prefer using pexpect interface to maxima, instead of much faster maxima_calcuclus loadable library interface?

Certainly by lack of knowledge... Thanks for your feedback! Can you elaborate a little bit though? Do you mean it is bad to use expr._maxima_() for expr in SR?

[rws]

Replying to egourgoulhon:

Certainly by lack of knowledge... Thanks for your feedback! Can you elaborate a little bit though? Do you mean it is bad to use expr._maxima_() for expr in SR?

This uses sage/interfaces/interfaces.py which is pexpect. The libmaxima functionality can be found in sage/interfaces/maxima_lib.py.

[dimpase]

I wonder why _maxima_lib_() is used only in few places in the library code, as opposed to _maxima_(). Should one open a ticket to modify all these places?

Certainly maxima_lib is more robust and ought to be faster on large data of certain type, at least. It runs Maxima in a Python extension module rather than talks to Maxima run as an external process.

[egourgoulhon]

Replying to dimpase:

I wonder why _maxima_lib_() is used only in few places in the library code, as opposed to _maxima_(). Should one open a ticket to modify all these places?

From what you say about maxima_lib, I would say yes. In particular, _maxima_() is used in various methods of sage.symbolic.expression.Expression, like simplify(), simplify_factorial() and simplify_trig().

[rws]

See #17753 and ​https://trac.sagemath.org/wiki/symbolics/maxima for a summary.

[rllozes]

In the code at ​https://groups.google.com/d/msg/sage-devel/3sN7gVTdNuY/U9v70LoDAwAJ, if we change the computation method from 'SR' to 'sympy', the same Maxima/ECL bug occurs when computing g.inverse(), where 'g' is the Riemannian metric. Why does the code call the same simplification logic, disregarding the computation method setting as 'sympy'?

[rws]

Please open a new ticket.

[egourgoulhon]

Replying to rws:

Please open a new ticket.

This is #24290. It was on the todo list anyway (cf. the TODO statement in line 794 of ​https://git.sagemath.org/sage.git/tree/src/sage/manifolds/utilities.py?id=780e1a477fe81c46d32286174fcb58d53e8cbe4c ).