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

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

Simple exercise

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

Contents

  Simple exercise Rodrick Brown <rodrick.brown@gmail.com> - 2016-03-10 04:02 -0500
    Re: Simple exercise Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-10 11:30 +0100
      Re: Simple exercise Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-10 12:07 +0100
      Re: Simple exercise Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-10 17:05 +0100
        Re: Simple exercise Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-10 17:08 +0100
    Re: Simple exercise Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-11 12:24 +1300
      Re: Simple exercise Chris Angelico <rosuav@gmail.com> - 2016-03-11 10:38 +1100
    Re: Simple exercise BartC <bc@freeuk.com> - 2016-03-11 00:05 +0000
      Re: Simple exercise Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-11 01:21 +0000
        Re: Simple exercise BartC <bc@freeuk.com> - 2016-03-11 01:45 +0000
          Re: Simple exercise Larry Martell <larry.martell@gmail.com> - 2016-03-10 20:53 -0500
          Re: Simple exercise "Martin A. Brown" <martin@linux-ip.net> - 2016-03-10 17:56 -0800
          Re: Simple exercise Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-11 02:03 +0000
            Re: Simple exercise BartC <bc@freeuk.com> - 2016-03-11 02:18 +0000
            Re: Simple exercise Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 07:35 -0700
              Re: Simple exercise Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-14 15:06 +0000
                Re: Simple exercise Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 09:00 -0700
                Re: Simple exercise Steven D'Aprano <steve@pearwood.info> - 2016-03-15 10:59 +1100
                  Re: Simple exercise Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-15 07:26 +0200
                    Re: Simple exercise Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-15 19:39 +1100
                      Re: Simple exercise Chris Angelico <rosuav@gmail.com> - 2016-03-15 19:53 +1100
                      Re: Simple exercise Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-15 11:04 +0200
                  Re: Simple exercise Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-15 11:09 +0000
              Re: Simple exercise Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-14 09:16 -0600
                Re: Simple exercise Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 09:11 -0700
              Re: Simple exercise Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 15:23 +0000
              Re: Simple exercise Peter Otten <__peter__@web.de> - 2016-03-14 17:00 +0100
          Re: Simple exercise Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-11 02:05 +0000
        Re: Simple exercise Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 07:07 -0700
          Re: Simple exercise Larry Martell <larry.martell@gmail.com> - 2016-03-14 10:13 -0400
          Re: Simple exercise alister <alister.ware@ntlworld.com> - 2016-03-14 14:18 +0000
            Re: Simple exercise Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 08:22 -0700
              Re: Simple exercise MRAB <python@mrabarnett.plus.com> - 2016-03-14 15:57 +0000
      Re: Simple exercise Chris Kaynor <ckaynor@zindagigames.com> - 2016-03-10 18:14 -0800
    Re: Simple exercise boffi <boffi@casa.sua> - 2016-03-17 22:28 +0100

Page 2 of 2 — ← Prev page 1 [2]

#104925

On Tue, Mar 15, 2016 at 7:39 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Why should zip be called convolution?
>
> Why should anything be called anything?
>
> Don't worry, I'm not suggesting that the zip function be renamed.
>

It's like referring to the 'and' and 'or' operators as conjunctions
and disjunctions. You wouldn't rename the operators, but it's still
accurate to describe them that way.

ChrisA

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

#104926

Steven D'Aprano writes:

> On Tuesday 15 March 2016 16:26, Jussi Piitulainen wrote:
>
>> Steven D'Aprano writes:
>> 
>>> Unfortunate or not, it seems to be quite common that "zip"
>>> (convolution) discards items when sequences are of different lengths.
>> 
>> Citation needed. Where is zip called convolution?
>
> Wikipedia :-)
>
> Unfortunately "convolution" is one of those technical terms with many
> related but slightly different meanings. It's used in calculus, signal
> processing, geology, biology, probability theory, formal languages,
> and more. I don't have a citation for it being used in functional
> programming, but is it so hard to believe? A "convolution" is usually
> described as something being folded over another thing, which sounds
> rather like zip, doesn't it?

