Thanks Iain! I knew I'd seen something like *findnz* in the documentation somewhere but I couldn't find it again...
-- Sean On Thursday, December 11, 2014 11:38:24 PM UTC-6, Iain Dunning wrote: > > Or even simpler: > > coords(A::SparseMatrixCSC) = collect(zip(findn(A)...)) > > On Fri, Dec 12, 2014 at 12:22 AM, Iain Dunning <[email protected] > <javascript:>> wrote: >> >> Also, you can pretty much just do this with inbuilt functions: >> >> function coord(A::SparseMatrixCSC) >> rows, cols, vals = findnz(A) >> collect(zip(rows,cols)) >> end >> >> >> On Friday, December 12, 2014 12:14:22 AM UTC-5, Iain Dunning wrote: >>> >>> I'm imagine its something like the following pattern: >>> >>> Run 1: generate X garbage >>> Run 2: generate X garbage, for total 2X garbage, which is over >>> threshold, reduce back to 0 >>> Run 3: generate X garbage >>> Run 4: generate X garbage, for total 2X garbage, which is over >>> threshold, reduce back to 0 >>> and so on >>> >>> On Friday, December 12, 2014 12:09:19 AM UTC-5, Sean McBane wrote: >>>> >>>> Alright. I am curious now as to what causes this behavior; hopefully >>>> someone will offer an explanation. >>>> >>>> I'll be sure to from now on. >>>> >>>> -- Sean >>>> >>>> On Thursday, December 11, 2014 11:07:07 PM UTC-6, John Myles White >>>> wrote: >>>>> >>>>> This is just how the GC works. Someone who's done more work on the GC >>>>> can give you more context about why the GC runs for the length of time it >>>>> runs for at each specific moment that it starts going. >>>>> >>>>> As a favor to me, can you please make sure that you quote the entire >>>>> e-mail thread you're responding to? I find responding to e-mails without >>>>> context to be pretty jarring. >>>>> >>>>> -- John >>>>> >>>>> On Dec 12, 2014, at 12:04 AM, Sean McBane <[email protected]> wrote: >>>>> >>>>> > Right, I know I'm allocating it and discarding memory. However, if >>>>> the GC cleans up at deterministic points in time, as you point out in >>>>> your >>>>> first reply, why is timing erratic? And why the regular pattern in >>>>> timing? >>>>> It's always faster one call, slower one call, faster one call, slower one >>>>> call... >>>>> >>>>> > > -- > *Iain Dunning* > PhD Candidate > <http://orc.scripts.mit.edu/people/student.php?name=idunning> / MIT > Operations Research Center <http://web.mit.edu/orc/www/> > http://iaindunning.com / http://juliaopt.org >
