Export dotu with generic fallbacks

[dlfivefifty]

I have the following inconsistency in Julia v0.3.0:

julia> BLAS.dotu([1.+im,2.],[3.,4.+im])
11.0 + 5.0im

julia> BLAS.dotu([1.,2.],[3.,4.])
ERROR: dotu has no method matching dotu(::Int64, ::Array{Float64,1}, ::Int64, ::Array{Float64,1}, ::Int64)
in dotu at linalg/blas.jl:156

[simonster]

dotu is only defined for complex arguments, both in BLAS and in Julia. If you want to compute a dot product of real vectors, you can just use dot.

[dlfivefifty]

What if you want to right a function that uses dot for real arguments and dotu for complex?  (I.e., always do dotu)

On 11 Sep 2014, at 9:14 am, Simon Kornblith notifications@github.com wrote:

dotu is only defined for complex arguments, both in BLAS and in Julia. If you want to compute a dot product of real vectors, you can just use dot.

—
Reply to this email directly or view it on GitHub.

[johnmyleswhite]

Write a wrapper that gets inlined to each of them?

[dlfivefifty]

Yes of course, but I can’t see a good reason why dotu(Real,Real) != dot(Real,Real)    

not to mention dotu(Complex,Real) and dotu(Real,Complex)

On 11 Sep 2014, at 9:17 am, John Myles White notifications@github.com wrote:

Write a wrapper that gets inlined to each of them?

—
Reply to this email directly or view it on GitHub.

[simonster]

Because BLAS.dotu is a wrapper for BLAS ?dotu. If we were to create an exported dotu function it ought to do this and also have a pure Julia fallback for non-BLAS element types. Such a function currently does not exist, but it might make sense to have.

[dlfivefifty]

OK That’s fair enough.  I’d be in favour of the addition of an exported dotu ..  its a commonly used operation and dotu(u,v) looks cleaner than dot(conj(u),v) or (u.’*v)[1]

On 11 Sep 2014, at 9:22 am, Simon Kornblith notifications@github.com wrote:

Because BLAS.dotu is a wrapper for BLAS ?dotu. If we were to create an exported dotu function it ought to do this and also have a pure Julia fallback for non-BLAS element types. Such a function currently does not exist, but it might make sense to have.

—
Reply to this email directly or view it on GitHub.

[jiahao]

I think of dotu as semantically a special case of .*; we could just add the BLAS calls as special methods of .* called on StridedArray{<:BlasFloat}s.

[timholy]

Out of curiosity, are the BLAS versions any faster than the Julia versions? At least for Float32, the gap has narrowed a lot thanks to SIMD.

[simonster]

@jiahao It's really sum(x.*y) or (x.'y)[1], though, isn't it? It would be great if we could just make that call dotu, but we don't have the machinery to do that.

[jiahao]

Oh right, duh.

[simonster]

@timholy That's worth testing. @andreasnoack said that the difference wasn't big, but at the moment the generic version doesn't use @simd which would be necessary to let LLVM reassociate the adds, so it's probably at least a bit slower. The loop vectorizer was also not that great at optimizing summation the last time I tried it (#6928), but I never got around to trying with LLVM trunk after @ArchRobison fixed vectorization there.