Thread by @mathsppblog

I gave you a Python 🐍 challenge 🏆...

You delivered 💪!

This thread 🧵 will review some of your `argmax` implementations.

I'll also tell you what's good ✅ and bad ❌ about them.

I'll also tell you which one I think is the best, most Pythonic ✨ one.

Let's go 🚀

The `argmax` function returns the index of the maximum element of the argument.

So, why don't we write this solution?

Compute the maximum, and then use `.index` to get its index! 👇

But there are two issues here...

Can you see them? 👀

👉 first issue is that it traverses the argument twice;
(once to get the max, one more time to find its index)

👉 second issue is that it assumes the argument has a method `.index`, which might not be the case.

However, let's try and fix the first problem first...

If we only want to go over the argument once, then we can use a `for` loop to keep track of the maximum and its index!

Here's how you could write it 👇

This goes over the argument only once ✅

But if you've been paying attention to my tweets, you can improve it right away:

Instead of using `range(len(...))` which is almost always an anti-pattern ❌...

We can use `enumerate` 👇

This cleans up the code a little bit ✅

And it has another interesting effect...

By using `enumerate`, we no longer need to index into the argument to fetch the elements ✅

Why is this good?

Because it means we can use MORE types of iterables as input.

But for this to be true, we need to get rid of the initial indexing in the first line 👇

By using `float("-inf")`, we initialise the `mx` variable to something that will always be smaller than whatever is in the argument.

This means that the first iteration of the loop will *always* update the `mx` and `idx` variables.

Now, there's another fundamental difference between this solution and the previous ones.

The previous ones threw an error when the argument was empty.

This one returns -1 👇

Empty sequences do NOT have an argmax, so we want our function to raise an error when that happens.

How can we do this..?

Remember when we initialised `mx` with `lst[0]`?

We can do a “similar” thing, but that works on all types of iterables!

We just need to use `next` 👇

By using `next` on the iterator over the argument, we get a `StopIteration` error if the argument is empty.

Now, callers of the `argmax` function can know if it failed or not 👇

We are at a pretty good point, by now.

We have a function that works well, for a variety of input types.

Can we make it better..?

I say we can!

Let's talk about dictionary ordering 😁

Not `dict`.

Dictionary, as in, the book with the words!

Tuples are ordered like dictionaries; did you know that?

If you have a pair `(fst, snd)`, then the tuple is ordered by the value in `fst`.

If it matches the first element of the other pair, then the second element is used as a tie-breaker 👇

Now, this is a technique I have seen often:

Let's put both things together:

👉 we take the values that define the ordering (the values of the argument);

👉 we take the values that we want to return (the indices);

and we zip them together.

Then, we call `max` 😊 👇

Again, the problem here is that we are using `range(len(...))`, which is not ideal ❌

Why?

Because not all iterables have a length.

Sadly, `enumerate` builds the tuples in the wrong order (first indices, then elements)...

But we could flip them! 👇

But now...

We have the *initial problem* again ❌

We are going over the argument twice!

Once to build the enumeration with the correct ordering.

And another time to find the maximum!

Thankfully, we can fix this 😊

How?

Easy!

The `max` function accepts an optional argument called `key`.

We can use the `key` argument to change what/how the elements are compared within max!

For example, if `key` is the `neg` operator (the operator that negates numbers) we can use `max` to compute the `min` 👇

What we have to do is the following:

Use the regular enumeration we get.

But use `key` to tell `max` to look at the values (the second element of the tuple) instead of the indices!

👇

We can do this with a little `lambda` 👇

Beautiful 🔥

But...

Let's make it just a little bit more pretty!

The `operator` module has an operator that renders our lambda useless!

Also, if we are not using `mx`, no need to assign to it, we can just use a sink variable.

In the end, this is what we get 👇

What a beautiful solution:

✅ errors on empty sequences
✅ traverses argument only once
✅ makes good use of built-ins
✅ leverages the `key` argument from `max`
✅ accepts a wide range of argument types

Do you like this solution?

I do 😁

Thank you to everyone who participated!

For reference, here is the original challenge, where you will find people who proposed really great solutions 👇

Do you enjoy these challenges?

Because I do 😂

Follow @mathsppblog for more content like this!

https://twitter.com/mathsppblog/status/1455982863816474627