Well, yes, I should have put a rather big asterisk on that:
* Unless your code explicitly depends on the element type of that or
derived arrays.
So, yes, it's not that simple.
On Fri, May 2, 2014 at 9:06 AM, Andreas Noack Jensen <
andreasnoackjen...@gmail.com> wrote:
> 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
>
