Functional programming like this can be great for minimizing lines of code. But it is also great for making your brain spin. Here is how I would initially write this (if I were fancy, I would use the Sieve of Eratosthenes):
Can we collapse this into fewer lines of code? Certainly, (the functional style already showed that) we can. One thing to realize is that lines 3-6 can be replaced with an any call:
At this point, the code is structured such that we can use a list comprehension (or generator expression). Alternatively,
we could parameterize the code into a function and convert it to a generator. Let's see the list comprehension:
Let's make it into a function:
Recognizing that the function is accumulating, we can convert it into a generator by replacing the .append call with yield, or converting the list comprehension version into a generator expression:
What code do I prefer? I try to focus on making readable code. While I understand comprehensions, I don't favor complex comprehensions and I would probably write out the for loop. Just because you can write less lines of code doesn't mean that you always should.
Thanks for reading!
Feel free to share if you learned something and follow me for more Python insights. π
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
XGBoost is a popular machine learning algorithm that provides excellent performance out of the box for various types of machine learning problems, including regression and classification.
However, one common issue with XGBoost is overfitting, leading to poor generalization and inaccurate predictions on new data.
Overfitting occurs when the model learns the training data too well, including the noise and randomness, and cannot generalize to new data.
You can use various techniques to determine whether an XGBoost model is overfitting, including cross-validation, regularization, and monitoring the training and validation errors.
Many know how to use them, but few can write them.
These are tricky because nested functions make our brains hurt.
Here are some hints for grokking them.
1/
In short, decorators allow you to inject orthogonal behavior before or after a function is executed.
But my favorite decorator definition is related to the construction and will help you easily create them: A callable that takes a callable and returns a callable.
2/
What do I mean by "orthogonal"?
A function should do one thing. If you want to add caching or logging, it really isn't related to the function (and could be applied to multiple functions). It is "orthogonal" behavior.
3/
Many know how to use them, but few can write them.
These are tricky because nested functions make our brains hurt.
Here are some hints for grokking them.
1/
In short, decorators allow you to inject orthogonal behavior before or after a function is executed.
But my favorite decorator definition is related to the construction and will help you easily create them: A callable that takes a callable and returns a callable.
2/
What do I mean by "orthogonal"?
A function should do one thing. If you want to add caching or logging, it really isn't related to the function (and could be applied to multiple functions). It is "orthogonal" behavior.
3/
Many know how to use them, but few can write them.
These are tricky because nested functions make our brains hurt.
Here are some hints for grokking them.
1/
In short, decorators allow you to inject orthogonal behavior before or after a function is executed.
But my favorite decorator definition is related to the construction and will help you easily create them: A callable that takes a callable and returns a callable.
2/
What do I mean by "orthogonal"?
A function should do one thing. If you want to add caching or logging, it really isn't related to the function (and could be applied to multiple functions). It is "orthogonal" behavior.
3/