Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #29484 > unrolled thread

Re: A little morning puzzle

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A little morning puzzle Peter Otten <__peter__@web.de> - 2012-09-19 14:09 +0200
    Re: A little morning puzzle Tobiah <toby@tobiah.org> - 2012-09-20 09:28 -0700
      Re: A little morning puzzle Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-22 23:44 -0400
        Re: A little morning puzzle alex23 <wuwei23@gmail.com> - 2012-09-23 20:46 -0700
          Re: A little morning puzzle Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-24 17:22 -0400
          RE: A little morning puzzle "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-09-27 17:58 +0000
      Re: A little morning puzzle Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-23 22:51 -0600
      Re: A little morning puzzle Ethan Furman <ethan@stoneleaf.us> - 2012-09-24 14:18 -0700
      Re: A little morning puzzle Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-24 18:07 -0400
      Re: A little morning puzzle Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-24 17:01 -0600
      Re: A little morning puzzle Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-24 19:13 -0400

#29484 — Re: A little morning puzzle

Dwight Hutto wrote:

>> I have a list of dictionaries.  They all have the same keys.  I want to
>> find the
>> set of keys where all the dictionaries have the same values. 
>> Suggestions?
> 
> Here is my solution:
> 
> 
> a = {}
> a['dict'] = 1
> 
> b = {}
> b['dict'] = 2
> 
> c = {}
> c['dict'] = 1
> 
> d = {}
> d['dict'] = 3
> 
> e = {}
> e['dict'] = 1
> 
> 
> x = [a,b,c,d,e]
> collection_count = 0
> 
> for dict_key_search in x:
> if dict_key_search['dict'] == 1:
> collection_count += 1
> print dict_key_search['dict']
> 
> 
> Might be better ones though.

Unlikely. 

[toc] | [next] | [standalone]

#29558

>> Here is my solution:

>> ** Incredibly convoluted and maximally less concise solution
>> than other offerings. **

>> Might be better ones though.
>
> Unlikely.

Zing!



  

[toc] | [prev] | [next] | [standalone]

#29780

On Thu, Sep 20, 2012 at 12:28 PM, Tobiah <toby@tobiah.org> wrote:
>
>>> Here is my solution:
>
>
>>> ** Incredibly convoluted and maximally less concise solution
>>> than other offerings. **
>
>
>>> Might be better ones though.
>>
>>
>> Unlikely.
>
>
> Zing!
>

Why don't you all look at the code(python and C), and tell me how much
code it took to write the functions the other's examples made use of
to complete the task.

Just because you can use a function, and make it look easier, doesn't
mean the function you used had less code than mine, so if you look at
the whole of what you used to make it simpler, mine was on point.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[toc] | [prev] | [next] | [standalone]

#29889

On Sep 23, 1:44 pm, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> Just because you can use a function, and make it look easier, doesn't
> mean the function you used had less code than mine, so if you look at
> the whole of what you used to make it simpler, mine was on point.

Word of advice: when we use "simpler" around these parts we're
referring to cognitive burden on the end developer and not the actual
amount of interpreter/library code utilised to solve the problem.

Ergo: 'enumerate(<some_list>)' is the correct suggestion over manually
maintaining your own index, despite it ostensibly being "more" code
due to its implementation.

[toc] | [prev] | [next] | [standalone]

#29932

> Ergo: 'enumerate(<some_list>)' is the correct suggestion over manually
> maintaining your own index, despite it ostensibly being "more" code
> due to its implementation.

But, therefore, that doesn't mean that the coder can just USE a
function, and not be able to design it themselves. So 'correct
suggestion' is a moot point.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[toc] | [prev] | [next] | [standalone]

#30317

Dwight Hutto wrote:
> > Ergo: 'enumerate(<some_list>)' is the correct suggestion over manually
> > maintaining your own index, despite it ostensibly being "more" code
> > due to its implementation.
> 
> But, therefore, that doesn't mean that the coder can just USE a
> function, and not be able to design it themselves. So 'correct
> suggestion' is a moot point.
> 

Can you rephrase your first sentence? I am not sure what
you mean.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#29893

On Sat, Sep 22, 2012 at 9:44 PM, Dwight Hutto <dwightdhutto@gmail.com> wrote:
> Why don't you all look at the code(python and C), and tell me how much
> code it took to write the functions the other's examples made use of
> to complete the task.
>
> Just because you can use a function, and make it look easier, doesn't
> mean the function you used had less code than mine, so if you look at
> the whole of what you used to make it simpler, mine was on point.

