On Mon, Mar 10, 2014 at 11:36:01AM -0700, Niles Johnson wrote:
> Oh -- maybe that's why I have a hard time understanding categories :)
:-)
> That makes sense -- I see the need for something along these
> lines. After scanning the ticket discussion and documentation, I
> think the purpose is to provide some way of mixing in some (but
> not all) methods from one class to another. And it is desirable
> that these be "top-level" methods -- that makes sense too.
Hmm, I am not sure to see what you mean. See below too.
> But the way this is done does seem confusing (at least, as I
> understand it from examples here, on the ticket, and the
> documentation on defining a new axiom [1]).
You might want to check the primer as well (there is a link at the
beginning of the axiom doc).
> Is the global axiom list necessary so that Sage knows where to
> find the relevant "mix-in" methods?
Nope. Roughly speaking it's basically just used for printing out
categories, and to make FiniteGroups() work as an alias for
Groups().Finite(), which is mostly for backward compatibility.
> On the question of which category should contain the actual definition of
> a method, a more even-handed approach would be to define a separate class
> so there is no arbitrary selection of a "largest category". But it sounds
> like at this stage you would like *fewer* implementation ideas, not more
> ;)
:-)
Still, if you can elaborate on what you mean on an example, e.g. for
in which class to put the definition of the Distributive axiom. that
can give ideas for the future.
> As you said, implementing axioms involves some guessing about the
> future, and some opinions on what is
> useful/natural/convenient/pythonic/mathematical etc. Maybe
> another useful exercise (for those of us just joining the
> discussion) would be a list of desirable properties for a notion
> of axioms in sage. I think you gave something like this in the
> "relevance" section of your first post, but that is more about
> why we want axioms, rather than what properties they should have.
Yup.
> Lastly, now that I've been thinking about this for a while, could
> someone explain how topological groups or Lie groups might be
> implemented in this framework? The axiom documentation stresses
> that axioms define full subcategories, but Topological groups are
> not a full subcategory of sets (or groups), so I guess maybe one
> would define a category of topological spaces, and a Discrete
> axiom, making Sets the category of discrete topological spaces?
> Would one have to move methods from Sets to TopologicalSpaces
> then? I do mean this as a genuine question, even though it seems
> silly to insist that sage represent sets as discrete topological
> spaces (obviously we would want discrete *equivariant*
> topological spaces with trivial group action ;)
I am not a topologist by far, so I am probably going to say some
stupid things. But let me give it a shot at how we could design
this. I assume in general that a Topological Foo (or TFoo for short)
is a foo where the foo-operations are somehow *compatible* with the
topology (continuity I guess).
Assuming, for example, that Foo is a subcategory of groups, the
category hierarchy would look like:
Sets
/ \
Groups TSets
/ \ /
Foos TGroups
\ /
TFoos
I.e., under the usual hierarchy of categories (Sets, Groups, Foos,
...), you would get a parallel hierarchy for their Topological
variants. That is, in theory. In practice it's going to be a much
smaller hierarchy: for most categories Foos, there won't be specific
code implemented for Topological Foos.
Note that automatic intersections would not be appropriate here: a foo
which is also a topological set is not necessarily a topological foo.
That's related to the fact you mentioned: the category of topological
foos is not a full subcategory of the category of foos. Therefore
"Topological" should not be an axiom, but a "covariant functorial
construction" (very much like "Graded").
In practice, one just need to define the construction in the Sets
category, and then, when there is something to be implemented about
topological foos, we create a class Foos.Topological to model this
category. There is no need to hardcode that a topological foo is both
a foo and a topological group: the super category relation for
topological categories is constructed automatically.
Finally one needs to hardcode some facts, in particular about
compatibility with other axioms. For example, commutativity is
compatible with continuity: a commutative topological group is a
topological commutative group. On the other hand the existence of
inverses does not guarantee that those are continuous: a topological
monoid with inverse is not a topological group.
Now to the "Discrete" thing. It's often the case that a given set X
can be equipped with several topologies, and we probably don't want to
handle several topologies at once in the same parent. That is, instead
of having a single parent modeling X, we will have several parents
(possibly facades), each one modeling "X equipped with the YYY
topology". Those parents will be in the category of topological sets
(or some subcategory).
X by itself will be modeled by a parent in the category of sets, and
not endowed by default with it's discrete topology. Instead, there
would be some constructor, say SetWithDiscreteTopology, for building
"X equipped with the discrete topology".
Now what to do with the code for XXX equipped with their discrete
topology? If we have such code for several categories XXX, say Sets,
Groups, ... then it can make sense to model the corresponding
categories like "foos equipped with their discrete topology". Given
that, e.g., a "set equipped with the discrete topology" which is also
a group is a "group equipped with the discrete topology", this would
be a good use case for an axiom "EquippedWithTheDiscreteTopology".
Code would then go in classes Sets.EquippedWithTheDiscreteTopology,
Groups.EquippedWithTheDiscreteTopology.
As above the hierarchy relations will be deduced automatically, and as
a bonus, intersections will happen automatically.
> I've already made my attempt above, but I'll attempt to say
> it more clearly, as I understand it:
> * An "axiom" is a collection of methods that can be called from two or
> more different classes.
> * The methods inherited from an axiom are top-level.
> * Each "axiom" has a mathematical description.
> * If class Cs includes the methods from "axiom" A, then it must be true
> (either as a theorem or by definition) that every instance of "Cs with A"
> satisfies the description of the axiom A.
> The last two seem is especially important as new methods may be added to
> the "axiom", without necessarily testing them on Cs. So there needs to be
> a theoretical guarantee that any (correctly implemented) method in A will
> work correctly for "Cs with A"
> I guess under this definition then any time B is a subclass of A, the
> methods of A not overridden by B are an "axiom" since they're accessible
> by A and B. But we also want to make just some of the methods of A into
> an axiom, without having to move them to a new superclass for both A and
> B.
Err, I am not sure I can connect the above with what I have in mind :-)
For me, an axiom A is just a predicate on the objects of the category
Cs() defining it. Then, for each subcategory Ds() of Cs(), you can
consider the full subcategory Ds().A() of the objects of Ds satisfying
the axiom. And, if relevant, implement that category to provide
methods for those objects and their elements.
Topological is not axiom, because the predicate defining topological
groups is not the same predicate as for defining topological sets.
> I think Nathann Cohen gave a good answer, but I think another point is
> that different mathematical backgrounds are going to give different but
> equivalent ways of describing the same categories. So it should be as
> easy as possible to figure out which description sage is using.
Would you have a concrete example in mind?
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
