Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in DiGraph.longest_path #14412

Closed
nathanncohen mannequin opened this issue Apr 4, 2013 · 11 comments
Closed

Bug in DiGraph.longest_path #14412

nathanncohen mannequin opened this issue Apr 4, 2013 · 11 comments

Comments

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Apr 4, 2013

Reported by Nicolas Thiery :

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

CC: @nthiery

Component: graph theory

Author: Nathann Cohen

Reviewer: Nicolas M. Thiéry

Merged: sage-5.10.beta2

Issue created by migration from https://trac.sagemath.org/ticket/14412

@nathanncohen nathanncohen mannequin added this to the sage-5.10 milestone Apr 4, 2013
@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 4, 2013

comment:1

Most stupig bug ever. I fixed it without noticing what I did, and it turns out that DiGraph.incoming_edges() can be called without any argument, which has no sensible meaning at all. Turns out that the code should have been calling incoming_edges(v) but called incoming_edges() instead -_-

Needs a review !

Nathann

(I also moved a "solver" argument from one place to another, as this is the way things are done nowadays with the LP backends)

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 4, 2013

comment:3

(this patch also rewrites many lines using <= instead of min/max arguments. Easier to read.)

Nathann

@nthiery
Copy link
Contributor

nthiery commented Apr 12, 2013

comment:4

Hi Nathann,

I just went through your patch, and it looks good. Thanks!

So positive review assuming all tests pass. I am going to kick to bot.

@fchapoton
Copy link
Contributor

comment:5

This breaks the function "a_long_simple_root", see bot report

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 30, 2013

comment:6

This breaks the function "a_long_simple_root", see bot report

That's crazy O_o

Nathann

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 30, 2013

Attachment: trac_14412.patch.gz

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 30, 2013

comment:7

Fixed ! I also had the pleasure to read things like that in root_lattice_realizations.py...

Caveat: this may be break in affine type `A_{2n}^{(2)}`
Caveat: meaningful/broken for non irreducible?
.. TODO:: This implementation is only valid in the root or weight lattice 

It's a long way.... >_<

Nathann

@nthiery
Copy link
Contributor

nthiery commented Apr 30, 2013

comment:8

Replying to @nathanncohen:

Fixed !

Thanks! I checked it, and it's good.

I also had the pleasure to read things like that in root_lattice_realizations.py...

Caveat: this may be break in affine type `A_{2n}^{(2)}`
Caveat: meaningful/broken for non irreducible?
.. TODO:: This implementation is only valid in the root or weight lattice 

It's a long way.... >_<

Yes, the limitations of the algorithms are precisely documented. This in particular to prompt creative people to find better algorithms that will work in a more general setting (it's non trivial).

Amitiés.

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Apr 30, 2013

comment:10

Yoooooooooooo !

Yes, the limitations of the algorithms are precisely documented. This in particular to prompt creative people to find better algorithms that will work in a more general setting (it's non trivial).

(with birds singing in the background) it is indeed a delight to see this small piece of software grow everyday, becoming more powerful and accurate. Wouldn't it be nice though if those cases raised an exception ? Some forgetful users may not read the documentation. Some functions that use this one may not contain the warning in their docstring. Our innocent users may be led to believe that this method and those that may depend on it always returns correct results even though its docstring states the opposite.

And (without birds singing in the background) : it's not "other people's job" to add these tests in a code they did not write.

Nicolas. C'est dangereux ces trucs, tu sais bien... C'est des choses qu'on fait dans son code perso, pas dans du code qu'on partage.

Nathann

@jdemeyer
Copy link

jdemeyer commented May 1, 2013

Reviewer: Nicolas M. Thiéry

@jdemeyer
Copy link

jdemeyer commented May 7, 2013

Merged: sage-5.10.beta2

@jdemeyer jdemeyer closed this as completed May 7, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants