1463 entries in 0.155s
sina: ok fuck this GPL hashing shit, let's just say, it's slow
sina: I missed all the tings
sina: as if that isn't one line of lisp?
sina: ben_vulpes: how fast can you run it against the GPL in my repo?
sina: watching this slow ass shit in python is making me want to start rewriting in C right now even though I have done nothing for the last ~24 except write this code, eat pizza and 8h of sleep
sina: anyone tell you guys that' you're fucking crazy? :D
sina: ben_vulpes: M = [0] * 32
sina: assuming it's a correct implementation of the spec anyway
sina: this is definitely going to need a system language impl
sina: oh right, its binary, stupid me
sina: wonder what it's doing
sina: still going, currently at 20893
sina: lol...the 2048 bit hash for GPLv2 was taking a really long time so I killed it to add some print statements. Checked "wc -c LICENSE", it reports ~18,000 chars. I re-ran mpfhf with 32 bits, thinking it'd finish at M_pos ~18,000
sina: ben_vulpes: if you count from 0 do we get same hashy hash?
sina: does it mean to the final of the array and n-1?
sina: sorry I don't grok that syntax diff
sina: or is this a spec bug
☟︎ sina: ok, so should I keep my screw implementation as is?
sina: so the step == M_pos
sina: there is no rewind, right?
sina: but when you have a string of all 1s
sina: I dunno if this makes any difference
sina: 64 1s and 32 1s result in hashes of all 0s
sina: then I get the same issue as you
sina: + flip(b, ((i+1 * M_pos) % len(b)))
sina: - flip(b, ((i * M_pos) % len(b)))
sina: yes but your reading of the footnote does seem correct, it starts at 1
sina: mircea_popescu: can you confirm/clarify same statement above, start at 0 or 1?
sina: I only mean in the sense, glaring errors or differences that cause disagreement between implementations, should be obvious
sina: ben_vulpes: also per above my halfscrew won't take any action if the len(a) is 1, can you confirm cl behaviour?
sina: ben_vulpes: as you can see my implementation for screw is only 3 lines long, can you see any faults in it?
sina: ben_vulpes: in your halfscrew I notice (underlying-screw b m-position (floor (/ (length a) 2)))
sina: also testing with pypy
sina: I dunno, I keep deleting the debug statements
sina: currently trying 2048bit hash of GPLv2 out of curiosity, will lety ou know when it finally completes :P
sina: changing it to the value of the iterator per ben_vulpes cl code fixed it
sina: I had it originally set to the value of the bit, and that was the cause of my cycle
sina: it's the value of the iterator, not the value of the bit at the iterator position?
sina: mircea_popescu: can you confirm/clarify "his operation consists of taking the bit count of either S or R, iterating over that value, at each step multiplying the iterator with the current position in M" ...
sina: mircea_popescu: there was a bug in my screw method which caused the cycle, once I identified it, it stopped cycling
sina: mircea_popescu: nope
sina: I keep taking the debug lines out because it's fucking impossible to follow the logic of the code with them in
sina: 0010111010001000101011101000100000110011110111011111001001110010
sina: cos I test with "M = [1] * 32"
sina: that was 32 chars of 1s right?
sina: 0110100011001111010010001111100000000001110001111000001001000001
sina: sorry can you clarify "re maxint"?
sina: e.g I get 1000010000110110001010111111010000010110110100000010010100110110 for "MP kicks ass!" 64
sina: I feel like my code is now correct, and it no longer loops. However I'm getting different results to ben_vulpes
sina: mircea_popescu: ok thanks
sina: mircea_popescu: earlier you said half screw should round down. In that case, if len is 1 the halfscrew will be 0. so should no iterations be peformed on halfscrew where the len is 1?
sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 32)
sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 64)
sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 32)
sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 64)
sina: the log msgs make it much harder to follow the code unfortunately, my code has the same issue :(
sina: oh, is it still workday where you are?
sina: ben_vulpes: any chance you'd be willing to take a peek at my code>?
sina: mircea_popescu: seems you're correct, "MP kicks3453453453 ass!" still loops
sina: for "MP kicks ass!"
sina: 1000111001011100101000010000100000000001111000010100001100000100
sina: making that modification and my thing no longer loops
sina: + * We expand S and screw R in S.
sina: - * We screw S in R.
sina: it seems to be flipping correctly :(
sina: lol, that changed it a little, now I loop at step 71 instead of 5 :P
sina: so, do we rewind, and then still increment?
sina: mircea_popescu: per the spec, " During each step, the function considers whether the position-th bit in M is 0 or 1, and executes a defined set of operations in either case. Once the operations have been executed, the position is incremented by one."
sina: damn debug statements make it impossible to follow
sina: mircea_popescu: pls help me understand rewind? doesn't it guarantee loops if I end up in a step which has a rewind? because I will go back one and then rewind?
sina: lol now I am in infinite loop
sina: gonna have to switch looping mechanism
sina: hmm, I don't think my rewind is working