Almost, but return a tuple instead of an array to avoid array allocation.
Tight now, cov allocates temporary arrays for the demeaned vectors but that
should probably be changed later anyway.
On Monday, May 23, 2016 at 2:50:34 AM UTC-4, Gabriel Gellner wrote:
>
> So I am not able to get such a dramatic speed up. Do you mean something
> beyond:
>
> function linreg2{S <: Number, T <: Number}(x::AbstractArray{S},
> y::AbstractArray{T})
> mx = mean(x)
> my = mean(y)
> b1 = Base.covm(x, mx, y, my)/varm(x, mx)
> b0 = my - b1*mx
> return [b0, b1]
> end
>
> Which I find speeds up around 3x, or do you mean writing a custom cov
> function that is smarter about memory? (I am returning an array as I like
> to be able to do vector math on the coefficients ... but if I return a
> tuple it isn't much faster for me)
>
> On Sunday, May 22, 2016 at 8:37:43 PM UTC-7, Andreas Noack wrote:
>>
>> 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.
>>>
>>
