Support matrix chebyshev transforms, matrix coefficients in Clenshaw

[dlfivefifty]

This (partially) supports "regions" in Chebyshev transform. Also supports truely non-allocating transforms:

julia> X = randn(n,n); Y = similar(X); P = plan_chebyshevtransform(X); @time mul!(Y, P, X);
  0.008426 seconds

[codecov]

Codecov Report

Merging #152 (062f15e) into master (ef00b65) will increase coverage by 1.32%.
The diff coverage is 97.89%.

@@            Coverage Diff             @@
##           master     #152      +/-   ##
==========================================
+ Coverage   80.11%   81.44%   +1.32%     
==========================================
  Files          13       12       -1     
  Lines        1775     1902     +127     
==========================================
+ Hits         1422     1549     +127     
  Misses        353      353              

Impacted Files	Coverage Δ
src/chebyshevtransform.jl	96.58% <97.66%> (+1.53%)	⬆️
src/clenshaw.jl	98.83% <100.00%> (+0.56%)	⬆️
src/FastTransforms.jl

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef00b65...062f15e. Read the comment docs.

[dlfivefifty]

@MikaelSlevinsky This adds support for regions, e.g., chebyshevtransform(X, 1) will apply the Chebyshev transform on each column where X is a matrix. Note this is 3x (or as much as 300x...) faster than using vector transforms (JuliaMath/FFTW.jl#216).

I also improved the out-of-place transforms, adding support for mul!(y, P, x). It turns out (see that issue) that out-of-place is much faster than in-place as in-place is allocating.

The matrix chebyshevutransform isn't quite finished but I'll wait until I try to use that (fairly straightforward to add at this point).

Let me know if you have any comments in the next day or so, otherwise I'll merge and tag.

[dlfivefifty]

If you are curious why I'm working on this: I'm in the process of making matrix function expansion fast: JuliaApproximation/ClassicalOrthogonalPolynomials.jl#77

[MikaelSlevinsky]

This looks great. The coverage increases (and the tests are almost the same), so even if I haven't looked it over line by line I think it's good.

Wondering whether or not you think this should eventually find its way into the C library. Not a question of efficiency outright but rather based on the fact that they're all diagonal scalings of FFTW plans (and won't change until Chebyshev polynomials are renamed) and that it cuts down pre-compilation.

[MikaelSlevinsky]

Is there a reason 1.3 is dropped?

[dlfivefifty]

Yes: it's type inference isn't clever enough for the kindtuple stuff

[dlfivefifty]

Wondering whether or not you think this should eventually find its way into the C library. Not a question of efficiency outright but rather based on the fact that they're all diagonal scalings of FFTW plans (and won't change until Chebyshev polynomials are renamed) and that it cuts down pre-compilation.

I think the design could be refined more before committing to that. E.g. I don't think chebyshevutransform needs to be its own thing as it could be incorporated in to kind.

[MikaelSlevinsky]

Right, there should probably be a basiskind and a pointkind.

[MikaelSlevinsky]

If the OP expansion coefficients are matrices, should the resulting summation sum(p[k-1](x)c[k] for k in 1:n) not be a matrix? In what sense should it return a vector?

[dlfivefifty]

They aren't a matrix, is a matrix whose columns are coefficients

It's the same logic that A[1,1:5] returns a vector