I’m not a python dev. Can anyone brrakdown the first code? I’m a bit confused
I am a Python dev of too many years and I neither could nor would want to. It's one of those penis measuring contest as interview question questions. I like the concept of "furrowed-brow code".
Pythonic monotonic
21–30 of 64 posts
Re: Pythonic monotonic
#22Earlier quoted context omitted.
I am a Python dev of too many years and I neither could nor would want to. It's one of those penis measuring contest as interview question questions. I like the concept of "furrowed-brow code".
i think thats the point the article is making? don't just use a tool or lib, but understand how generators work. that is more pythonic. am i right?
Re: Pythonic monotonic
#23It's kind of interesting how we're discussing which solution is most pythonic, but nobody has managed to write a solution which actually works. This is partially because the problem is slightly ambiguous, but even then nobody seems to have written a version that works for any of the possible interpretations of the problem. Most solutions suffer from a combination of any of the following problems: - Not using strict v…
This is a really good point. I am very big on making code Pythonic, but I always tell junior developers to get the thing to work first. Once it works, we can re-write it with the advantage of hindsight. The hard part is getting people to tell the manager it's going to be a few days longer even though it's already working.
- Partition the list into strictly monotonic runs (either increasing or decreasing)
- Reverse the decreasing runs.
But writing a version that is entirely bug free turns out to be surprisingly tricky.
You also need to be careful about how you allow runs to be split up. You can't require each run to be maximally large because then [1,2,3,4,3,2,1] must be partitioned into overlapping runs. You also can't just require the list to be partition into any set of monotonic runs, because then [[1],[2],[3],[4]] is a valid partition of [1,2,3,4]. This is especially a problem when you allow runs that aren't strictly monotonic.
Re: Pythonic monotonic
#24I like how the first one uses groupby() but I don't like the definition of "Monotonic" inside of the module, nor the name, nor returning a list instead of a generator. I also prefer functions instead of callable instances. One alternative to use a function closure instead of a class: import math import itertools def compare_with_previous(): prev = -math.inf def compare(value): nonlocal prev test = prev Another is to…
Why is [2, 1, 1] not being reversed? Since you do call reverse(), I'm not even sure what the bug is on first inspection, which is not a good sign! Edit: I believe the bug is that the code assumes the first sequence is increasing. It seems a bug carried by all these variants that starts by declaring a -inf variable at the top. IMO, the problem is trying to find a solution in one's head, then trying to write Pythonic c…
Re: Pythonic monotonic
#25 def order_values(value, prev):
"""
Compare value and prev, returns, -1, 0, 1
depending on the relative ordering.
"""
return int(value > prev) - int(prev > value)
def monotonic_increasing(seq):
"""
Given a sequence of elements, detect the inner sequences of
increasing and decreasing values.
Return a list of list of values of these inner sequences,
but with the decreasing ones reversed to be increasing.
"""
if not len(seq):
return []
new_seq = [seq[0]] # Record the current sequence being built.
seq_of_seq = [new_seq] # The sequence of sequences to return.
seq_of_order = [0] # Record the sequences ordering (0 for unknown).
for value in seq[1:]:
value_order = order_values(value, new_seq[-1])
if value_order == seq_of_order[-1] or not value_order or not seq_of_order[-1]:
new_seq.append(value)
# If sequence order was unknown, adopt value order.
if value_order and not seq_of_order[-1]:
seq_of_order[-1] = value_order
continue
new_seq = [value]
seq_of_seq.append(new_seq)
seq_of_order.append(0)
# Reverse decreasing sequences.
for seq, order in zip(seq_of_seq, seq_of_order):
if order Re: Pythonic monotonic
#26Choosing either implementation as "more Pythonic" than the other feels to me like choosing tabs over spaces, or vice versa: https://www.youtube.com/watch?v=V7PLxL8jIl8 i.e., it's a matter of personal preference -- except that, as gizmo686 points out below, as of Python 3 tabs are now, officially, considered more Pythonic.
Re: Pythonic monotonic
#27The first case is clearer to me than the second, by quite away. Iter, next? Opaque testing of [-1] values? Adjusting a few identifier names, the first actually describes what's going on. Eg., rename `Monotonic()` to `CurrentLtLast()`
Re: Pythonic monotonic
#28Earlier quoted context omitted.
Why is [2, 1, 1] not being reversed? Since you do call reverse(), I'm not even sure what the bug is on first inspection, which is not a good sign! Edit: I believe the bug is that the code assumes the first sequence is increasing. It seems a bug carried by all these variants that starts by declaring a -inf variable at the top. IMO, the problem is trying to find a solution in one's head, then trying to write Pythonic c…
Yes, the -inf approach gives the wrong answer. It's seems clever at first, but induces an invalid mental assumption.
Re: Pythonic monotonic
#29The first case is clearer to me than the second, by quite away. Iter, next? Opaque testing of [-1] values? Adjusting a few identifier names, the first actually describes what's going on. Eg., rename `Monotonic()` to `CurrentLtLast()`
Re: Pythonic monotonic
#30Choosing either implementation as "more Pythonic" than the other feels to me like choosing tabs over spaces, or vice versa: https://www.youtube.com/watch?v=V7PLxL8jIl8 i.e., it's a matter of personal preference -- except that, as gizmo686 points out below, as of Python 3 tabs are now, officially, considered more Pythonic.
https://flinhong.github.io/images/201607/tabs-spaces.jpg