#12630: Add representations of quivers and quiver algebras to sage
-------------------------------------------------+-------------------------
Reporter: JStarx | Owner:
Type: enhancement | AlexGhitza
Priority: major | Status:
Component: algebra | needs_work
Keywords: algebra, quiver, module, | Milestone: sage-5.12
days49 | Resolution:
Authors: Jim Stark, Simon King, | Merged in:
Mathieu Guay-Paquet, Aladin Virmaux | Reviewers: Simon
Report Upstream: N/A | King
Branch: | Work issues:
Dependencies: #12412, #12413, #14806 | Commit:
| Stopgaps:
-------------------------------------------------+-------------------------
Comment (by ncohen):
Hellooooooooo !!
> Let me rephrase my question: Probably, if one really wants to play
dirty, one could change edge labels. But is it possible to change edge
labels by using "official" (non-underscore) methods of the graph? If it is
impossible, then I'd say the graph is immutable.
Well... You can get the edge label from a pair of vertices u,v (and that
label could be a list), then modify it. But you'd be looking for trouble
of course.
> And concerning edge labels: Yes, I need them for the constructions of
quiver
> algebras and so on.
Okayokay `:-P`
> So, if it is possible to change the edge labels of a "static_sparse"
digraph
> by using non-underscore method, then I'd say we ''can't'' work with
digraph
> (and need a sub-class or something else).
Ahem. Well, for a start, the static backend only support multiple edge,
loops and labels because you need them. And most of this patch headaches,
as usual, come from multiple edges, loops and labels. I personally hate
them with all my heart `:-P`
Then, as the graph is static these things have no reason to be mutable.
Though the backend only stores the labels as "python objects", and Python
objects can be anything. A "clean" implementation would be to refuse to
convert to an immutable graph any graph which has non-immutable edge
labels, but I think that's going too far. And this implementation gives
you the freedom to filter whatever you want anyway.
> > Embedding, layout, name, allowing or not multiple edges/loops.
>
> This won't matter for me. Actually, if you compare digraphs ("=="),
would the
> embedding, layout, name and so on be taken into account?
Good question. I hope not. I don't have Sage right now (it's compiling),
but if
g = graphs.PetersenGraph(); g == Graph(g.edges())
says True, then we are sage and these are not taken into account.
Though it would make sense to prevent anybody from changing the
embedding/layout in an immutable graph anyway. Let's pretend, at the very
least `:-P`
> Let me rephrase my needs: For me, it is important that one can't (by
> non-underscore methods) change the ==-equivalence class of the graph. If
this
> is the case, then it is immutable.
Well. You would have to check what == actually checks, and make sure that
your equality uses exactly the same set of parameters. And to make sure
that one doesn't get updated while the other one does not in the future
`:-P`
I hope that there is nothing surprising/worrying there, though.
Though of course, if two graphs with the same edges have different labels
they will be different. And you can (currently) modify an edge label if
the edge label object is mutable, using only non-underscore methods.
> The stuff here is not related with #14535 (which is probably just a bad
idea).
Well, if you want immutable graphs you will probably have to use these
decorators ! I think that two graphs cannot be equal if one allows
multiple edge while the other one does not. Perhaps it is a mistake,
though `:-P`
> AFAIK, there is no mathematical difference between a quiver and a
digraph.
Then why would you call them quivers ? `:-P`
> And
> of course, for any digraph, you can construct the algebra whose monoids
> correspond to directed paths, which are multiplied by concatenation
(yielding
> zero if the end/startpoints don't match): The quiver algebra.
>
> So, yes, the mathematical notions here make sense for all digraphs.
Hmmm... Well, a `.quiver_algebra()` method would make sense indeed then.
Would you have many to add ?
> But, as you know, I like `UniqueRepresentation`.
`:-D`
> And since the digraph together with a
> base ring is enough to determine the quiver algebra, I would like to use
the
> digraph as a cache key.
It does make sense. I also need this from time to time actually `O_o`
> Hence, from the implementation point of view, "quiver algebra" and
friends
> will only make sense for all ''immutable'' digraphs.
Why so ? I chatted a bit with Florent about this, and it seems that you do
need some specific data structure to store all these paths, and
concatenate them easily and quickly and everything. I thought that calling
a `.quiver_algebra()` in a (possibly mutable) graph would somehow give you
a new object containing that data structure, and that this would probably
encode the graph in a better way too ?... By the way, this static data
structure is now ... extremely cheap, compared to the current graphs.
Really, really cheap. And copying it is really just a `memcpy` of size
`g.size()`.
> No. For me, the digraphs are just labels for some algebra.
Cool, cool.
> Well, a quiver ''is'' the same as a digraph. So, I believe it totally
makes
> sense to have 10000 unrelated methods.
Really, why don't you call them digraphs then ? `O_o`
> And yes, I also believe that digraph should
> have even more methods, namely in addition: A method returning the
quiver algebra
> over a given ring and some methods being able to construct
representations of the
> quiver.
Hmmm... And what about having a `quiver_albegra()` method that returns
this quiver algebra, and having those method for representations be
methods of this quiver algebra object ? Or would it make more sense to
have these methods be methods of digraphs (or Quivers), directly ?
> __Conclusive question__
>
> Do we have digraphs with the property that it is impossible to change
the ==-equivalence class by using non-underscore methods?
You can definitely do that if the graph has mutable edge labels. In this
case the non-underscore method .get_edge_label() would return the object,
you can then modify it, and the graph should not be equal to what it was
before anymore. Then you probably have to check what equality ensures
right now, and I'm sorry I cannot do this but I have no Sage install
available right now `^^;`
> If we have, then I'd suggest to add a few more methods to them. And
don't worry, I won't turn digraphs into parents or facades... :)
Thaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanks !! `:-P`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:129>
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.
