feat(python): enhanced Series.dot method and related interop

[alexander-beedie]

Added @ matrix multiplication operator support for Series, along with implicit coercion for types that make sense (1D lists and/or numpy arrays).

import numpy as np
import polars as pl

s1 = pl.Series("a", [1, 2, 3])
s2 = pl.Series("b", [4.0, 5.0, 6.0])

for dot_result in (
    s1.dot(s2),                # << existing
    s1 @ s2,                   # << new
    s1 @ [4, 5, 6],            # << new
    s1 @ np.array([4, 5, 6]),  # << new
):
    assert dot_result == 32

Reference: (numpy behaviour)

np.array([1, 2, 3]) @ np.array([4, 5, 6]) 
# 32
np.array([1, 2, 3]) @ [4, 5, 6]
# 32

Also:

Slightly more informative error messages on failed Series/DataFrame init, for example:

• Before: "DataFrame constructor not called properly."
• After: f"DataFrame constructor called with unsupported type; got {type(data)}"

---

I admit to being tempted to try proper 2D matrix multiplication support without taking on additional dependencies, but getting that fast is non-trivial! (There is a reason BLAS exists :). So, for now, just adding @ support for Series.

[alexander-beedie]

Odd CI error at the moment; will come back to this tomorrow (everything else looks good).

package ‘data.table’ is not available (for R version 3.5.3) 
[22](https://github.com/pola-rs/polars/actions/runs/3396784772/jobs/5648235387#step:7:23)
Error: Error in library(data.table) : there is no package called ‘data.table’

[ritchie46]

Odd CI error at the moment; will come back to this tomorrow (everything else looks good).

Yes, I think our benchmark script is dead. :(

I admit to being tempted to try proper 2D matrix multiplication support without taking on additional dependencies, but getting that fast is non-trivial! (There is a reason BLAS exists :).

Yes, this is something we should do parallel on the Rust side. I certainly don't think we should beat BLASS. But we must be cheaper than copying to numpy + BLAS + copying back.

That sounds more doable. :)

[alexander-beedie]

That sounds more doable. :)

Heh; I knocked up a trivial baseline out of morbid curiosity to see how far away the naive implementation is from the optimised one - only 250x slower, haha... "The only way forward is up..." :)