Using AbstractArray instead of Array in finite_difference_jacobian!() ?

[biogeo]

I attempted to use curve_fit from LsqFit.jl on data stored in a DataFrame column, as in curve_fit(model, df[:x], df[:y], p0). This produced the following error:

LoadError: MethodError: `finite_difference_jacobian!` has no method matching finite_difference_jacobian!(::Function, ::Array{Float64,1}, ::DataArrays.DataArray{Float64,1}, ::Array{Float64,2}, ::Symbol)
Closest candidates are:
  finite_difference_jacobian!{R<:Number,S<:Number,T<:Number}(::Function, ::Array{R<:Number,1}, !Matched::Array{S<:Number,1}, ::Array{T<:Number,N}, ::Symbol)
  finite_difference_jacobian!{R<:Number,S<:Number,T<:Number}(::Function, ::Array{R<:Number,1}, !Matched::Array{S<:Number,1}, ::Array{T<:Number,N})

Of course this is easily resolved by explicitly converting the inputs to Arrays, but it's a bit cumbersome. I'm pretty new to Julia and its type system, but from looking at the code there's no obvious reason to me why finite_difference_jacobian! couldn't work with its signature changed to use AbstractArray and AbstractVector, relieving the need to convert DataArrays. Is this reasonable? If there's no reason not to do it, I can try to test it out and make a pull request when I have time.

[johnmyleswhite]

Generalizing this would make sense. It unfortunately will mean that the code tries to write into immutable AbstractArray objects (e.g. Range), but the increase in generic programming probably makes up for the decrease in useful compile-time errors.

[biogeo]

Hm, interesting point. Julia doesn't offer something like a AbstractMutableArray type?

[johnmyleswhite]

No, that would require traits or multiple inheritance -- neither of which exist at the moment.