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

Test failure on 32-bit systems #407

Open
d-torrance opened this issue Feb 10, 2023 · 16 comments
Open

Test failure on 32-bit systems #407

d-torrance opened this issue Feb 10, 2023 · 16 comments

Comments

@d-torrance
Copy link
Contributor

I'm working on a Normaliz 3.10 package to upload to Debian, but a test is failing in the 32-bit build. From https://salsa.debian.org/math-team/normaliz/-/jobs/3918755/raw:

cp test-grb/polytope.grb test-grb/polytope.grb.out
17c17
< 4 5 1 6 -1 9 -1 10 1 
---
> 4 5 -1 6 1 9 1 10 -1 
19,20c19,20
< 4 6 -1 9 1 10 1 11 -1 
< 4 5 1 6 -1 11 -1 12 1 
---
> 4 5 -1 6 1 11 1 12 -1 
> 4 5 -1 9 1 10 1 12 -1 
23a24
> 5 5 -1 6 1 10 1 17 1 19 -1 
28d28
< 5 5 1 6 -1 10 -1 17 -1 19 1 
32c32
< 5 6 1 11 1 15 -1 18 1 19 -1 
---
> 5 5 1 12 1 15 -1 18 1 19 -1 
34c34
< 3 4 -1 5 2 6 -1 
---
> 3 4 1 5 -2 6 1 
54c54
< 3 7 -1 11 2 13 -1 
---
> 3 7 1 11 -2 13 1 
57c57
< 4 3 -1 4 1 5 1 6 -1 
---
> 4 3 1 4 -1 5 -1 6 1 
59d58
< 4 3 1 5 -1 8 -1 10 1 
60a60
> 4 3 1 5 -1 8 -1 10 1 
62a63
> 4 4 1 8 -1 9 -1 11 1 
66d66
< 4 4 1 8 -1 9 -1 11 1 
69a70
> 4 7 1 11 -1 14 -1 17 1 
72,73c73
< 5 3 1 6 -1 11 -1 15 -1 19 1 
< 4 7 -1 11 1 14 1 17 -1 
---
> 5 3 1 5 -1 12 -1 15 -1 19 1 
93d92
< 4 1 1 2 -1 9 -1 10 1 
94a94
> 4 1 1 2 -1 9 -1 10 1 
make[4]: *** [/builds/math-team/normaliz/debian/output/source_dir/_build/../test/Makefile.classic:153: test-mrk/polytope.mrk.diff] Error 1
@w-bruns
Copy link
Contributor

w-bruns commented Feb 13, 2023

I have compared the 64 bit result to the result of Singular for the same task. They are identical. The 32 bit result for 32 bit is incorrect. Most likely a long vs. long long problem.

I will try to compile a 32 bit version and to find the problem.

@w-bruns
Copy link
Contributor

w-bruns commented Feb 14, 2023

My 32 bit build does not show the difference you have found. However, it produces other differences. The reason is that certain computations use LLL for improving lattice bases, and LLL depends on floating point.

Version 3.10.1 will solve this problem by disabling LLL in the tests. We must then see whether the test that failed the Debian 32 bit build will behave better then.

@d-torrance
Copy link
Contributor Author

I went ahead and uploaded 3.10.0 to Debian experimental, and tests are failing on several other architectures as well. Could these also be LLL-related?

arm64

full log

cp test-cst/A443.cst test-cst/A443.cst.out
82,83c82,83
< 1 0 0 1 -1 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 0 0 -1 1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 
---
> -1 0 0 -1 1 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0 
> 1 0 0 1 -1 0 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 
86c86
< 1 0 0 1 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 
---
> -1 0 0 -1 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 0 
90c90
< 0 0 -2 0 -1 1 1 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -1 0 -2 -1 0 1 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 
95c95
< -1 -1 -2 -1 0 1 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
---
.
.
.
---
> -10 0 0 -7 0 0 0 0 0 0 0 1 0 1 0 
> -9 0 -1 -7 0 0 0 0 0 0 0 0 0 2 0 
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:154: test-mrk/PowerSum-80.mrk.diff] Error 1

ppc64el

full log