I understood the sarcastic comments (the first one, at least) to be
referring to your solution as bad not due to complexity (I actually
thought it was quite simple), but because it does not solve the
problem as stated.  The problem posed by the OP was to find a set of
common keys that are associated with the same values in each dict.
Your solution takes only one predetermined key-value pair and counts
how many times it occurs in the dicts, which isn't even close to what
was requested.  With your comment of "Might be better ones, though", I
actually thought that you were aware of this and were being
intentionally satirical.

[toc] | [prev] | [next] | [standalone]

#29936

Ian Kelly wrote:
> On Sat, Sep 22, 2012 at 9:44 PM, Dwight Hutto <dwightdhutto@gmail.com> wrote:
>> Why don't you all look at the code(python and C), and tell me how much
>> code it took to write the functions the other's examples made use of
>> to complete the task.
>>
>> Just because you can use a function, and make it look easier, doesn't
>> mean the function you used had less code than mine, so if you look at
>> the whole of what you used to make it simpler, mine was on point.
> 
> I understood the sarcastic comments (the first one, at least) to be
> referring to your solution as bad not due to complexity (I actually
> thought it was quite simple), but because it does not solve the
> problem as stated.  The problem posed by the OP was to find a set of
> common keys that are associated with the same values in each dict.
> Your solution takes only one predetermined key-value pair and counts
> how many times it occurs in the dicts, which isn't even close to what
> was requested.  With your comment of "Might be better ones, though", I
> actually thought that you were aware of this and were being
> intentionally satirical.

Unlikely.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#29939

On Mon, Sep 24, 2012 at 5:18 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> Ian Kelly wrote:
>>
>> On Sat, Sep 22, 2012 at 9:44 PM, Dwight Hutto <dwightdhutto@gmail.com>
>> wrote:
>>>
>>> Why don't you all look at the code(python and C), and tell me how much
>>> code it took to write the functions the other's examples made use of
>>> to complete the task.n in or register.
>>>
>>> Just because you can use a function, and make it look easier, doesn't
>>> mean the function you used had less code than mine, so if you look at
>>> the whole of what you used to make it simpler, mine was on point.
>>
>>
>> I understood the sarcastic comments (the first one, at least) to be
>> referring to your solution as bad not due to complexity (I actually
>> thought it was quite simple), but because it does not solve the
>> problem as stated.  The problem posed by the OP was to find a set of
>> common keys that are associated with the same values in each dict.

>> Your solution takes only one predetermined key-value pair and counts
>> how many times it occurs in the dicts, which isn't even close to what

They stated:

I have a list of dictionaries.  They all have the same keys.  I want to find the
set of keys where all the dictionaries have the same values.  Suggestions?

No, to me it meant to find similar values in several dicts with the
same key, and value. So I created several dicts, and some with the
same key and value, and showed the matches.

The OP can comment as to whether that is the correct interpretation of
the situation.


>> was requested.  With your comment of "Might be better ones, though", I
>> actually thought that you were aware of this and were being
>> intentionally satirical.

I am. I just write out the algorithm as I understand the OP to want
it, to give my version of the example.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[toc] | [prev] | [next] | [standalone]

#29953

On Mon, Sep 24, 2012 at 4:07 PM, Dwight Hutto <dwightdhutto@gmail.com> wrote:
> They stated:
>
> I have a list of dictionaries.  They all have the same keys.  I want to find the
> set of keys where all the dictionaries have the same values.  Suggestions?
>
> No, to me it meant to find similar values in several dicts with the
> same key, and value. So I created several dicts, and some with the
> same key and value, and showed the matches.

Well, to me at least it is clear that when the OP writes "I want to
find the *set* of *keys*..." (emphasis added), then setting aside the
rest of the problem statement, the result of the algorithm should be a
set (or at least something set-like), and the contents of the set
should be keys.  The posted code produces neither a set nor any keys;
it prints out the same predetermined non-key value multiple times.

[toc] | [prev] | [next] | [standalone]

#29956

The posted code produces neither a set nor any keys;
> it prints out the same predetermined non-key value multiple times.

This shows multiple dicts, with the same keys, and shows different
values, and some with the same, and that is, in my opinion what the OP
asked for:

a = {}
a['dict'] = 1

b = {}
b['dict'] = 2

c = {}
c['dict'] = 1

d = {}
d['dict'] = 3

e = {}
e['dict'] = 1


x = [a,b,c,d,e]
count = 0
collection_count = 0
search_variable = 1
for dict_key_search in x:
        if dict_key_search['dict'] == search_variable:
                print "Match count found: #%i = %i" % (count,search_variable)
                collection_count += 1
        count += 1
print collection_count



The OP can jump in and tell me to alter the example, if they want to.




-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web