--- Day changed Mon Jul 08 2019
04:45 < digi_james> adiabat: I have been reading through the utreexo library line-by-line and there are some very advanced/efficient bitshift ops in here so been learning a lot about binary forests :) 
04:46 < digi_james> adiabat: I am currently stuck on utreexo/utils.go#L119, may I ask what the elements of the following term represent? 
04:46 < digi_james> (position<<nh) & ((2<<th)-1)
04:48 < digi_james> From what I understand so far, the loop is walking through the different subtrees in descending order with the (1<<th)&numLeaves term, as th is incremented downwards, but the above expression in the for loop condition still eludes me.
04:50 < digi_james> It seems this is a critical function (detectOffset) as it returns the path/bitfield from forest tip to node in question.
11:33 < adiabat> digi_james - Hi, yeah detectOffset has that loop which is a bit complex / ugly...
11:33 < adiabat> the line above saying "TODO write some description of this bitshift stuff.  Bit of a mess."
11:33 < adiabat> I will do that now!
11:52 < digi_james> Thx in advance! These are def. ninja-level <<bitshift>> moves :)
12:24 < adiabat> ok - pushed description on github
12:25 < digi_james> cheers - gonna pull right now
12:25 < adiabat> I can't seem to make the line itself simpler / clearer though, which is too bad...
12:25 < adiabat> the "(1<<th)&numLeaves" part shows up 3 times but is repeated each time
13:45 < digi_james> The childMany/child functions have helped me get an intuition for the (2<<th)-1 mask, now moving back to revisit the detectOffset function ...
14:11 < digi_james> adiabat: This is a different question: In transform.go#L134, I dont understand why the is root stashed if there is no odd number of deletions?  If deletions on a row are even, do we not leave the roots on that level in  place?  Thx
14:45 < adiabat> That line is a bit weird since the root stays in the "same place"
14:46 < adiabat> it's the same place from the perspective of "here's a tree with 64 leaves"
14:47 < adiabat> but it may not be in the same place in terms of "here's the 5th largest tree"
14:47 < adiabat> one example is if you have 3 trees: one with 8 leaves, one with 4, and one with 2
14:48 < adiabat> the 4-tree gets completely deleted
14:48 < adiabat> the 2-tree now needs to move left 4 positions.  It's still the same tree, but in the indexed perspective (what 'forest' uses)
14:49 < adiabat> or the binary tree perspective (what 'pollard' uses), it has moved
14:51 < adiabat> pollard is tops []*polNode , so a slice.  If it were  tops [64]*polNode or something then this could be omitted, as the tree with 64 leaves would always be in the same place
14:52 < adiabat> and if a tree wasn't there, it would just be a nil pointer at that index, so tops[8] == nil would mean there's no tree with 256 leaves
14:53 < adiabat> I actually think that would make the code simpler; maybe it's worth re-writing it to work that way.
15:51 < digi_james> adiabat: Ah of course,  a tree may be removed and the tree with the root in the current height will have to move left. 😅
15:56 < digi_james> Regarding your suggestion for alternative approach, I think I understand, so having index in tops [index]*polNode  always refer to the tree root node with 2^index leaves, whether it is populated or not.
16:47 < adiabat> right - it may be simpler because then the trees don't have to move around.  You'd have a fixed size array and most of it would be wasted by nil pointers
16:47 < adiabat> but that's like a couple bytes, and if you needed to serialize it to disk you could omit the empty spots
16:49 < adiabat> hm... in that case you could actually get rid of numLeaves and compute it from which pointers were nil and which weren't.  not worth it :)