>
> Does your code break if it is applied to an array with an abstract element
> type? If so, you must be doing something rather strange.
Stefan, I think this is stated too strongly. There have been many questions
and issues related to arrays with abstract element type. For functions
returning arrays it is not so intuitive to get the promotion right and
there are still problems in base, e.g. this funny one
julia> sum(Real[1.0 1.0],1)
1x2 Array{Int64,2}:
1 1
2014-05-01 17:20 GMT+02:00 Simon Kornblith <si...@simonster.com>:
> It seems to me that the massive difference in performance between
> homogeneous and heterogeneous arrays is at least in part a characteristic
> of the implementation and not the language. We currently store
> heterogeneous arrays as arrays of boxed pointers and perform function calls
> on values taken out of them using jl_apply_generic, but I think this could
> be made more efficient. For arrays of types that are sufficiently small or
> sufficiently close in size, e.g. Array{Union(Float32,Float64)}, we could
> store type information and value in the array instead of resorting to
> boxing, and we could create code that branches based on type unions instead
> of resorting to jl_apply_generic. Then (some?) heterogeneous arrays could
> be nearly as fast as homogeneous arrays, modulo branch prediction for the
> type. This is basically how we store DataArrays, which could just be
> Array{Union(T,NA)} if the compiler did this. This is easier for arrays of
> unions of concrete types than it is for arrays of abstract types, since for
> abstract types someone could subtype the element type of the array after
> the array has been constructed and both storage and code need to be able to
> accommodate that. But I'm not sure it's right to structure the language
> based on the performance characteristics of the current implementation
> unless we think they cannot be improved.
>
> Simon
>
>
> On Wednesday, April 30, 2014 10:08:15 AM UTC-4, Oliver Woodford wrote:
>>
>>
>>
>> On Wednesday, April 30, 2014 2:31:43 PM UTC+1, Patrick O'Leary wrote:
>>>
>>>
>>> It's a flexible type system, but it doesn't provide the power of ML or
>>> Haskell. If you really, really want this, do a runtime check:
>>>
>>> reduce((==), [typeof(el) for el in a])
>>>
>>
>> I feel that the difference between homogeneous and heterogeneous arrays
>> is a very important distinction, and not some odd thing that you might only
>> rarely care about. The distinction has a massive impact on speed. The point
>> of Julia is to be a fast dynamic language. Hiding the distinction under the
>> carpet seems contrary to one of the aims of Julia.
>>
>> Ivar's suggestion of:
>> @assert isleaftype(T)
>> is nice, but it doesn't feel quite right to me.
>>
>
--
Med venlig hilsen
Andreas Noack Jensen
