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...
>>>
>>>
