#17921: faster matching polynomial
-------------------------------------+-------------------------------------
Reporter: pernici | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.6
Component: graph theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/pernici/ticket/17921 | c87c039e54817c90a98610c3b7a48b575128acec
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Description changed by pernici:
Old description:
> Added `matching_generating_poly`, modified `matching_polynomial`, added
> an option
> to `permanental_minor_polynomial`, which for some graphs is faster than
> the previous
> algorithm.
>
> `matching_generating_poly` computes the matching generating polynomial
> on (possibly weighted) graphs; this is used in
> `permanental_minor_polynomial`.
>
> The algorithm (see [!ButPer]) uses polynomials on nilpotent elements,
> implemented in the class `Hobj` in matchpoly.pyx.
> The idea is that the matching generating polynomial can be computed from
> the product of terms
> `(1 + x w_{i j} \eta_i \eta_j)`, for all edges `(i, j)`
> where `w_{i j}` is the weight of the edge `(i, j)` and `\eta_i^2 =
> \eta_j^2=0`.
> The term `1` corresponds to the absence of the dimer `(i,j)`,
> the other term to its presence. A configuration with two adjacent dimers
> does not contribute due to nilpotency. The matching generating polynomial
> is given by the sum of the coefficients of the non-vanishing products of
> `\eta`'s.
>
> While the result does not depend on the ordering of the edges in the
> above
> product, the speed of the algorithm depends on the ordering; in fact
> doing
> the above product from left to right, one can set `\eta_i=1` as soon
> as `\eta_i` does not appear in the yet unused factors on the right,
> reducing
> in this way the number of terms.
> A greedy argument to order edges is contained in active_nodes.py
>
> This algorithm is much faster than the Godsil algorithm on large graphs.
>
> {{{
> sage: from sage.graphs.matchpoly import matching_generating_poly
> sage: g = graphs.BuckyBall()
> sage: time sum(matching_generating_poly(g).coefficients())
> Wall time: 184 ms
> 1417036634543488
> }}}
> It can be much faster than the `rook` algorithm for matching polynomials
> of bipartite graphs
>
> {{{
> sage: time
> BipartiteGraph(graphs.LadderGraph(30)).matching_polynomial()[0]
> Wall time: 65.7 ms
> 1346269
> }}}
>
> It is also much faster than the previous algorithm (now called
> `bipartite`)
> for computing the sum of the permanental minors, in the case of
> randomized band matrices
>
> {{{
> sage: from sage.matrix.matrix_misc import permanental_minor_polynomial
> sage: n, w = 20, 3
> sage: m = matrix([[i*j + 1 if abs(i-j) <= w else 0 for i in range(n)] for
> j in range(n)])
> sage: a = list(m); shuffle(a); b = zip(*a); shuffle(b); m1 = matrix(b)
> sage: time p1 = permanental_minor_polynomial(m1, algorithm='matching')
> Wall time: 174 ms
> }}}
New description:
Added `matching_generating_poly`, modified `matching_polynomial`, added an
option
to `permanental_minor_polynomial`, which for some graphs is faster than
the previous
algorithm.
`matching_generating_poly` computes the matching generating polynomial
on (possibly weighted) graphs; this is used in
`permanental_minor_polynomial`.
The algorithm (see [!ButPer]) uses polynomials on nilpotent elements,
implemented in the class `Hobj` in matchpoly.pyx.
The idea is that the matching generating polynomial can be computed from
the product of terms
`(1 + x w_{i j} \eta_i \eta_j)`, for all edges `(i, j)`
where `w_{i j}` is the weight of the edge `(i, j)` and `\eta_i^2 =
\eta_j^2=0`.
The term `1` corresponds to the absence of the dimer `(i,j)`,
the other term to its presence. A configuration with two adjacent dimers
does not contribute due to nilpotency. The matching generating polynomial
is given by the sum of the coefficients of the non-vanishing products of
`\eta`'s.
While the result does not depend on the ordering of the edges in the above
product, the speed of the algorithm depends on the ordering; in fact doing
the above product from left to right, one can set `\eta_i=1` as soon
as `\eta_i` does not appear in the yet unused factors on the right,
reducing
in this way the number of terms.
A greedy argument to order edges is contained in active_nodes.py
The Godsil algorithm is faster for small graphs, which take little time
with either algorithms; it becomes progressively slower as the number
of vertices increases; e.g. on my computer
for `graphs.KnightGraph([4, n])`, the Godsil algorithm
for `n=5` is 25% faster, for `n=6` 5x slower, for `n=9` 4000x slower.
The new algorithm can be much faster than the `rook` algorithm for
matching polynomials of bipartite graphs
{{{
sage: time BipartiteGraph(graphs.LadderGraph(30)).matching_polynomial()[0]
Wall time: 65.7 ms
1346269
}}}
It is also much faster than the previous algorithm (now called
`bipartite`)
for computing the sum of the permanental minors, in the case of randomized
band matrices
{{{
sage: from sage.matrix.matrix_misc import permanental_minor_polynomial
sage: n, w = 20, 3
sage: m = matrix([[i*j + 1 if abs(i-j) <= w else 0 for i in range(n)] for
j in range(n)])
sage: a = list(m); shuffle(a); b = zip(*a); shuffle(b); m1 = matrix(b)
sage: time p1 = permanental_minor_polynomial(m1, algorithm='matching')
Wall time: 174 ms
}}}
--
--
Ticket URL: <http://trac.sagemath.org/ticket/17921#comment:16>
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/d/optout.
