Logs for #trilema-mod6

Go to: #trilema #pizarro #trilema-mod6 #chainstate #eulora

This is the log of #trilema-mod6 : Contained within are the daily on-goings of The Bitcoin Foundation's (http://thebitcoin.foundation) Reference Implementation (trb) development. Do not, under any circumstances, use any code/vpatch/logic/configurations/ideas or otherwise found in this forum. In fact, you should NOT read this at all. Failure to heed these warnings may result in death or dismemberment! ALL ANNOUNCEMENTS, BUSINESS, AND/OR QUESTIONS INVOLVING THE BITCOIN FOUNDATION AND/OR THE BITCOIN REFERENCE IMPLEMENTATION (TRB) WILL TAKE PLACE IN #TRILEMA: YOU HAVE BEEN WARNED.

2017-12-31 | 2018-2-1

mod6: asciilifeform: hey, as previously discussed, the right pill for the problem with the press path calcuation is not to use the 'flow' as the input for this, but instead calculate from a leaf or other given vpatch.
mod6: i have, what looks like to be a possible implemented pill for this. but i wanted to get you to take a look to see if we can come to and understanding about the current behavior of v99 with regard to this ...
mod6: so here's what i've logged here:
mod6: http://wotpaste.cascadianhacker.com/pastes/wBNWA/?raw=true
mod6: The first part shows my implemented fix in v.pl.99993, i show the flow, the antecedents and then press up through ch2_truerandom.vpatch, then following, a press up through eucrypt_mpi_fix_copy_incr.vpatch.
mod6: This seems to me to press correctly as it follows it's antecedents down to the root, then presses all the way back up.
mod6: In the second part there, I used v99 to press up through 'eucrypt_mpi_fix_copy_incr.vpatch', and it seems to also lay down ch2_truerandom.vpatch. Which, like my v (99994), is the wrong behavior, right?
mod6: That was long asf. My bad. Thanks in advance.
mod6: jeeze, forgot to recover this channel
mod6: asciilifeform: so ben was going through FZ_IDiv and asked me for some insight into some of what's going on there...
asciilifeform: hm?
mod6: I'm pretty sure that it follows Knuth's Algo D from TAoCP Vol. 2, section 4.3.1 'Division of nonnegative integers', correct?
mod6: It does look like it... just wanna be sure we're all looking at the same thing.
asciilifeform: it's binary long division.
mod6: ah! so i'm wrong. ok
mod6: is there a section or refernece in knuth you can point me to?
asciilifeform: http://fourier.eng.hmc.edu/e85_old/lectures/arithmetic_html/node8.html << midway through the pg, another picture of same algo
mod6: awesome thanks!
mod6: hey ben_vulpes
mod6: ok i was wrong.
mod6: read the chan log, alf just gave us something to look at here.
asciilifeform: mod6: you're in the right section of knuth. but knuth's discussion is broader.
mod6: oh
mod6: im still pulling up your link here...
mod6: just a sec
mod6: ah, alright
asciilifeform: and the intention in ch5 was that it would be apparent that it is an exact inverse of the egyptian division algo
asciilifeform: err
asciilifeform: multiplication algo
mod6: ah. to be honest, I shouldn't even be digging into this yet. i haven't even formally started ch1.
asciilifeform: i.e. you see 'if goes in', and if yes, you mark the current binaryplace as '1' ; then shift, do the next
mod6: been just trying to get this vtron stuff out of the way. once that's complete, will work my way through your chapters.
asciilifeform: aite.
asciilifeform: knuth is unfortunately not the ideal starting point for a n00b
asciilifeform: sorta like trying to learn physics from feynman's text
mod6: right, gotcha.
mod6: i spent time yesterday doing 81/9 with ffa in gdb
mod6: and it seemed to work, was just trying to follow all that was going on. your link + some extra text on it is a help.
asciilifeform: mod6: try it on paper also
ben_vulpes: this is where i gotta put on me dunce cap and admit to not understanding where the divisor is calculated to 'go in' to the dividend, as in the FZ_IDiv routine divisor is subtracted from R, which is zeroed at the beginning of the routine
asciilifeform: eventually it will 'click' in your head
mod6: yeah, i think that'll be good. lol, there were 1280 iterations. but w/e.
ben_vulpes stares sadly at ream of grid paper
asciilifeform: ben_vulpes: consider how R is filled up
asciilifeform: ( R is only called R because the contents of it ~at the end~ is equal to the remainder of the div )
asciilifeform: mod6: 1280 iterations of what ?
mod6: of 'for i in FZ_Bitness(Bitness)'
mod6: since i had it set to 256.
mod6: i can make it smaller though i suppose for less times through the loop
asciilifeform: how did you count this 1280 ?
asciilifeform: ( and you can't use bitnesses smaller than 256 in the published ffa )
mod6: err. im wrong here.
mod6: nevermind. it's 1280 instructions
asciilifeform: aaa see.
mod6: well. not instructions
asciilifeform: FZ_Bitness(Dividend) should be the ffa bitness you ran with. always.
mod6: but in the debugger, instead of hitting 'next' 1280 times through the loop. just was doing 1280 to get to end.
mod6: like 1 step shift left
mod6: another step, over sub
mod6: another step over gated ... etc.
mod6: should be 256 iterations
asciilifeform: mod6: i debug with good old print-to-stderr method , virtually always
mod6: each iteration containing 5 steps or w/e
asciilifeform: but interestingly for ffa i've barely had to do it at all
mod6: yeah, i like that method too, but I wanted to be able to examine the vars to see what is going on. some of this code is a bit heady for me.
mod6: gotta remember, im basically retarded.
asciilifeform: mod6: don't hesitate to point to the parts that do not make sense immediately
asciilifeform: mod6: also don't hesitate to rewrite an algo in your favourite script lang, and see how it works
asciilifeform: all of ffa should theoretically be makeable in perl or similar, with minimal effort
mod6: it may come down to some of that.
asciilifeform: ( it won't be parachute-grade , but ought to make it easier to grasp )
mod6: right. just as an educational thing. im not stumbling on the ada, in fact, the ada makes it pretty clear.
mod6: just have trouble sometimes evaluating some of the expressions in my head
asciilifeform: mod6: are there any that i could give a useful hint for ?
mod6: not at the moment. and like i said, i came into this in the wrong order.
mod6: i appreciate the help tho.
mod6: im sure, that i'm gonna need lot more help before all is signed off.
asciilifeform: mod6 ( and ben_vulpes and anybody else who did not immediately grasp the algo ) you are the most valuable readers, from this pov, i gotta find out if any of the routines are 'not obvious'
asciilifeform: in fixable way
asciilifeform: this is pretty vital, ffa is not there to simply run, it gotta be graspable
mod6: in the case of FZ_IDiv, i think the hardest part for me, is never having done it this way on paper.
mod6: once I can do it by hand, then it'll click.
mod6: i believe your link above will help in this capacity, immensely.
asciilifeform: it's the algo used in most hardware dividers. various schoolbooks, e.g. hennessey and patterson , have illustrated step-by-step
mod6: *nod*
mod6: i dont really have any formal education, so for me, it's a learn-in-progress.
asciilifeform: http://www.ece.lsu.edu/ee3755/2012f/l07.v.html << verilog, possibly of interest
mod6: ah cool
ben_vulpes: FZ_Shift_Left turns around and calls FZ_Shift_Left_O_I, with an OF_In of zero, which (and i'm sure that this is the part i'm misunderstanding) means that R is still zero at the time of the trial subtraction, and after has the divisor added to it
ben_vulpes: it is very opaque to me how this ever touches the dividend, so i suspect i catastrophically misunderstand something in the shifts
asciilifeform: ben_vulpes: link to the lines using phf's patch viewer plox
asciilifeform: makes it easier to follow the discussion
ben_vulpes: http://btcbase.org/patches/ffa_ch5_egypt#L234 << at this point R is all 0's
ben_vulpes: http://btcbase.org/patches/ffa_ch5_egypt#L237 << after this, the underflow will be 1, and so FZ_Add_Gated will add the divisor into R
ben_vulpes: which i think must bring R back to zero?
ben_vulpes: (which after the next iteration's shift, will *still* be zero and i am certain that i'm misunderstanding something about how this works)
ben_vulpes: asciilifeform: is the mistake in my reading obvious to you?
asciilifeform: ben_vulpes: observe, ~QR~ is shifted
asciilifeform: the bottom of R , at each step, will contain the bit that fell off the top of Q
asciilifeform: (draw them on paper)
ben_vulpes: yeah okay, i misread that as filling the lowest bit with 0, not a wraparound
asciilifeform: there's no wraparound in there
asciilifeform: when you shift QR, the lowest bit of ~QR~ becomes 0
asciilifeform: not of R
asciilifeform: but of QR (and , from other pov, Q )
ben_vulpes: oh in that case i think that i also misunderstand the 'renames' declaration
asciilifeform: ben_vulpes: what did you think it did ?
ben_vulpes: something along the lines of a cl displaced array
asciilifeform: ben_vulpes: that isn't far off
asciilifeform: and ought to have given you an accurate picture of what it does
ben_vulpes: how does shifting QR not shift R then?
asciilifeform: it does !
asciilifeform: it shifts whole thing
asciilifeform: it is exactly the same thing as shifting Q , and then shifting R with the overflow of Q becoming the shift-in bit of R.
asciilifeform: ( which in fact is how it worked in the old, pre-genesis ffa snippets )
ben_vulpes: now it's starting to sound like i don't understand the layout of an FZ, which actually starts to make sense
asciilifeform: ben_vulpes: review ch1
ben_vulpes: right
asciilifeform: a FZ is simply an array of Word
asciilifeform: a Word is whatever your machine word is ( in the published ffa, hardwired to 64bits )
asciilifeform: there is literally nothing else to FZ . ( ada does internally keep track of the wordnesses of individual FZ; which is why you can do Foo'Length , Foo'Range, etc )
mod6: so when i wanna do 81/9, (81 = x51), i start with QR like:
mod6: (gdb) p/x QR
mod6: $20 = (0x51, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
mod6: and then after shifting
mod6: (gdb) p/x QR
mod6: $21 = (0xa2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
mod6: so this for me is helpful as i can see how the array is changing through the steps
asciilifeform: mod6: try write a thing that prints'em bitwise , binarized , will make evenmoar sense
mod6: indeed, that would be best. i'd love to just see the entire array, in binary.
asciilifeform: mod6: phunphakt, originally i wanted an animated gif that shows the thing going
asciilifeform: fought with various tools for weeks
mod6: yeah, maybe i'll do that here soon alf. good suggestion
asciilifeform: 0 usable result came from it
mod6: oh
ben_vulpes: right, right. the mistake is thinking that FZs are laid out backwards from what they are
mod6: yeah, that'd have been really cool. who knows, maybe one of us will come with something like that eventually.
mod6: i kinda like those that i see on the web sometimese.
asciilifeform: ben_vulpes: it helps to picture the bits sitting 'arabic' style, with the least-significant on the right hand of the playing field, and the most-significant -- on the left
asciilifeform: hence 'left shift' by 1 , is a multiplication by 2; right shift - a division by 2
asciilifeform: elementarily.
ben_vulpes: yes, this i follow. the array of words in my head had the most significant word at the left instead of the right.
mod6: me too
asciilifeform: that's correct though !!
mod6: because in the above QR, 0x51 is in the left most word
asciilifeform: the confusion is when using the array notation in ada ( or c ), where the picture is reversed
asciilifeform: ( you have to list the least-significant, first , there )
mod6: ok so
mod6: (0x51, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
mod6: ^ LSB
mod6: ?
asciilifeform: lsw.
mod6: aha, ok
ben_vulpes: wait i just said that "the most significant word" was at the left and you said that was correct but now that's the least significant word?
asciilifeform: ben_vulpes: i was referring to the mental model that includes shift-left and shift-right concepts
asciilifeform: NOT TO ARRAY NOTATIONS
asciilifeform: array notations are backwards from the textbook and mental picture where 'shift left' increases magnitude and 'shift right' decreases.
asciilifeform: i suspect that this was at the root of ben_vulpes's puzzlement.
ben_vulpes: me too.
ben_vulpes: yeah, i totally see it now. carry from the leftmost word of of the array into the next word to the right.
asciilifeform: ben_vulpes: lemme know if you're cured, or need moar picture.
asciilifeform: also i recommend to ben_vulpes , mod6 , to post this log, it may help other readers.
ben_vulpes: i'll burn another pile of graph paper and get back to you, tyvm
asciilifeform: aite.
mod6: wb
TomServo: Thanks mod6
mod6: np, sorry, i forgot to restore this chan after my last disconn
mod6: I like how the image in the link that asciilifeform gave us is the same as the one in my 'Principles of Computer Architecture' book from 18 years ago.
mod6: <+asciilifeform> http://fourier.eng.hmc.edu/e85_old/lectures/arithmetic_html/node8.html << midway through the pg, another picture of same algo
mod6: (for Hardware for Division)
mod6: heheh
mod6: got my whiteboard cleared off. now to take a stroll down chapter 3 from back in 2000
asciilifeform: it aint as if the algo could have changed, mod6
asciilifeform: or ever will.
asciilifeform: been ~same since pyramids were built.
mod6: lol
mod6: alright, did a bunch of long binary division by hand over the weekend. nice refresher there.
mod6: will come in handy when I can actually get into this thing!
asciilifeform: neato

2017-12-31 | 2018-2-1