[Tutor] decomposing a problem

[Alan Gauld]

On 28/12/2018 20:34, Avi Gross wrote:

> So before I respond, here is a general statement. I am NOT particularly
> interested in much of what we discuss here from a specific point of view.
> Someone raises a question and I think about it. They want to know of a
> better way to get a random key from a dictionary. My thought is that if I
> needed that random key, maybe I would not have stored it in a dictionary in
> the first place. But, given that the data is in a dictionary, I wonder what
> could be done. It is an ACADEMIC discussion with a certain amount of hand
> waving.

But you need to apply real world constraints.
The choice of data type is intrinsic to the language in use.
(The same is true of control structures - loops,
decision points etc - but that is less pertinent here.)

If you program in C pretty much all you get is the array.
Everything else (including struct/union/typedef) is hand
crafted by the programmer.

If its Lisp then you get the list and anything else
is coded (or simulated in code) by hand.

In Python we have lists, tuples, dictionaries and sets.
Anything else, including subclassing the basic types, is
down to the programmer (or finding a module already created
by somebody else).

In Smalltalk we have over a hundred basic collection
types to choose from. And the choice to subclass any
of them.

So when you address a problem in any given language the
available solutions must be constrained by whatever the
language in question offers. Wishing for non-existent
data structures that may exist elsewhere is simply to
request a new feature to be designed and programmed
in the language at hand. That may be the best solution
depending on the nature of the problem but we need to
recognise the nature of the request. It is still a new
feature.

Of course we can learn a great deal by comparing features
on one language against another but in terms of solving
a specific request we need specific answers too.


> ---
> The obvious solution:
> 
> keys = list(mydict.keys())
> random.shuffle(keys)
> index = len(keys)*3//4
> training_data = keys[:index]
> reserved = keys[index:]
> ---

> For me, it seems more natural in this case to simply have the data in a data
> frame where I have lots of tools and methods available. 

But only if such a data frame exists. In Python it does not
(at least, not in the standard library). So any reference
to such a non existent structure is in effect a work request
for someone to build one. To do so requires a specification
or design that the OP can follow or better still a prototypical
template. It also assumes a much higher level of skill than the
original request and the "obvious solution".

> but if your coding style is more comfortable with another way, why bother
> unless you are trying to learn other ways and be flexible.

If your current language does not support the structure
you desire you have three choices:
1) change your programming language or
2) build the missing feature or
3) find a workaround using the structures available.

Most people opt for #3. (Although all may be valid options
depending on the circumstance)


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos