Actually it is that easy... you just have to get in the habit of doing it:
julia> function mysum(arr::Array)
s = zero(eltype(arr))
for a in arr
s += a
end
s
end
mysum (generic function with 1 method)
julia> mysum(1:10)
ERROR: MethodError: `mysum` has no method matching mysum(::UnitRange{Int64})
julia> mysum(collect(1:10))
55
julia> function mysum_generic(arr::AbstractArray)
s = zero(eltype(arr))
for a in arr
s += a
end
s
end
mysum_generic (generic function with 1 method)
julia> mysum_generic(1:10)
55
julia> mysum_generic(collect(1:10))
55
For something like this, you never need allocate space for the array.
On Wed, Oct 21, 2015 at 11:38 AM, Gabriel Gellner <[email protected]>
wrote:
> No that is a good point. Often you can use an iterator where an explicit
> array would also work. The issue I guess is that this puts the burden on
> the developer to always write generic code that when you would want to
> accept an Array you also need to accept a iterator like LinSpace.
>
> Maybe this is easier to do than I currently understand? If not for regular
> scientists like myself I find that this would force me to make my functions
> far more complex than I generally would do in practice. I would often just
> write a signature like func(x::Vector) when I want my code to accept of
> Vector, but if I pass a LinSpace object to this I get a type error. I like
> this type of coding as it fits my model of what I want to do. The
> contortions I would need to do for something as basic as having a nice way
> to get a linear array of floating point numbers to a simple function that
> wants to accept a Vector seems like a wart to me. Am I missing something
> simple?
>
> For the builtins clearly this is not the case which is nice, but it only
> masks the issue of how this would be used by regular users in my opinion.
>
>
> On Wednesday, 21 October 2015 05:59:21 UTC-7, Jonathan Malmaud wrote:
>>
>> Gabriel, I rewrote your code to not ever explicitly convert ranges to
>> arrays and it still works fine. Maybe I'm not quite understanding the issue?
>>
>> function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 )
>> # Inputs:
>> #
>> # Outputs:
>> N0 = 8; # As suggested by Jakes
>> N = 4*N0+2; # An accurate approximation
>> wd = 2*pi*fd; # Maximum Doppler frequency
>> t = t0 + (0:Ns-1)*Ts;
>> tf = t[end] + Ts;
>> coswt = [ sqrt(2)*cos(wd*t'); 2*cos(wd*cos(2*pi/N*(1:N0))*t') ]
>> temp = zeros(1,N0+1)
>> temp[1,2:end] = pi/(N0+1)*(1:N0)'
>> temp[1,1] = phi_N
>> h = E0/sqrt(2*N0+1)*exp(im*temp ) * coswt
>> return h, tf;
>> end
>>
>> On Wednesday, October 21, 2015 at 3:11:44 AM UTC-4, Gabriel Gellner wrote:
>>>
>>> I find the way that you need to use `linspace` and `range` objects a bit
>>> jarring for when you want to write vectorized code, or when I want to pass
>>> an array to a function that requires an Array. I get how nice the iterators
>>> are when writing loops and that you can use `collect(iter)` to get a array
>>> (and that it is possible to write polymorphic code that takes LinSpace
>>> types and uses them like Arrays … but this hurts my small brain). But I
>>> find I that I often want to write code that uses an actual array and having
>>> to use `collect` all the time seems like a serious wart for an otherwise
>>> stunning language for science. (
>>> https://github.com/JuliaLang/julia/issues/9637 gives the evolution I
>>> think of making these iterators)
>>>
>>>
>>>
>>> For example recently the following code was posted/refined on this
>>> mailing list:
>>>
>>>
>>>
>>> function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 )
>>>
>>> # Inputs:
>>>
>>> #
>>>
>>> # Outputs:
>>>
>>> N0 = 8; # As suggested by Jakes
>>>
>>> N = 4*N0+2; # An accurate approximation
>>>
>>> wd = 2*pi*fd; # Maximum Doppler frequency
>>>
>>> t = t0 + [0:Ns-1;]*Ts;
>>>
>>> tf = t[end] + Ts;
>>>
>>> coswt = [ sqrt(2)*cos(wd*t'); 2*cos(wd*cos(2*pi/N*[1:N0;])*t') ]
>>>
>>> temp = zeros(1,N0+1)
>>>
>>> temp[1,2:end] = pi/(N0+1)*[1:N0;]'
>>>
>>> temp[1,1] = phi_N
>>>
>>> h = E0/sqrt(2*N0+1)*exp(im*temp ) * coswt
>>>
>>> return h, tf;
>>>
>>> end
>>>
>>>
>>>
>>> From <https://groups.google.com/forum/#!topic/julia-users/_lIVpV0e_WI>
>>>
>>>
>>>
>>> Notice all the horrible [<blah>;] notations to make these arrays … and
>>> it seems like the devs want to get rid of this notation as well (which they
>>> should it is way too subtle in my opinion). So imagine the above code with
>>> `collect` statements. Is this the way people work? I find the `collect`
>>> statements in mathematical expressions to really break me out of the
>>> abstraction (that I am just writing math).
>>>
>>>
>>>
>>> I get that this could be written as an explicit loop, and this would
>>> likely make it faster as well (man I love looping in Julia). That being
>>> said in this case I don't find the vectorized version a performance issue,
>>> rather I prefer how this reads as it feels closer to the math to me.
>>>
>>>
>>>
>>> So my question: what is the Juilan way of making explicit arrays using
>>> either `range (:)` or `linspace`? Is it to pollute everything with
>>> `collect`? Would it be worth having versions of linspace that return an
>>> actual array? (something like alinspace or whatnot)
>>>
>>>
>>> Thanks for any tips, comments etc
>>>
>>
