I don't think that linreg has received much attention over the years. Most
often it is almost as simple to use \. It you take a look at linreg then
I'd suggest that you try to write in terms of cov and var and return a
tuple instead of an Array. That will speed up the computation already now
and with an unallocating cov, I see 20x speed up over linreg for n=10000
and Float64 element on 0.4.
On Saturday, May 21, 2016 at 2:33:20 PM UTC-4, Gabriel Gellner wrote:
>
>
>
> I think it's an error. The method definition should probably just be:
>>
>> linreg{T<:Number,S<:Number}(X::AbstractVector{T}, y::AbstractVector{S}) =
>> [ones(T, size(X,1)) X] \ y
>>
>> which will allow it to work for X and y of different types.
>>
>> Is using the more specific typing (<: Number) the current best practices?
> I notice a lot of the methods in linalg/generics.jl just check for
> AbstractVectors etc without requiring numeric types even though that would
> be the more correct check.
>
>
>> A PR (pull request) with a patch and a test case would be most welcome.
>>
> On it! Taking me a bit of sweat to figure out the build process and github
> stuff but once I have that all sorted a PR will be submitted. Thanks for
> the quick response.
>
