enable single-argument gcd/lcm
fix conversion PARI -> rational function field in several variables
add doctests to PARI gcd and lcm
Trac 5153: Filter out the 2-torsion from the points returned by Simon's 2-descent.
Merge branch 'u/wuthrich/ticket/13593' of git://trac.sagemath.org/sage into ticket/5153

* 'u/wuthrich/ticket/13593' of git://trac.sagemath.org/sage:
  Trac 13593: Do not put torsion points into gens.
  Trac #13593: ranks of elliptic curves over number fields
Trac 5153: Furhter modifications to the documentation
Merge branch 'u/wuthrich/ticket/13593' of git://trac.sagemath.org/sage into ticket/5153

* 'u/wuthrich/ticket/13593' of git://trac.sagemath.org/sage:
  spelling error
PARI gcd/lcm documentation fix
Trac #5153: small change in documentation.
Implemented IntegerVectors_nk.rank(). Fixes #15609
trac #15619: Pickling of immutable graphs
test for membership with `x in self`; minor doc formatting change

In reply to @ncohen's review of #15609.
trac #15619: bug in the former definition; exception to avoid it in the future
Implement splitting fields for number fields
Make q monic before computing cubic resolvent
Add comments, small cosmetic changes
No need to specify caller_name in verbose()
Trac 15619: Review commit
trac #15619: Pickling multigraphs with loops and labels
Trac #15278: Hash and equality for graphs

At #14806, an immutable graph backend has been introduced. However, the
resulting graphs are not known to be immutable.
{{{
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, when the immutable graph backend is used, then the `._immutable`
attribute should be set to True.

But hang on: Does using the immutable graph backend really result in
immutable graphs? I.e., would it really be impossible to change the
`==`- and `cmp`-classes of a graph by "official" methods such as
"`add_vertex()`"? And is the current equality testing really what we
want to test?

Currently, `__eq__()` starts like this:
{{{
        # inputs must be (di)graphs:
        if not isinstance(other, GenericGraph):
            raise TypeError("cannot compare graph to non-graph
(%s)"%str(other))
        from sage.graphs.all import Graph
        g1_is_graph = isinstance(self, Graph) # otherwise, DiGraph
        g2_is_graph = isinstance(other, Graph) # otherwise, DiGraph

        if (g1_is_graph != g2_is_graph):
            return False
        if self.allows_multiple_edges() !=
other.allows_multiple_edges():
            return False
        if self.allows_loops() != other.allows_loops():
            return False
        if self.order() != other.order():
            return False
        if self.size() != other.size():
            return False
        if any(x not in other for x in self):
            return False
        if self._weighted != other._weighted:
            return False
}}}

1. Is it really a good idea to raise an error when testing equality of a
graph with a non-graph? Most likely not!
2. For sure, a graph that ''has'' multiple edges can not be equal to a
graph that does not have multiple edges. But should it really matter
whether a graph ''allows'' multiple edges when it actually doesn't
''have'' multiple edges?
3. Similarly for `.allows_loops()`.
4. Should `._weighted` be totally removed? Note the following comment in
the documentation of the `.weighted()` method: "edge weightings can
still exist for (di)graphs `G` where `G.weighted()` is `False`". Ouch.

Note the following annoying example from the docs of `.weighted()`:
{{{
            sage: G = Graph({0:{1:'a'}}, sparse=True)
            sage: H = Graph({0:{1:'b'}}, sparse=True)
            sage: G == H
            True

        Now one is weighted and the other is not, and thus the graphs
are
        not equal::

            sage: G.weighted(True)
            sage: H.weighted()
            False
            sage: G == H
            False
}}}
So, calling the method `weighted` with an argument changes the
`==`-class, even though I guess most mathematicians would agree that `G`
has not changed at all. And this would actually be the case even if `G`
was using the immutable graph backend!!!

The aim of this ticket is to sort these things out. To the very least,
graphs using the immutable graph backend should not be allowed to change
their `==`-class by calling `G.weighted(True)`.

URL: http://trac.sagemath.org/15278
Reported by: SimonKing
Ticket author(s): Simon King
Reviewer(s): Nathann Cohen