pzahemszky / pzudoku Goto Github PK

Try profiling & annotation, as well as Cython

• 1. Remove formatted string literals (f-strings).
• 2. Avoid using collections.deque.__add__ (operation_queue.py, line 100, in remove_rearrange).

Add flake8 check to the repository, and make it part of CI.

It would be useful to add extra CI jobs that test the package with various different versions of the prerequisites.

As well as the indexing order of position within a box.

setuptools gives a warning that python setup.py test will be removed. It should be replaced with something else, e.g. something like python -m unittest discover. See the logs e.g. on Cirrus CI.

coverage run setup.py test
running test
WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox.

During a single run of quick_fill() the number of possible candidates in any given square can only ever decrease. Hence it would be slightly safer for _add() to just call _remove_candidate(dig, row, col) instead of the direct override of self._board items that's happening currently.

However, this would be slower because of the loops.

https://github.com/pzahemszky/sudoku/blob/dccaf8ae0c26a79f60798a479598af491e85da6d/board.py#L169-L181

Collect library dependencies together.

• 1. filled_in, the number of filled in squares on the board (e.g. a property calculated from empties)
• 2. ndigits, the number of unique digits the board has so far
• 3. has_clash and its first occurence
• 4. has_unique_soln
• 5. has_multi_soln (probably hard to calculate)

Add a public to_array() method to the HB6DBoard class, that would be the equivalent of the from_array() function.

Might need different types of peers (for closer ones and less close ones).

One reason for this is that during from_str (and the recursive solve call) some operations are supposed to be deleted from the queue.
Also, move operations.remove_rearrange inside the _add function.

Add support for box-shaped boards that have rectangular boxes (e.g. 6x6, 7x7).

Issue #56 is a subtask of this.

from_txt() or read_txt() should read in the content of a text file and fill in the board similarly to from_str().

To avoid issues with recursion depth it would be good to convert the _recursive_solve function to its iterative variant.

In the most recent PR #69 the python3 -m ensurepip --default-pip command fails on FreeBSD 11.1 platform. Strangely enough, it succeeds on versions 10.4, 11.2, and 12.0.

Shared object "libdl.so.1" not found, required by "python3"

See the full log here.

Unfortunately, pkg install py3-pip doesn't solve this issue, because that results in a "No packages available" error message (on all versions, not just 11.1).

Edit: this has probably little to do with ensurepip. It might be a problem with the python3 installation.

Explore the possibility of using other multi-dimensional arrays (instead of NumPy ndarrays), and extract an abstract base class (e.g. Core6DArray) purely for storing the underlying boolean data.

For example,

• memoryview on a 1-D array / bytearray (so that strides, 1-D slicing and multi-dimensional indexing are implemented), or
• nested lists / dicts / OrderedDicts (with custom-built slicing and multi-dimensional indexing).

This way the code would not dependent on NumPy.

For example an empty candidate being _dig_row instead of _row_col (=cell), i.e. a (digit, row) pair that has more than one possible columns where the digit is still a candidate.

Think of it as "projecting" board along the first dimension to find empty cells, and along other dimensions to find the other options.

There could be a simple two-level hierarchy between peers: those operations that are more likely to be successful after _add(dig, row, col) should be placed in front of the secondary operations in the queue of remove_rearrange.

In particular, for the triple (dig, row, col) and corresponding row_slice and col_slice objects the below operations should be prioritised before any of the other ones.

• Operation('digcol', dig, c), if c is within col_slice
• Operation('digrow', dig, r), if r is within row_slice
• Operation('digbox', dig, b), if b intersects with row or col

• 1. filled, without clash
• 2. filled, with clash
• 3. not filled, with immediate clash (=no solution)
• 4. not filled, with hidden clash (=no solution)
• 5. not filled, no clash, unique solution
• 6. not filled, no clash, multiple solutions
• 7. various recursion depths

