On Nov 13, 4:53 pm, Nathann Cohen <nathann.co...@gmail.com> wrote: > Helloooooooooooooo Emil ! > > Well, it looks like I am to blame for most of these errors :-/
Hi Nathan, thanks for quick response! I am not sure if those are errors, but when I, as a non export, try to build sage then I take failing doctests seriously. But to go into the details with each failing test takes time and is tedious, so I think it is better to avoid possible problems (like those with the multible solutions) whenever possible. > The first one is about a matching in Petersen's Graph. Then the error in > the gale_ryser theorem function. Both codes are calling GLPK (I assume that > you have not installed the CBC package ? Or CPLEX ?), and it seems its > results depend on the architecture (though I believe they are not random, > so they should always return the same on your architecture). I know GLPK (Gnu Linear Programming Kit) but I am, yet, totally ignorant of the other two packages. And yes, results are not random. The Functions give always the same solution on my machine > > Why choose doctests with multiple possible solutions? > > > > Well. It's not that I was exactly looking for examples which had several > solutions, but then the doctests are also made to lead the user to > understand how the commands are to be used and what they do, and there's no > point in building a very complicated graph while losing the reader only > because of our technical problems. These days, I am really keen on adding > many EXAMPLES whith the flag "not tested", and a TEST section afterwards > ensuring that the methods work with symmetry-free doctests. > I mean... Doctests are nice, and the way they are checked create technical > problems, but the solution is not to change the documentation (meant for > users) so that it solves our technical problems. Doctests are a tool, not a > master :-p > So the best is probably to comment these tests out (this is a thematic > tutorial anyway, and those methods are tested extensively elsewhere) and > add correction tests somewhere else. I fully agree - is it okay if I create a "track ticket" for this? I haven't done this before but I think I'll manage. > You said that you got an error on : > > sage: all( random_acyclic(100, .2).is_directed_acyclic() # long time > ... for i in range(50)) # long time > > Could you say what happened ? It is also wrong that feedback_edge_set would > return nothing, though this function intensively calls the > "is_directed_acyclic" method, so this is probably the same problem. I will look into this error again try to give more details > ... and I am totally ignorant about the other bugs you found :-) Well, I think the error with sage -t -force_lib "devel/sage/sage/structure/sage_object.pyx" is based on testing as root. So there could be a check if this test is run as root, however I have no idea how this would be implemented. Or one could give a warning in the beginning of all tests. Or on could ignore this case entirely and say people who run as root have to live with such minor inconveniences (Don't miss the hilarious http://www.garyshood.com/root/!) My issue with sandpile.py is closely related to the issues with gyle & ryler. I think there is lot's of double testing of the same functionality. If I got it right a possible solution would be to include some TEST sections which doctest the functionality once (S.betti ...), then the bunch of the other examples would be ignored? I am aware that those are minor issues, but if building sage on a stock PC they might cause some confusion and extra detective work. Does this qualify to file a bug or open an issue on trac? sincerly emil -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
