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
Failing doctest in poset_examples #26586
Comments
comment:1
It seems that adding sorted() to the doctest does not sort, hence does not fix the issue
|
comment:2
A difference also happens with respect to
Moreover, removing the only
|
comment:3
Finally, when running the offending test on its own in a session, there is no mismatch:
Adding
just before the test in line 1400 "fixes" it. |
comment:4
Here is a minimal example for my computer. Could you please check whether this yields a failure when run without
|
comment:5
Apparently it has nothing to do with the doctest framework, i.e., your example can be easily reproduced in an interactive session:
then restart Sage, then
Very likely some kind of caching is causing the inconsistency, but I am not familiar with the code and therefore have no clue where that cache can be found. What I find odd: Even when sorting the output, the two results are different. Is sorting not properly implemented for |
comment:6
But shouldn't doctests in each function start with a fresh environment? |
comment:7
Replying to @mantepse:
No. I could be mistaken, but when I write doctests, I always assume:
|
comment:8
Its in the nature of posets that there is usually no canonical total order, so trying to make the output canonical is probably not going to happen in all cases. Without looking at the code I'm guessing that you are somewhere iterating over an associative container, which ends up being random because the elements can't be ordered. You probably want to rewrite the test as X == Y instead of looking at the output |
comment:9
The output is a python list of python lists of elements. So, testing equality won't work. But perhaps one can turn the lists into sets and compare them? |
comment:10
We could do
if we do not want to have sorting for cartesian products. |
comment:11
Is it easier to just say |
comment:12
Wouldn't it be better to have cartesian product export sorting? (lexicographic) |
comment:13
Besides, shouldn't upper and lower covers be tuples, not lists? |
comment:14
Unless something happens real soon this will not be fixed in Sage 8.5 |
Branch: u/chapoton/26586 |
Commit: |
Author: Frédéric Chapoton |
comment:15
ok, here it is New commits:
|
comment:16
Why not use a plain |
comment:17
Because this does not work. See comment:1 |
Reviewer: Volker Braun |
comment:19
I understand that you want to get rid of this blocker, but this is not a right fix. |
Changed branch from u/chapoton/26586 to u/jdemeyer/26586 |
Changed author from Frédéric Chapoton to Frédéric Chapoton, Jeroen Demeyer |
comment:21
Don't hide bugs, at least mark it as New commits:
|
Changed author from Frédéric Chapoton, Jeroen Demeyer to Jeroen Demeyer |
Changed reviewer from Volker Braun to Volker Braun, Frédéric Chapoton |
comment:23
right. ok for me |
Changed branch from u/jdemeyer/26586 to |
With
--gc=never
, this doctest fails consistently:Component: combinatorics
Author: Jeroen Demeyer
Branch/Commit:
dc77918
Reviewer: Volker Braun, Frédéric Chapoton
Issue created by migration from https://trac.sagemath.org/ticket/26586
The text was updated successfully, but these errors were encountered: