Hi,
this is lifted Sergiu's pull request discussion to expose it to a wider
audience. We are discussing the class hierarchy for morphisms (to the
extent that there should be any hierarchy).
In general, a morphism is essentially a directed edge of a graph, the
starting vertex is called domain and the ending vertex codomain.
There are, for practical purposes, three kinds of morphisms:
- "named" morphisms.
These have associated a domain, codomain and "name". Two named morphisms
are equal iff they have the same name, domain and codomain.
- identity morphisms
These have a domain, and codomain equal to domain. There is a unique
identity morphism for every object.
- composed morphisms
Since categories model typical mathematical situations, composition of
morphisms is of course important. But since categories are essentially
abstract, the only thing we know, a priory, about a composed morphism is
what morphisms it was obtained from. As such, composed morphisms have
domain, codomain, and "components" (the list of morphisms that was
composed to obtain the current morphism).
Sergiu started out with one class for all three cases. He then turned
identity morphisms into a subclass (because storing booleans in .args is
tricky). I then suggested a finer splitting still:
Tom:
Actually (sorry for not thinking this through earlier): why do composed
>> morphisms have names at all? I see why it can be useful to name
morphisms in a diagram (also composed ones, presumably), but that's not
>> really the point. The kinds of names we attach to both morphisms and
objects
>> are "internal" - they are used *purely* to distinguish them, and are
not necessarily related to user-visible names.
Sergiu:
Yes, agreed.
I would think that composed morphisms are identified by their components,
>> and as such don't need names. In fact, I think composed and named
morphismsshould live in separate classes!
That's an unexpected point of view, for me And you do raise important points.
> I'll try to muse a bit here, and I'll then sleep it over.
Initially, I thought that what you suggested sounded like removing the name from
> `Morphism` and deriving a class `NamedMorphism` from `Morphism`.
> However, in this case `NamedMorphism` inherits the components from
`Morphism`.
> If we do if the other way round (derive `Morphism` from
`NamedMorphism`), then > `Morphism` will have a name, which defeats the whole point.
This means that
> there should be a third class, `MorphismBase`, which, uhm, has only a
domain and
> a codomain. `CompositeMorphism` derives from `MorphismBase` and can
have components,
> while `NamedMorphism` derives from `MorphismBase` and adds a name.
> Then, hm, we derive `IdentityMorphism` from `MorphismBase`(?), because
> names don't really make much sense for identities, and identities
cannot be composite.
Does this go along the lines you were thinking of?
Yes.
If yes, I can't say I am really enthusiastic, because, to factor out the name
of a morphism,
> we add two classes. Also, there is essentially no way of treating a
collection of morphisms uniformly, since some morphisms don't have names,
> others don't have components; one will always have to check the type.
Not necessarily. You could have properties (implemented in MorphismBase)
.name, .components which return "" and [self] to allow uniform access.
Not sure to what extent this defeats the idea.
Not that I say it's critical or even necessary; just throwing about ideas.
I'm not very sure about it either. That's why I said "what do you think"
:-).
Generally, I like it when the class model follows the real-world model with
> great granularity; but in this case I'm afraid whether this isn't
> going to be an overkill.
Yes, I also tend to worry about overkill, mostly because sometimes I
don't see when I create it ^^. I think what troubles me most about the
current design (and "most" really does not mean very much at all) is
that there is one class doing several things, not all of which make a
lot of sense in all scenarios.
Tom
--
You received this message because you are subscribed to the Google Groups
"sympy" 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/sympy?hl=en.
