Opened 3 months ago

Closed 2 months ago

# enhance maple interface

Reported by: Owned by: chapoton major sage-9.7 interfaces: optional maple tscrim., slelievre, gh-kliem, klee, mmezzarobba Frédéric Chapoton Marc Mezzarobba N/A b454e74 b454e74bb0938b4c06862ae994f2b961bc4438ea

### Description

by trying to convert back functions names

### comment:1 Changed 3 months ago by chapoton

• Branch set to u/chapoton/maple_names
• Commit set to 4a4c415f280c37eecf5477767c384db794ff8746
• Status changed from new to needs_review

New commits:

 ​fdb2a86 conversion of maple functions ​da2e96b slightly better maple "parser" ​4f2bc3f detail ​4a4c415 better maple interface, with doctests

### comment:3 Changed 3 months ago by git

• Commit changed from 4a4c415f280c37eecf5477767c384db794ff8746 to 4fcdf5c3e69c6b777fec34e5e5d36eab44436adc

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

 ​4fcdf5c more work on maple "parser"

### comment:4 Changed 3 months ago by git

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

 ​9d1d769 fix details in maple parser

### comment:5 Changed 3 months ago by git

• Commit changed from 9d1d769ad499c9e9bcea481415125f3017b0f455 to 2940e700888d1b305c8fa6061e8faed421e34ed8

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

 ​2940e70 conversion of maple functions

### comment:6 Changed 3 months ago by git

• Commit changed from 2940e700888d1b305c8fa6061e8faed421e34ed8 to 9d33c1deb887d3224a4b86ad990b855db8674624

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

 ​9d33c1d one more doctest

### comment:7 Changed 3 months ago by git

• Commit changed from 9d33c1deb887d3224a4b86ad990b855db8674624 to f307ea75caba505fbeb164faa3a991ca10c27d9d

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

 ​f307ea7 also convert Sum and Product

### comment:8 Changed 3 months ago by git

• Commit changed from f307ea75caba505fbeb164faa3a991ca10c27d9d to 9ea07376cf5bf27d3bd63fd0189090c1ef56422a

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

 ​9ea0737 now for integrals too

### comment:9 Changed 3 months ago by git

• Commit changed from 9ea07376cf5bf27d3bd63fd0189090c1ef56422a to b454e74bb0938b4c06862ae994f2b961bc4438ea

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

 ​b454e74 tweak maple parser

### comment:10 Changed 3 months ago by chapoton

• Cc tscrim. slelievre gh-kliem klee added

bot is morally green, ticket ready for review. A good step forward in the translation back from maple, I would say.

### comment:11 Changed 3 months ago by chapoton

one could also treat "Limit" and "limit" in the same way, maybe.

### comment:12 Changed 2 months ago by mmezzarobba

This is an improvement, though the conversion remains very fragile.

One thing I don't like is that the conversion is based purely on the textual representation of the Maple expression and does not differentiate between global and local Maple symbols. For example, maple("(proc() local zeta; return zeta; end)()(2)").sage() yields π²/6 although the Maple zeta we are converting is not the one bound to the zeta function. I do understand that fixing this is beyond the scope of this ticket, but I also believe that we should make the interface more robust before trying to extend it too much.

Can you explain why you needed to do this

         BuiltinFunction.__init__(self, 'hurwitz_zeta', nargs=2,
conversions=dict(mathematica='HurwitzZeta',
-                                                  maple='Zeta',
+                                                  # maple='Zeta', conflict with zeta here
sympy='zeta'),
latex_name=r'\zeta')



?

### comment:13 follow-up: ↓ 14 Changed 2 months ago by chapoton

I agree that this is not a solid conversion. Still better than previously.

It would be much more work to switch to something else, maybe some kind of standardized API.

For the second point, we are hitting here a limitation of our conversion system. We use different names for Zeta (one parameter) and Hurwitz zeta (two parameters). Maple uses just one name. We cannot have both a correct conversion forward and a correct conversion backward, using just a dictionary of functions names. One solution would be to enhance our conversion system to be able to make different choices for different numbers of arguments. Not for this ticket, I would say

For the time being, I chose to give priority to Zeta over Hurwitz Zeta

### comment:14 in reply to: ↑ 13 Changed 2 months ago by mmezzarobba

• Status changed from needs_review to positive_review

I agree that this is not a solid conversion. Still better than previously.

Yes, I agree.

It would be much more work to switch to something else, maybe some kind of standardized API.

Maple actually has a C API that would make it easier to have a robust interface. But yes, that would require a bit of work, and it is not clear to me if we can use it without having Maple as a build-time dependency for the corresponding binary modules.

For the second point, we are hitting here a limitation of our conversion system. We use different names for Zeta (one parameter) and Hurwitz zeta (two parameters). Maple uses just one name. We cannot have both a correct conversion forward and a correct conversion backward, using just a dictionary of functions names. One solution would be to enhance our conversion system to be able to make different choices for different numbers of arguments. Not for this ticket, I would say

For the time being, I chose to give priority to Zeta over Hurwitz Zeta

Ok, thanks for the explanation.

### comment:15 Changed 2 months ago by chapoton

• Reviewers set to Marc Mezzarobba

merci !

### comment:16 Changed 2 months ago by vbraun

• Branch changed from u/chapoton/maple_names to b454e74bb0938b4c06862ae994f2b961bc4438ea
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.