Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pythonic monotonic

nedbatchelder.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Pythonic monotonic

#41

Post by alecst »

benburk wrote: post #37
alecst wrote: post #33

Gave it a try. I enjoy writing readable code but it's hard to judge one's own work. What do you all think? def monotonic(arr): """ Turn an unordered list into a list of lists of monotone sequences. All sequences are converted to increasing. Start reading the list in chunks of two to decide if we're increasing or not. """ if len(arr) = sub_arr[0] for m in gen_arr: if m >= sub_arr[-1] and increasing \ or m = m) if n el…

Fails for [1, 1, 2, 3, 3, 2, 1, 1] -> [[1, 1, 2, 3, 3], [1, 2], [1, 2], [1]]

Thanks. I was inconsistent in my use of >= and >. Making them consistent has fixed this edge case.

Re: Pythonic monotonic

#42

Post by alecst »

xorcist wrote: post #35
alecst wrote: post #33

Gave it a try. I enjoy writing readable code but it's hard to judge one's own work. What do you all think? def monotonic(arr): """ Turn an unordered list into a list of lists of monotone sequences. All sequences are converted to increasing. Start reading the list in chunks of two to decide if we're increasing or not. """ if len(arr) = sub_arr[0] for m in gen_arr: if m >= sub_arr[-1] and increasing \ or m = m) if n el…

This is the easiest one to read, thanks for that. If the intention of posting it was an invitation for review, here's a quick one. Making the first entry a special case is probably a good idea, but it must also take into account when the first sub_arr is also the only: >>> monotonic([1, 2]) [] There's also the fact that equality is considered a valid increase both not a valid decrease. One might expect that either it…

Thanks. That was absolutely my intention and I'm grateful you replied. I amended this solution by changing strict > to >=, which seems to have fixed some of the problematic behavior.

Re: Pythonic monotonic

#43

Post by neolog »

cs702 wrote: 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.

No. Once you've internalized the idioms of the language, it becomes obvious that TFA's preferred solution is in the Python style and the other is not.

Re: Pythonic monotonic

#44

Post by benburk »

alecst wrote: post #41
benburk wrote: post #37

Earlier quoted context omitted.

Fails for [1, 1, 2, 3, 3, 2, 1, 1] -> [[1, 1, 2, 3, 3], [1, 2], [1, 2], [1]]

Thanks. I was inconsistent in my use of >= and >. Making them consistent has fixed this edge case.

Also fails for

  [3, 3, 2, 2, 1, 1] -> [[3, 3], [2, 2], [1, 1]]
Here's my solution https://news.ycombinator.com/item?id=28170735

Re: Pythonic monotonic

#45

Post by zzzeek »

Here's two from me which just try to replicate the results of the original, it doesn't accommodate for values being the same or anything like that. This took me well over half an hour, I got more stuck on the first one trying to reduce the logic than I'd prefer to have, and I would have failed any job interview by now because I'm someone that's known to supposed to be "smart", but these things are always difficult for me to focus on.

    def mono_runs_pythonic_two(seq):
        curr = []

        result = []
        prev = None
        is_decreasing = None

        for elem in seq:
            if prev is not None:
                if (
                    elem

Re: Pythonic monotonic

#46

Post by wmanley »

Here's my solution:

    def monotonic(it):
        run = []
        for this in it:
            if not run:
                pass
            elif run[0]
It's short, is a single function, doesn't rely on fancy features (unless you consider subscripting with `-1` or using `yield` fancy). It will work on arbitrary iterators, the input doesn't need to be a sequence. It passes all of eesmith's tests. It uses memory proportional to the longest run in the sequence.

The trick I've applied is that we don't explicitly keep track of whether we're increasing, decreasing or undecided. Instead we check the run in progress.

Re: Pythonic monotonic

#47

Post by mlochbaum »

transfire wrote: post #38

How now APL?

Here's my BQN solution. It uses shift functions « and Group ⊔ (links below) where APL would use windowed reduction (e.g. 2≠/d) and partitioned enclose (r←b⊂𝕩) so it's slightly different.

    MonoRuns ← {
      d ←
Run online: https://mlochbaum.github.io/BQN/try.html#code=TW9ub1J1bnMg4o...

https://mlochbaum.github.io/BQN/doc/shift.html

https://mlochbaum.github.io/BQN/doc/group.html

Re: Pythonic monotonic

#48

Post by eesmith »

wmanley wrote: post #46

Here's my solution: def monotonic(it): run = [] for this in it: if not run: pass elif run[0] It's short, is a single function, doesn't rely on fancy features (unless you consider subscripting with `-1` or using `yield` fancy). It will work on arbitrary iterators, the input doesn't need to be a sequence. It passes all of eesmith's tests. It uses memory proportional to the longest run in the sequence. The trick I've ap…

Nice! It passes all of my tests, including cross-comparison with my code on random sequences. And it's delightfully clear.

Re: Pythonic monotonic

#49

Post by eesmith »

benburk wrote: post #44
alecst wrote: post #41

Earlier quoted context omitted.

Thanks. I was inconsistent in my use of >= and >. Making them consistent has fixed this edge case.

Also fails for [3, 3, 2, 2, 1, 1] -> [[3, 3], [2, 2], [1, 1]] Here's my solution https://news.ycombinator.com/item?id=28170735

And for [1]; the "return sorted(arr)" needs to be "return [sorted(arr)]".

Re: Pythonic monotonic

#50

Post by eesmith »

mlochbaum wrote: post #47
transfire wrote: post #38

How now APL?

Here's my BQN solution. It uses shift functions « and Group ⊔ (links below) where APL would use windowed reduction (e.g. 2≠/d) and partitioned enclose (r←b⊂𝕩) so it's slightly different. MonoRuns ← { d ← Run online: https://mlochbaum.github.io/BQN/try.html#code=TW9ub1J1bnMg4o... https://mlochbaum.github.io/BQN/doc/shift.html https://mlochbaum.github.io/BQN/doc/group.html

Neat link to working code!

"⟨3, 2, 1⟩" generates "⟨ 2 1 3 ⟩". I expected "⟨1, 2, 3⟩".

Post reply on HN