Okay so I am starting to see the light. I see that if LinSpace becomes
fully replacable for an Array it is fine.
Final Questions:
* I can't use LinSpace in matrix mult A * b::LinSpace, is this simply a
Bug/Missing Feature? Or intentional? In general if basic builtin functions
that operate on Array{Float64} types don't accept LinSpace objects is this
something to be fixed? Or do we make special assumptions about the
meaningfulness of such operations?
* LinSpace objects seem much slower when used in things like element
multiplication A .* b::LinSpace is much much Slower than A .* b::Array, is
this to be expected (the cost of the extra abstraction lack of required
denseness) or simply a side effect of lack of optimization?
* In general if I make my code accept AbstractArray{Float64} in general
should I expect a performance penalty when calling the function with
Array{Float64} parameters?
thanks
On Wednesday, 21 October 2015 14:25:17 UTC-7, Stefan Karpinski wrote:
>
> On Wed, Oct 21, 2015 at 5:13 PM, Gabriel Gellner <[email protected]
> <javascript:>> wrote:
>
>> Maybe all this is just transitional that soon LinSpace objects will
>> always work like Arrays in all code I might use as an end user. Currently
>> as a new user I have not had this experience. I have noticed that LinSpaces
>> where returned, and had to learn what they were and at times run `collect`
>> to make them into what I wanted. I have not felt this abstraction bleed yet
>> in other areas of Julia.
>
>
> I think this is exactly what's happening. The LinSpace type is hitting
> code that should be abstracted in a lot of places but hasn't yet been.
> You'd get the exact same issues if you'd passed a FloatRange object into
> those functions. So the LinSpace type is really doing us all a favor by
> forcing more Julia libraries to the right level of abstraction.
>
