search

JuliaMath / Calculus.jl

Calculus functions in Julia
Other
278 stars 76 forks source link

Using AbstractArray instead of Array in finite_difference_jacobian!() ? #86

Open biogeo opened 8 years ago

biogeo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

johnmyleswhite commented 8 years ago

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