Find word by given characters

[dn]

On 03/11/2020 12:10, Bischoop wrote:
> On 2020-11-02, dn <PythonList at DancesWithMice.info> wrote:
>> If you have a working Py2 version, once print-statements were changed
>> into functions, what errors were thrown-up?
>>
> That was almost 15 if no more years ago when I was learning then had a
> long break beacause Life :-) Got married, working as Chef, now have some
> more time, working part time so a got back to old hobby and learning
> again, however I see now with age everything is going slower lol

Apologies, I hoped that you had the Py2 code to-hand.


>> Multiple loops written in Python are likely to be slower than same in
>> compiled code - which was probably part of the motivation for @Terry's
>> response. Plus, "re-use" - why write something ourselves if someone else
>> has already done the work?
> 
> For educating purposes?

We are/should all be learning!


>> How about a change of tactics?
>>
>> - str.find() or .index() will locate a character within the string
>> (starting from character[0]/the left-hand side)
>> - if this fails, tears will fall...
>> - repeat, from the right
>> - if both results are the same character/position, it must be unique
>> within the string
>> - repeat for each character in "Letters"
>>
>> This process assumes that built-in functions are faster than exhaustive
>> scans written in Python, and thus (presumably) also that the number of
>> "Letters" is small in comparison with the lengths of words.
>>
> ha, everything seems easy only if you know that.
> Sorry mate, for you it's obvious for me: oh, OK.


You are correct: "any sufficiently advanced technology is 
indistinguishable from magic" [Arthur C Clarke].

I'd like to think that characterisation correct (it would be more 
believable if you cataloged my debonair demeanor and devastatingly-good 
looks -maybe!). However, the reality is that I had to stop and think 
about it. That said, my 'catalog' of Python tactics may/should be wider 
than yours (and yet is probably 'not much' when compared with certain 
others!)

No question: one must start with the basics, even whilst aspiring to 
'the lofty peaks'.

In a parallel response (to @Duncan's post) other approaches - which may 
be beyond your current reach, are discussed.

The 'learning opportunity/ies' (if not for you/me, for the many others 
following this discussion on-list) are (at least) three-fold:
- how to write loops and wrangle strings;
- how sometimes not writing code can be 'faster' (at dev.time and/or in 
prod) because someone else has already coded a solution (or something I 
can 'improve'); and
- there is often more than one way to look at the problem (do I search 
every letter of the candidate word, once for every letter in Letters, or 
vice-versa - or is there yet another way!)

My suggestion: continue with the nested loops approach until you've 
cracked it. Then, working at your own pace, and at your own interest, 
consider implementing the counter() idea. Can you make it work? Can you 
make it meet the spec? Then, take a look at a str.index() alternative. 
Then, look-around for some other approach. Finally (which seems to imply 
an 'end' - hah!), look back, and reflect on both the acquiring of so 
many new skills; and how some solutions are 'faster', some more 
'obvious', and some more "elegant". Hey, it all sounds like "learning" 
to me!


>> Once the algorithms are proven, a speed comparison might be an
>> interesting exercise...
>>
>> For extra credit: once you've solved both, and compared the alternatives
>> on your machine; post the code (and test data), and ask various
>> colleagues 'here' to repeat the speed/performance comparisons on other
>> machines.
>>
>> Will/should the results be identical?
> 
> I'll look into that tomorrow, your sugestions guys and hopefully I've
> achieve these goals.

You cast yourself as 'the learner', but if you (whenever) contribute 
something along these lines, there will be many who learn from you...
-- 
Regards =dn