cp test-Aut/A443.aut test-Aut/A443.aut.out
82,83c82,83
< 1 0 0 1 -1 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 0 0 -1 1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 
---
> -1 0 0 -1 1 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0 
> 1 0 0 1 -1 0 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 
86c86
< 1 0 0 1 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 
---
> -1 0 0 -1 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 0 
90c90
< 0 0 -2 0 -1 1 1 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -1 0 -2 -1 0 1 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 
95c95
< -1 -1 -2 -1 0 1 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
---
.
.
.
---
> -5 -2 0 -5 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 2 0
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:154: test-mrk/Kwak10.mrk.diff] Error 1
make[4]: *** Waiting for unfinished jobs....
20d19
< 1 0 0 0 0 -1 0 -1 0 0 1 0 0 0 0 
22,23c21,23
< 0 0 0 0 0 0 0 0 0 0 0 0 -1 1 0 
< 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 1 
---
.
.
.
---
> -10 0 0 -7 0 0 0 0 0 0 0 1 0 1 0 
> -9 0 -1 -7 0 0 0 0 0 0 0 0 0 2 0 
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:154: test-mrk/Kwak10-mrk.mrk.diff] Error 1
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:154: test-mrk/PowerSum-80.mrk.diff] Error 1

s390x

full log

cp test-cst/A443.cst test-cst/A443.cst.out
82,83c82,83
< 1 0 0 1 -1 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 0 0 -1 1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 
---
> -1 0 0 -1 1 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0
> 1 0 0 1 -1 0 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0
86c86
< 1 0 0 1 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 
---
> -1 0 0 -1 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 0
90c90
< 0 0 -2 0 -1 1 1 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -1 0 -2 -1 0 1 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 0
95c95
< -1 -1 -2 -1 0 1 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
---
.
.
.
--
---
> -5 -2 0 -5 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 2 0 
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:153: test-mrk/Kwak10.mrk.diff] Error 1

Less important because they're not officially supported Debian architectures, but there were also build failures in:

@w-bruns
Copy link
Contributor

w-bruns commented Feb 16, 2023

For completeness I insert my answer to the last issue here.

Quick reply: yes. The result of the computations in test-mrk are not uniquely determined, and depends on LLLL. In my 32 bit (on a 64 bit system) build I also get "failures" for some of them.

I am thinking about either avoiding LLL or to find a floating point type that is independent of the architecture.

The problem you found in test-grb worries me more since the output is uniquely determined up to the order of the rows of the critical matrix. I could not reproduce this problem. I have no access to a true Linux 32 bit system. Could you provide one?

@w-bruns
Copy link
Contributor

w-bruns commented Feb 27, 2023

Correction: the first error you found is also an mrk test failure. Fortunately no problem in grb! I was mislead by the first line.

To take care of the mrk ambiguity, 3.7.1 will use the existing NoLLL option in the mrk tests. Then everything should go smoothly.

@d-torrance
Copy link
Contributor Author

I'm still getting the follow test errors on the 32-bit i386 architecture after the recent 3.10.1 release. Might these also be related to LLL, or is it something else?

