Luca Palmieri

I would consider both of them to be out of scope for this project - it's already incredibly broad as it is right now :sweat_smile: I'd love to see something...

Hi @Ricocotam! I have read the blog post when it came out and I found it quite interesting as well. Nonetheless, I don't think you can avoid index-based tensor access...

Give me dataframes in Rust and I can slowly start to use it for work :heart:

Going through all of these issues, I have starting to think at broader challenges which should probably fall under `ndarray`'s umbrella or are relevant to the project: - [masked arrays](https://docs.scipy.org/doc/numpy-1.15.0/reference/maskedarray.generic.html)...

The front-end is what I dreamed I could have when I started to use `np.einsum` back in the days - quite cool @oracleofnj! Parsing the output correctly is definitely the...

The only other compensated summation algorithm that comes to my mind is [Kahan's summation algorithm](https://en.wikipedia.org/wiki/Kahan_summation_algorithm), but its performance overhead is not negligible, hence I wouldn't provide it as a default...

Running these benchmarks I get: ``` name master ns/iter branch ns/iter diff ns/iter diff % speedup contiguous_sum_1e2 16 16 0 0.00% x 1.00 contiguous_sum_1e4 1,223 1,415 192 15.70% x 0.86...

> We can specialize on integer types to avoid pairwise summation for them if that turns out to provide a significant performance benefit. However, the general case should be pairwise,...

Ok, I'll make the required changes to have a uniform behaviour. One observation: out of curiosity, I have repeated the benchmarks on a different machine (my desktop has a AMD...

I addressed all your observations @jturner314 :+1: