On Monday, 9 July 2012 10:22:31 UTC+8, Birk Eisermann wrote:
>
> Hello!!
>
> What is your opinion about improving the export and import of graphs?
>
> My conclusion of the sage-devel thread "Code duplication and aliases in
> methods" is that at the moment the source code in graph theory is not
Hello!!
What is your opinion about improving the export and import of graphs?
My conclusion of the sage-devel thread "Code duplication and aliases in
methods" is that at the moment the source code in graph theory is not so
optimal organized. As promised, I want to show some modifications that
Hi Jason,
Good point! Networkx comes quite close. I agree with the distinction
between graphs and algorithms as in networkx. Graphs objects just for
storage of the graph data.
But for algorithms, I have different picture which is closer to how it
is in sage... e.g. no segmentation (hence als
There is a patch at http://trac.sagemath.org/sage_trac/ticket/7160
which uses the embedding for the comparison, but there are two doctest
failures still.
--Mike
On Sun, Jul 8, 2012 at 8:54 AM, vdelecroix <20100.delecr...@gmail.com> wrote:
> Hi,
>
> Once I initialize a number field with a real emb
Hi,
Once I initialize a number field with a real embedding, I would like
(as a user) that the order defined on the number field (ie the answers
of comparisons) is the one induced from RR. This is not the case right
now. I started to implement the thing for quadratic number field, and
it works well
Hi, the following seems suspicious to me:
sage: M = matrix(2,[1,3,2,0])
sage: G = DiGraph(M, loops=True, multiedges=True)
sage: H = DiGraph(M.transpose(), loops=True, multiedges=True)
sage: G.is_isomorphic(H)
True
Strangely enough, this works fine:
sage: M = matrix(2,[1,3,1,0])
sage: G = DiGraph
