[Tutor] The Python way and two dimensional lists

[Phil]

On 7/12/21 20:34, Alan Gauld via Tutor wrote:

Thank you Alan, Dennis and dn, now I have even more to think about!

I previously mentioned that this current sudoku solver project is one 
that I've translated from a C++ project that I wrote many years ago. It 
does, as it stands, solve all but the more difficult puzzles. I've added 
some extra solving strategies over the past couple of months and I'm 
attempting to make the code, even though it works, more understandable. 
Visualising and manipulating objects in space is one of my many failings 
and one that cost me a job at an IBM interview.

> I believe you are building a model of a Sudoku game?
> But from your description it's not clear what data
> structure you are using. Please just show it!
>
The first list of lists represents the board.

         self.solution = [[None] * self.num_cols for _ in 
range(self.num_rows)]

The second list of lists represents the Tkinter GUI where the user can 
enter a puzzle to be solved. The programme solves the puzzle, not the user.

         self.entry_grid = [[None] * self.num_cols for _ in 
range(self.num_rows)]
> If it works it is "correct" for some definition of correct.
Both working correctly and being understandable is the issue here.
> But personally here is how I would tackle your problem.
>
> I'd just use a single list of 81 cells.
I'll think about this. As dn pointed out, knowing where the line endings 
are could be a complication. I'll think about this and helper functions. 
I'm a little reluctant to move from the model that I have because I 
understand how it represents the board, I'm just having a problem with 
manipulating the board grid to extract the columns. I don't have a 
problem with the rows. I will experiment with the class methods provided 
by Dennis, it may persuade me to change from a list of lists to a snake 
list as dn calls it.
> I'd then write helper functions to extract the sublists I needed:
>
> def get_cell(table, row, col)
>
> def get_row(table, row_num)
>
> def get_col(table, col_num)
>
> def get_box(table, row_num, col_num)  # or just box_num?

I don't have a function that just gets a column. Column extraction is 
performed as part of other functions. I know that a function should do 
just one job, so I'll work on that. I have started a function that gets 
the box number but I cannot see, at the moment, how to integrate it with 
the rest of my programme.

> The next problem (based on previous posts) is that your
> cells are sets which are immutable, so you need to:
> 1) create another set of functions for writing back changes
> to a cell - tricky...

I'm not sure that I understand why this is difficult. This is how I 
update a cell:

self.solution[row][col] = set(num)

> OR
> 2) use lists instead of sets because they are mutable.
I had originally used lists instead of sets as a result of my 
translation from arrays to lists. The use of sets was an experiment that 
didn't cause any harm so it's use stayed.
> OR
> 3) Use OOP and make your cells objects with methods
> to add/remove values and using a set internally to
> check uniqueness etc. This would be my choice.
I'll give this some thought as well.
> Personally, I'd use OOP for the table too, and make the
> functions above methods of the table. So you would have
> a table object with 81 mutable cells.
>
> But you haven't mentioned OOP up to now so that may be
> an extra learning curve you don't want to deal with.

A grid class would probably be a good idea, more to think about.

-- 

Regards,
Phil