Make chebyshev transforms type stable, make points lazy

[dlfivefifty]

No description provided.

[codecov]

Codecov Report

Merging #114 into master will increase coverage by 1.76%.
The diff coverage is 91.72%.

@@            Coverage Diff             @@
##           master     #114      +/-   ##
==========================================
+ Coverage   79.25%   81.02%   +1.76%     
==========================================
  Files          13       13              
  Lines        1417     1449      +32     
==========================================
+ Hits         1123     1174      +51     
+ Misses        294      275      -19     

Impacted Files	Coverage Δ
src/FastTransforms.jl	100.00% <ø> (ø)
src/chebyshevtransform.jl	92.94% <91.48%> (+15.56%)	⬆️
src/clenshaw.jl	98.07% <100.00%> (-0.04%)	⬇️
src/clenshawcurtis.jl	100.00% <100.00%> (ø)
src/fejer.jl	100.00% <100.00%> (ø)

---

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 2a2c5a3...40a6276. Read the comment docs.

[dlfivefifty]

@MikaelSlevinsky Any opinions? I decided to make the code type-stable, mostly because the Julia compiler is a lot faster when it doesn't need to deal with un-inferred code. So this will help down-stream packages compile time.

I also removed support for transforming empty vectors, or for just single-point Chebyshev of the 2nd kind. I'm not sure if the latter is actually used anywhere anymore. For empty vectors, this can probably be done with an extra check in ApproxFun.

There are alternative ways to work around this if we decide empty vectors is important to support.

[MikaelSlevinsky]

How is it an improvement to remove the empty array checking? Some folks might be using the points/transforms for modified moment-based quadrature independent of JuliaApproximation. If we don’t want the execution case, then maybe put an assertion in the plan creation?

[dlfivefifty]

For the 1st kind transforms: its not an improvement, but is because FFTW throws errors iwth empty arrays

julia> dct(Float64[])
ERROR: FFTW could not create plan

So then we can't create a plan. This gives the following options:

1. Make the field plan::Union{Nothing,FFTW.r2rFFTWPlan{...}}. This should have no penalty, and still be type-stable via

isnothing(F.plan) ? copy(x) : something(F.plan) * copy(x)

But it slightly complicates things.
2. Don't initialise F.plan. This means F.plan gives an undefined error. So the above becomes:

!isdefined(F, :plan) ? copy(x) : F.plan * copy(x)

3. Add a parameter n::Int and check if n = 0.
4. Just throw an error. This is as you say annoying, but consistent with FFTW.

Any preference between the 4 options?

For the 2nd kind transform, I don't think we want it the check on n == 1 makes getindex slower for ChebyshevGrid{2}. And it's not clear to me that we should making a definition when its not really defined, so throwing an error is probably the right thing to do here.

[dlfivefifty]

If we don’t want the execution case, then maybe put an assertion in the plan creation?

This assertion already happens in FFTW.

[MikaelSlevinsky]

Ok you can decide. (I won’t be able to merge this week.)