Sorry for nitpicking, but point 3 is wrong, and it might cause trouble in
the following discussion.
f{T<:Real}(a::Array{T})
Matches any array with a element type that is a subtype of Real (eg.
Integer[1,2,BigInt(44)] and Real[1, 3.4])
I have had trouble with this too, but now that I somewhat understand the
rationale, I'm less frustrated. I'm not at the point of defending the
current behaviour (yet), so others will have to do that (again).
kl. 11:38:33 UTC+2 tirsdag 29. april 2014 skrev Oliver Woodford følgende:
>
> A habitual MATLAB user, I've been trying out Julia over the last two weeks
> to see if it might be a suitable replacement. I want something that is as
> fast to develop using, but has much faster runtime. Perhaps I'll write
> about my general thoughts in another post. However, in this thread I want
> to address one linguistic thing I found confusing.
>
> Ignoring subarrays, dense/sparse arrays, there are two main types of array
> in Julia. I will call them homogenous and heterogenous. Homogenous arrays
> are declared as having all elements be the same type: e.g. array{Float64}.
> They are efficient to store in memory, as the elements are simply laid out
> consecutively in memory. Heterogenous arrays have an abstract element type,
> e.g. array{Real}. The way Julia interprets this is that every element must
> be a concrete subtype of Real, but that they don't have to be the same
> type. Each element can therefore be a different type, with different
> storage requirements, so these arrays contain a pointer to each element,
> which is then stored somewhere else - this carries a massive overhead. In
> MATLAB these arrays would be termed an array and a cell array respectively,
> so there is a clear distinction. What I found confusing with Julia is that
> the distinction is less clear.
>
> This confusion was highlighted in a stackoverflow
> question<http://stackoverflow.com/questions/23326848/julia-arrays-with-abstract-parameters-cause-errors-but-variables-with-abstract>,
>
> which I'll outline it again, now:
>
> f(x::Real) = x is equivalent to f{T<:Real}(x::T) = x, but f(x::Array{Real})
> = x is different from f{T<:Real}(x::Array{T}) = x.
>
> The second form for input arrays, requiring static parameters, is needed
> to declare that the array is homogenous, not heterogenous. This seems a
> funny way of doing things to me because:
> 1. The homogeneity/heterogeneity of the array is a characteristic of the
> array only, and not of the function
> 2. The static parameter T is not required anywhere else, and the Julia
> style
> guide<http://julia.readthedocs.org/en/latest/manual/style-guide/#don-t-use-unnecessary-static-parameters>
> explicitly
> counsels against the use of such parameters, where they are unnecessary.
> 3. To declare a function which can take homogenous or heterogenous arrays,
> I believe you'd have to do something like f{T<:Real}(x::Union(Array{T},
> Array{Real})) = x, which seems totally bizarre (due to point 1).
>
> What I would advocate instead is two types of array, one homogenous, one
> heterogenous. Array for homogenous and Cell for heterogenous would work.
> It would do away with the need for static parameters in this case, and
> also, in my view, make people far more aware of when they are using the
> different types of array. I suspect many beginners are oblivious to the
> distinction, currently.
>
> In the stackoverflow question, someone suggested two points against this:
> 1. Having an array whose elements are all guaranteed to be some subtype of
> Real is not particularly useful without specifying which subtype since
> without that information almost no structural information is being provided
> to the compiler (e.g. about memory layout, etc.)
> Well, firstly I disagree; there is a lot of structural information being
> supplied - to read each element, the compiler knows that it just needs to
> compute an offset, rather than compute an offset, read a pointer and then
> read another memory location. However, I don't think this is exploited
> (though it could be) because the function will be recompiled from scratch
> for each element type. Secondly, this isn't about helping the compiler,
> it's about making the language more consistent and sensible - helping the
> *user*.
> 2. You almost always pass homogenous arrays of a concrete type as
> arguments anyway and the compiler is able to specialize on that.
> Firstly, homogenous arrays that you pass in *always *have a concrete
> type. Secondly, you don't always know what that type will be. It might be
> Float64 or Unit8, etc.
>
> I haven't yet heard a convincing counterargument to it making more sense
> to distinguish homogenous and heterogenous arrays by the array type rather
> than by static function parameter.
>
> Let the discussion begin...
>