1c1
< 0 lattice points in polytope (Hilbert basis elements of degree 1)
---
> 16 lattice points in polytope (Hilbert basis elements of degree 1)
18c18,34
< 0 lattice points in polytope (Hilbert basis elements of degree 1):
---
> 16 lattice points in polytope (Hilbert basis elements of degree 1):
>  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 11
>  0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 66
>  0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 30
>  0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 47
>  0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 44
>  0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1 15
>  0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 1 75
>  0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 1 42
>  0 0 0 0 0 0 1 0 0 1 1 0 0 0 0 0 1 35
>  0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 76
>  0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 1 89
>  0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0 1 98
>  1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 1 74
>  1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 24
>  1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 89
>  1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 29
make[4]: *** [/builds/math-team/normaliz/debian/output/source_dir/_build/../test/Makefile.classic:157: test-/lowrankPF.diff] Error 1
1c1
< 0 lattice points in polytope (Hilbert basis elements of degree 1)
---
> 20 lattice points in polytope (Hilbert basis elements of degree 1)
21c21,41
< 0 lattice points in polytope (Hilbert basis elements of degree 1):
---
> 20 lattice points in polytope (Hilbert basis elements of degree 1):
>  0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 0
>  0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0
>  0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 1 0
>  0 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0
>  0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 1 0 0 0
>  0 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1
>  0 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0
>  0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0
>  0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0
>  0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 1
>  0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0
>  0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 1
>  0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0
>  0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1
>  0 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0
>  0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0
>  1 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 1 0 0
>  1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0
>  1 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0
>  1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:157: test-Special/5x5PF.diff] Error 1
17c17
< 4 5 1 6 -1 9 -1 10 1 
---
> 4 5 -1 6 1 9 1 10 -1 
19,20c19,20
< 4 6 -1 9 1 10 1 11 -1 
< 4 5 1 6 -1 11 -1 12 1 
---
> 4 5 -1 6 1 11 1 12 -1 
> 4 5 -1 9 1 10 1 12 -1 
23a24
> 5 5 -1 6 1 10 1 17 1 19 -1 
28d28
< 5 5 1 6 -1 10 -1 17 -1 19 1 
32c32
< 5 6 1 11 1 15 -1 18 1 19 -1 
---
> 5 5 1 12 1 15 -1 18 1 19 -1 
34c34
< 3 4 -1 5 2 6 -1 
---
> 3 4 1 5 -2 6 1 
54c54
< 3 7 -1 11 2 13 -1 
---
> 3 7 1 11 -2 13 1 
57c57
< 4 3 -1 4 1 5 1 6 -1 
---
> 4 3 1 4 -1 5 -1 6 1 
59d58
< 4 3 1 5 -1 8 -1 10 1 
60a60
> 4 3 1 5 -1 8 -1 10 1 
62a63
> 4 4 1 8 -1 9 -1 11 1 
66d66
< 4 4 1 8 -1 9 -1 11 1 
69a70
> 4 7 1 11 -1 14 -1 17 1 
72,73c73
< 5 3 1 6 -1 11 -1 15 -1 19 1 
< 4 7 -1 11 1 14 1 17 -1 
---
> 5 3 1 5 -1 12 -1 15 -1 19 1 
93d92
< 4 1 1 2 -1 9 -1 10 1 
94a94
> 4 1 1 2 -1 9 -1 10 1 
make[4]: *** [/<<PKGBUILDDIR>>/_build/../test/Makefile.classic:158: test-mrk/polytope.mrk.diff] Error 1

@w-bruns
Copy link
Contributor

w-bruns commented Jun 30, 2023

Looks like floating point problems. I am on a trip. Will take care next week.

@d-torrance
Copy link
Contributor Author

Thank you!

There were several other test failures on some 64-bit architectures after I uploaded the 3.10.1 package to Debian:

arm64, ppc64el, and s390x

82,83c82,83
< 1 0 0 1 -1 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 0 0 -1 1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 
---
> -1 0 0 -1 1 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0 
> 1 0 0 1 -1 0 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 
86c86
< 1 0 0 1 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 
---
> -1 0 0 -1 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 0 

...

207c207
< -4 -2 0 -4 -1 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 2 0 
---
> -5 -2 0 -5 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 2 0 
make[4]: *** [/home/dtorrance/normaliz-3.10.1+ds/_build/../test/Makefile.classic:153: test-mrk/Kwak10-mrk.mrk.diff] Error 1

s390x only (big-endian)

1c1
< 0 lattice points in polytope (module generators)
---
> 1067 lattice points in polytope (module generators)
12c12
< module rank = 0
---
> module rank = 1067
1c1
< 0 lattice points in polytope (module generators)
---
> 1067 lattice points in polytope (module generators)
13c13
< module rank = 0
---
> module rank = 1067
17c17,1084
< 0 lattice points in polytope (module generators):
---
> 1067 lattice points in polytope (module generators):
>  -4  0  0  0  0  0  0  0 1
>  -3  0  0  0 -1  0  0  0 1
>  -3  0  0  0  0  0  0  0 1
>  -3  0  0  0  1  0  0  0 1
>  -2 -1  0  0  0  0 -1  1 1
>  -2 -1  0  0  0  0  0  0 1
>  -2 -1  0  0  0  0  1 -1 1
>  -2 -1  1  0  0  0  0  0 1

...