• normal 3x3
• other square boxed, e.g. 2x2
• rectangular box
• 4x4 (from newspapers)

I don't have time to debug the build failure on Windows (Python 3.4), but this would be good to investigate. (See the Python34 and Python34-x64 build details.)

Labelling with build, since it seems unrelated to other parts of the code. (Other CI builds pass on multiple platforms.)

Since _recursive_solve is essentially a traversal of a directed acyclic graph, it should be easy to run concurrently.

...based on boxID (0...8) and position within the box (0...8).
Used in this way:
self._add(digit, box, boxpos, alternative=True)

E.g. randomly generate many sudoku boards and solve them

Currently there's a single badge showing the build status.

It would be good to have one for each platform.

This might require the introduction of new CI tools.

Rename finds to e.g. inspects, and change

• 'dig' to 'square',
• 'row' to 'digcol',
• 'col' to 'digrow', and
• 'pos' to 'digbox'.

Add support for board that are not 9x9, but still have square-shaped boxes (e.g. 4x4 and 16x16 boards).

Currently Cirrus CI uses Python 2.7 for all macOS and FreeBSD containers. This should be changed to multiple Python 3 versions.

In addition to a fast version, where every possible thing is stored, it would be nice to have an alternative implementation that's the least memory heavy (but also slower).

As a regression test for 6092cd8, it would be nice to have the same tests as test_iadd has in https://github.com/python/cpython/blob/c9265c1534b7e62bb9b15460d0420c0c3bb57ff9/Lib/test/test_deque.py#L214-L219.

Related to #28, since Python2's collections.deque doesn't have __add__.

Currently it's like <Operation(row, (0, 1)>.

Would be really nice to retrieve the newly filled in squares even if the user terminates the solution halfway through the process.

This functionality might be very hard to test (non-manually).

Record the first requeued operation since the beginning / the last _add call, then check for equality with the current operation. Finish the loop when the operation reoccurs.

Replace them with global(?) variables, so that renaming is easy (e.g. with and IDE).
For example, use SQUARE, DIGIT_ROW, DIGIT_COLUMN, DIGIT_BOX, referring to the string literals 'square', 'digrow', 'digcol', 'digbox'.

Useful functionalities:

• __str__ & __repr__
• __init__
• __eq__
• +, +=
  Possibly handy for testing:
• len
• slicing
• setter, getter
• __contains__

...since in that case a box is simply a row/column.

Algorithm meaning recursion, operation details, no 1-based indexing, no reading from string. For example, Solver().

Access this class via a more user-friendly and slower interface, e.g. Board().

E.g. Property for attributes that depend on others, and for type validation

• Add an entry point in setup.py,
• add "extra" CLI dependencies (e.g. click) to be used by console_scripts,
• catch errors and print message without traceback,
• add a man page.

The solve method should call _recursive_solve, and additionally print/record things afterwards (e.g. regarding depth of recursion, whether a clash has been found, etc). Hence _recursive_solve should not have any side effects.

Currently one gets this traceback when typing board = Board(1, 2); board.from_str('1234').

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/unittest/case.py", line 59, in testPartExecutor
    yield
  File "/usr/local/lib/python3.6/unittest/case.py", line 605, in run
    testMethod()
  File "/home/zpeti/sudoku/tests/test_board.py", line 364, in test_solve_filled_1x1_with_clash
    board.from_str('1234')
  File "/home/zpeti/sudoku/board.py", line 222, in from_str
    char = characters[i]
IndexError: string index out of range

There should be an error for not enough number of squares (arising from the dropping of out-of-bounds digits in the input string).

Add a class similar to the current Board, but with 5D 6D boolean hyper-rectangle array as the underlying data structure.

Rename the HB6DBoard class to SixD_Board.

Use _copy_from() instead of deepcopying or copying over specific attributes "manually".

To store the many different types of sudoku boards for testing.

Has same meaning as digit 0.

Currently HB6DBoard._check_consistency is not fully tested.