Conversation
|
This implementation is highly questionable, as |
|
Absolutely, numpy is about 40% C and C++. |
Many regard Python+numpy (or one of its siblings) as its own language, and that's why I added it as a new case rather than replacing the original. Certainly all the AI/ML world does think that way, so this is grounded in a lot of real world use cases. If you call using numpy an unfair advantage, I question the whole benchmark.Python is a glue- and integration language by design, thus a benchmark which deliberately excludes it strongest virtue isn't fair, and Python shouldn't be there at all. And besides, few of the other solutions can claim total independence of C or its stdlib, there is hardly such a thing as total purity. |
|
Lets ask repo owner to define the scope of this project, as suggested in #98 Everyone is correct with their defined scope, but project will go haywire without some restriction.. |
|
Thanks for the contribution. This PR is interesting, as it probably does yield significant improvement (I didn't run myself to check). However, the idea is not to create the most highly-optimized solution to solve the problem, but to create an implementation that is the "same" across all languages. Also, numpy is not a builtin component of the Python language / standard library. If I allowed for these types of optimizations, then to be fair, I'd have to open up all the other implementations to such optimizations and third-party libraries as well. At this time, I'm not going to take that jump. |
|
Just want to add that under the premise of using numpy this is not optimized at all, but the most true to original version I think possible The nested inner loop still exists with the same operations, it just moved to a library. |
No description provided.