@Patric. It's not just a better implementation. It actually works, because
your check only check that the actual types are equal, but not if the type
of the container is specific. Number[1,2,34,54] would pass your test, but
the array will still be pointers to boxed values.
kl. 15:40:33 UTC+2 onsdag 30. april 2014 skrev Patrick O'Leary følgende:
>
> And today I learned about isleaftype()! This is a better implementation
> than what I posted.
>
> On Wednesday, April 30, 2014 8:32:45 AM UTC-5, Ivar Nesje wrote:
>>
>> You can do something like
>> function f{T<:Real}(x::Array{T,1})
>> @assert isleaftype(T)
>> # function implementation
>> end
>>
>>
>> kl. 15:16:40 UTC+2 onsdag 30. april 2014 skrev Oliver Woodford følgende:
>>>
>>> On Wednesday, April 30, 2014 2:09:45 PM UTC+1, Patrick O'Leary wrote:
>>>>
>>>> On Wednesday, April 30, 2014 7:52:16 AM UTC-5, Oliver Woodford wrote:
>>>>>
>>>>> Is that correct? If not, what really is the correct way to constrain
>>>>> input arrays to be homogenous?
>>>>>
>>>>
>>>> The tendency in Julia is to embrace that it's a dynamic language, and
>>>> not excessively type constrain inputs. While I don't think there's a way
>>>> to
>>>> do exactly what you want, why do you want to do it?
>>>>
>>>>
>>> When my function will be a lot slower if you pass in a heterogeneous
>>> array, and I want to avoid programmers accidentally and obliviously doing
>>> that. Now, I could convert heterogeneous arrays to homogeneous ones within
>>> the function, but the Julia style
>>> guide<http://julia.readthedocs.org/en/latest/manual/style-guide/#handle-excess-argument-diversity-in-the-caller>very
>>> sensibly counsels against that.
>>>
>>
