Well, that is no solution for casual REPL usage, is it?
I don't know what you mean with "Julia does not analyze runge",
it happens in any case, for instance:
julia> xs = [1.0, 2.0]
2-element Array{Float64,1}:
1.0
2.0
julia> [x for x = xs]
2-element Array{Any,1}:
1.0
2.0
That's exactly what the Julia manual describes.
On Wednesday, May 7, 2014 12:27:40 PM UTC+2, Ivar Nesje wrote:
>
> 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.
>>
>