>   2  1  0  0  0  0 -1  1 1
>   2  1  0  0  0  0  0  0 1
>   2  1  0  0  0  0  1 -1 1
>   3  0  0  0 -1  0  0  0 1
>   3  0  0  0  0  0  0  0 1
>   3  0  0  0  1  0  0  0 1
>   4  0  0  0  0  0  0  0 1
make[4]: *** [/home/dtorrance/normaliz-3.10.1+ds/_build/../test/Makefile.classic:157: test-/ChF_8_1024Nr.diff] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [/home/dtorrance/normaliz-3.10.1+ds/_build/../test/Makefile.classic:157: test-/ChF_8_1024.diff] Error 1
1c1
< 0 lattice points in polytope (module generators)
---
> 3654 lattice points in polytope (module generators)
16c16
< module rank = 0
---
> module rank = 3654
20c20,3674
< 0 lattice points in polytope (module generators):
---
> 3654 lattice points in polytope (module generators):
>        0     0 1
>      241     5 1
>      482    10 1
>      723    15 1
>     2603    54 1
>     2844    59 1
>     3085    64 1
>     3326    69 1
>     3567    74 1
>     3808    79 1
>     5688   118 1
>     5929   123 1
>     6170   128 1
>     6411   133 1
>     6652   138 1

...

>  1785778 37047 1
>  1786019 37052 1
>  1786260 37057 1
>  1786501 37062 1
>  1786742 37067 1
>  1788622 37106 1
>  1788863 37111 1
>  1789104 37116 1
>  1789345 37121 1
make[4]: *** [/home/dtorrance/normaliz-3.10.1+ds/_build/../test/Makefile.classic:156: test-/ThierryPF.diff] Error 1
>  10  1  6  5  1 1
>  10  1  6  6  0 1
>  10  1  7  5  0 1
>  11  0  3  5  3 1
>  11  0  3  5  4 1
>  11  0  3  6  3 1
>  11  0  4  5  2 1
>  11  0  4  5  3 1
>  11  0  4  6  2 1
>  11  0  5  5  1 1
>  11  0  5  5  2 1
>  11  0  5  6  1 1
>  11  0  6  5  0 1
>  11  0  6  5  1 1
>  11  0  6  6  0 1
>  11  0  7  5  0 1
make[4]: *** [/home/dtorrance/normaliz-3.10.1+ds/_build/../test/Makefile.classic:156: test-/smallPF.diff] Error 1

@w-bruns
Copy link
Contributor

w-bruns commented Jul 3, 2023

I have looked at all tests mentioned in the last comment. All involve floating point arithmetic in two ways that can also come together:

  1. The option ProjectionFloat uses it directly for a computation goal, namely the computation of lattice points. There is no guarantee that it gives the correct result, but in all tests on Intel 64 architecture /Linus, MacOS, MS Windows) it yields the same result s as integer arithmetic.
  2. Some algorithms use LLL for finding a good system of coordinates, notably project-and-lift for lattice points (in integer or floating point arithmetic) and project-and-lift for Markov bases. The latter are not uniquely determined,and this makes tests of type "doctest" dufficult.

I have added NoLLL to the tests that fail on 64 bit architectures. Pleas btry again with the current master.

I guess that the two ProjectionFloat tests on i386 that failed have done so because of the principal problems of floating point. I think that the Markov basis for polytope.in is correct, even if it is not the same as in the refernce file.

@d-torrance
Copy link
Contributor Author

d-torrance commented Jul 12, 2023

I was able to try running the tests on the various failing architectures using master branch. The ppc64el and arm64 tests are now passing! I'm still getting a few of the same errors on various architectures, though:

32-bit:

  • i386: test-mrk/polytope.mrk.diff
  • armhf: test-/lowrankPF.diff

big-endian:

  • s390x: test-/ChF_8_1024.diff, test-/ChF_8_1024Nr.diff, test-/ThierryPF.diff, test-/smallPF.diff

@w-bruns
Copy link
Contributor

w-bruns commented Sep 12, 2023

I think I have now found the bug that causes the i386 problems. It is kind of a miracle that it has never surfaced on 64 bit systems. It is contained in a routine related to floating point, and so one in inclined to believe that it is caused by the usual problems with floating point.

