[Tutor] The Python way and two dimensional lists

[dn]

On 22/11/2021 13.13, Phil wrote:
> I hope my questions are not becoming too tiresome.

@Alan seems to have jumped-in first, so I've edited this response, and
hope it has not become too disjointed.

First question: have you located (and at least dipped-into) Pilgrim's
book (as mentioned earlier). He certainly discusses lists, and (I
haven't looked (again)) may well cover 2D...

Later there is a specific explanation, but the reason for reading is not
(only) that you pick-up Python-syntax, but also that you can see the
idioms of the language - the way 'bits' work together, and how the
language designers were thinking things should go (mental models make
another appearance below). Thus, time worth investing...

Incidentally, have a look at the bottom of @Alan's posts, because such
may (also) be covered in his tutorial.

(in both cases, a while since I've looked for specifics in either)


> It will require a major effort to rewrite my use of lists in the Python
> way and so I want to make sure that the first steps are correct. The
> first index refers to the columns and the second to the rows.
> 
> num_rows = 9
> num_cols = 9
> 
> solution = [[0 for i in range(num_cols)] for j in range(num_rows)]

Python's storage allocation is dynamic. It is not necessary to 'reserve'
space.


> solution[0][0] = {7,3}
> solution[1][0] = {5}
> solution[2][0] = {4,8,6}
> solution[3][0] = {7,8}
> solution[4][0] = {1}
> solution[5][0] = {9,3}
> solution[6][0] = {7,9}
> solution[7][0] = {4,6,3}
> solution[8][0] = {2}

As per @Alan, I also kept feeling that this was 'the wrong way around'!
Firstly, I'm a navigator, so I'm used to looking at Cartesian
Co-ordinate systems - across before up/down. Secondly, it shouldn't
really matter which way around one considers the rows and the columns -
so time to get my head out of ...

That said, consistency is key. If *you* don't have a visualisation (a
mental model) of how this system will work, then all is lost! (at sea?)
- and the rest of us have 'no chance'...


Next point: Python's lists are not arrays. Notably (but largely
irrelevant in this case) many languages require the elements of an array
to be of the same type. Items in Python lists can vary, as desired!

Lists are typically built either from another "collection" or
incrementally. Thus:

l = list( ( 1, 2, 3 ) )

or

l = list() # or []
l.append( 1 )
l.append( 2 )
...


...

> row = [{7,3},{5},{4,8,6},{7,8},{1},{9,3},{7,9},{4,6,3},{2}]

May I suggest that you ignore the 2D issue, for now. Work with the
above. Identify the match(es) in this one row, and prove that part of
the algorithm.


This is what we (in the business) call "Stepwise Decomposition" (plenty
of web-links). The idea is to break a large problem into smaller
problems. Then break those into even smaller problems. Continuing until
the size of the problem becomes 'easily manageable'. In your case, as a
Python-Apprentice, this might be a smaller unit than someone else, but
that is *not* important. In short everyone's definition of
'small-enough' is going to be different (aka YMMV)!

Now, with a 'small' problem, you can wrap it into a Python-function (and
when you come to linking small-solutions into the solution of a
larger-problem, it becomes a matter of stringing-together a bunch of
function calls! (he says, breezily)


This also picking-up your point about wanting to be sure that 'the core'
of the idea is correct, cf risking spending a lot of time 'flogging a
dead horse'. Conversely, and as I was reminding myself when I feared
wasting my time on testing and refactoring existing code this morning
(cf feeling I was 'solving the emergent problem, as needed') - testing
and becoming confident in the capacities of the 'building blocks'
becomes a series of small encouragements, and "nothing succeeds like
success"!


Another advantage is that you can write some (automated) tests, eg

row = [{7,3}, etc
result = find_duplicates( row )
assert result == x,y,z

(if you've not previously met "assert", its boolean-expression must
result in True, otherwise it fails - and the exception report will draw
your (much-needed) attention to the disparity!)


> Confusion is setting in. I think my use of enumerate is correct and I
> think the way that I'm referencing a row from the solution list is
> correct. If both of those aren't the source of the error then it has to
> do with my use of sets. for r in col[0] doesn't give me the sets
> {7,3},{5} etc.

This, and something you said earlier, represent other good reasons for
building short functions. Even if you don't want to risk 'breaking'
working-code, they are easy to copy-paste, and thus allow you to tinker
with a 'disposable' copy.

Such can thus be regarded as a 'test-bench' which you can use to
experiment, and compare different ideas as they occur to you. (it's what
many of us do, even if you can't see us...)


> Searching the Internet for information hasn't made me any wiser yet and
> again I'm sorry to burden the list members with my problems.

See first question (above). That said, we like intelligent questions
posed by people who make an effort...
-- 
Regards,
=dn