emix i.8 68112070 67580715 540296643 2058 539239185 529307 67580712 539769534
umix i.8 |length error: SH | umix i.8 |[-23] ? On Sat, Sep 5, 2015 at 10:50 AM, Raul Miller <[email protected]> wrote: > Nice. > > Except, I prefer shift to take the number of bits as a left argument. > Also, there's still the matter of doing it tacitly. > > So, here's my rephrasing of your excellent work, for the explicit mix: > > top=: <:2^32 > SH =: top AND 34 b. NB. 32 bit shift > MP =: top AND + NB. 32 bit addition ("modplus") > > emix =: verb define > for_j. 11 _2 8 _16 10 _4 8 _9 do. > 'a b c d e f g h' =. y > i=. a XOR j SH b > y =. (b MP c), c, (d MP i), e, f, g, h, i > end. > ) > > And, here is a tacit equivalent: > > rfold=: 1 :'u&.>/@,&.:(<"_1),:' > tmix=: _9 8 _4 10 _16 8 _2 11 umix rfold ] > imix=: 1 }. ], (0,[) XOR/@SH 2 {. ] > ymix=: MP/ .*&(8 8$1(8 58}),=i.8) > umix=: ymix@imix > > Honestly, though, I prefer the explicit version. It's simpler, more > concise, and faster. But I think that that is more a direct > consequence of the (somewhat arbitrary) design of the algorithm than > anything else. > > Thanks, > > -- > Raul > > On Sat, Sep 5, 2015 at 12:33 AM, Michal Wallace > <[email protected]> wrote: > > It's just a hashing algorithm, mixing up the bits of data in a > > deterministic but irreversible way. > > > > If you notice that the "alphabet-distance" between the variable names on > > each line is always the same, > > my implementation might make more sense. Since the offsets are always the > > same, I'm just rotating the > > array and re-applying the same logic. > > > > Here's the c code that will tell us what the result should be for mix > i.8: > > > > #include <stdio.h> > > int main() { > > int a,b,c,d,e,f,g,h; > > a=0;b=1;c=2;d=3;e=4;f=5;g=6;h=7; > > a^=b<<11; d+=a; b+=c; > > b^=c>>2; e+=b; c+=d; > > c^=d<<8; f+=c; d+=e; > > d^=e>>16; g+=d; e+=f; > > e^=f<<10; h+=e; f+=g; > > f^=g>>4; a+=f; g+=h; > > g^=h<<8; b+=g; h+=a; > > h^=a>>9; c+=h; a+=b; > > // a b c d e f g h > > printf("%d %d %d %d %d %d %d %d\n", a,b,c,d,e,f,g,h); > > } > > > > Answer: > > > > 68112070 67580715 540296643 2058 539239185 529307 67580712 539769534 > > > > Here's the corrected code: > > > > top=: <:2^32 > > > > SH =: top AND (34 b.)~ NB. 32 bit shift > > > > MP =: top AND + NB. 32 bit addition ("modplus") > > > > mix =: verb define > > > > for_i. 11 _2 8 _16 10 _4 8 _9 do. > > > > 'a b c d e f g h' =. y > > > > x =. a XOR b SH i > > > > y =. 1 |. x, (b MP c), c, (d MP x), e, f, g, h > > > > end. > > > > ) > > > > > > assert (mix i.8) -: 68112070 67580715 540296643 2058 539239185 529307 > > 67580712 539769534 > > > > > > > > > > > > > > > > On Fri, Sep 4, 2015 at 10:34 PM, Dan Bron <[email protected]> wrote: > > > >> Michal Wallace wrote: > >> > I don't know whether or not this produces the correct results because > I > >> > don't have any test data, but... > >> > >> > >> Yeah, that is troublesome. Unfortunately, it’s the same catch-22 I’m > in. > >> > >> I’m transliterating the C code here: > >> > >> http://rosettacode.org/wiki/The_ISAAC_Cipher#C < > >> http://rosettacode.org/wiki/The_ISAAC_Cipher#C> > >> > >> as directly as possible into J, so that I can get a working program > which > >> produces the expected outputs for the given inputs. > >> > >> Once I have a working program that I can test, interrogate, and reason > >> about, I’ll be in a much better position to refactor the code into > >> idiomatic, and, hopefully, elegant J. > >> > >> But the very reason I have to do it this cart-before-horse way is > because > >> I don’t (yet) understand the algorithm on a conceptual level. So I’m > >> starting from the code. > >> > >> I guess what I was asking for in my previous email was for someone who > >> does or can easily grok the concepts underlying the code to express > them in > >> J (which is a language I speak, so such code would teach me those > concepts). > >> > >> Barring that, someone who is confident enough in his C to trust in his > >> translation of the macro would also suffice. > >> > >> (One big obstacle here, and I think more broadly to the lack of adoption > >> of ISAAC the author of that article laments is the majority of > >> easily-accessible artifacts dealing with it are code, rather than > prose.) > >> > >> -Dan > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
