That said... for compatibility with emix, you want to use tmix. umix, is the u (like in u/) used by tmix. imix does the part of the i=. expression in emix, ymix does the part of the y=. expression in emix.
Hopefully that makes sense... Thanks, -- Raul On Sat, Sep 5, 2015 at 8:24 PM, Raul Miller <[email protected]> wrote: > Oops, I should have included example uses. > > umix is a dyad - you need to give it a left argument saying how many > times you want it to run. > > Try: > 1 umix i.8 > > emix would need another loop (or a power conjunction) to achieve the same > thing. > > Thanks, > > -- > Raul > > > On Sat, Sep 5, 2015 at 7:00 PM, Jose Mario Quintana > <[email protected]> wrote: >> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
