Opened 8 years ago
Last modified 5 years ago
#14194 new defect
Conversion from pari to sage
Reported by: | roed | Owned by: | was |
---|---|---|---|
Priority: | major | Milestone: | sage-wishlist |
Component: | interfaces | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Conversion from pari to Sage uses the global namespace:
sage: QQ['s'].gen()._pari_().sage() Traceback (most recent call last): ... NameError: name 's' is not defined sage: GF(9, 'a').gen()._pari_().sage() Traceback (most recent call last): ... NameError: name 'a' is not defined
We can do better.
Change History (3)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
- Milestone changed from sage-5.9 to sage-wishlist
comment:3 Changed 5 years ago by
I'm sure roed knows this, but the correct call syntax here is:
sage: sage: R = QQ['s'] sage: sage: t = R.gen()._pari_() sage: sage: R(t) s sage: F = GF(9, 'a') sage: t = F.gen()._pari_() sage: F(t) a
After all, PARI has no class hierarchy, so why should a PARI univariate polynomial be expected to know which Sage polynomial ring it should convert back to?
If I were feeling provocative, I might go further and propose that the sage method of a PARI object should be deprecated in favor of the constructor syntax shown above, even for PARI types where there isn't any ambiguity about the Sage parent (e.g., integers).
Note: See
TracTickets for help on using
tickets.
What's the problem? I don't really see how you want to fix this.