Closed GMS103 closed 1 year ago
Where's your nauty
coming from? (See config.log
)
Related (maybe dup): #34133
It is coming from Homebrew, as indicated in https://doc.sagemath.org/html/en/installation/source.html
macOS package installation If you use the Homebrew package manager, you can install the following:
brew install arb bdw-gc boost bzip2 cddlib cmake curl ecl flint fplll freetype gcc gd gengetopt gfortran glpk gmp gpatch gsl libatomic_ops libffi libiconv libmpc libpng meson mpfi mpfr nauty ncurses ninja ntl openblas openssl pari pari-elldata pari-galdata pari-galpol pari-seadata pcre pkg-config ppl primecount primesieve python3 qhull readline singular sqlite suite-sparse tox xz zeromq zlib
and Homebrew is up to date. Namely:
% brew info nauty […] ==> nauty: stable 2.8.6 (bottled) Automorphism groups of graphs and digraphs https://pallini.di.uniroma1.it/ /opt/homebrew/Cellar/nauty/2.8.6 (79 files, 9.1MB) * Poured from bottle using the formulae.brew.sh API on 2023-02-18 at 16:54:53 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/nauty.rb License: Apache-2.0 ==> Analytics install: 116 (30 days), 319 (90 days), 1,280 (365 days) install-on-request: 57 (30 days), 133 (90 days), 620 (365 days) build-error: 0 (30 days)
I attach one
config.log
. config.log Perhaps I should add that this is on Apple Silicon Macs ("M" series).
FWIW, after ./configure --without-system-nauty
one has that make ptestlong
succeeds.
The issues with nauty_gentreeg
are bugs introduced in version 2.8.6 that have already been reported upstream (https://mailman.anu.edu.au/pipermail/nauty/2023-January.txt).
With nauty 2.7.r1 (current version for Sagemath)
MAC-04017247:nauty27r1 dcoudert$ ./gentreeg 1
>A ./gentreeg Z=0:0 D=0 n=1
:@
>Z 1 trees generated in 0.00 sec
MAC-04017247:nauty27r1 dcoudert$ ./gentreeg 2
>A ./gentreeg Z=1:1 D=1 n=2
:An
>Z 1 trees generated in 0.00 sec
MAC-04017247:nauty27r1 dcoudert$ ./gentreeg 3
>A ./gentreeg Z=2:2 D=2 n=3
:Bc
>Z 1 trees generated in 0.00 sec
With nauty 2.8.6
MAC-04017247:nauty2_8_6 dcoudert$ ./gentreeg 1
>A ./gentreeg Z=0:0 D=0 n=0
:@
>Z 1 trees generated in 0.00 sec
MAC-04017247:nauty2_8_6 dcoudert$ ./gentreeg 2
>A ./gentreeg Z=0:0 D=0 n=0
>Z 0 trees generated in 0.00 sec
MAC-04017247:nauty2_8_6 dcoudert$ ./gentreeg 3
>A ./gentreeg Z=0:0 D=0 n=0
:Bc
>Z 1 trees generated in 0.00 sec
The issues with geng
are due to the introduction of new parameters in version 2.8.6, as documented in https://pallini.di.uniroma1.it/changes24-28.txt. We will have to update the doctests when we will upgrade to a newer version:
- geng got sigificantly faster for connected graphs with a
small number of edges. However, if you want trees the program
gentreeg is still much faster. There are also new options:
-k generate graphs without K4
-T generate chordal graphs
-S generate split graphs
-P generate perfect graphs
-F generate claw-free graphs
All the options can be used in combination unless the program
complains.
So we have to wait for the release of a corrected version of nauty. Meanwhile, we may restrict versions to 2.7.r1.
Has this been reported to Homebrew? They probably don't know that they ship a buggy version. (Brendan McKay sent me a patch for 2.8.6 some time ago)
No.
I reported this for about 5 Sagemath beta (last time here) on Debian testing and Debian's nauty, which is 2.8.6
.
As also discussed in #34133, a temporary solution is to restrict nauty to version 2.7.r1. Unfortunately, I don't know how to modify the build scripts to do that.
fortunately, Gentoo has patched 2.8.6 - their package is sci-mathematics/nauty-2.8.6-r1
. However, pkg-config still reports 2.8.6 (well, not sure whether this is a Gentoo bug, or nauty bug, or neither)
The best would be to test the output of gentreeg 2
for correctness. Somehow, it goes (mostly) to stderr
, so one needs |&
, not just |
in the pipe.
$ gentreeg 2 |& grep "Z 1 trees"
>Z 1 trees generated in 0.00 sec
(there will be no output in the buggy case)
No.
well, dear macOS users, please pay you open source dues and report bugs ;-)
Done here (but I am not sure it is the good place):
https://github.com/Homebrew/homebrew-core/issues/125101
Guillermo
On Wed, 8 Mar 2023 at 00:59, Dima Pasechnik @.***> wrote:
Has this been reported to Homebrew? They probably don't know that they ship a buggy version. (Brendan McKay sent me a patch for 2.8.6 some time ago)
Fixed in Homebrew: https://github.com/Homebrew/homebrew-core/pull/125117
I still get some failing tests. The patched nauty from Homebrew is version 2.8.6_1. It gives
% gentreeg 2
>A gentreeg Z=0:0 D=0 n=0
:An
>Z 1 trees generated in 0.00 sec
% gentreeg 3
>A gentreeg Z=0:0 D=0 n=0
:Bc
>Z 1 trees generated in 0.00 sec
% gentreeg 4
>A gentreeg Z=0:0 D=0 n=0
:Cdf
:Ccf
>Z 2 trees generated in 0.00 sec
%
which does not seem correct to me.
Huh? On 2 vertices - 1 tree: o---o ($A_2$ diagram). As well as on 2: o---o---o - $A_3$-diagram. There are 2 non-isomorphic trees on 4 vertices: 3-path, i.e. $A_4$-diagram, and a claw with 3 fingers, i.e. $D_4$ diagram. What's wrong here?
Sorry, Dima, this is what I mean (from make ptestlong
).
**********************************************************************
File "src/sage/graphs/generators/families.py", line 3662, in sage.graphs.generators.families.nauty_gentreeg
Failed example:
print(next(gen))
Expected:
>A ...gentreeg Z=2:3 D=3 n=4
Got:
>A /opt/homebrew/bin/gentreeg Z=0:0 D=0 n=0
<BLANKLINE>
**********************************************************************
File "src/sage/graphs/generators/families.py", line 3689, in sage.graphs.generators.families.nauty_gentreeg
Failed example:
list(graphs.nauty_gentreeg("3", debug=True))
Expected:
['>A ...gentreeg Z=2:2 D=2 n=3\n', Graph on 3 vertices]
Got:
['>A /opt/homebrew/bin/gentreeg Z=0:0 D=0 n=0\n', Graph on 3 vertices]
**********************************************************************
OK, more things to replace with ...
(they changed the meaning of parameter Z=
)
For other people arriving here, I quote Dima:
Actually, one can patch 2.8.6, as reported by upstream: https://mailman.anu.edu.au/pipermail/nauty/2023-January.txt
Sorry, my PR arrives too late (I did not see Gonzalo's).
I marked PR #35327 as duplicate, but I don't know if it is enough.
Can this be closed?
I think so. Should/Could I do it?
Is there an existing issue for this?
Did you read the documentation and troubleshoot guide?
Environment
Steps To Reproduce
Running
make ptestlong
givesas follows (the last 3 seem cosmetic, but not the first).
Expected Behavior
All tests passed!
Actual Behavior
and
Additional Information
No response