It’s still hard for me to understanding what the value of returning an array is
by default.
By getting a structured LinSpace object, it enables things like having the REPL
print it in a special way, to optimize arithmetic operations on it (so that
adding a scalar to a LinSpace is O(1) instead of O(N) in the length of the
space), to inspect its properties by accessing its fields, etc. And on top of
that, it can be used transparently in virtually all expressions where a
concrete array can be used. It’s not like Python where iterators are generally
going to be much slower and clunkier to work with than a reified Numpy array.
The only downside really is if your arguments are explicitly and unnecessarily
typed to expect an Array, which is not a great habit to get into no matter what
linspace returns.
Not trying to be argumentative or dismissive here- just trying to understand. I
would think that if one of your motivations for getting into Julia is the rich
type system compared to Matlab, you’d be happy that Julia isn’t forced to
discard semantic information from operations like linspace as a result of only
only raw numeric vectors being first-class constructs in the language (as in
Matlab and Numpy).
> On Oct 21, 2015, at 2:38 PM, Gabriel Gellner <gabrielgell...@gmail.com> wrote:
>
> 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
