Thanks Patrick. So to clarify: *FloatingPoint* is not a concrete types, so
explicitly defining variables or function inputs using it will not speed
things up. Instead, I should use *Float64*, *Float32*, etc.
Is *Int* an abstract type as well? I'm wondering if I should go back and
rename everything *my_var::Int* to *my_var::Int32*.
On Monday, 25 August 2014 14:54:14 UTC-4, Patrick O'Leary wrote:
>
> On Monday, August 25, 2014 12:28:00 PM UTC-5, John Myles White wrote:
>>
>> Array{FloatingPoint} isn't related to Array{Float64}. Julia's type system
>> always employs invariance for parametric types:
>> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
>>
>> <https://www.google.com/url?q=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCovariance_and_contravariance_%28computer_science%29&sa=D&sntz=1&usg=AFQjCNH5Mpuwh71o9dv0_TDx9OcMvvKfWg>
>>
>
> To underline this point a bit, it's even a bit worse than that:
> Array{FloatingPoint} will work just fine for a lot of things, but it stores
> all elements as heap pointers, so array-like operations (such as linear
> algebra routines) will often be extremely slow.
>
> As a rule, you almost never use an abstract type as the type parameter of
> a parametric type for this reason. Where you wish to be generic over a
> specific family of types under an abstract type, you can use type
> constraints:
>
> function foo{T<:FloatingPoint}(src::Array{T,1})
> ...
> end
>
> But often type annotations can be omitted completely.
>