I'm asking precisely because the term "convolution" already has more
interesting uses that I find somewhat non-trivial, and I don't see zip
being one of those.

> Take two pieces of paper, say one white and one black, one on top of the 
> other, and fold them in half, then in half again, then again:
>
> zero folds = W B
>
> one fold = W B B W
>
> two folds = W B B W W B B W
>
>
> which is not that far from what zip would give you:
>
> W B W B W B W B ...

Seems different to me.

> I don't know enough about the lambda calculus and other theoretical computer 
> science topics to give a definitive citation for "zip" being a convolution, 
> but I do know enough to accept it as plausible.

Perhaps someone else can provide citations. At the moment, I think the
idea is both new and bad.

>> Why should zip be called convolution?
>
> Why should anything be called anything?
>
> Don't worry, I'm not suggesting that the zip function be renamed.

I'm not worried about "zip". I'm worried about "convolution". It's
confusing to adopt an existing term for a different purpose.

>>> See https://en.wikipedia.org/wiki/Convolution_%28computer_science%29
>> 
>> "This article possibly contains original research. Please improve it by
>> verifying the claims made and adding inline citations."
>
> Meh, there are Wikipedia editors that seem to flag just about every article 
> with that. You could write "water is wet" and technically that's "original 
> research" that needs a citation. It is so over-used that it is practically 
> meaningless.

In this case, it seems accurate to me. The article makes a factual claim
that the term is actually used this way in computer science, with no
evidence to back it up. I doubt it. I failed to find evidence myself.

Anyone?

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

#104933

On 14 March 2016 at 23:59, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 15 Mar 2016 02:06 am, Oscar Benjamin wrote:
>
>> On 14 March 2016 at 14:35, Rick Johnson <rantingrickjohnson@gmail.com>
>> wrote:
>>>
>>> I would strongly warn anyone against using the zip function
>>> unless
>> ...
>>> I meant to say: absolutely, one hundred percent *SURE*, that
>>> both sequences are of the same length, or, absolutely one
>>> hundred percent *SURE*, that dropping values is not going to
>>> matter. For that reason, i avoid the zip function like the
>>> plague. I would much rather get an index error, than let an
>>> error pass silently.
>>
>> I also think it's unfortunate that zip silently discards items.
>
> Are you aware of itertools.zip_longest?

I am.

> That makes it easy to build a zip_strict:
>
> def zip_strict(*iterables):
>     pad = object()
>     for t in itertools.zip_longest(*iterables, fillvalue=pad):
>         if pad in t:
>             raise ValueError("iterables of different length")
>         yield t

There are many ways to build a zipstrict. As I said in my own usage of
zip I would almost always want it to raise an error because I almost
always give zip iterables of the same length. However the situation
where zipstrict would benefit is often the kind of situation where
you're not really thinking about the fact that zip truncates. Also if
you only have one zip call in a script it'd be easier (and clearer) to
write:

    if len(x) != len(y):
        raise ValueError

> Unfortunate or not, it seems to be quite common that "zip" (convolution)
> discards items when sequences are of different lengths. I think the usual
> intent is so that you can zip an infinite (or near infinite) sequence of
> counters 1, 2, 3, 4, ... with the sequence you actually want, to get the
> equivalent of Python's enumerate().

That's fine but in the Python code I see zip is much more often used
with equal length finite iterables than with infinite ones. One of the
things I like about Python (especially since I'm learning JS right
now) that you can write your code in the obvious way and then most of
your error checking comes for free: I want loud error messages instead
of corrupted data. I would rather have the potentially bug-prone
zip_shortest be an opt-in itertools feature and zip_strict the default
behaviour for zip. I realise it's not going to change but I think it
would be better.

--
Oscar

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

#104820

