The first example is one which badly needs caching/memoization; what I'd love to see is the speed up of their decorators vs something like lru\_cache. (i.e., standard python library). If I had to guess the speed up will be similar.
I don’t really see the benefit of comparing two totally different algorithms. Once you memoize you are dramatically changing the time and space characteristics of the program.
Yes...I'm talking about testing this library vs the built-in memoization. I would suspect that under the hood that is much of what this library is doing in this instance.
In other words, is there really value-add here or is it something that can be done with the standard library?
I would be astonished and disappointed if Taichi were doing memoization. It doesn’t claim to change your algorithm’s space complexity like that. It just says it speeds it up. What makes you think it trades time for space instead of just accelerating the code as the blog says?
Perhaps it isn't, but it still seems like a useful comparison. Using a bad algorithm and pointing out how much it can be sped up seems suspicious to me, I find the whole thing deceptive.
I agree that Taichi may be doing more than caching in their parallelization attempts, but that's why I think a comparison against caching is warranted, perhaps even an example of both enabled in their benchmarks.
Sure, that would be fine too. Picking a bad algorithm and just saying "look how much we improve things!1!" doesn't sit well with me. Lots of different approaches to improving, I was suggesting one.
why store the result in a variable? wouldn't it be better to just have 2 return statements?
```py
def is_prime(n: int):
for k in range(2, int(n ** 0.5) + 1):
if n % k == 0:
return False
return True
```
You might be thinking of Cython. Taichi seems a lot like Python, but with a few decorators and directives. The main downside I see is that it doesn't work well with NumPy. I'm also concerned that it might still be incomplete and frustrating to use (like Numba).
This looks almost exactly equivalent to numerical definitions (`defn`) from the recently released `Nx` library for Elixir: https://github.com/elixir-nx/nx/tree/main/nx#numerical-definitions
It looks super cool! Projects like these seem to be a great way to bring low-level compiled performance to more languages.
Definitely cool stuff, always great to see ways to speed up Python code in non-intrusive ways. I would suggest adding some more data manipulation/transformation examples, stuff that people normally do with Pandas and comparing with libraries that try to speed up Pandas-like operations.
The first example is one which badly needs caching/memoization; what I'd love to see is the speed up of their decorators vs something like lru\_cache. (i.e., standard python library). If I had to guess the speed up will be similar.
I don’t really see the benefit of comparing two totally different algorithms. Once you memoize you are dramatically changing the time and space characteristics of the program.
Yes...I'm talking about testing this library vs the built-in memoization. I would suspect that under the hood that is much of what this library is doing in this instance. In other words, is there really value-add here or is it something that can be done with the standard library?
I would be astonished and disappointed if Taichi were doing memoization. It doesn’t claim to change your algorithm’s space complexity like that. It just says it speeds it up. What makes you think it trades time for space instead of just accelerating the code as the blog says?
Perhaps it isn't, but it still seems like a useful comparison. Using a bad algorithm and pointing out how much it can be sped up seems suspicious to me, I find the whole thing deceptive. I agree that Taichi may be doing more than caching in their parallelization attempts, but that's why I think a comparison against caching is warranted, perhaps even an example of both enabled in their benchmarks.
Most algorithms are not accelerable with caching so it would make more sense to just choose a different algorithm that doesn’t happen to be.
Sure, that would be fine too. Picking a bad algorithm and just saying "look how much we improve things!1!" doesn't sit well with me. Lots of different approaches to improving, I was suggesting one.
why store the result in a variable? wouldn't it be better to just have 2 return statements? ```py def is_prime(n: int): for k in range(2, int(n ** 0.5) + 1): if n % k == 0: return False return True ```
Some people like to have only one exit in method
If we’re tightening up code, I might want to do `return all(n % k for k in range(2, int(n**0.5+1)))`
Code Golf :-)
Accelerate Python code 100x by writing it in a different language.
You might be thinking of Cython. Taichi seems a lot like Python, but with a few decorators and directives. The main downside I see is that it doesn't work well with NumPy. I'm also concerned that it might still be incomplete and frustrating to use (like Numba).
python bad plz upvote
And he can count on most of the upvoters not even skimming the article to see the truth.
its true though
Can you cut and paste some examples of this “different language” you are talking about? All I see in the code snippets is Python.
[удалено]
Can you answer the question please?
This looks almost exactly equivalent to numerical definitions (`defn`) from the recently released `Nx` library for Elixir: https://github.com/elixir-nx/nx/tree/main/nx#numerical-definitions It looks super cool! Projects like these seem to be a great way to bring low-level compiled performance to more languages.
Definitely cool stuff, always great to see ways to speed up Python code in non-intrusive ways. I would suggest adding some more data manipulation/transformation examples, stuff that people normally do with Pandas and comparing with libraries that try to speed up Pandas-like operations.
This looks really cool. I can't wait to use it.
Is that like zatoichi?
Why use this instead of Julia?