Weird error, very lost


#1

For some reason Y[idx1,c] and Y[idx2,c] are returning single, large Ints (even though idx1 and idx2 are ranges).

This does not happen if I run the code manually (run each line in julia REPL, rather than calling function). What is happening?

I can reproduce with random data (MWE):

Y=reshape(round(Int, abs(randn(5*1000)))+1,1000,5)

function FOO(Y::AbstractMatrix; frac::Float64=0.3, nbins::Int=100, n_sims::Int=100)
  ## setup temp vars
  num_iters, num_chains = size(Y)

  #start_iters = collect(1:round(Int64, num_iters/(2*nbins)):(round(Int64, num_iters/2)))
  start_iters = unique([1; [round(Int64, s) for s in logspace(log(10,100),log(10,num_iters/2),nbins-1)]])
  result = zeros(Float64, 10, length(start_iters) * num_chains)
  j=1
  for c in 1:num_chains
    for st in 1:length(start_iters)
      n = length(start_iters[st]:num_iters)
      println(STDERR, start_iters[st]:round(Int64, start_iters[st] + frac * n - 1))
      println(STDERR, round(Int64, num_iters - frac * n + 1):num_iters)
      idx1 = start_iters[st]:round(Int64, start_iters[st] + frac * n - 1)
      idx2 = round(Int64, num_iters - frac * n + 1):num_iters
      y1 = Y[idx1,c]
      y2 = Y[idx2,c]
      println(y1)
      println(y2)
      n_min = min(length(y1), length(y2))
      println(n_min)
      X = [y1[1:n_min] y2[(end - n_min + 1):end]]
    end
  end
end

julia> FOO(Y)
1:300
701:1000
214700992
213779136
1
ERROR: MethodError: no method matching getindex(::Int64, ::UnitRange{Int64})
 in #FOO#24(::Float64, ::Int64, ::Int64, ::Function, ::Array{Int64,2}, ::Int64) at ./REPL[53]:22
 in FOO(::Array{Int64,2}, ::Int64) at ./REPL[53]:3

If i comment out last line of FOO (where X is set), the function runs. Whats up? Also if I change

start_iters = unique([1; [round(Int64, s) for s in logspace(log(10,100),log(10,num_iters/2),nbins-1)]])

to something like

start_iters=1:num_iters

it works

Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
  System: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, ivybridge)

#2

This looks like a bug with inference. I reduced it a bit further:

julia> function FOO(Y::AbstractMatrix)
         frac=.3
         nbins=100
         n_sims=100
         num_iters, num_chains = size(Y)

         start_iters = unique([1; [round(Int64, s) for s in logspace(log(10,100),log(10,num_iters/2),nbins-1)]])
         c=1
         for st in 1:length(start_iters)
             n = length(start_iters[st]:num_iters)
             idx1 = start_iters[st]:round(Int64, start_iters[st] + frac * n - 1)
             y1 = Y[idx1,c]
             return y1[1:end]
         end
       end

If you look at how it gets typed, you can see that it thinks that the result of indexing y1 by an unknown index type is an Int:

y1::Int64 = (Main.getindex)(Y::Array{Int64,2},idx1::Any,c::Int64)::Int64 #

This should be y1::Any. Would you be willing to submit a bug report on the issue tracker? In the meantime, you can work around it by asserting start_iters = unique(...)::Vector{Int}.


#3

Thanks, I never had to deal with issues with type inference before. Issue open at


#4

If you need a work-around, type coercion seems to avoid the bug:

idx1::UnitRange = start_iters[st]:round(Int64, start_iters[st] + frac * n - 1)
idx2::UnitRange = round(Int64, num_iters - frac * n + 1):num_iters