On Mon, Mar 14, 2016 at 9:06 AM, Oscar Benjamin
<oscar.j.benjamin@gmail.com> wrote:
> On 14 March 2016 at 14:35, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
>>
>> I would strongly warn anyone against using the zip function
>> unless
> ...
>> I meant to say: absolutely, one hundred percent *SURE*, that
>> both sequences are of the same length, or, absolutely one
>> hundred percent *SURE*, that dropping values is not going to
>> matter. For that reason, i avoid the zip function like the
>> plague. I would much rather get an index error, than let an
>> error pass silently.
>
> I also think it's unfortunate that zip silently discards items. Almost
> always when I use zip I would prefer to see an error when the two
> iterables are not of the same length.

It's sometimes very useful, though. For example on multiple occasions
I've taken advantage of the fact that enumerate(x) is equivalent to
zip(itertools.count(), x). If zip raised an error then that would only
be possible using islice, and then only if the length is known in
advance.

Also, in order for zip to know that the lengths are not equal, it
would have to try to read one additional item from the longer
iterable. That's rather unfortunate if it's an iterator and you're
hoping to catch the exception and then use the rest of the iterator
for something else.

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

#104833

On Monday, March 14, 2016 at 10:17:54 AM UTC-5, Ian wrote:
> It's sometimes very useful [for zip to discard values],
> though. 

The obvious solution is to allow the caller to decide if the
error should be raised, or not. Currently, the caller has no
control over the internals of zip unless he creates a
wrapper, or validates the sequences by hand, before passing 
them into zip. Both of which are violating DRY.

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

#104824

On 14/03/2016 15:06, Oscar Benjamin wrote:
> On 14 March 2016 at 14:35, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
>>
>> I would strongly warn anyone against using the zip function
>> unless
> ...
>> I meant to say: absolutely, one hundred percent *SURE*, that
>> both sequences are of the same length, or, absolutely one
>> hundred percent *SURE*, that dropping values is not going to
>> matter. For that reason, i avoid the zip function like the
>> plague. I would much rather get an index error, than let an
>> error pass silently.
>
> I also think it's unfortunate that zip silently discards items. Almost
> always when I use zip I would prefer to see an error when the two
> iterables are not of the same length. Of course you're not necessarily
> safer with len and range:
>
> a = [1, 2, 3]
> b = 'abcde'
>
> for n in range(len(a)):
>      print(a[n], b[n])
>
> --
> Oscar
>

This is a job for Bi, no, 
https://docs.python.org/3/library/itertools.html#itertools.zip_longest

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#104832

Ian Kelly wrote:

> On Mon, Mar 14, 2016 at 9:06 AM, Oscar Benjamin
> <oscar.j.benjamin@gmail.com> wrote:
>> On 14 March 2016 at 14:35, Rick Johnson <rantingrickjohnson@gmail.com>
>> wrote:
>>>
>>> I would strongly warn anyone against using the zip function
>>> unless
>> ...
>>> I meant to say: absolutely, one hundred percent *SURE*, that
>>> both sequences are of the same length, or, absolutely one
>>> hundred percent *SURE*, that dropping values is not going to
>>> matter. For that reason, i avoid the zip function like the
>>> plague. I would much rather get an index error, than let an
>>> error pass silently.
>>
>> I also think it's unfortunate that zip silently discards items. Almost
>> always when I use zip I would prefer to see an error when the two
>> iterables are not of the same length.
> 
> It's sometimes very useful, though. For example on multiple occasions
> I've taken advantage of the fact that enumerate(x) is equivalent to
> zip(itertools.count(), x). If zip raised an error then that would only
> be possible using islice, and then only if the length is known in
> advance.
> 
> Also, in order for zip to know that the lengths are not equal, it
> would have to try to read one additional item from the longer
> iterable. That's rather unfortunate if it's an iterator and you're
> hoping to catch the exception and then use the rest of the iterator
> for something else.

That's a problem you may run into with the current zip(), too -- unless you 
know that the first is the shortest iterator:

