unambiguously doctest longest_path()

[charpent]

A doctest or longest_path() is ambiguous :

sage: l = [(0, 1), (0, 3), (2, 0)]
sage: G = DiGraph(l)
sage: G.longest_path().edges()
[(0, 3, None), (2, 0, None)]

Starting with sage 6.5beta1, sage gives the equally valid answer

[(0, 1, None), (2, 0, None)]

but this is detected as a failure by sage ptestlong.

So let's use a problem with a unique solution.

[charpent]

Passes "make ptestlong"

---

New commits:

​c39b680

Trac #17410: unambiguously doctest longest_path()

[vdelecroix]

Hello,

Are you sure that it is unique ? Why the output can not be the same path in the other direction

[(3, 4, None), (2, 0, None), (0, 3, None)]

EDIT: it is not even sure that the list of edges is output in any sorted way, is it ?

You can at least test the length, or the vertices/edges as a set.

Vincent

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​fcc15b4

Trac #17410: unambiguously doctest longest_path()

[charpent]

Damn. You're right. The path is unique (G is directed). But edges() has no special reason to sort them in any specified way. So the new version tests only set equality.

This passes "make ptestlong".

And you're co-author.

[vdelecroix]

Hi Emmanuel,

I changed my status from author to reviewer. That's more reasonable.

why bool(something) instead of something like in

sage: p = G.longest_path()
sage: set(p.edges(labels=False)) == {(0,3), (2,0), (3,4)}
True

(and by the way, the option labels=False of the method .edges is really cool)

Sorry for being so picky.

Vincent

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​52c5c08

Trac #17410: unambiguously doctest longest_path()

[charpent]

New commit, up to reviewer's cosmetic wishes.

Passes "make ptestlong".

[vdelecroix]

Wonderful ;-) Thanks.

Vincent