Wow! Thanks everyone for all the advice!!! Super helpful. I now see that it
is super easy to deal with the LinSpace objects.
That being said I guess I get scared when the docs tell me to use concrete
types for performance ;) Most of the code I write for myself is working
with Float64 arrays a la Matlab. I am comfortable with duck typing and what
not but one of the things that drew me to Julia (vs lets say Mathematica)
is how in general the type system feels easy to reason about. All the
layers of indirection can scare me as it makes it harder for me to
understand the kinds of performance problems I might face. I like sending
concrete array types for my own code as it often catches bugs (when I maybe
used an int literal and this accidentally created a int array when i really
wanted a float, potentially leading to horrible performance cascades as all
my generic code starts doing the wrong thing...).
I guess really what this comes down to is the point made by DNF that
changing linspace to an iterator when that name means an array in Matlab
and python is not the path of least surprise. It feels to me like this is a
strange inconsistency as we could just as easily return other common
functions, like `rand` to be an AbstractArray like type, but this would
suck as it does in this case. I guess it all comes down to wishing that,
like DNF suggested, we had a proper name for linspace and the iterator
version was a new name. I guess my way forward will likely be to define my
own linarray() function, sadly this will make my code a bit confusing to my
matlab friends ;)
Again thanks though. I really have learned a crazy bunch about the generic
type system.
On Wednesday, 21 October 2015 08:50:32 UTC-7, Spencer Russell wrote:
>
> On Wed, Oct 21, 2015, at 11:38 AM, Gabriel Gellner 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?
>
>
> In general you can just make your function accept an AbstractVector (or
> more generally AbstractArray) and things will just work. If there are
> places where Ranges, LinSpaces, etc. aren't behaving as proper arrays
> then I think those are generally good candidates for Issues (or even
> better, PRs).
>
> As a related aside:
> For efficiency you'll still want to use a concrete Vector field if you're
> defining your own types, but luckily there seems to be a convert method
> defined so you can do:
>
> type MyArr{T}
> x::Vector{T}
> end
>
> a = MyArr{Int64}(1:4)
>
> And it will auto-convert the range to an array for storage in your type.
>
> -s
>