>>> from itertools import count
>>> indices = count()
>>> for items in "abc", "def", "gh":
...    list(zip(indices, items))
... 
[(0, 'a'), (1, 'b'), (2, 'c')]
[(4, 'd'), (5, 'e'), (6, 'f')]
[(8, 'g'), (9, 'h')]

I'm with Oscar here, raising an exception would be the better default; the 
current implementation could have been made available as 
itertools.zip_shortest().

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

#104576

On 11/03/2016 01:56, Martin A. Brown wrote:
>
>>>> for i in range(len(names)):
>>>>      print (names[i],totals[i])
>>>
>>> Always a code smell when range() and len() are combined.
>>
>> Any other way of traversing two lists in parallel?
>
> Yes.  Builtin function called 'zip'.
>
>    https://docs.python.org/3/library/functions.html#zip
>
> Toy example:
>
>    import string
>    alpha = string.ascii_lowercase
>    nums = range(len(alpha))
>    for N, A in zip(nums, alpha):
>        print(N, A)
>
> Good luck,
>
> -Martin
>

Which would usually be written for N, A in enumerate(alpha):

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#104811

On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
> Always a code smell when range() and len() are combined.

I would be careful about dealing in absolutes Mark. 

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

#104812

On Mon, Mar 14, 2016 at 10:07 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
>> Always a code smell when range() and len() are combined.
>
> I would be careful about dealing in absolutes Mark.

I always think people should never use absolutes.

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

#104813

On Mon, 14 Mar 2016 07:07:45 -0700, Rick Johnson wrote:

> On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
>> Always a code smell when range() and len() are combined.
> 
> I would be careful about dealing in absolutes Mark.

a code smell does not necesarily mean the code is wrong, just that it 
warrents investigation as thre is a strog possibility it may be sub-
optimal



-- 
Andries Brouwer wrote:
> Linux is unreliable.
> That is bad.

Since your definition of reliability is a mathematical abstraction 
requiring
infinite storage why don't you start by inventing infinitely large SDRAM
chips, then get back to us ?

	- Alan Cox

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

#104822

On Monday, March 14, 2016 at 9:19:04 AM UTC-5, alister wrote:
> A code smell does not necessarily mean the code is wrong,
> just that it warrants investigation as there is a strong
> possibility it may be sub- optimal

Yes, technically speaking, you're correct. 

But the concept of "code smell" has become something of a
scarlet letter within the programming community. Once you
apply it to someone's code, the stigma becomes very
difficult to rub off -- and not just the "external" stigma
you feel radiating from scornful stares of your peers, but
the "self-imposed" stigma as well. It has become a
derogatory term, and sadly, one that is thrown around much
too carelessly.

Sure, there are legitimate instances where the term should
be applied, but in the case of "zip vs explicit sequence
indexing", the usage of this term could influence a "less
experienced Python programmer", to adopt a very dangerous
habit *SIMPLY* because he does not want to be labeled a "bad
programmer". But the irony is, he may produce worse code by
blindly reaching for his "sequence zipper"!

The zip function is not something you should get in the
habit of using without first considering the consequences of
*EACH SPECIFIC USE-CASE*. Yes, it can be helpful at times,
and yes, it can make code easier to read. But it can also
create subtle bugs. Personally, i choose to avoid it, but
others should make the decision for themselves.

In a nutshell, the zip function is both "elegantly powerful"
and "cunningly destructive". So buyer beware. Because,
Python.org ain't no Walmart folks, and they sure as hell
don't give refunds for sequence members that evaporated into
the ether, after you adopted the bad habit of using zip,
simply because -> "Mark said so"!

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

#104830

