Hi Hans,
There was a huge slowdown in your code with : local i::Int. If you change
it to i = 0 (therefore i::Int64), the return type is always Int64.
Therefore, Julia can generate efficient code.
Use @time to check it. This change makes your code 10 time faster on my
machine.
On Wednesday,
I don't think this slowness is because of type instability, as I understand
the concept. On a 64-bit machine `Int === Int64` is true. Also, the
following is also slow and results in lots of allocation:
local i::Int64
as does simply declaring
local i
However, if one completely leaves off
Good catch. I have no idea the reason behind this behaviour. It would be
interesting to know why.
On Wednesday, May 21, 2014 7:58:02 PM UTC+2, Peter Simon wrote:
I don't think this slowness is because of type instability, as I
understand the concept. On a 64-bit machine `Int === Int64` is
I think this is because the loop might have zero iterations, and in that
case `i` might not be initialized. Variables that might be used
uninitialized get pessimized. We could improve this by representing such
variables internally as a pair of a fast variable and a boolean flag.
On May 21, 2014
Added issue #6914 to describe this performance issue.
--Pete
On Wednesday, May 21, 2014 6:48:31 PM UTC-7, Jeff Bezanson wrote:
I think this is because the loop might have zero iterations, and in that
case `i` might not be initialized. Variables that might be used
uninitialized get
Hi,
I would do a while as the loop is a conditional loop :
function test(x::Vector{Float64})
i = 1
while i = length(x) x[i] != 0.0
i += 1
end
return i - 1
end
or I would use a return inside the for loop even though I prefer to avoid a
return in the middle of a
Hi,
I would do a while as the loop is a conditional loop :
function test(x::Vector{Float64})
i = 1
while i = length(x) x[i] != 0.0
i += 1
end
return i - 1
end
or I would use a return inside the for loop even though I prefer to avoid a
return in the middle of a
This method is also a bit faster as you can check with @time. I guess that
it's because there is only one if per loop as opposed to 2 if per loop
in your design (Are we at the end of the array ? Is it a 0.0 ?).
François
On Wednesday, May 21, 2014 12:09:02 AM UTC+2, francoi...@gmail.com wrote:
Also, your program is weird. My guess is that you want to give the largest
k such that x[1],..., x[k] are not equal to 0. If you want that, your
program is wrong when x does not contain any 0.
The fact that if x does not contain any 0, your program return length(x) -
1 is very weird to me.
On
Thanks, Mike, for the prompt answer.
But what if i want to explicitly exclude integers.
I think with Real I would allow them.
On Saturday, May 17, 2014 2:13:09 PM UTC+2, Mike Innes wrote:
I think your first example is right, although someone may well correct me
on that. That's how I've done
Well, you could do this by defining another method on the (more specific)
Integer type:
test(x::Real) = x*x
test(x::Integer) = error()
There's also the FloatingPoint type, but that excludes pi.
I have to say, though, that it seems odd that you'd want to do this, seeing
as integers are
11 matches
Mail list logo
