#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):
Helloooooooo !!
> I think you are the person to answer the questions I raised in my
previous post and on sage-combinat-devel:
Oh ? Hmmm, I don't always read them.
> - Are digraphs constructed with `data_structure="static_sparse"`
considered being immutable? If they are, shouldn't one set the attribute
`._immutable` to the graph, so that the hash won't complain about
mutability?
No, they are not. Only the backend is immutable, the graph itself isn't. I
mean, you can't add/remove vertices nor edges (you would get an exception)
using the Graph object, but there is a wealth of awful things that graphs
store, and that are still mutable. Like embeddings, like a LOT of stuff.
Can't an edge label be mutable too, btw ? Embedding, layout, name,
allowing or not multiple edges/loops.
My problem with the patch at #14535, is that decorators on methods that
are heavily used could impact ALL graphs (not only the immutable ones),
and also that knowing a graph is immutable is information that can make
you save space and speed, which is now done. But there is nothing wrong at
all with using those decorators for less critical methods, like setting
the embedding or the layout ! So you can update #14535 to use #14806 and
only decorate these additional methods, and get real immutable Graph
objects, it seems the best way to do it !
> - Would it be OK from your perspective to add the methods for creation
of "free small category" (i.e., directed paths with concatenation), quiver
representations and quiver algebras to `DiGraph`? Or would you prefer that
we keep creating a sub-class `Quiver` of `DiGraph` providing these
methods?
I don't really know what these methods do, to be honest.. Do they apply to
all digraphs, for a start ? And do you think that you would ever want the
digraphs you use to have anything to do with the parent/element stuff and
facades ?
Most importantly, do you really think that you want to inherit from
DiGraph ? You can use the backends without inheriting from DiGraph
objects, and in particular you wouldn't have 10000 unrelated methods in
your objects. And you could have a method from quivers to graph if you
ever want to do things like computing a hamiltonian circuit in your
quivers ? `:-P`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:127>
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.
