#15475: Reenable broken doctests in #15473 and #15476 when #10963 is merged
-------------------------------------+-------------------------------------
Reporter: darij | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.4
Component: categories | Resolution:
Keywords: 10963, | Merged in:
categories, c3, coercion, | Reviewers:
transitivity, descent algebras, | Work issues:
symmetric functions | Commit:
Authors: | bf3415442124b6778afdb799016efa4343c677b8
Report Upstream: N/A | Stopgaps:
Branch: |
public/categories/15475 |
Dependencies: #10963, #15473, |
#15476, #16678 |
-------------------------------------+-------------------------------------
Comment (by darij):
That's good news! #15229 might actually be a fix for the root cause, not a
workaround:
{{{
sage: SymmetricFunctions(Zmod(14))
Symmetric Functions over Ring of integers modulo 14
sage: Zmod(13) in Fields() # if not for this "check", then the following
would break
True
sage: SymmetricFunctions(Zmod(13))
Symmetric Functions over Ring of integers modulo 13
}}}
and, for #11979:
{{{
sage: from sage.algebras.divided_power_algebra import
UnivariateDividedPowerAlgebra
sage: A = UnivariateDividedPowerAlgebra(Zmod(9)); A
The divided power algebra over Ring of integers modulo 9
sage: Zmod(5) in Fields() # if not for this "check", then the following
would break
True
sage: A = UnivariateDividedPowerAlgebra(Zmod(5)); A
The divided power algebra over Ring of integers modulo 5
}}}
So my guess would be that category refinement doesn't like it when a
category changes in the midst of it, and the category of Zmod(n) does
change when Zmod(n) is tested for fieldness:
{{{
sage: Zmod(17).category()
Join of Category of finite commutative rings and Category of subquotients
of monoids and Category of quotients of semigroups
sage: Zmod(17) in Fields()
True
sage: Zmod(17).category()
Join of Category of finite fields and Category of subquotients of monoids
and Category of quotients of semigroups
}}}
With #15229 fixing this, I think we can hope to see the end of this issue.
Is this pattern, where an object lazily starts off with a broad category
and then refines in when the user checks for properties, common in Sage?
Should we get rid of that or tweak the code to allow it?
--
Ticket URL: <http://trac.sagemath.org/ticket/15475#comment:45>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
