Find word by given characters
dn
PythonList at DancesWithMice.info
Mon Nov 2 21:56:53 EST 2020
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
More information about the Python-list
mailing list