22:11 <@matches> But they won't be fixed size
22:12 <@matches> Anyway I will see if you have magically solved the problem for me in the morning :P
22:14 <@sulix> I wouldn't count on it...
+--- Day changed Wed Jun 18 2014
+16:50 <@matches> Behold, the glory of Beziers and Bresenham!
+16:50 <@matches> Breseniers I shall call them
+16:54 <@matches> I'm getting a very strong vibe of "Reinventing graphics technologies from the 1990s" at the moment
+16:55 <@matches> I should probably look at floating point some more
+16:55 <@matches> And reinvent numerical computation technologies from the 1980s
+16:56 <@matches> We need a GPU renderer for the Beziers, and we need to fix save/load to not assume everything is a fixed size, and ...
+16:56 <@matches> Argh
+16:56 <@matches> All the things
+17:00 <@matches> Maybe I'll multithread the CPU rendering too, just to make things more difficult :P
+22:48 <@sulix> So I got some béziers rendering on the GPU.
+22:48 <@sulix> They're not the ones in the document, and they're not in the right spots, though.
+23:12 <@sulix> First 3 béziers are rendering properly on the GPU, then we get corrupted memory or something.
+23:14 <@sulix> Ah: I see, I need some way of uploading which bézier IDs are being used.
+23:41 <@sulix> Okay, Béziers now render on the GPU as well.
+23:43 <@sulix> The code is a little bit ugly, and for that I am sorry, but blame the fact that the GL feature that makes this nice is only about a year old and so nothing supports it.
+23:43 <@sulix> So we're basically uploading all of the raw document data into a huge texture.
+23:47 <@sulix> (If you ask me, the GPU ones also look slightly nicer, though that's probably a bug)
+--- Day changed Thu Jun 19 2014
+13:55 <@matches> From those papers I was under the impression just rendering a bezier on a GPU was an impressive feat, so well done :P
+13:57 <@sulix> (It's basically just a direct port of your CPU implementation, tbh)
+13:59 <@matches> When I zoom out the GPU ones look nicer, there's probably something wrong with my Bresenham implementation
+13:59 <@matches> Although it was mostly shamelessly copied from "Computer Graphics"
+13:59 <@matches> Except they were like "Here it is for 0 < m < 1, the rest can be done by symmetry"
+14:02 <@matches> The lines definitely have gaps on the CPU, and they also seem too thick as you zoom out
+14:02 <@matches> Having said that, I don't think the GPU starts at x0,y0
+14:03 <@matches> Anyway I'm going to implement a Rational number type and see if anything exciting happens (that's how you do research right?)
+14:06 <@matches> Fortunately I sort of did most of this for one of the codejam problems (where it turned out I didn't really need Rational numbers but I thought I did)
+14:20 <@sulix> Fixed the missing bit off the end.
+16:43 <@matches> I suspect Rationals are either not a very good idea, or there is a bug in one of my fundamental operations
+16:43 <@matches> +, -, *, / are hard
+16:56 <@sulix> Is it at least a pretty bug?
+16:59 <@matches> Um...
+16:59 <@matches> No
+17:00 <@matches> It seems buggy for anything other than the {0,0,1,1} starting view
+17:14 <@matches> I suspect it's the expf in the mouse wheel scrolling
+17:14 <@matches> Since you know, exp is definitely not a rational number...
+17:15 <@matches> Hmm, but it shouldn't matter because it will just convert to the nearest rational number
+17:16 <@matches> ie: p = (int64_t)(whatever*1e10) q = (int64_t)1e10
+17:28 <@matches> Oh
+17:28 <@matches> Oh
+17:28 <@matches> Head -> Desk
+17:28 <@matches> Rational & operator*=(const Rational & r) {this->operator=(*this*r); return *this;}
+17:28 <@matches> Rational & operator/=(const Rational & r) {this->operator=(*this*r); return *this;}
+17:29 <@matches> Rational & operator-=(const Rational & r) {this->operator=(*this+r); return *this;}
+17:29 <@matches> I think the worst part is that I actually said "It is probably a bug in my +,-,*,/
+17:29 <@matches> And it still took me this long to notice
+17:30 <@matches> The second worst thing is I've made that sort of mistake like 1000 times before
+17:30 <@matches> The third worst thing is I am recalling that article where the guy says "At least plus and times are sort of the same thing"
+17:30 <@sulix> Feel the power of copy and paste flowing through you.
+17:32 <@matches> Well let's not celebrate just yet, the view still goes to shit. Just slightly slower :P
+17:33 -!- matches changed the topic of #ipdf to: NaNpdf
+17:33 <@matches> Our document supports a view of {-inf,-inf,nan,nan} thus making it truly infinite precision
+17:34 <@sulix> I had that happen a lot when I was writing the original zoom code.
+18:19 <@matches> So I suspect that Rationals are just a really shitty number representation :P
+18:20 <@matches> Specifically, you get integer overflows really really fast
+18:20 <@matches> And if you are going to have a Rational that's BigInt / BigInt you may as well just have a BigFloat
+18:21 <@matches> The ancients were probably right.
+18:21 <@matches> When they decided not to use rationals.
+18:23 <@matches> I guess floats are rationals technically, I mean the representation using P/Q
+18:23 <@matches> I kind of wish I'd done some pure maths here...
+18:23 <@matches> Or paid more attention in second year
+18:28 <@matches> At least I sort of have conclusive evidence that rationals suck. As opposed to "it should be obvious to anyone with half a brain"
+19:00 <@sulix> Floats are not rationals.
+19:00 <@sulix> Not exactly.
+19:01 <@sulix> Something which can be stored in a finite amount of space as a rational cannot always be stored in a finite amount of space as a float, but not vice-versa.
+19:01 <@sulix> e.g.: 1/3
+19:04 <@sulix> Basically floats = rationals where the denominator must be a power of two.
+19:05 <@sulix> (Of course, these are all the same in the limit, but the limit of a cauchy sequence of rationals gives the reals, so the point is kinda moot, there, anyway)
+19:18 <@matches> Yeah floats are a subset of the rationals I think I meant
+--- Day changed Sat Jun 21 2014
+16:22 <@matches> So I got a new smartphone today... I'm having fun trying to zoom in on things
+16:24 <@matches> Actually the zooming isn't annoying so much as the needing to pan around to view all the text in a pdf
+16:25 <@matches> This is what I get for buying the cheapest phone with the lowest resolution they had :P
+16:26 <@matches> I didn't want to get one more expensive than my old one because I'm still convinced I will get around to fixing it one of these days
+16:26 <@matches> Or months. Or years. But eventually.
+--- Day changed Mon Jun 23 2014
+11:51 <@matches> The meeting happened at ~11:30
+12:49 <@sulix> Oh damn. I thought there wasn't going to be one today.
+12:49 <@sulix> What did I miss?
+13:04 <@matches> Basically I told him what we'd done
+13:05 <@matches> Which was rendering on CPU or GPU, and Beziers (but only degree 2)
+13:06 <@matches> And I implemented Rationals but they are terrible, so he sent me some code from an ACM competition about approximating things with Rationals
+13:13 <@sulix> Some javascript guy is trying to convince people that the only numeric data type should be some custom 64-bit decimal thing.
+13:13 <@sulix> A lot of people have started quoting Kahan at him.
+13:20 <@matches> Haha
+--- Log closed Tue Jun 24 16:07:29 2014
+--- Log opened Tue Jun 24 16:17:39 2014
+16:17 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+16:17 -!- Irssi: Join to #ipdf was synced in 15 secs
+--- Day changed Wed Jun 25 2014
+21:41 < matches> So... if we need to put a HTTP server in IPDF I've got us covered...
+21:44 <@sulix> You terrify me.
+21:45 < matches> I still have to work out Websockets
+21:45 < matches> They are silly
+21:46 <@sulix> I take it they aren't compatible with regular sockets.
+21:46 < matches> Well you use a TCP socket, but they aren't just plain text
+21:46 < matches> There's a protocol on top of it
+21:46 < matches> It's wired
+21:47 < matches> *wierd
+21:47 < matches> There are frames and things
+21:47 < matches> And copious amounts of base64 encoding the SHA1 hash of a string prepended to a magic string
+21:48 < matches> Apparently this makes it more secure
+21:48 * sulix looks doubtful.
+21:48 <@sulix> I could understand it being more secure if they actually encrypted things.
+21:48 < matches> They have wss:// as well which is just the same thing through ssl
+21:48 < matches> Yes it doesn't make sense
+21:49 <@sulix> But plain "boring" TCP has been used since (I am assured) the beginning of time and there are still one or two things that use it which are not currently being hacked into.
+21:49 < matches> Haha
+21:49 < matches> I'd like websockets so I can control my robot via my phone through its web browser...
+21:50 < matches> I can probably do that without websockets but it will also be useful for humphrey the rabbit
+21:50 <@sulix> Surely with plain old TCP you could control your robot via telnet, which is more awesome and just as user friendly.
+21:51 < matches> :P
+21:51 < matches> It will have a webcam image though
+21:51 * sulix mutters "ASCII art" under his breath.
+21:52 < matches> I figure if I implement everything in C++ it will be less "Webby"
+21:52 < matches> And more segfaultastic
+21:52 * sulix has a new favourite word.
+--- Day changed Thu Jun 26 2014
+14:58 < matches> I think the WebSocket RFC put this "Framing" business in just to confuse people
+14:58 < matches> My RFC Compliant* WebSocket server just sends the entire message in a single frame
+14:59 < matches> Doesn't TCP already do framing or something
+15:00 < matches> I mean, they specifically allow for frames with up to 2^63 bytes
+15:00 < matches> Sorry, bits not bytes
+15:02 < matches> So server -> client is pretty much TCP but you stick some stupid frame guff on the message
+15:02 < matches> client -> server involves... "masking"
+15:02 < matches> There are several long paragraphs on it
+15:10 < matches> I'm going to pretend this is related to precision
+--- Day changed Wed Jul 02 2014
+17:30 < matches> I put the code repository on github
+17:32 < matches> This is where a more hip and cool person would say something like "#yolo" but I prefer to wonder how I got 26K of lines and you have 65K...
+17:32 < matches> "How many lines of code does it take to draw a rectangle?" 91000
+--- Day changed Fri Jul 04 2014
+12:59 < matches> Found my rational bug
+13:00 < matches> ...
+13:00 < matches> Copy paste strikes again
+13:00 < matches> My operator/ looked suspiciously similar to operator+ -_-
+13:00 < matches> -____-
+13:02 < matches> Not sure how it got like that, it was definitely working at one point
+13:02 * matches should probably use git properly
+13:12 < matches> Pushed it
+13:21 < matches> So yeah, it should work fine until you zoom
+13:21 < matches> Then crazy things happen
+16:44 < matches> I think all the references you added at the last minute break my litreview
+16:45 < matches> (he says several months later :P_
+21:00 <@sulix> Question: in Rational::Simplify(), why is (-P)/(-Q) becoming (-P)/(Q) rather than P/Q?
+21:01 <@sulix> Shouldn't P = -P here? http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/rational.h;h=41cce09078b4e96eb17a6bb6e28478ea64637b57;hb=HEAD#l74
+21:02 <@sulix> Also zoom can be improved (but not totally fixed) by reducing precision when overflow would be possible.
+21:19 < matches> Yeah, that's the idea of using the Stern Barcot tree Tim was talking about
+21:20 < matches> Which I still need to read about
+21:20 < matches> Also yes P should be -P because I am just that amazing at maths
+21:22 < matches> In other news assembly happened
+21:22 < matches> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s
+21:22 < matches> Which no doubt has terrible bugs in it :P
+21:23 < matches> It was a bit confusing how passing and returning arguments with x64 was completely and utterly different from x86 and almost every tutorial is from at least ten years ago talking about x86
+21:24 < matches> x64 is actually much easier though
+21:25 < matches> At least, I think they are different, I didn't have to mess with the stack which seemed to be a thing with x86 and also that motorolla language we used in first year
+21:25 < matches> Just got all the arguments in a bunch of registers
+21:31 <@sulix> I think I just worked out why you have 16 "inc" instructions, and am loving it!
+21:32 <@sulix> inc doesn't change flags!
+21:32 < matches> I wonder if it would be faster to just store the carry flag in a register though
+21:33 < matches> Actually probably not because there'd be branches involved
+21:33 < matches> Hmm
+21:33 <@sulix> Traditionally, mucking about with flags is slow.
+21:33 < matches> Yep cool
+21:34 < matches> I've got the AMD64 ABI
+21:34 < matches> Chapter 2 is a good one
+21:34 < matches> "Software Installation"
+21:35 < matches> "This document does not specify how software must be installed on an AMD64 architecture machine"
+21:35 < matches> End chapter
+21:35 <@sulix> Just a thought, can use use the lea instruction instead of all of those incs.
+21:37 <@sulix> Like lea rsi, [rsi+8h]?
+21:37 * sulix ponders.
+21:38 < matches> Maybe, my assembly is very rusty and was based on those ELEC1301 labs in the first place...
+21:38 < matches> I don't even remember if they had lea
+21:39 <@sulix> (Also I just got a message from KDE: "could not launch a process. perhaps you have reached the limit of running processes")
+21:39 < matches> :S
+21:40 < matches> When did you last reboot?
+21:40 <@sulix> This morning, actually.
+21:40 < matches> Integer overflow in PID?
+21:40 <@sulix> It looks like it was an out-of-memory problem.
+21:40 <@sulix> On a related note, the intel instruction set documentation is a 3 and a half thousand page pdf.
+21:41 <@sulix> and firefox has a PDF viewer written in javascript.
+21:41 <@sulix> ...that runs by default.
+21:44 < matches> Hahaha
+21:44 < matches> Yes, pdf.js is apparently the best thing since sliced bread...
+21:45 < matches> I'm having some difficulty with lea, possibly the syntax
+21:47 < matches> "lea (%rsi+8), %rsi" is wrong
+21:48 <@sulix> Yeah, gcc's assembler uses whacked syntax.
+21:48 < matches> I thought it was just () instead of [], add % to all the registers, and swap destination and source
+21:48 <@sulix> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s;hb=HEAD
+21:49 <@sulix> They replaced the arithmetic operators with strange things, too.
+21:49 < matches> Riight
+21:49 < matches> Thanks
+21:49 < matches> So 8(,%rdi,1) means [rdi+8]
+21:49 < matches> That is dumb
+21:49 <@sulix> I'm not sure if it's worth using nasm or the ".syntax intel" directive.
+21:51 < matches> Hopefully there won't be too much more assembly to write...
+21:51 <@sulix> Technichally lea (and other memory addressing instructions) take the form "[register+register*(1,2 or 4)+(number)]" in intel and "number(%register,%register,(1,2 or 4))"
+21:51 <@sulix> in gcc
+21:51 < matches> ok
+21:51 < matches> Well once I know the syntax I can cope with it
+21:51 < matches> But all the documentation being written in a different syntax doesn't help :P
+21:52 <@sulix> Yeah, there are a lot of people who hate gcc syntax, which was an (unsuccessful) attempt to make assembly for different machines more consistent)
+21:52 < matches> I decided to go with it because I vaguely remembered your commander keen patches looked like they were in gcc syntax :P
+21:53 <@sulix> Hah: they were in "ckpatch" syntax.
+21:53 <@sulix> And were just the final output bytes.
+21:53 < matches> The memory can play strange tricks...
+21:54 <@sulix> I used the "debug.com" utility that came with dos to assemble them, which let you write assembly to arbitrary memory.
+21:54 <@sulix> and then read the contents of that memory to see what it assembled down to.
+21:55 < matches> So, I need subtraction and multiplication but not division to implement arbitrary rationals
+21:55 < matches> I'll try sort those out tomorrow
+21:56 < matches> I'm pretty sure I'm doing better than at least one arbitrary integer representation
+21:56 < matches> Which had a int32_t word and int64_t "double" word
+21:56 < matches> So they could tell if they had a carry by doing the additions using double words
+21:57 < matches> The code in C was longer than add_digits is in assembly
+21:57 < matches> Although to be fair it might actually work on things that aren't amd64
+21:57 <@sulix> Well, the good news is that there's an "sbb" instruction like "adc"
+21:57 < matches> Excellent
+21:58 <@sulix> The bad news is that multiplication is harder.
+21:58 < matches> Yeah, at least I don't need division though
+21:59 < matches> Although converting it to a string will be annoying
+21:59 <@sulix> IIRC, the IMUL instruction gives an output twice as long as the inputs, to prevent overflow.
+22:00 <@sulix> Converting to a string won't be so bad if you get division done.
+22:00 <@sulix> And you can always just implement multiplication and division by slow recursive addition/subtraction.
+22:03 < matches> There's a bunch of papers on number representations that use things that aren't floats or rationals from a quick look
+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.
+09:47 <@sulix> long division of an arbint by a uint64 now actually works and is less obviously badly designed
+10:32 < matches> Thanks...
+10:33 < matches> In other news I seem to have broken X again
+10:34 <@sulix> Oh no!
+10:35 < matches> We need an ASCI renderer...
+10:36 <@sulix> That can not possibly end badly.
+10:40 < matches> shouldn't be too hard...
+10:40 < matches> Lets see if reinstalling fglrx works
+10:41 < matches> I need to add that to a boot script :S
+10:42 < matches> uhoh installation failed
+10:48 <@sulix> Hmm... enabling optimization makes Arbint segfault.
+10:49 < matches> You should probably make quadtrees
+10:50 < matches> Although I admit you're better at Arbints than me :P
+10:50 <@sulix> Yeah... I should.
+10:50 <@sulix> But segfaults...
+10:51 < matches> Yeah somewhere in std vector I had some as well
+10:51 < matches> I think I might change to a custom dynamic array
+10:52 < matches> Then fast copying is easier
+10:52 <@sulix> Yeah, it's segfaulting in std::swap somewhere, I think.
+10:52 < matches> I'll fix it when I have X
+10:53 < matches> Or an ascii renderer...
+10:54 < matches> Probably more realistic at this stage
+10:55 <@sulix> I'm pretty certain there's a unicode character for "face of disapproval due to fglrx bugginess".
+10:56 < matches> Yeah but when you try and render it you get a seg fault
+11:24 < matches> Woo, xvesa
+11:26 < matches> I see what you mean about fglrx being hard to remove
+11:58 <@sulix> So: quick profile. 98% of frame rendering time is spent in Arbint::Division.
+11:59 < matches> Yeah
+12:00 < matches> I *was* trying to install kcachegrind you know
+12:00 <@sulix> The vast majority of that time is spent in malloc and free.
+12:01 < matches> Well copy constructing an Arbint requires copy constructing the vector
+12:01 < matches> I'll investigate
+12:01 < matches> Now I have X again
+12:01 < matches> Go make a quad tree
+12:02 <@sulix> Also, should add_digits clear the carry flag at the beginning?
+12:02 < matches> Hmm
+12:02 < matches> Probably
+12:02 < matches> Yeah
+12:09 < matches> I suspect having a copy-on-write Arbint won't help as much as having a non-terrible division algorithm so I'll try fix that first
+12:09 < matches> But copy-on-write Arbint shouldn't be too hard
+12:09 < matches> Oh unless the original changes
+12:10 < matches> Yeah it would be hard
+12:10 < matches> I'm sure I did something like it before
+12:10 < matches> Back when I actually made my own data structures instead of just using std::vector
+12:15 <@sulix> My custom vector class: http://davidgow.net/stuff/DynamicArray.h
+12:15 <@sulix> Probably won't compile without a bunch of other files, though.
+12:16 < matches> I think I have several, in different versions of neurosis
+12:16 < matches> Which was never under git
+12:16 < matches> Some of them were prone to segfaults though
+12:17 < matches> So, will you have some kind of quad-tree-y thing by monday? :P
+12:17 <@sulix> Mine works, but doesn't call constructors or destructors, so it's only really useful for ints/floats/pointers or structs thereof.
+12:18 <@sulix> I have a "struct QuadTree".
+12:18 <@sulix> (You can't do anything with it, but the basic idea is there)
+12:20 < matches> My shifting operators might not have been as fith as I thought last night
+12:20 < matches> Since 7 and e do actually have the same number of bits
+12:21 < matches> I'm not sure where that came from
+12:21 < matches> Ah dammit
+12:21 < matches> Cannot find -lGL
+12:22 <@sulix> Try just removing that from the Makefile
+12:22 <@sulix> I think when I GL-3'd everything I made it load libGL at runtime.
+12:23 < matches> Well it will compile but I get glx errors
+12:23 < matches> I get similar errors running glxinfo though...
+12:24 < matches> Odd
+12:26 <@sulix> I think you still have some of fglrx breaking things.
+12:26 <@sulix> It replaces the system libGL.so
+12:26 < matches> I installed mesa's stuff
+12:27 <@sulix> You need to also get the version of libGL that runs as part of the X server, IIRC.
+12:28 < matches> I'll try some apt-get --reinstalls
+12:29 < matches> I think most of my problems were that debian was going "You don't have a graphics driver, here, have one" and then things were breaking and reinstalling fglrx would give me graphics but leave me with a partially installed debian driver as well :S
+12:30 < matches> Well ok
+12:30 < matches> most of my problems were fglrx
+12:30 <@sulix> I remain sceptical that installing fglrx by hand will ever cause anything that is not pain.
+12:30 < matches> Well it worked better than the open source drivers for a very long time
+12:30 < matches> It all ended in tears and segfaults though
+12:32 < matches> Also it worked better than the non-free fglrx package in the debian repos which always ended in tears and segfaults
+12:33 <@sulix> I use the non-free nvidia package, which works fine, even if it is horribly outdated.
+12:34 <@sulix> I'm scared of the sheer amount of ripping up the rendering code getting quadtrees working will take.
+12:39 < matches> Haha
+12:40 < matches> It might be easier to do the CPU rendering in quad trees first?
+12:40 < matches> I'm not quite sure how you'll do it
+12:41 < matches> CPU rendering at least gives you direct control over the rendering target as a pixel buffer
+12:41 < matches> GPU rendering is a bit shady (ho ho)
+12:41 <@sulix> ...
+12:42 <@sulix> That was terrible, yet accurate!
+12:42 < matches> With the CPU rendering we're already passing the objects list, view, and target bounds
+12:42 < matches> So maybe you can adapt View or something to be quad-tree-ish
+12:43 < matches> Good luck
+12:44 <@sulix> Yeah, the current plan is to adapt the rendering stuff to accept a "first object id" and "last object id", and then only render those.
+12:47 < matches> Hmm, you could call RenderUsingCPU with a different target pixel buffer for each part of your quad tree or something
+12:48 < matches> Oh well, hopefully I can adapt whatever you do into RenderUsingASCII :P
+12:49 < matches> I don't need GLX working to try and fix division but I'd really like to have GLX working
+12:49 < matches> Sigh
+13:12 < matches> I'm making progress, instead of reporting an invalid operation glxinfo segfaults now
+13:13 < matches> So I have the wrong libraries or something... how to get the right ones...
+13:32 <@sulix> Woo. I got it compiling again!
+13:32 <@sulix> And the rendering is only half-wrong.
+13:33 < matches> Nice
+13:33 < matches> Manually deleting anything on my system with fglrx in it...
+13:34 <@sulix> Someone really needs to write an "fglrx removal guide".
+13:34 < matches> I'm not sure why reinstalling the radeon driver and mesa isn't actually giving me a libGL
+13:34 < matches> At least
+13:34 < matches> I suspect it is just leaving the existing broken one
+13:36 <@sulix> So it turns out that *2 I don't understand is important.
+14:01 < matches> Ok
+14:01 < matches> I have glxgears
+14:01 < matches> An epic achievement
+14:01 < matches> I had to go back to fglrx but at least this time its the debian packaged version
+14:02 < matches> The radeon driver seems to work better for stuff that isn't glx
+14:03 < matches> Which is pretty cool but I kind of like glx actually working
+14:11 < matches> Ok... time to fix division
+14:11 < matches> Finally
+14:11 < matches> No wait time for coffee
+14:11 < matches> Then time to fix division
+14:24 < matches> Did you test the div_digits function at all?
+14:25 < matches> # We want to point to the end of the buffer (LSB)
+14:25 < matches> Aren't I doing it the other way around...
+14:25 < matches> I'll test it
+14:28 <@sulix> With long division you do things in the opposite direction to addition.
+14:29 <@sulix> I tested it with some simple things and it worked.
+14:34 < matches> Hmm
+16:35 < matches> Well the good news is that division is faster now
+16:35 <@sulix> Cool!
+16:36 < matches> The bad news is that I can't see anything
+16:36 < matches> Even when GPU rendering
+16:36 < matches> Also segfaults
+16:36 <@sulix> I've just pushed some initial quadtree-enabling breakage.
+16:36 < matches> I didn't work out how to apply the div_digits to a multi digit number either
+16:36 <@sulix> Yeah, I thought about that, then went to bed.
+16:36 < matches> I might convert the current algorithm which is all based on bit shifting
+16:36 < matches> To assembly
+16:37 < matches> But maybe not
+16:37 < matches> Actually being able to see something render would be good even if it were slow
+16:37 < matches> Then I can think about making it faster
+16:38 <@sulix> The old one had all of the beziers connected for no readily apparent reason.
+16:38 < matches> I have a tester called "Arbitrary Rationals" (arbrationals.cpp) which sounds like some kind of political party
+16:39 < matches> A rather indecisive political party
+16:39 <@sulix> That's amazing.
+16:48 < matches> Ah, I might be having trouble with the sign of things, hm
+16:49 < matches> Rational 15625/288230376151727369 (0.000000) is not close enough at representing 1.000000 (1.000000 vs 0.001000)
+16:49 < matches> That doesn't look like a sign problem...
+16:52 <@sulix> I admit, 15625/288230376151727369 is not really similar to 1.
+16:54 < matches> So, somewhere along the way Arbint(1e6) became 15625 and Arbint(1e6) also became 288230376151727369 ?
+16:54 < matches> Uninitialised things?
+16:54 < matches> Constructing from int64_t seems fine
+17:00 < matches> That amazing moment when it works perfectly and then you realise that's because you compiled with reals as doubles and not rationals
+17:00 <@sulix> Ha: I've done that a few times.
+17:19 < matches> Maybe I shouldn't have pulled your latest commit
+17:19 < matches> Now I have two problems :(
+17:22 < matches> Meeting tomorrow
+17:22 < matches> "So how much progress have you made?"
+17:22 < matches> "Segfaults are up 100% to a record high!"
+17:26 < matches> Oh ok
+17:26 < matches> I'm not sure if this is new
+17:26 < matches> But if there is nothing in the document the GPU rendering doesn't like it
+17:27 <@sulix> Hmmm... there might be some issues with that.
+17:28 < matches> Ok
+17:28 < matches> Rectangle renders
+17:28 < matches> With arbitrary rationals
+17:28 < matches> In the default view
+17:29 <@sulix> Ooh!
+17:31 < matches> I'm going to commit this even though it's totally broken
+17:32 <@sulix> Things being broken hasn't stopped me from committing them.
+17:35 < matches> I love this though
+17:35 < matches> When you activate CPU rendering
+17:36 < matches> You get like a billion errors from Rational<Arbint>::CheckAccuracy
+17:36 < matches> And then the Bezier appears!
+17:36 < matches> Magically!
+17:36 < matches> I guess I shouldn't rule out a bug in CheckAccuracy :P
+17:36 < matches> Although zooming will definitely cause a segfault
+17:38 <@sulix> I tried running the really slow version under valgrind, but that turned out to be a bad idea.
+17:39 < matches> I've pushed the slightly less really slow version
+17:39 < matches> That is still really slow
+17:39 < matches> I can't install kcachegrind
+17:39 < matches> It is really annoying
+17:40 < matches> There aren't any valgrind analysis things that don't require the entirity of KDE are there?
+17:40 < matches> Or should I just learn how to read the raw output files
+17:40 <@sulix> Cool: it works.
+17:41 <@sulix> (I dunno, I just use KDE :P)
+17:41 <@sulix> You can try "perf" or "oprofile".
+17:41 < matches> Well I can't even install KDE :S
+17:41 <@sulix> They're terminal-based.
+17:41 <@sulix> Well, perf is, at least. There's a gtk+ oprofile gui.
+17:41 <@sulix> They both measure the entire system by default though.
+17:43 <@sulix> Rational::Simplify is ~54% of time (w/ GPU rendering) with the new build, according to callgrind.
+17:50 < matches> I'm a little confused by some of the outputs of Rational::CheckAccuracy given that it does actually seem to render the bezier properly on the CPU
+17:50 < matches> I think the segfault might be related to my (ab)use of things like memcpy on std::vector::data()
+17:52 < matches> Also I think I've fixed my dependency hell
+17:52 < matches> Well
+17:53 < matches> Depending on how this turns out I will end up with the entirity of KDE hopefully including kcachegrind, or I will end up with no X again
+17:53 < matches> And much swearing will ensue
+17:54 <@sulix> Yeah, it segfaults immediately if you enable optimization level 2 or higher.
+17:55 < matches> Hm
+17:56 < matches> I'll probably get rid of std::vector then
+17:57 <@sulix> The problem I'm seeing is in the vector<Bezier>::push_back() bit, so who knows what is going on.
+17:58 < matches> Oh that's odd
+17:58 <@sulix> Okay, don't run it in valgrind.
+17:58 <@sulix> I'm getting about 200 "uninitialized values" a second in the nVidia driver.
+17:58 < matches> But I just installed kcachegrind!
+17:59 <@sulix> (Oh wait, that was with REAL=double)
+17:59 < matches> Haha
+18:00 < matches> Wait, vector<Bezier>::push_back causes problems even with REAL=double :S
+18:00 <@sulix> Nah, the nVidia driver seems to.
+18:01 <@sulix> I've now compiled again with REAL=5 and I'm getting a number of invalid reads off the end of the vector<digit_t> in GetBit()
+18:02 < matches> Division
+18:02 < matches> Oh
+18:02 < matches> oooh
+18:02 < matches> > -> >=
+18:02 < matches> ...
+18:03 <@sulix> Well, my first attempt to fix it just broke rendering.
+18:04 <@sulix> Ah, yep, I see it.
+18:05 < matches> I think I need to do less memcpy/memseting and more std::vector::operator= -_-
+18:05 < matches> I mean, they implemented it for a reason
+18:05 <@sulix> So, with that change it no longer segfaults!
+18:05 <@sulix> (It corrupts memory and throws an exception instead)
+18:05 < matches> Woah
+18:06 < matches> I changed Arbint operator= to use std::vector operator=
+18:06 < matches> And now I get a filled circle on top of my bezier...
+18:07 < matches> Ok, I will rewrite Arbint to just rely solely on std::vector operations
+18:08 < matches> That might slow it down but it's impossible to test that the maths works properly with all these memory errors
+18:09 <@sulix> Should you be using m_sign more often?
+18:09 <@sulix> It seems to be "forgotten" in a number of places...
+18:10 <@sulix> Hmm... everything looks like it's working at the moment, actually.
+18:10 < matches> What else did you change?
+18:10 < matches> Try zooming
+18:11 < matches> That will break it
+18:11 <@sulix> Zooming seemed to work, actually.
+18:11 < matches> Are you sure you compiled with REAL=5
+18:11 < matches> The sign is a bit wierd
+18:12 <@sulix> It works for a little bit, then the view bounds suddenly become huge.
+18:12 < matches> Haha
+18:12 <@sulix> For no reason, the y coordinate jumps to 10^8.
+18:13 <@sulix> Also after you've zoomed, sometimes translating goes in the wrong direction or is otherwise broken.
+18:15 < matches> That might be related to m_sign...
+18:15 < matches> The joys of implementing your own number representation
+18:16 <@sulix> Trying to "fix" the sign fixed zoom, but broke translation even more.
+18:18 <@sulix> Also: best representation of 1 ever: 9223372036854775807/9223372036854775807
+18:18 < matches> Hahaha
+18:18 < matches> Oh
+18:18 < matches> I think I commented out a Simplify() somewhere :P
+18:18 < matches> No
+18:18 < matches> I didn't
+18:18 < matches> Hmm
+18:19 < matches> Well I am going to push some minor changes
+18:20 <@sulix> Also: T g = gcd(T(llabs(P)),T(llabs(Q)));
+18:20 <@sulix> Is that "llabs" truncating everything?
+18:20 < matches> ...
+18:20 < matches> Probably
+18:20 < matches> !
+19:05 <@sulix> Well, my attempt to write a templated abs() function that worked for Arbint may have worked, but it crashed X before I could find out.
+19:05 <@sulix> I do not want to know how that is possible.
+19:05 < matches> Heh, I was trying to do that before dinner
+19:06 < matches> I just got segfaults
+19:08 < matches> Oh
+19:08 < matches> I see
+19:08 <@sulix> I suspect the best thing for me to do is to just stash all of my changes and break some more quadtrees.
+19:08 < matches> Yeah
+19:08 <@sulix> But first I'll have to get X working again.
+19:08 < matches> The problem with overriding llabs is that the constructor for Arbint calls llabs...
+19:08 < matches> And Arbint has a constructor from int64_t...
+19:09 < matches> So as soon as you implement llabs using Arbint it will call itself for eternity
+19:09 <@sulix> I made a new function called "real_abs" (because "i_went_to_the_gym_now_look_at_my_abs" was too long) and just used that.
+19:09 < matches> Bahaha
+19:10 <@sulix> Then X started using 100% of my CPU and nothing responds to anything.
+19:10 < matches> :S
+19:10 <@sulix> The mouse cursor still moves, but everything else is a black screen.
+19:11 <@sulix> Excellent, "sudo pkill -9 Xorg" has made everything work again.
+19:12 <@sulix> (And even fixed an unrelated problem, which is good but worrying)
+19:17 <@sulix> Note to self: if something crashes X when you run it once, don't run it again after fixing X.
+19:18 < matches> Haha
+19:18 <@sulix> Now to try it for a third time.
+19:18 < matches> I've got an abs working
+19:18 <@sulix> Ah, excellent.
+19:19 <@sulix> Does it make things better? Worse? The same but slower?
+19:19 <@sulix> Crash X?
+19:20 < matches> It doesn't crash X but I think I have an infinite loop in gcd now
+19:21 < matches> I should probably work out why X/X for really big X is not simplifying to 1/1
+19:43 < matches> So it turns out it's a pretty good idea to have a tester that actually tests lots of different numbers with every single operation
+19:43 < matches> As opposed to
+19:43 < matches> "1/2 == 0.5" yep looks good she'll be right
+19:43 < matches> One could say
+19:43 < matches> There are *signs* of serious problems
+19:44 * matches puts on sunglasses
+19:44 < matches> No wait I got the order wrong
+19:44 < matches> Oh well I wasn't cool enough to watch that show anyway
+20:18 < matches> So now I have a tester that actually tests things
+20:18 < matches> I just need to blindly fumble around with m_sign until all the tests are passed!
+20:18 < matches> Right?!
+20:26 < matches> Heh, it's amazing how many errors fixing the sign in Division prevents
+20:27 < matches> Well amazing until you realise that every single Rational calls a division at least once
+20:44 <@sulix> Hmmm... there seem to be a lot of cases where we get things becoming 1 (randomnumber/randomnumber) instead of what they should be, according to CheckAccuracy.
+20:46 < matches> Yeah
+20:46 < matches> It should work nicer nowish
+20:46 < matches> At least, the tester works most of the time...
+20:46 < matches> It still randomly fails sometimes
+20:46 <@sulix> Yeah, it's working much better.
+20:46 < matches> Now 12% of the time is in std::vector::size()
+20:46 <@sulix> All of the things I've seen have been to do with subtraction in ScaleAroundPoint()
+20:47 < matches> Ah
+20:47 < matches> Wait I haven't pushed the 12% in std::vector::size yet
+20:47 < matches> tl;dr I was allocating one extra digit every single addition operation and then deleting it if it wasn't used
+20:48 < matches> Because I am just that good :P
+20:48 < matches> I suspect the Arbint is going to break when it actually does need to resize itself
+20:49 < matches> But for now I will settle for "At least as good as an int64_t"
+20:49 < matches> * But slower
+20:49 <@sulix> I'm curious as to why digit_t is int64_t and not uint64_t.
+20:49 < matches> Oh it is uint64_t now
+20:49 < matches> It was int64_t mainly because geany doesn't syntax highlight uint64_t
+20:50 <@sulix> Ah.
+20:50 < matches> Then I realised being int64_t instead of uint64_t broke the shift operators
+20:50 < matches> Because they try to preserve the sign
+20:50 <@sulix> Shift on signed ints is undefined behaviour, IIRC.
+20:51 < matches> Yeah I was considering writing the shift in assembly but its easier to handle the underflow/overflow into the next digit in C
+20:52 < matches> Zooming is still incredibly slow
+20:54 < matches> In fact it is infinitely slow
+20:54 <@sulix> I once waited about 10 minutes and did get another frame.
+20:54 < matches> In fact the Arbint appears to want to grow an infinite number of 0L digits
+20:55 <@sulix> Ah ha! I have realised why CheckAccuracy is only throwing errors on "-".
+20:55 <@sulix> The CheckAccuracy calls for everything else have been commented out,
+20:55 < matches> They should all be commented out so I can use tests/realops.test instead
+20:57 < matches> 23 / 12000 operations failed... doesn't seem too bad...
+20:58 <@sulix> Keep in mind that == isn't precise as it casts to doubles.
+20:58 < matches> You get more like 40 out of Rational<int64_t>
+20:58 < matches> Yeah they are "equal" if it is within 1e-1 :S
+20:58 < matches> I'm searching for the more totally catastrophic failures like the wrong sign first :P
+21:20 < matches> Ok tomorrow I might just try using boost arbitrary integers or something
+21:28 <@sulix> All of the failures I'm getting are with "/="
+21:28 <@sulix> Except one, which was only just outside the error bounds, so probably the doubles' fault.
+21:30 < matches> I was restricting the test values somewhat though
+21:30 < matches> (With rand()%100 + 1)
+21:33 <@sulix> You do know that the Rational<Arbint> -> double conversion is totally broken if either P or Q have > 1 digit.
+21:33 < matches> Yeah I noticed that
+21:37 <@sulix> Oh man, re-enabling the operator double on Arbint totally breaks things.
+21:40 < matches> Yeah don't touch it
+21:40 < matches> Basically touching anything will totally break something else
+21:40 < matches> :S
+21:40 < matches> I should probably sleep some more before attempting to fix things
+21:40 <@sulix> The other bug I just found is that Arbint didn't have the unary "-" operator, so writing "-P" would silently cast to int64_t.
+21:41 < matches> Ah ok
+21:41 < matches> I thought unary - was equivelant to "0 - x" but I suppose that doesn't make sense
+21:41 <@sulix> Nah, it has to be written explicitly.
+21:44 <@sulix> Okay, I think I've got realops.test down to 0 errors with Arbint.
+21:45 < matches> Well you're doing better than me
+21:46 <@sulix> I'm running it with a huge number of tests now.
+21:47 <@sulix> 85.95% of my entire computer's processing time is in IPDF::Rational<IPDF::Arbint>::operator/=
+21:48 < matches> Can you push what you have?
+21:48 <@sulix> Yeah, I will in a second.
+21:48 <@sulix> It's basically a lot of hacks.
+21:49 <@sulix> CPU rendering is broken, though.
+21:49 < matches> There were cases where it would grow an infinite number of digits; did you fix those?
+21:49 <@sulix> Probably not: it still gets very, very slow zooming.
+21:51 < matches> Yeah there's something wrongish it shouldn't need extra digits so fast
+21:51 <@sulix> Pushed now.
+21:52 <@sulix> Now to look at the diff and see what I actually changed.
+21:53 < matches> Oh
+21:54 < matches> Simplify call in Rational operator= is good
+21:56 < matches> I think I fixed some more bugs but I also introduced an infinite loop so...
+21:57 < matches> How is the quad tree bit going :P
+21:57 <@sulix> Yeah, about that...
+21:58 < matches> Remember Arbints don't have to work for quad trees to work :P
+21:58 < matches> Or do they
+21:58 <@sulix> In theory, no.
+21:58 <@sulix> In practise, it probably depends on how one defines "success".
+21:59 < matches> I think we need to design a test pattern where you actually want to zoom forever
+21:59 <@sulix> Highly theoretically, I'm pretty certain the QuadTree basically ends up isomorphic to the Arbint.
+21:59 < matches> Seems legit
+21:59 < matches> Can you prove it?
+21:59 < matches> That would be a useful result
+21:59 <@sulix> Yes*
+22:00 <@sulix> *hopefully
+22:00 < matches> I'm afraid most of my "theory" is based solely on intuition at this point :S
+22:00 < matches> Well the division algorithm came from wikipedia but division isn't as intuitive as the other operations
+22:01 < matches> Actually if I can fix all these other stupid bugs I'll try my binary searchish division idea
+22:01 <@sulix> Yeah, I spent a while racking my brain for long division, and then only managing to work it out for dividing by a single digit.
+22:02 <@sulix> That's really, really easy in asm, as well, which is nice, but not quite as useful as I'd hoped.
+22:02 < matches> It's pretty useful; we can still have a "if div.m_digits.size() use the assembly function"
+22:02 < matches> * size() == 1 that is
+22:02 <@sulix> Wikipedia mentioned doing newton-raphson for division, which is a terrifying thought.
+22:02 < matches> Haha
+22:03 < matches> So I've got Arbint::Shrink() calls pretty much after every operation now for no apparent reason
+22:04 <@sulix> Does it help?
+22:05 < matches> On the 551st test Shrink has been called 4 times in a row and then something after that causes an infinite loop
+22:05 < matches> I can't work out what it is
+22:05 < matches> I have a GrowDigit that spams Debug messages now
+22:05 < matches> So its not that
+22:05 < matches> It's silent
+22:05 < matches> Let's see what callgrind has to say
+22:06 < matches> A few minutes should be enough for it to be obvious right
+22:07 < matches> I think the division loop runs forever
+22:07 < matches> Bugger
+22:08 < matches> Wait that doesn't make sense there's only 1 digit
+22:08 < matches> Blargh
+22:17 <@sulix> So using the asm version when possible makes realops.test 20x faster, but there were a couple of failed tests.
+22:18 <@sulix> I'm not sure if they're new or not, because I was able to run many more tests.
+22:20 <@sulix> Also, I think I've found your infinite loop.
+22:23 <@sulix> Okay, maybe I've just obfuscated the code some more.
+22:24 < matches> Infinite loop is due to subtraction bug
+22:24 < matches> I'm pretty sure
+22:24 <@sulix> Yeah, pushing a "fix"
+22:26 <@sulix> Pushed, but think I might have found a bug in the fix.
+22:26 < matches> Ok
+22:27 < matches> (0,0) - +(16292953875657448384,1) = -(16292953875657448384,2) seems wrong
+22:28 <@sulix> Pish! Nothing could be more beautiful.
+22:28 < matches> It's pretty hard to debug with such huge numbers :P
+22:31 <@sulix> Try this...
+22:31 * sulix pushes.
+22:32 < matches> What does that do...
+22:33 < matches> oh
+22:33 < matches> You negate the entire thing and add one
+22:33 < matches> Seems legit
+22:33 <@sulix> So "two's complement" negatives mean that -A == flip all bits of A and add 1.
+22:33 < matches> Yeah
+22:34 <@sulix> There seems to be a bug in the asm div_digits though.
+22:35 < matches> I'm taking that out until I know the main algorithm works :P
+22:35 < matches> Silly I spent so much time wondering why division was broken without checking subtraction
+22:36 < matches> After I spent all that time thinking I was so clever for doing division using bit shifts and subtractions
+22:37 <@sulix> It still takes forever.
+22:37 <@sulix> (Zooming in, that is)
+22:37 < matches> Nah there's still a bug
+22:37 < matches> You're running with an older version of realops test
+22:37 < matches> Hang on
+22:37 < matches> I will push things
+22:38 < matches> Trying to avoid a merge...
+22:38 <@sulix> And I will get a drink.
+22:44 < matches> So if you run enough tests you eventually get a bunch of SubBasic spam
+22:45 < matches> Which is actually occuring due to "<" operators
+22:45 <@sulix> Yeah: I'm going to add a bunch of hacks to "<" at some point.
+22:45 < matches> Which are in the Division loop ( >= is implemented in terms of <)
+22:45 < matches> Don't add the hacks until subtraction works!
+22:46 < matches> I don't want to optimise it yet
+22:46 < matches> Otherwise all the optimisations hide the bugs
+22:47 < matches> Time for a tester that just does subtractions I think
+22:48 <@sulix> It might be worth adding a bunch of SDL_assert_paranoid()'s everywhere that check that (a - b)+b == a and similar on every - call.
+22:49 < matches> Most of the tested numbers can be represented in a single digit which is causing problems
+22:50 < matches> With finding the bugs in the multi-digit algorithm
+22:52 < matches> For small enough multi digit Arbints testing against doubles might work?
+22:52 <@sulix> Maybe.
+22:53 <@sulix> You'd lose enough precision that it's not worth it for anything > 2 digits, I'd say.
+22:53 < matches> Yeah, 2 digits should be enough to make sure the algorithms actually work though
+22:54 < matches> 2 digits in one operand and 1 in the other (which will resize itself to have a leading zero if necessary)
+22:55 < matches> At some point I am going to have to use a library for Arbints and compare ours to it
+22:55 < matches> But I kind of want ours to work properly before bringing in an external one
+22:56 < matches> When I try floats I might just bring in the external library :P
+22:56 <@sulix> Two questions:
+22:57 <@sulix> 1. What is "borrow" supposed to be? Is it the "carry" or the "result has changed sign" or something else?
+22:57 <@sulix> 2. What do you think of replacing Sub() with Add() + Negate()?
+22:59 < matches> borrow's like carry (I'm using subtract with borrow in asm) it should get subtracted from the next digit, and if at the end it is still set then it means your result is less than zero
+22:59 < matches> and 2 sounds like an excellent idea
+23:00 <@sulix> Okay.
+23:00 <@sulix> 'cause there's a separate "carry" flag and "sign" flag, so I wasn't sure.
+23:01 < matches> subtract actually working would be slightly faster than add and then negate I think
+23:01 <@sulix> I'm not 100% sure if all the code is using m_sign as the sign or if some of it is trying to use 2's complement, which isn't really possible with arbints.
+23:03 < matches> When I was testing the subtraction code I was using int64_t instead of uint64_t and it seemed to work :S
+23:04 < matches> I should check whether sbb does unsigned or signed subtraction
+23:04 <@sulix> Both, I think.
+23:04 <@sulix> 2's complement makes them the same, which is why it's so nice.
+23:04 <@sulix> But it requires a fixed number of bits to work.
+23:09 < matches> Whoops now the bit shift tester runs forever as well
+23:13 < matches> Oh no it doesn't
+23:13 < matches> It just exceeds the limit on GrowDigits
+23:14 < matches> Phew
+23:14 < matches> Bit shifting works at least
+23:14 < matches> Or at least it is consistently broken
+23:14 < matches> (a >> X) << X == a
+23:14 < matches> But == could be broken
+23:14 < matches> NOTHING IS SAFE
+23:14 < matches> When you are writing your own number represntation :(
+23:15 <@sulix> Idea: 2's complement subtraction will make -ve numbers have an "infinite" number of 1s at the front, so would that be infinite looping, trying to continually add digits with 1s.
+23:15 < matches> Operator overloading is amazingly powerful and yet it seems like the best way to make seemingly sane code do batshit insane things
+23:15 <@sulix> I think the answer is "no: we're always trapping it and converting it" but am not sure.
+23:16 < matches> Our subtraction doesn't take forever
+23:16 < matches> The issue is when the result would be less than zero
+23:16 < matches> Hang on let me make another tester
+23:17 < matches> Well, I'll put it in the arbint tester instead of the real tester
+23:18 < matches> Since it's pretty clear the bugs are in arbint not rational<arbint> itself
+23:18 < matches> Although there might be bugs in rational<T> as well
+23:18 < matches> But we'll squish those when we get to them
+23:18 < matches> Also quad trees are they a thing yet?
+23:20 <@sulix> "The quadtrees aren't in the code, they were in your heart all along."
+23:21 < matches> Haha
+23:21 < matches> Tell that to Tim :P
+23:21 < matches> Ok (45,10) - (128,0) = -(83,18446744073709551605)
+23:21 < matches> But I'm pretty sure it should be -(83,9)
+23:21 < matches> + even
+23:22 < matches> (The least significant digit is first)
+23:23 < matches> Actually the plot thickens
+23:23 < matches> +45,10 - +128,0 = +18446744073709551533,9
+23:23 < matches> +45,10 - +128 = -83,18446744073709551605
+23:23 <@sulix> What is 0 + -1?
+23:24 < matches> +0 + -1 = -1
+23:24 <@sulix> I am pleased to hear that.
+23:25 < matches> +0 - +1 = -1
+23:25 <@sulix> -1 + 2?
+23:25 < matches> Now you're getting tricky...
+23:25 <@sulix> (As a maths major, I should know this)
+23:25 < matches> -1 - +2 = +1
+23:25 < matches> They're all single digit though
+23:26 <@sulix> Do you mean -1 + +2 = +1?
+23:26 <@sulix> Otherwise I'm slightly concerned.
+23:26 < matches> Uh yeah
+23:26 < matches> Sorry I have to change both the Arbint c(a + b) and the Debug
+23:26 < matches> Before copy pasting
+23:27 < matches> So I guess I should calculate if 45 + 10*2^64 - 128 == 18446744073709551533 + 9*2^64
+23:31 < matches> Expletive grenade
+23:31 < matches> I started Mathematica
+23:31 < matches> fglrx segfaulted
+23:31 < matches> startx
+23:32 < matches> -bash: /usr/bin/startx: No such file or directory
+23:32 < matches> Also now I am getting zenity int3 error messages all over the bottom line of my terminal
+23:33 < matches> Whyyy
+23:33 <@sulix> That's terrible.
+23:33 < matches> Why does this computer persecute me so
+23:34 < matches> I gave it a good life
+23:34 <@sulix> You should ask frames how he runs mathematica on the command line.
+23:34 < matches> I fed it lots of AC power
+23:34 < matches> I replaced that keyboard that I broke
+23:34 < matches> I only spilled coffee on it once
+23:34 < matches> I *tried* to use the drivers that weren't fglrx
+23:35 < matches> I give up, see you tomorrow. Try not to totally rewrite all the Arbint code :P
+23:35 < matches> I think the subtraction might actually work except for the resizing bit
+23:35 <@sulix> Nah, I'm calling it a night here too.
+23:36 <@sulix> I tried replacing the carry bit with the sign bit and all went to hell there, so I'm inclined to agree with you.
+23:37 < matches> Well using my calculator I get something with a 184 ish at the start and too many digits to display
+23:37 < matches> Hence the mathematica disaster
+23:40 < matches> Oh well, I got startx back by installing "xinit" so that's something
+23:41 < matches> I guess apt decided to remove it as part of apt-get autoremove in its infinite wisdom
+23:41 <@sulix> I have decided to never call apt-get autoremove.
+23:42 <@sulix> If at any point there are too many old packages for me to get things done, I'll just reinstall the OS entirely.