#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.13
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):
Hellooooooo Simon !
> I had recently focused on different things, but now want to resume work
here---and need some pointers/advice from you.
Ahem. As I needed pointers and advice myself I asked Nicolas, who should
shortly give his advice on the namind problems. Like this
{{{.free_small_category()}}} function, the Magma which is not a Magma (he
told me that the operation was not defined for all pairs of paths), and
hence about the monoid which is not a monoid `:-)`
> To me as well. But it seems that some people really think of it in terms
of the graph.
He will answer that too.
> It could be that you have answered the following question already; in
this case please give me a remainder: Is #14806 really enough to have
immutable graphs, in the sense of "official methods such as `add_vertex`
will not be able to change the ==- and cmp-classes of the graph"?
No, it's not sufficient because of {{{Graph.__eq__??}}}. Before anything,
it checks that both graphs answer the same to {{{Graph.allows_loops()}}}
and {{{Graph.allows_multiple edges()}}}. In particular it does not mean
that the graphs have loops or multiple edges, only that they allow them.
So if you want == to make sense on immutable graphs I think you would have
to install your immutability decorator in those methods.
Oh, and it also checks the value of the boolean variable {{{._weighted}}}.
I personally never used it, and I don't like it `:-P`
If those three parameters are correctly managed I think that there is no
problem left with {{{__eq__}}}. Except that it can be made MUCH faster
than the current implementation with a C-level function of equality test
in the static sparse graph backend. To be honest, reading this Python code
to test equality scares me `:-P`
> Note that I don't care about the possibility to have mutable labels and
change these in-place. This is a misuse that is in the user's own
responsibility.
Yep. I agree with that too.
> If you answer this question affirmatively, then the question is what we
shall do with the hash:
> {{{
> sage: g = graphs.CompleteGraph(400)
> sage: gi = Graph(g,data_structure="static_sparse")
> sage: hash(gi)
> Traceback (most recent call last):
> ...
> TypeError: graphs are mutable, and thus not hashable
> }}}
> So, if you answer my question affirmatively, then apparently the flag
`gi._immutable` should be set to `True` when using the immutable graph
backend. Shall I open a new ticket for this?
Yep. Along with the decorators for weights, loops and multiple edges. You
will not have to wait very long for review.
> And what is the preferred way of creating an immutable copy? Is it (as
above) `Graph(g, data_structure="static_sparse")`? Or is there a faster
way to create an immutable copy?
Ahem. There is a "faster" way for the user, but all are equally shameful
from the point of view of computer speed. Any input that the {{{Graph}}}
constructor accepts can be used with {{{data_structure="static_sparse"}}}
: a normal graph will first be built, THEN its backend will be replaced by
a static one. So yeah, not very efficient. That's because the C-level
method to create a static sparse graph only takes Graphs as an input.
If you think it should be made faster one trick would be to work directly
on the internal dictionary into which Sage temporarily stores the input
data before creating the non-static sparse graph backend. This may not be
too much work, I don't know if it will produce a very great change in the
speed (though I would stop wondering if it does), and I don't mind doing
it myself if calling {{{Graph}}} is too slow for your uses.
And it seems Nicolas wrote his answer while I was writing mine `:-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:134>
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.
