From: C R Onjob Date: Sat, 5 Jul 2014 17:00:02 +0000 (+0800) Subject: Automatic commit of irc logs X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=c705f85d36cae91b75365b11e76b0c2042c5982b;p=ipdf%2Fdocuments.git Automatic commit of irc logs You are as I am with You. --- diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 45cca1c..370fe6b 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -2204,3 +2204,81 @@ 22:04 < matches> I guess I just need to implement as many things as possible and compare them all 22:04 < matches> Seems easy enough... 22:04 < matches> (Famous last words) +--- Day changed Sat Jul 05 2014 +11:09 < matches> Well... subtraction took me two seconds +11:09 < matches> Should probably have just done it last night +11:09 < matches> I got distracted +11:09 < matches> By someone actually using my websocket library +11:09 < matches> Does this mean I'm officially an open source developer now +11:09 < matches> I didn't even give it a license :S +11:11 < matches> Hmm +11:12 < matches> Multiplication... +11:12 < matches> It is tempting to just use a for loop and call the += operator... +11:40 < matches> I'll do that for now I think +11:41 < matches> Once += actually works +11:41 < matches> Turns out I will definitely need division also +11:42 < matches> I was looking at the rationals going "There are no divisions here!" +11:42 < matches> But there are +11:42 < matches> In the gcd +11:42 < matches> Mind you maybe I don't need to call gcd if I have arbitrary integers :P +11:42 < matches> Just use all the memory +12:39 < matches> Ok for loop for multiplication is not easy +12:39 < matches> Bah +12:39 < matches> Having to actually learn assembly properly +12:40 < matches> I mean I could use a for loop but it would have to use an Arbitrary integer and take a very long time... +12:47 <@sulix> There's no need to have a for loop index > 64bit because there will never be enough memory for an integer that big. +12:47 < matches> True +12:54 < matches> Putting "_asm" in filenames so that our Makefile can do the .s files is kind of irritating +12:54 < matches> Would naming them .cpp work? That would be even more irritating though! +12:54 < matches> Oh well it compiles +12:58 < matches> I bet it turns out 128 bit integers would have been more than sufficient for any zoom range people could feasibly get to by scrolling +13:15 <@sulix> I'm told 256-bit integers can represent the visible universe to the width of a proton or something. +13:45 < matches> I might put a maximum length in once this works +13:45 < matches> So I'm not doing a Java +13:46 < matches> Where 1/3 becomes "Runtime Exception!" +13:46 < matches> That's with BigDouble not BigInt but whatever +14:00 < matches> I must admit, assembly is pretty nice for this sort of thing +14:00 < matches> At least, the inner operations +14:00 < matches> Not for managing the memory +15:29 < matches> Alright. We have an Arbint class that is equivelant to an int64_t when it only has one digit. +15:30 < matches> I'm not sure how to test that extra digits function correctly +15:30 < matches> Other than just looking at a few cases and going "Yep that looks right" :S +16:40 < matches> Well... somewhere along the way I lost kcachegrind and now I seem to have to run dist-upgrade to get it back +16:41 < matches> Currently 10% of the way through upgrading tex-live... +16:41 < matches> The mystery of just how shitty the Arbints are will have to wait +16:42 < matches> Well it's clear they are shitty but I suspect there is a bug in division +16:42 < matches> Maybe I should actually read my code +16:42 < matches> Blargh +16:47 < matches> Ok constructing a rational takes infinite time +16:51 < matches> Ah, 1 % 1 == 1 +16:51 < matches> That is definitely not correct :P +17:56 < matches> Oh my goodness I just rendered a frame +17:56 < matches> On the GPU... +18:00 <@sulix> Hmm... {add,sub}_digits_asm.s are missing from git. +18:05 < matches> Really +18:05 < matches> Whoops +18:07 < matches> There you go +18:07 < matches> Addition, subtraction, multiplication should be fine, I need to actually do division properly +18:08 < matches> Also probably pow at some point +18:08 < matches> Since pow still just casts things to doubles +18:22 <@sulix> It works! +18:22 <@sulix> (Eventually) +18:24 < matches> Haha +18:24 < matches> Of course it's still in the single digit range +18:24 < matches> Or did you manage to wait long enough to zoom a bit +18:25 < matches> I'm sure I can make this division better if I use some kind of binary searchish type algorithgm +18:25 < matches> I could look up the proper algorithm too I guess +18:25 <@sulix> Yeah, I was thinking binary search. +18:26 <@sulix> You'd want a decent bitshift implementation. +20:32 < matches> Yeah it is more difficult than I thought +20:33 < matches> I'm going to need "shift_digits" assembly functions +20:33 < matches> C style bit shifting has too many wierd edge cases +20:36 < matches> 0x7000000000000000 >> 3 == 0x0e00000000000000 ? +20:36 < matches> There are more bits set in the second number than the first! +20:38 < matches> And unlike multiplication where it fills an extra register for you, you just lose the extra bits with shr and shl :S +20:39 < matches> Except for a carry +20:39 < matches> So I'd have to do a loop one bit shift at a time +20:39 < matches> Blergh +20:40 < matches> I shall resume my epic battle with primary school level mathematics tomorrow +--- Day changed Sun Jul 06 2014 +00:32 <@sulix> long division of an arbint by a uint64 worksish.