Thanks, Steve. I certainly think this will work if I need it to.
I actually managed to squeak out a reasonably compact solution by
overriding Base.cat_t, an unexported function in abstractarray.jl used by
cat. Here's its signature:
function cat_t(catdim::Integer, typeC, A::AbstractArray...)
typeC is actually a Type, computed by applying promote_type to all of the
element types of the abstract arrays.
So I defined some promote methods to ensure that if even one CVX array
appears in the list, the promoted type will be CVX-specific, and I can pick
that up.
Base.cat_t{T}( catdim::Integer, ::Type{Scalar{T}}, X::Base.AbstractArray...
) = cat_cvx( catdim, X )
Of course, this is a bit fragile, because it depends on unexported
behavior. But by having this discussion here and on the GitHub issues page,
we can hopefully find a solution that will work more generally.
On Wednesday, August 6, 2014 5:41:11 PM UTC-5, [email protected] wrote:
>
> Michael,
>
> I am much more of a newbie at Julia than you, but it seems to me that
> there is a brute-force solution to this problem, namely define a few dozen
> methods:
>
> vcat(A1::CVXArray{T}, rest::AbstractArray{T}...)
> vcat(A1::AbstractArray{T}, A2::CVXArray{T}, rest::AbstractArray{T}...)
> vcat(A1::AbstractArray{T}, A2::AbstractArray{T}, A3::CVXArray{T},
> rest::AbstractArray{T}...)
>
> Maybe you could automate the generation of all of these with a Julia
> macro?
>
> It would be rare for a user to have a vcat statement with more than a
> handful of arguments, so you should be able to cover all the cases that
> would ever occur in practice. You could define the 100th in this sequence
> to throw an error, so that if any user ventured outside the range of cases
> covered, at least he/she would know that something is wrong.
>
