#15223: Let the `TestSuite` test that the construction of a parent returns the
parent
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-5.12
Component: coercion | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/SimonKing/ticket/15223 | a81fcc1072df88cc369d7aa0b7ae423fd97d7f02
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:10 SimonKing]:
> I just added Nicolas to this ticket, since it relates not only with
coercion (this is the component of this ticket) but also with categories.
>
> In a nutshell: If P is a parent, then `P.construction()` should return
None, or a pair F,O, where F is a construction functor and O is some
object.
>
> The contract is that `F(O)==P`. But nobody has checked this contract so
far. The original aim of this ticket is to introduce a test.
This sounds like a good idea indeed! I would tend to put the test in
Sets (in the general trend that there is already too much stuff in
Parent; and maybe construction should be moved there, so as to make it
easier to overload it, e.g. in some categories).
It would make sense as well for the test to accept the case where
`construction` is an undefined abstract method. But maybe we don't
have a use case for now.
> While we are at it, I thought one could improve `QuotientFunctor`. First
of all, it ''must'' allow to pass additional arguments to the quotient
being constructed. For example, the construction functor for
`IntegerModRing(19, category=Fields())` must know that the category is
specialised. Similarly, the construction functor for
`BooleanPolynomialRing(...)` must know that the result is not just a
quotient of a polynomial ring, but has a special implementation.
>
> And something else that I want to improve with the `QuotientFunctor`:
Currently, it is a functor from Rings() to Rings(). But why?? Perhaps, at
some point, we want to apply the `QuotientFunctor` in the context of
groups!
>
> Hence, I think it would make sense to be more precise when choosing the
domain and codomain of the functor.
>
> Today, I experimented with this idea: If Q is a quotient, and
`F,O=Q.construction()`, then the quotient functor F should go from
`O.category()` to `Q.category()`.
>
> But when running the tests, it turns out that this is too narrow:
Sometimes, we want to apply the quotient functor F to a ring over a
''different'' base ring.
This does not seem directly related to this ticket. Could this easily
be split off into a separate ticket?
> This makes me think of the following: Would it make sense to introduce a
method of categories `C.without_parameters()`, returning the join of all
super-categories of C that are not instances of `CategoryWithParameters`?
>
> For example, for `C = Category.join([EnumeratedSets(),Algebras(QQ)])`,
`C.without_parameters()` would return `Join of Category of rings and
Category of enumerated sets`.
>
> Nicolas, do you think it would hurt to introduce such method here?
This seems like a sensible method; so if you have a use for it, go
ahead.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/15223#comment:12>
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/groups/opt_out.