On 2016-03-14 15:22, Rick Johnson wrote:
> On Monday, March 14, 2016 at 9:19:04 AM UTC-5, alister wrote:
>> A code smell does not necessarily mean the code is wrong,
>> just that it warrants investigation as there is a strong
>> possibility it may be sub- optimal
>
> Yes, technically speaking, you're correct.
>
> But the concept of "code smell" has become something of a
> scarlet letter within the programming community. Once you
> apply it to someone's code, the stigma becomes very
> difficult to rub off -- and not just the "external" stigma
> you feel radiating from scornful stares of your peers, but
> the "self-imposed" stigma as well. It has become a
> derogatory term, and sadly, one that is thrown around much
> too carelessly.
>
> Sure, there are legitimate instances where the term should
> be applied, but in the case of "zip vs explicit sequence
> indexing", the usage of this term could influence a "less
> experienced Python programmer", to adopt a very dangerous
> habit *SIMPLY* because he does not want to be labeled a "bad
> programmer". But the irony is, he may produce worse code by
> blindly reaching for his "sequence zipper"!
>
> The zip function is not something you should get in the
> habit of using without first considering the consequences of
> *EACH SPECIFIC USE-CASE*. Yes, it can be helpful at times,
> and yes, it can make code easier to read. But it can also
> create subtle bugs. Personally, i choose to avoid it, but
> others should make the decision for themselves.
>
> In a nutshell, the zip function is both "elegantly powerful"
> and "cunningly destructive". So buyer beware. Because,
> Python.org ain't no Walmart folks, and they sure as hell
> don't give refunds for sequence members that evaporated into
> the ether, after you adopted the bad habit of using zip,
> simply because -> "Mark said so"!
>
In other words, code is like cheese. Some of it smells, even when 
there's nothing wrong. :-)

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

#104577

On Thu, Mar 10, 2016 at 4:05 PM, BartC <bc@freeuk.com> wrote:

> Here's a rather un-Pythonic and clunky version. But it gives the expected
> results. (I've dispensed with file input, but that can easily be added
> back.)
>
> def last(a):
>     return a[-1]
>
> def init(a):                 # all except last element
>     return a[0:len(a)-1]
>
> data =["BANANA FRIES 12",    # 1+ items/line, last must be numeric
>        "POTATO CHIPS 30",
>        "APPLE JUICE 10",
>        "CANDY 5",
>        "APPLE JUICE 10",
>        "CANDY 5",
>        "CANDY 5",
>        "CANDY 5",
>        "POTATO CHIPS 30"]
>
> names  = []                        # serve as key/value sets
> totals = []
>
> for line in data:                  # banana fries 12
>     parts = line.split(" ")        # ['banana','fries','12']
>     value = int(last(parts))       # 12
>     name  =  " ".join(init(parts)) # 'banana fries'
>

This could be written as (untested):

name, value = line.rsplit(' ', 1) # line.rsplit(maxsplit=1) should also work
value = int(value)


No need to rejoin the string this way.

See also: https://docs.python.org/3.5/library/stdtypes.html#str.rsplit


>     try:
>         n = names.index(name)      # update existing entry
>         totals[n] += value
>     except:
>         names.append(name)         # new entry
>         totals.append(value)
>
> for i in range(len(names)):
>     print (names[i],totals[i])
>

Chris

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

#105155

Rodrick Brown <rodrick.brown@gmail.com> writes:

> BANANA FRIES 12
> POTATO CHIPS 30
> APPLE JUICE 10
> CANDY 5
> APPLE JUICE 10
> CANDY 5
> CANDY 5
> CANDY 5
> POTATO CHIPS 30
>
> I'm expecting the following output
> BANANA FRIES 12
> POTATO CHIPS 60
> APPLE JUICE 20
> CANDY 20

>>> data =["BANANA FRIES 12",
...        "POTATO CHIPS 30",
...        "APPLE JUICE 10",
...        "CANDY 5",
...        "APPLE JUICE 10",
...        "CANDY 5",
...        "CANDY 5",
...        "CANDY 5",
...        "POTATO CHIPS 30"]
>>> d = {}
>>> for el in data:
...     el = el.split()
...     name, n = ' '.join(el[:-1]), int(el[-1])
...     d[name] = d[name]+n if name in d else n
...
>>> d
{'POTATO CHIPS': 60, 'BANANA FRIES': 12, 'APPLE JUICE': 20, 'CANDY': 20}
>>> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web