CLArrays.jl
CLArrays.jl copied to clipboard
JuliaGPU
Should the convenience constructor be `zero(CLArray{Float32}, n, n)` instead of `zeros`?
I'm in the process of replicating the zeros and eye convenience constructors in BandedMatrices.jl and other packages, see
https://github.com/JuliaMatrices/BandedMatrices.jl/issues/42
Personally, the semantics of zeros(CLArray{Float32},n,n) seems wrong as it looks like it's asking to create a Matrix{CLArray{Float32}}. So I would propose zero(CLArray{Float32},n,n) instead. But I'm interested to hear the logic behind the current convention.
Personally, the semantics of zeros(CLArray{Float32},n,n) seems wrong as it looks like it's asking to create a Matrix{CLArray{Float32}}
Interesting ambiguity! I wouldn't mind just going with zero(CLArray{Float32},n,n)!
👍 It would be good to make a pull request into Base to add these as well at some point.
Maybe the real answer is defining CLArrays.zeros(Float32, n, n)::CLArray...
With a alias this could be as short as cl.zeros(n, n)
It doesn’t help in the situation where you want to write generic code with multiple matrix types, some from packages which don’t depend on CLArrays.jl.
Another option would to make a Zeros <: AbstractArray that doesn’t allocate, and then use conversion like
CLArray(Zeros(Float32,n,m))
There could also be a Fill and Eye. These could live in a shared package that implements the Array versions.
That seems like a good idea :) could be a generator, so it would automatically work for arrays having a constructor for generators!
They should be <: AbstractArray, which should automatically work for most arrays.
I'll mock it up in https://github.com/dlfivefifty/FillArrays.jl
We can move the package to JuliaArrays down the line.
I agree that zeros(CLArray{Float32},n,n) is kind of a weird API, given the analogy to zeros(Float32, n, n). It seems like the equivalent would be something like zeros(CLVal{Float32}, n, n) or something, where CLVal{T} could be a singleton type just used for dispatch. Having CLArrays.zeros be a different function from Base.zeros also seems pretty reasonable to me.
I'm less enthused about needing a bunch of different types for Fill, Zero, Eye, etc, as then you have to remember which array-generating functions have been mapped over to their type-based CL versions, and it seems like a big departure from the way of doing things in Base.
It might also be a nice API to have a @cl macro that would just take any zeros, fill, etc. functions and translate them to their CLArrays-based (and maybe more verbose) versions.
The macro could be a nice way ;) Note that what we discussed here should have been implemented and works for all sized, isbits iterators!
Julia 0.7 has completely deprecated zeros, ones, etc. so it's not worth discussing until that is finalised.
Also, Fill, Zero, and Eye are all AbstractArray, so those constructors should work regardless of whether or not it's the "canonical" way of creating such matrices.