#11900: Serious regression caused by #9138
-----------------------------------------------------------------+----------
Reporter: SimonKing |
Owner: tbd
Type: defect |
Status: needs_work
Priority: blocker |
Milestone: sage-4.7.2
Component: performance |
Keywords: categories regression
Work_issues: fiy doctests, fix categories for polynomial rings |
Upstream: N/A
Reviewer: |
Author: Simon King
Merged: |
Dependencies: #9138
-----------------------------------------------------------------+----------
Changes (by SimonKing):
* work_issues: => fiy doctests, fix categories for polynomial rings
Comment:
Replying to [comment:34 nthiery]:
> > The caching (so that the cache already happens when calling
> > `Category.join(L)`, not only when creating the `JoinCategory`)? Or
> > the attempt to directly create the `JoinCategory` during creation of
> > a polynomial ring?
>
> This might induce some quite big caching, since a given join may be
> created in many different ways (order of arguments, ...).
I thought that the join does depend on the order of the input categories.
If it doesn't, one could always use frozen sets as key, rather than
tuples.
> > I think the latter is justified by having only few cases: It can be
`UniqueFactorisationDomain`, `IntegralDomain` or `EuclideanDomain`, and it
can be commutative or not. So, one can directly write down the result,
rather than calling the `Category.join(...)` mechanism. Of course, one
needs to verify that I wrote it down correctly.
>
> The only potential issue is about the order of the categories in the
join. Having everything go through Category.join makes it easier to
maintain consistency, and make it evolve if needed.
OK. If join changes the order of arguments in future versions of Sage,
then we should change the five or six hard-coded categories that my patch
uses in the initialisation of polynomial rings.
I suggest to add doc tests of the form
{{{
sage: P.<x> = ZZ[]
sage: P.category() is Category.join([CommutativeAlgebras(ZZ),
UniqueFactorizationDomains()])
True
}}}
(that should be the answer, but with the current patch it is only the join
of `Algebras(ZZ)` with `UniqueFactorizationDomains()`. So, that needs to
bee fixed as well.
Having such tests would detect incompatible changes in the order of base
categories in the join.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11900#comment:36>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
