This is true. I agree in general that having the tighter container is
desirable but hey, if you are only interested in the homogeneity property
(which is what I was testing) and not in the storage there ya go.
On Wednesday, April 30, 2014 8:53:02 AM UTC-5, Ivar Nesje wrote:
>
> @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.
>>>>
>>>
