Live data from Hacker News

Pythonic monotonic

nedbatchelder.com

21–30 of 64 posts

Re: Pythonic monotonic

#21
post #15

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".

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

#22
post #15

Earlier 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?

[deleted]

Re: Pythonic monotonic

#23

It'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.

Yeah, though at this point it would help to be a bit more explicit about what we even want. The most consistent interpretation I can come up with as follows:

- 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

#24
post #2

I 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…

[deleted]

Re: Pythonic monotonic

#25
FWIW, here is my solution. I think it is grokable and does not rely on one knowing complex python, I think even someone without Python knowledge would understand what is going on:

    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

#26
post #11

Choosing 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

Re: Pythonic monotonic

#27

The 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()`

What's wrong with iter and next?

Re: Pythonic monotonic

#28
post #18

Earlier 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.

[deleted]

Re: Pythonic monotonic

#29

The 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()`

It's really hard to do anything in python without `iter` and `next` - understanding iterators and `iter` in particular is table stakes with python.

Re: Pythonic monotonic

#30
post #11

Choosing 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

LOL. That cartoon is particularly funny because it is rather insightful about the nature of such disagreements.
Post reply on HN