Open 1to9only opened 1 year ago
Hi @1to9only
Thank you for your report. But I cannot reproduce it.
Here are the results on Ubuntu (on WSL2) and Mac.
$ cat test.txt
..9......5...8.2..4...2..9..1.3...6..8.6....7.5....9..6.873.......1.65......4.7..
........1.....2.3..14.5.2........4673...48...7..2.......3......1.6....9398..75...
$ ./minlex test.txt
000000001000002030014050200000000467300048000700200000003000000106000093980075000
000000001000002030014050200000000467300048000700200000003000000106000093980075000
It shows the identical result.
Can you tell us about your execution environment, especially your compiler and compile options?
P.S. I have modified the code to accept periods instead of zeros.
Hello @kaityo256 Have you tried minlexing:
$ cat test.txt
..9......5...8.2..4...2..9..1.3...6..8.6....7.5....9..6.873.......1.65......4.7..
829461375567983241431527698714359862983612457256874913648735129372196584195248736
...461375567983241431527698714359862983612457256874913648735129372196584195248736
..9461375567983241431527698714359862983612457256874913648735129372196584195248736
.29461375567983241431527698714359862983612457256874913648735129372196584195248736
I run minlex.exe on Windows 10 64-bit. I dont have g++ installed at the moment, but my notes show the program was built as follows:
g++.exe -c -static-libgcc -static-libstdc++ -Ofast -std=c++11 -march=native -Wall -Wextra minlex.cpp
g++.exe -flto -Ofast -s -static -static-libgcc -static-libstdc++ -Wall -Wextra -o minlex.exe minlex.o
Thanks for taking the time to look into this.
Hello @1to9only
I have tried the following and reproduced the problem you reported on Windows, Linux, and Mac.
$ cat test.txt
..9......5...8.2..4...2..9..1.3...6..8.6....7.5....9..6.873.......1.65......4.7..
829461375567983241431527698714359862983612457256874913648735129372196584195248736
...461375567983241431527698714359862983612457256874913648735129372196584195248736
..9461375567983241431527698714359862983612457256874913648735129372196584195248736
.29461375567983241431527698714359862983612457256874913648735129372196584195248736
$ ./minlex test.txt
000000001000002030014050200000000467300048000700200000003000000106000093980075000
999999999999999999999999999999999999999999999999999999999999999999999999999999999
000123456124567389563489721251846937376295814489731265618972543745318692932654178
999999999999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999999999999
This is obviously a bug. Thanks for reporting it. The code was written so long ago that I have completely forgotten its contents and it may take some time to fix it.
Stay tuned.
Here is another puzzle (already in minlex format) which shows the minlex bug.
$ cat test.txt
..1..2..3.2..3..4.3..5..2....2.5...4.6.7..8..9....8.5...8.1...9.9.6...7.1....93..
$ ./minlex test.txt
999999999999999999999999999999999999999999999999999999999999999999999999999999999
The puzzle is already in minlex format, so the output should be same as the puzzle.
Hi @1to9only
Thank you for your report and sorry for my late reply. I confirmed that the output is not correct. It is obviously a bug of my code. I will find time to fix it.
I tried the minlex tool with these sudokus
On Windows I get these results
Another minlexer I also use is from https://github.com/dclamage/SudokuClassicMinLex which gives these results