This is (I believe) because Julia does not analyze runge to ensure that it
does not change the type of the xs global variable.
Try to execute the list comprehension in a function (or a let ... end)
scope, where the xs variable is a local reference, and see that you get
different result.
Ivar
kl. 12:16:25 UTC+2 onsdag 7. mai 2014 skrev Hans W Borchers følgende:
>
> As I concluded from the discussion on the ".+" operator,
> it might be better to define functions (like Runge) non-vectorized
> (and because of speed considerations, too?):
>
> julia> function runge(x::Number)
> 1 / (1 + 5 * x^2)
> end
>
> Say, I want to plot this function with Winston from -1 to 1.
> So I use linspace() for generating the x-coordinates.
>
> julia> xs = linspace(-1.0, 1.0)
> 100-element Array{Float64,1}:
> ...
>
> Now I would like to generate the y-coordinates through a comprehension, but
> ys = [runge(x) for x = xs] will be of type Any, as is rightly described
> in the Julia manual.
> I feel this is very unfortunate, and writing
>
> julia> ys = Float64[runge(x) for x = xs]
>
> is clumsy, especially as I do not like to be preset on Float64,
> preferring a type that is returned by the function.
> And applying type Number (or FloatingPoint) does not work properly either.
>
> Of course, I can do it like this:
>
> julia> ys = zeros(100);
>
> julia> for i = 1:100; ys[i] = runge(xs[i]); end
>
> This looks even more clumsy though it might be the most casual approach.
> What is the best/shortest way to generate such a vector for a
> non-vectorized function?
>
> I apologize if I have overlooked an obvious solution.
> The Winston manual, e.g., only mentions vectorized functions like sin(),
> etc.
>
