fit fails with BigFloat: MethodError: no method matching _fit

[nsajko]

When I do:

const F = BigFloat
x = F[0, 1, 2, 3]
y = F[1, 2, 3, 4]
fit(x, y, 1)

I get:

ERROR: MethodError: no method matching svd!(::Array{BigFloat,2}; full=false, alg=LinearAlgebra.DivideAndConquer())
Closest candidates are:
  svd!(::LinearAlgebra.AbstractTriangular; kwargs...) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/triangular.jl:2672
  svd!(::StridedArray{T, 2}; full, alg) where T<:Union{Complex{Float32}, Complex{Float64}, Float32, Float64} at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/svd.jl:93
  svd!(::StridedArray{T, 2}, ::StridedArray{T, 2}) where T<:Union{Complex{Float32}, Complex{Float64}, Float32, Float64} at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/svd.jl:363 got unsupported keyword arguments "full", "alg"
  ...
Stacktrace:
 [1] svd(::Array{BigFloat,2}; full::Bool, alg::LinearAlgebra.DivideAndConquer) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/svd.jl:158
 [2] pinv(::Array{BigFloat,2}; atol::Float64, rtol::BigFloat) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/dense.jl:1356
 [3] pinv(::Array{BigFloat,2}) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/dense.jl:1335
 [4] _fit(::Type{Polynomial}, ::Array{BigFloat,1}, ::Array{BigFloat,1}, ::Int64; weights::Nothing, var::Symbol) at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:115
 [5] #fit#59 at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/polynomials/standard-basis.jl:336 [inlined]
 [6] #fit#17 at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:102 [inlined]
 [7] fit(::Array{BigFloat,1}, ::Array{BigFloat,1}, ::Int64) at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:102
 [8] top-level scope at REPL[6]:1
 [9] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

But if I do:

X = [0, 1, 2, 3]
Y = [1, 2, 3, 4]
fit(X, Y, 1)

I get the expected (if slightly inaccurate) result:

Polynomial(1.0 + 1.0000000000000002*x)

This is Julia 1.5.3.

[nsajko]

Somewhat similarly, fit(ChebyshevT, x, y, 1) produces:

ERROR: MethodError: no method matching _fit(::Type{ChebyshevT}, ::Array{BigFloat,1}, ::Array{BigFloat,1}, ::Int64, ::Nothing, ::Symbol)
Closest candidates are:
  _fit(::Type{var"#s45"} where var"#s45"<:AbstractPolynomial, ::AbstractArray{T,1}, ::AbstractArray{T,1}, ::Integer; weights, var) where T at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:104
  _fit(::Type{var"#s46"} where var"#s46"<:AbstractPolynomial, ::AbstractArray{T,1}, ::AbstractArray{T,1}) where T at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:104
Stacktrace:
 [1] fit(::Type{ChebyshevT}, ::Array{BigFloat,1}, ::Array{BigFloat,1}, ::Int64; weights::Nothing, var::Symbol) at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:80
 [2] fit(::Type{ChebyshevT}, ::Array{BigFloat,1}, ::Array{BigFloat,1}, ::Int64) at /home/nsajko/.julia/packages/Polynomials/w2QmG/src/common.jl:80
 [3] top-level scope at REPL[5]:1
 [4] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

[nsajko]

Just tried installing Polynomials from master, and it seems that fit(x, y, 1) now works OK, but the issue with fit(ChebyshevT, x, y, 1) persists.

[jverzani]

Thanks for the report!

[AndiMD]

Possibly related, Unitful.jl compatibility:

using Polynomials, Unitful
fit([1.0,2.0,3.0,4.0].*u"m", [6.0,4.0,7.0,7.5].*u"m",2)

ERROR: DimensionError

[jverzani]

Yeah, this is a different issue, and I'm not sure there is a proper fix. For fitting, a Vandermonde matrix is constructed with columns which would need units of u^0, u^1, ...,u^n. So currently there is an error as we type that matrix by eltype(x).

Some discussion on the issue of using units with matrices can be found here:
PainterQubits/Unitful.jl#46

with the simplest recommendation being to strip the units and add them back, as needed.

[jakewilliami]

@jverzani @AndiMD, I have submitted a new issue for this Unitful compatibility so that we can close this issue. See #306