I indicate the correction: in project-and-lift.h insert

only_single_point = false;

after the line no_relax = Original.no_relax;

@d-torrance
Copy link
Contributor Author

This fixes many of the issues -- thank you!

I'm still getting the Kwak10-mrk test failure on the s390x architecture, which is 64-bit but big-endian.

@w-bruns
Copy link
Contributor

w-bruns commented Sep 17, 2023

Good! Could you (again) send me the diff Kwak10-mrk test failure on the s390x architecture. Sorry, I can' identify it above.

@d-torrance
Copy link
Contributor Author

Good! Could you (again) send me the diff Kwak10-mrk test failure on the s390x architecture. Sorry, I can' identify it above.

Here you go:

82,83c82,83
< 1 0 0 1 -1 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 0 0 -1 1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 
---
> -1 0 0 -1 1 0 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0 
> 1 0 0 1 -1 0 0 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 
86c86
< 1 0 0 1 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 
---
> -1 0 0 -1 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 0 
90c90
< 0 0 -2 0 -1 1 1 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -1 0 -2 -1 0 1 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 
95c95
< -1 -1 -2 -1 0 1 0 0 0 1 0 0 0 -1 0 0 0 0 0 0 0 
---
> 1 1 2 1 0 -1 0 0 0 -1 0 0 0 1 0 0 0 0 0 0 0 
99c99
< 0 -3 -1 0 -1 0 1 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -1 -3 -1 -1 0 0 1 0 1 -1 0 0 0 0 0 0 0 0 0 0 0 
105c105
< -1 -1 -3 -1 0 0 1 0 0 0 0 0 1 -1 0 0 0 0 0 0 0 
---
> 0 0 -1 0 0 -1 1 0 0 -1 0 0 1 0 0 0 0 0 0 0 0 
107,108c107,108
< -1 -4 -1 -1 0 0 0 0 1 1 0 0 0 -1 0 0 0 0 0 0 0 
< -1 -3 -2 -1 0 0 0 0 1 0 1 0 0 -1 0 0 0 0 0 0 0 
---
> 1 4 1 1 0 0 0 0 -1 -1 0 0 0 1 0 0 0 0 0 0 0 
> 0 -2 0 0 0 -1 0 0 1 -1 1 0 0 0 0 0 0 0 0 0 0 
113c113
< 0 -1 -1 0 0 -1 0 0 0 1 0 0 1 -1 0 0 0 0 0 0 0 
---
> 0 1 1 0 0 1 0 0 0 -1 0 0 -1 1 0 0 0 0 0 0 0 
117c117
< -1 -1 0 -1 -1 0 1 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 
---
> -2 -1 0 -2 0 0 1 1 0 -1 0 0 0 0 0 0 0 0 0 0 0 
125,126c125
< -2 -2 0 -2 0 0 1 0 0 0 0 1 0 -1 0 0 0 0 0 0 0 
< -2 -2 0 -2 0 0 0 1 0 1 0 0 0 -1 0 0 0 0 0 0 0 
---
> 0 0 0 0 0 0 1 -1 0 -1 0 1 0 0 0 0 0 0 0 0 0 
127a127
> 2 2 0 2 0 0 0 -1 0 -1 0 0 0 1 0 0 0 0 0 0 0 
136,137c136,137
< -2 -1 -2 -2 0 0 1 0 0 0 0 0 0 -1 0 1 0 0 0 0 0 
< 0 -1 0 0 0 0 0 -1 0 1 0 1 0 -1 0 0 0 0 0 0 0 
---
> -1 0 0 -1 0 -1 1 0 0 -1 0 0 0 0 0 1 0 0 0 0 0 
> 0 1 0 0 0 0 0 1 0 -1 0 -1 0 1 0 0 0 0 0 0 0 
143c143
< -1 -1 0 -1 0 -1 0 0 0 1 0 0 0 -1 0 1 0 0 0 0 0 
---
> 1 1 0 1 0 1 0 0 0 -1 0 0 0 1 0 -1 0 0 0 0 0 
152c152
< -6 -2 0 -3 0 0 0 0 0 0 0 0 0 -1 0 0 0 1 1 0 0 
---
> -4 0 0 -1 0 0 0 -1 0 -1 0 0 0 0 0 0 0 1 1 0 0 
154,155c154,155
< -6 -2 0 -2 -1 0 0 0 0 0 0 0 0 -1 0 0 0 2 0 0 0 
< -6 -2 0 -2 -1 0 0 0 0 0 0 0 0 -1 0 0 1 0 1 0 0 
---
> -7 -2 0 -3 0 0 0 0 0 -1 0 0 0 0 0 0 0 2 0 0 0 
> -7 -2 0 -3 0 0 0 0 0 -1 0 0 0 0 0 0 1 0 1 0 0 
158c158
< -6 -2 0 -1 -2 0 0 0 0 0 0 0 0 -1 0 0 1 1 0 0 0 
---
> -7 -2 0 -2 -1 0 0 0 0 -1 0 0 0 0 0 0 1 1 0 0 0 
160c160
< -6 -2 0 0 -3 0 0 0 0 0 0 0 0 -1 0 0 2 0 0 0 0 
---
> -7 -2 0 -1 -2 0 0 0 0 -1 0 0 0 0 0 0 2 0 0 0 0 
163c163
< -3 -2 0 -2 -2 0 0 0 0 0 1 0 0 -1 0 0 0 0 1 0 0 
---
> -4 -2 0 -3 -1 0 0 0 0 -1 1 0 0 0 0 0 0 0 1 0 0 
165c165
< -4 -2 0 -3 -1 0 0 0 0 0 0 0 0 -1 1 0 0 0 1 0 0 
---
> -5 -2 0 -4 0 0 0 0 0 -1 0 0 0 0 1 0 0 0 1 0 0 
169,172c169,172
< -5 -2 0 -4 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 1 1 0 
< -3 -2 0 -1 -3 0 0 0 0 0 1 0 0 -1 0 0 0 1 0 0 0 
< 1 0 0 0 0 0 0 0 0 1 0 0 0 -1 0 0 0 -1 1 0 0 
< -4 -2 0 -2 -2 0 0 0 0 0 0 0 0 -1 1 0 0 1 0 0 0 
---
> -3 0 0 -2 0 0 0 -1 0 -1 0 0 0 0 0 0 0 0 1 1 0 
> -4 -2 0 -2 -2 0 0 0 0 -1 1 0 0 0 0 0 0 1 0 0 0 
> -1 0 0 0 0 0 0 0 0 -1 0 0 0 1 0 0 0 1 -1 0 0 
> -5 -2 0 -3 -1 0 0 0 0 -1 0 0 0 0 1 0 0 1 0 0 0 
175,178c175,178
< -5 -2 0 -3 -1 0 0 0 0 0 0 0 0 -1 0 0 0 1 0 1 0 
< -3 -2 0 0 -4 0 0 0 0 0 1 0 0 -1 0 0 1 0 0 0 0 
< 1 0 0 0 0 0 0 0 0 1 0 0 0 -1 0 0 -1 1 0 0 0 
< -4 -2 0 -1 -3 0 0 0 0 0 0 0 0 -1 1 0 1 0 0 0 0 
---
> -6 -2 0 -4 0 0 0 0 0 -1 0 0 0 0 0 0 0 1 0 1 0 
> -4 -2 0 -1 -3 0 0 0 0 -1 1 0 0 0 0 0 1 0 0 0 0 
> -1 0 0 0 0 0 0 0 0 -1 0 0 0 1 0 0 1 -1 0 0 0 
> -5 -2 0 -2 -2 0 0 0 0 -1 0 0 0 0 1 0 1 0 0 0 0 
180c180
< -1 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 1 -1 0 0 1 
---
> -2 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 1 0 -1 0 1 
182c182
< -5 -2 0 -2 -2 0 0 0 0 0 0 0 0 -1 0 0 1 0 0 1 0 
---
> -6 -2 0 -3 -1 0 0 0 0 -1 0 0 0 0 0 0 1 0 0 1 0 
187,189c187,189
< 0 -1 0 0 0 0 -1 0 0 2 0 0 0 -1 0 0 0 0 0 0 0 
< 0 0 -1 0 0 0 -1 0 0 1 1 0 0 -1 0 0 0 0 0 0 0 
< 0 -2 0 0 -5 0 0 0 0 0 2 0 0 -1 0 0 0 0 0 0 0 
---
> 0 1 0 0 0 0 1 0 0 -2 0 0 0 1 0 0 0 0 0 0 0 
> 0 0 1 0 0 0 1 0 0 -1 -1 0 0 1 0 0 0 0 0 0 0 
> -1 -2 0 -1 -4 0 0 0 0 -1 2 0 0 0 0 0 0 0 0 0 0 
191,198c191,198
< 0 0 0 0 0 0 0 0 0 1 -1 0 0 -1 1 0 0 0 0 0 0 
< 4 2 1 4 6 0 0 0 0 0 -1 0 0 -1 0 0 0 0 0 0 0 
< -1 -2 0 -1 -4 0 0 0 0 0 1 0 0 -1 1 0 0 0 0 0 0 
< 5 3 0 5 5 0 0 0 0 0 0 0 0 -2 0 0 0 0 0 0 0 
< 0 0 0 0 0 0 0 0 0 1 0 0 0 -2 0 0 0 0 0 0 1 
< 0 0 0 0 0 0 0 0 0 1 0 0 0 -1 -1 0 0 0 0 1 0 
< 5 2 1 5 5 0 0 0 0 0 0 0 0 -1 -1 0 0 0 0 0 0 
< 0 0 0 0 0 0 0 0 0 0 1 0 0 -1 -1 0 0 0 0 0 1 
---
> 0 0 0 0 0 0 0 0 0 -1 1 0 0 1 -1 0 0 0 0 0 0 
> 4 2 1 4 6 0 0 0 0 -1 0 0 0 0 -1 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 -1 0 0 0 2 0 0 0 0 0 0 -1 
> 5 3 0 5 5 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 -1 
> -2 -2 0 -2 -3 0 0 0 0 -1 1 0 0 0 1 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 -1 0 0 0 1 1 0 0 0 0 -1 0 
> 5 2 1 5 5 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 -1 0 
> 0 0 0 0 0 0 0 0 0 -1 1 0 0 0 0 0 0 0 0 -1 1 
200,204c200,204
< -2 -2 0 -2 -3 0 0 0 0 0 1 0 0 -1 0 0 0 0 0 1 0 
< -2 -2 0 -2 -3 0 0 0 0 0 0 0 0 -1 2 0 0 0 0 0 0 
< 6 2 2 0 9 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 -1 0 
< 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 1 0 0 0 0 -1 1 
< -3 -2 0 -3 -2 0 0 0 0 0 0 0 0 -1 1 0 0 0 0 1 0 
---
> -3 -2 0 -3 -2 0 0 0 0 -1 0 0 0 0 2 0 0 0 0 0 0 
> -3 -2 0 -3 -2 0 0 0 0 -1 1 0 0 0 0 0 0 0 0 1 0 
> 0 0 0 -1 0 0 0 0 0 -1 0 0 0 1 0 0 0 0 -1 1 0 
> 0 0 0 -1 0 0 0 0 0 -1 0 0 0 0 1 0 0 0 -1 0 1 
> -4 -2 0 -4 -1 0 0 0 0 -1 0 0 0 0 1 0 0 0 0 1 0 
207c207
< -4 -2 0 -4 -1 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 2 0 
---
> -5 -2 0 -5 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 2 0 
make[4]: *** [/home/dtorrance/normaliz/_build/../test/Makefile.classic:156: test-mrk/Kwak10-mrk.mrk.diff] Error 1

@w-bruns
Copy link
Contributor

w-bruns commented Sep 18, 2023

The difficulty with this test is that the minimal Markov basis of a binomial ideal is not uniquely determined. Their is no error in the number of generators. It is uniquely determined. Nevertheless it would be good to analyze what is going on. Can I get a login at a machine that rungs the critical operating system?

But before I can refine the test a bit. Not only the total number of generators is uniquely determined , but also the number in each degree. It may however take a while before I can add the refinement.

@w-bruns
Copy link
Contributor

w-bruns commented Sep 18, 2023

PS Can you send me the file Kwak10-mrk.mrk ? It is produce by the test run. I can use it as an input file and then check some necessary conditions for mathematical correctness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants