100% agree. I did not wanted to imply that this is a bug but a "surprising
slow pass" (at least for me). So absolutely thumbs up if there is an
opportunity of optimizing this case!
Cheers,
Tobias
Am Dienstag, 31. Mai 2016 16:14:27 UTC+2 schrieb Stefan Karpinski:
>
> This isn't exactly a bug
This isn't exactly a bug since the answer is correct, it's an optimization
that we don't yet do. (If all of those are bugs then every language
implementation has an infinite number of bugs.) But yes, fixing this is on
track. There's been a lot of recent work on Julia's IR which should make
this
It would be great if this is resolvable. It took me quite some time to
determine that this is an issue in my own code. My mental model was that
type stability is about the return type being statically dependent on the
input parameter types. That a local binding has changed is quite a
different
On Mon, May 30, 2016 at 7:54 PM, Erik Schnetter wrote:
> Yichao
>
> What is the known bug here: That Julia doesn't handle this more efficiently,
The bug is that the type instability here is spurious.
> or that the variable `x` can change its type from Int to Float64?
>
> In
Yichao
What is the known bug here: That Julia doesn't handle this more
efficiently, or that the variable `x` can change its type from Int to
Float64?
In this example, are there two variables `x` (the argument and the
explicitly declared local variable), or should the declaration be an error?
On Mon, May 30, 2016 at 7:23 PM, David P. Sanders wrote:
>
>
> El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió:
>>
>> function t1(n::Int, x::Int, a::Float64)
>>x::Float64 = x
>>for i in 1:n
>> x += a
>>end
>> x
>> end
>> @time