#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:449 vbraun]:
> Well a few categories are always going to be constructed on startup
In principle, we could imagine not having a single one; but I can live
with a couple.
> I'm sorry, I overlooked the comment in your code that stated that you
want to get rid of those imports-on-startup. Oh, no comment? In that case
I'm sorry for not having any telepathic abilities to read your mind ;-)
You really should work on your sightseer skills; then you would have
foreseen that this is now written in the documentation :-)
> > Mathematically speaking, you agree that an axiom *is* naturally tied
> > to a most basic category, right? That which provides the language
> > necessary to express the semantic of the axiom.
>
> I agree that there is, mathematically speaking, always some join
category that would be the most basic.
> But there is no need to require Sage developers to implement a common
supercategory by hand. Of course you can, but the whole point of this
ticket is to reduce the number of categories that you must construct by
hand.
I agree: it's non optimal to have to implement a placeholder category
MagmasAndAdditiveMagmas just to define the distributive
axiom. Likewise for the chain
DistributiveMagmasAndAdditiveMagmas.AdditiveAssociative.AdditiveCommutative.AdditiveUnital
I mentioned earlier. But this is well within the scope of the ticket
which is to go from a potentially exponential number of placeholder
categories to just a couple.
It's certainly a compromise, but I believe it's a reasonable price to
pay (with the asymmetry discussed above) for the current feature set
(in particular the ``C.Finite()`` idiom) and performance.
What I find more annoying is that Sage can't currently be taught that
MagmasAndAdditiveMagmas is the join of Magmas and AdditiveMagmas,
which is why I did not yet implement MagmasAndAdditiveMagmas together
with its Distributive axiom. In the longer run, I would like to fix
this by making `join` more powerful, but that will need some thought
on an appropriate idiom.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:468>
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.
