try
ys = map(runge,xs)
Am Mittwoch, 7. Mai 2014 12:40:17 UTC+2 schrieb Hans W Borchers:
>
> 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.
>>>
>>
