15:47 <@matches> Haha
15:54 <@matches> Ok I am still about 3 days behind on sleep but I guess I should do work
15:54 <@matches> Bye
+--- Day changed Tue May 27 2014
+12:49 <@matches> We missed the Computable Document Format (CDF) by Mathematica by the way
+12:49 <@matches> Wolfram would be offended
+12:50 * matches hopes none of the Mathematica fanatics read the lit review
+12:50 <@matches> Or this channel
+12:54 <@matches> I did have both Mathematica and IPython as a dot point and they got the mighty question mark of confusion over them
+12:54 <@matches> Maybe I'll add them in later
+12:55 <@matches> Frames does not seem to agree with my assertion that practically anything can be considered a document format :P
+12:55 <@matches> Plain text!
+12:57 <@matches> So I was looking through last year's Mech/Chem final year conference
+12:57 <@matches> Naturally there is nothing remotely like this project in there
+12:57 <@matches> :(
+--- Log opened Tue Jun 10 13:59:54 2014
+13:59 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+13:59 -!- Irssi: Join to #ipdf was synced in 3 secs
+16:29 -!- mode/#ipdf [+o matches] by OperServ
+--- Day changed Wed Jun 11 2014
+13:13 <@matches> JVB just asked me if it was possible to have a self updating pdf
+13:13 <@matches> I suppose he didn't ask whether it would be easy
+13:15 <@matches> As in, one that would download itself if there was a newer version
+13:16 <@matches> Technically with the crippled PostScript it would be "No" but with all that stuff in the standard about DRM and "Action Objects" and Javascript and stuff...
+13:18 <@matches> Hmm, a webserver running git and a cronjob and requiring authentication may solve his problem
+13:18 <@matches> With pdf.js or just relying on browsers to have pdf plugins
+13:18 <@matches> Wait why am I solving JVB's problem
+--- Day changed Fri Jun 13 2014
+16:31 <@matches> So exams have finished
+16:31 <@matches> Well my exams have finished
+16:32 <@matches> Now I can go back to panicking about the project again
+16:37 <@sulix> Excellent: it's your turn to do something impressive for the meeting on Monday, then. :P
+--- Day changed Mon Jun 16 2014
+14:49 <@matches> Some of this OpenGL stuff doesn't quite add up
+14:49 <@matches> Like m_cahed_display.UnBind(); m_cached_display.Blit();
+14:50 <@matches> Oh
+14:50 <@matches> I see
+14:50 <@matches> There is a difference
+14:51 * matches -> OpenGL documentation
+14:53 <@matches> Right I see
+15:03 <@matches> Well, this makes a lot more sense than tpg's "Adventures in VEMS" in #ucc at least
+15:18 <@sulix> Well that's an achievement, I guess.
+15:18 <@sulix> Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
+15:18 <@sulix> It's the spec for "nullptr"...
+15:20 <@matches> "Pointers are pretty cool. Pointers that are NULL are pretty cool. We address these issues by proposing nullptr" ?
+15:21 <@sulix> Haha: Pretty much.
+15:22 <@matches> Why not just reserve the word "null"
+15:22 <@matches> I could get behind it then
+15:23 <@matches> It is not a null reference
+15:23 <@matches> But if you ever have a null reference something is horrifyingly wrong
+15:23 <@matches> Bah humbug
+15:24 <@sulix> They have a page about that where they said "everyone was naming their variables \"null\"".
+15:24 * sulix realises he just escaped those quote. Oh dear.
+15:24 <@matches> A valid point, which should have lead to "Everyone are morons"
+15:24 <@matches> Fun fact
+15:25 <@matches> Matlab (like fortran actually) will let you use key words as variable names.
+15:25 <@sulix> "It's a feature!"
+15:25 <@matches> Question on CITS2401 exam: "Why is 'ii' preferred over 'i' and 'jj' over 'j' for loop iteration?"
+15:26 <@matches> Both i and j are the complex number sqrt(-1)
+15:27 <@matches> It seems like naming it 'nullptr' instead of 'null' missed an opportunity to stop people naming their variables really confusing things :P
+15:30 <@matches> Well I am infinitely wiser about nullptr now but I don't think it will stop me just using NULL
+16:15 <@matches> This is slowly starting to make sense
+16:35 <@matches> I'm having a bit of difficulty because it's all so optimised for the GPU
+16:35 <@matches> I think what we need is an ObjectRenderer class or similar
+16:36 <@matches> Have one for each type of object and implement RenderUsingGPU and RenderUsingCPU
+16:36 <@matches> I will see what monstrosity I can come up with
+16:36 <@matches> But a lot of that code for the circles and rectangles is exactly the same just copied and pasted with different variable names
+16:37 <@matches> I think there is an official software engineering term for that sort of thing...
+16:46 <@matches> Alright, breaking everything
+16:46 <@matches> This will probably take a while
+16:47 * matches dreads merges
+17:02 <@sulix> Yeah, I was going to basically end up with an ObjectRenderer class, too.
+17:02 <@sulix> So I'll leave it to you for now and procrasinate from doing my maths in some other way.
+17:07 <@matches> Cool :)
+17:52 <@matches> Now I'm not very strict about the whole RAII thing myself, but there seem to be some cases where things can probably just go in the constructor?
+17:52 <@matches> I guess we can fight about those later
+17:54 <@matches> I guess I can see us wanting to set m_render_inited to false and have it automatically recreate everything, maybe, but I can't see a case where we will want to recompile the shaders, so I am going to put the shader initialisation in the constructors
+17:54 <@matches> I have gone mad with power
+17:54 <@matches> Maaad
+20:30 <@matches> This ObjectRenderer is like a two headed hydra
+20:31 <@matches> I thought about using just the ibo and vbo and getting the indices out of it, but that's a bit terrible
+20:31 <@matches> So it will have an ibo for the GPU and an array for the CPU
+20:35 * sulix thinks this makes sense.
+21:47 <@matches> Good news! I have things on the screen. Bad news. They are still on the GPU and they are wrong.
+21:49 <@matches> More coffee required...
+21:58 <@matches> Not sure if code wrong or fglrx having an existential crisis
+22:04 <@matches> Unrelated to the segfaults of doom, but I just realised that there's all this interest in using GPUs for scientific computation, and everything seems to point to them having vastly inferior floating point computation to a CPU, which is a bit disconcerting
+22:05 <@matches> I imagine the OpenCL libraries etc actually use the IEEE floating point capabilities? I hope?
+22:05 * matches files under "beyond the scope of project"
+22:06 <@sulix> If you commit code I can test it on non-fglrx if that'll help.
+22:06 <@matches> I'd rather not commit it just yet, I am 90% sure it is something I have done wrong and don't want to shame myself by committing broken code
+22:06 <@matches> It'd be like vomiting all over the codebase
+22:07 * sulix is pretty sure half of his commits broke something.
+22:29 <@matches> Ok I committed stuff that should in theory work with the test pattern again
+22:30 <@matches> Using new and improved ObjectRenderer classes
+22:30 <@matches> For some definition of improved
+22:30 <@matches> It doesn't actually use the CPU yet
+22:30 <@matches> It'll get there
+22:33 <@matches> You can go and add your MandleBrotSetRenderer now though :P
+22:36 <@sulix> Cool.
+22:37 <@sulix> The circles do trigger that intel driver bug again, though...
+22:38 <@matches> Ah damn
+22:38 <@matches> Would making CIRCLE_FILLED the first ObjectType fix that?
+22:38 <@sulix> It does.
+22:38 <@sulix> (I just checked)
+22:38 <@sulix> Yay intel!
+22:39 <@matches> Haha
+22:49 <@matches> Hey, does our rendering approach completely break compositing?
+22:49 <@matches> Render all circles
+22:49 <@matches> Then render all rectangles...
+22:49 <@matches> There's no depth...
+22:49 <@sulix> Um, maybe.
+22:49 <@matches> :P
+22:49 <@matches> I was just worrying about how to make compositing work using the CPU
+22:49 <@matches> and then I realised it won't work using the GPU as it is either
+22:50 <@sulix> If we're not doing alpha-blending, we could just add a z-coordinate and use the z-buffer.
+22:50 <@sulix> Otherwise, they need to be sorted if they intersect.
+22:50 <@matches> Let's not worry about this for now...
+22:50 <@matches> Even though I spent a rather significant part of my lit review explaining how awesome compositing is
+22:51 <@matches> I guess it doesn't matter, clearly the lit review was not intended for anyone to actually read
+23:42 <@matches> I suspect RenderPixels doesn't work
+23:45 <@sulix> This may be the case.
+--- Day changed Tue Jun 17 2014
+01:05 <@matches> Behold the magnificence of CPU based rendering
+01:06 <@matches> In which we pass a massive pixel array to the ObjectRenderer's and just save it to a BMP
+01:06 <@matches> Because OpenGL
+01:06 <@matches> I'll probably fix it later
+01:11 <@matches> Whoops seg faults ahoy
+01:12 <@matches> Wait I swear it wasn't segfaulting before I commited that
+01:19 <@matches> It segfaults sometimes depending on where you have the view. If you just have one circle and zoom in you can see the amazingly less jagged looking lines.
+01:19 <@matches> That, is a certified result
+10:13 <@sulix> I got the CPU rendered version to show up on the screen.
+10:14 <@sulix> RenderPixels was pretty broken.
+10:38 <@matches> Nice
+10:39 <@sulix> I think the segfaults are it trying to draw outside of the display.
+10:39 <@matches> Yeah
+10:39 <@sulix> I haven't managed to zoom in too much yet.
+10:39 <@matches> My clipping is probably wrongish
+10:40 <@matches> fonttex_frag.glsl? Fear
+10:40 <@sulix> Yeah, the "basictex_frag" file did a bunch of pretty font-specific things.
+10:40 <@matches> Ah
+10:43 <@sulix> The CPU renderer also shows some random lines when there are no outlines on the screen.
+10:43 <@matches> Is it just me or does it look slightly nicer on the CPU when zoomed out a bit
+10:44 <@matches> Well it looks different
+10:44 <@matches> I can't quite work out whether it looks nicer or worse :P
+10:44 <@sulix> Okay, it doesn't segfault if the rectangle outlines are disabled.
+10:45 <@matches> Ah
+10:45 <@matches> Yeah it is setting top/bottom/left/right outside the pixels
+10:45 <@sulix> I think there are just some slightly different edge-case rules when zoomed out.
+10:47 <@matches> With my skills at writing renderers I should be working on the fglrx drivers
+10:47 <@matches> :P
+10:47 <@sulix> Things vanish if you zoom in too much, too.
+10:48 <@matches> Blame it on floats
+10:49 <@matches> The CPU renderer is using a width of 1 pixel less than it should be
+10:49 <@sulix> Why are the floats sinking? :P
+10:49 <@matches> That's unrelated
+10:49 <@matches> It's probably an integer rounding issue somewhere
+10:49 <@matches> When the view gets big something goes to zero
+10:50 <@matches> The CPU renderer transforms everything to pixel positions and then renders using those
+11:02 <@matches> The GPU renderer occassionally leaves off the corners of things
+11:02 <@matches> I never noticed before
+11:02 <@matches> Anyway I think the segfaults are fixed
+11:03 <@matches> Looking at the mysterious disappearances next
+11:04 <@matches> It's integer overflow!
+11:04 <@matches> Facepalm
+11:05 <@sulix> Is it int64_t time?
+11:05 <@sulix> Or magic huge bigint time?
+11:05 <@matches> No I don't think that's necessary
+11:06 <@matches> If the transformed width is smaller or larger than the width of the screen you can surely just ignore it
+11:06 <@matches> Well, depending on what you are drawing
+11:08 <@matches> Well it does matter unless you do some clever maths
+11:08 <@matches> The clever maths was your part of the project...
+11:09 <@matches> So I will just make them int64_t for now
+11:50 <@matches> Pushe
+11:50 <@matches> *d
+11:50 <@matches> I should probably just make all the coorinates into Real instead of int64_t actually
+12:03 <@sulix> Wow: this is pretty awesome.
+12:03 <@sulix> I still get the artefacts, but I have to zoom in a lot more.
+12:03 <@matches> Haha
+12:04 <@sulix> Also, the CPU rendering artefacts and the GPU rendering artefacts are pretty similar on my machine, so it looks like it's just precision causing them.
+12:04 <@matches> That is nice
+15:20 <@matches> I'm trying to do a performance graph. Gnuplot doesn't like it much
+15:20 <@matches> Well actually it's python's crappy interface to gnuplot that doesn't like it
+15:23 <@matches> ... tempted to implement the performance graph in ipdf...
+15:23 <@matches> Just keep adding circles to the document
+15:24 <@matches> So meta
+15:25 <@matches> We need a cool performance graph-y thing
+15:26 <@matches> I think doing it in OpenGL is going to be the least shitty way actually
+15:26 <@matches> This is a wheel that's probably been invented but it was invented wrong
+17:11 <@matches> I've got a performance graph sort of working
+17:11 <@matches> It almost looks like we are doing real science!
+17:13 <@matches> I think we'll need to put some effort into our data analysis though because it's extremely noisy
+17:13 <@matches> Smoothing averages or something
+17:13 <@matches> Smoothing averages are the best
+17:14 <@matches> They make any data look amazing
+17:15 <@matches> Anyway, CPU rendering is only worse than GPU rendering when you force re-rendering
+17:16 <@matches> So well done with the amazingly efficient cached frame buffer
+17:18 <@matches> We can probably make it draw every frame both on the CPU and GPU to compare them in real time
+17:18 <@matches> The possibilities are limitless!
+17:19 <@matches> Graphs graphs graphs!
+17:20 <@matches> Also I did end up using Gnuplot and python (sorry) but I made it slightly less shitty
+17:27 <@matches> I have pushed things
+17:27 <@matches> Also we probably don't need all three of those ways to measure performance
+21:00 <@sulix> I got the graphs working on my laptop: very nice.
+21:00 <@sulix> I can see how more GPU time is used with GPU rendering and more CPU time with CPU rendering quite well, actually.
+21:59 <@matches> So the objects all being in one structure of arrays is sort of inconvenient because the size of objects has to be constant
+21:59 <@matches> Also the size of Real has to be constant
+22:03 <@matches> I guess we could have union {Rect rect, Bezier bezier} and do rectangles and Beziers in the same thing but that is slightly terrifying
+22:04 <@matches> But there's still the problem of Real because as soon as Real becomes arbitrary precision it will start allocating memory and not be fwrite/fread'able
+22:04 <@matches> :S
+22:05 <@matches> You'll still want the struct of arrays because that will make view reparenting much easier
+22:05 <@matches> Gah
+22:06 <@sulix> I'm tempted to just split it by type: Have an array of Rects, an array of Béziers, an array of Circles, etc.
+22:06 <@matches> Yeah but you need to store an "indexes" array as well
+22:06 <@matches> But that might be the least terrible
+22:07 <@matches> Yes that should work
+22:07 <@matches> Our fwrite/fread is still doomed though
+22:07 <@matches> When shit gets Real
+22:07 <@sulix> Yeah, you'd need some indices one way or another.
+22:08 <@sulix> And yeah, we'll need a massive "ConvertWhateverRealIsStoredInTheFileToWhateverRealIsDefined" function or something.
+22:08 <@matches> That will totally be its name
+22:08 <@sulix> (Some old compilers had function name limits... I wonder if modern gcc has)
+22:09 <@sulix> (There is but one way to find out!)
+22:09 <@matches> We don't need an array of circles/ellipses since we get those for free with Rect. Unless you want circular arcs as well as bezier curves
+22:10 <@matches> Which you probably will? So you can approximate beziers
+22:10 <@matches> Anyway I'll worry about adding Beziers first and once we've worked that out others should hopefully be easier
+22:11 <@matches> I was sort of thinking it would be good to be able to define groups of objects as a special object type
+22:11 <@matches> Then you can make paths out of your beziers
+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.
+--- Day changed Mon Jul 07 2014
+08:40 < matches> I try to avoid it, but sometimes apt won't let me do anything because it would break some dependency
+08:40 < matches> Although usually even after I run autoremove it complains
+08:41 < matches> Had to use aptitude to fix my "You can'd have kde-runtime!" issues
+08:45 < matches> Anyway wolfram alpha says that example +45,10 - +128 == +18446744073709551533,9
+08:45 < matches> is correct
+08:45 < matches> Checking the algorithm using 8 bits it should work too
+08:46 < matches> So it works as long as you supply the leading zeros...
+08:46 < matches> (On that particular case...)
+08:48 < matches> I hope it's not interpreting Arbint(128L) as Arbint(128u, ...)
+08:48 < matches> Nope sanity seems to prevail there
+08:50 < matches> Ah
+08:50 < matches> Ok
+08:50 < matches> First bug of the day: The subtracted argument needs to be resized
+08:50 < matches> As I am doing (45,10) - (128)
+08:59 < matches> :O
+08:59 < matches> I passed the realops test
+09:00 < matches> And it's also a lot faster now!
+09:00 < matches> Probably because the subtraction bug meant it was spending a long time in division to get the wrong result
+09:01 < matches> Yeah it should have been obvious division can't have been that slow for numbers starting at 64 bits since it does at most as many iterations as the number of bits
+09:01 < matches> Oh well
+09:02 < matches> Should probably not celebrate just yet, now the bezier looks really wierd again
+09:04 < matches> Ok
+09:04 < matches> Actually compiling with Real == Rational<Arbint> might be a better test
+09:04 < matches> But it still passes
+09:05 < matches> In particular it passes with Arbints where int64_t fails horribly
+09:05 < matches> So something is right
+09:05 < matches> Just not all of it...
+09:08 < matches> The GPU rendering seems to workish
+09:09 < matches> We really quickly end up with Arbints of size 30 digits or so :S
+09:09 < matches> Which is big enough to give an overflow in doubles I think
+09:10 < matches> Rational::ToDouble can probably be written as double(integer division) + Rational(remainder, quotient).ToDouble()
+09:10 < matches> (With some things to stop it recursing infinitely)
+09:20 < matches> Or even double(integer division) + double(remainder)/double(quotient)
+09:20 < matches> I don't think any recursion is needed
+09:22 < matches> Oh, there's a "pow" call that is probably broken
+09:24 <@sulix> Yeah, I feel the growing quickly is just a fact of life.
+09:25 <@sulix> Perhaps changing the zooming to avoid coprimes or something.
+09:27 <@sulix> I'm pretty certain that about 3 seconds of zooming is enough to make us need precision and range to match measuring the size of the visible universe in Planck lengths, too.
+09:28 <@sulix> "New biggest Arbint of size 173"
+09:28 <@sulix> and counting...
+09:34 < matches> haha
+09:34 < matches> There are more issues I spotted with add and subtract
+09:34 < matches> Basically you have to add the leading zeros - all of them
+09:35 < matches> My patch only simulates adding one leading zero
+09:35 < matches> Actually maybe I don't need to add them all, just enough until the borrow becomes zero
+09:36 < matches> But whatever
+09:36 < matches> If you're left with a borrow you can't assume that subtracting it from the next digit won't cause a borrow as well
+09:37 < matches> Realops is not a good enough tester
+09:42 <@sulix> Surely if there's borrow bit, subracting it from zero will always give another...?
+09:42 < matches> You only need as many as there are digits in your number
+09:42 < matches> At most
+09:42 < matches> If you still have a borrow at the end
+09:42 < matches> That means the result is negative
+09:43 <@sulix> Yeah, that's what I thought: you need to cap the number of digits you add.
+09:44 < matches> The problem was the algorithm before didn't finish all the borrows
+09:44 < matches> eg: 100 - 2 would have become "-8"
+09:44 < matches> Because 2 only has one digit
+09:44 <@sulix> My powers of mathematics tell me that that is not quite correct.
+09:45 < matches> What, that our algorithm was wrong?
+09:45 <@sulix> No, that 100-2 is not -8
+09:45 < matches> Yes
+09:45 < matches> Yes that's the problem :P
+09:46 < matches> So basically the two numbers need to be the same size but since we have a constant argument I'm sticking in a "borrow_digits" vector if there is a borrow
+09:46 < matches> Addition also needs it for carry
+09:46 < matches> Damn
+09:47 < matches> I'd hoped that might fix the beziers not looking like beziers on the CPU bug
+09:50 <@sulix> I've pushed code to clear the carry/borrow flag before adding/subtracting.
+09:50 <@sulix> I don't think any bug is triggered, but there was the potential for off-by-one errors.
+09:52 < matches> Argh no
+09:52 < matches> Merge
+09:53 < matches> Yeah I'm pushing a fix for bugs that I don't think we've seen (yet)
+09:54 <@sulix> Out of curiosity, I tried removing the Simplify() calls from Rational.
+09:54 <@sulix> Relatedly, I've coined the term "NaN soup"
+09:54 < matches> Oh, clearing the carry/borrow flag might actually fix a bug with the code I just committed
+09:54 < matches> No wait it won't
+09:55 < matches> Eh it's still kind of dangerous to assume it isn't set to start with
+09:55 <@sulix> I think the flag was probably already cleared by the code the compiler generated, but that might not be the case if it's optimized.
+09:55 < matches> One of my early attempts had inline adc instructions in a for loop
+09:56 < matches> Which failed miserably because the for loop was clearing the carry flag :P
+09:57 <@sulix> For some reason "*=" segfaults if optimization is enabled, but I don't know why.
+09:57 < matches> Yuk
+09:58 <@sulix> Somehow we end up with "mul" as a null reference.
+09:58 < matches> Rataional::*= or Arbint?
+09:58 <@sulix> Arbint
+09:58 <@sulix> (So, also rational)
+09:58 <@sulix> Valgrind isn't picking anything up.
+09:58 < matches> null references are the worst
+09:59 < matches> Since I'm pretty sure the point of a reference is that it is never null...
+09:59 < matches> I'm sure this doesn'
+09:59 < matches> t stop people from deliberately creating null references
+09:59 < matches> And also checking that they are not null
+10:02 <@sulix> Tried compiling with clang. Nope.
+10:02 <@sulix> Apparently not even #include <iostream> compiles with clang.
+10:02 < matches> It might be worth implementing a non assembly version of those functions
+10:03 <@sulix> Yeah, that's always a good idea.
+10:03 <@sulix> The assembly ones are more fun, though.
+10:16 < matches> Hmm I should probably head towards the meeting
+16:23 < matches> I have pushed a Gmpint wrapper thing
+16:23 < matches> It mimics Arbint as closely as possible.
+16:24 < matches> Well by that I mean I just wrapped all the calls to mpz_add() etc in operators
+16:24 < matches> It doesn't have all of Arbint's more esoteric functions
+16:24 < matches> If we need bit shifts I think I can add them
+16:27 < matches> So, writing stuff...
+16:28 < matches> Running arbint_vs_gmpint.test in valgrind takes a fair while
+16:28 < matches> We will have the definitive answer of just how terrible our multiplication is compared to the Professional (TM) implementation
+16:29 < matches> I do have some good news, I think our string conversion might be better
+16:29 < matches> Well if you ignore the division
+16:31 < matches> *= is about 11 times slower
+16:32 < matches> Most of that is in std::vector::resize()
+16:32 < matches> But even just mul_digits is greater than the entire Gmpint::operator*=
+16:32 < matches> The plot thickens as I try division
+16:32 < matches> Which is a good opportunity to get food because it will probably take an hour
+16:34 < matches> Note: Don't disable Debug messages if you want time to get food :(
+16:35 < matches> And division is just under 100* slower
+16:36 < matches> No
+16:36 < matches> 1000*
+16:37 < matches> So... if we change Rational<Arbint> to Rational<Gmpint>...
+16:41 < matches> We still get {nan,nan,nan,nan} eventually but it is generally less shoddy
+16:50 <@sulix> Cool: looking at this now.
+16:50 <@sulix> I'm digging through the gmp source code as well.
+16:51 <@sulix> They have a similar "divide by single int64_t" optimization.
+16:51 <@sulix> Also their code is 90% preprocessor macros.
+16:51 < matches> Welp
+16:51 < matches> At least we have a readable Arbint
+16:52 < matches> I don't know what use a readable but slow implementation is
+16:52 <@sulix> Ah: I see what they're doing: this is quite clever, particularly from a pure maths point of view.
+16:52 <@sulix> They've got a natural number implementation, and have then built their integer representation around that.
+16:53 <@sulix> The natural numbler implementation is just a huge set of directories with different assembly implementation.
+16:53 <@sulix> So there's an "x86_64" directory, and in that there's a bunch of assembly + a bunch of directories with optimized versions for different individual processor models.
+16:55 <@sulix> Also their assembly has lots of ASCII art comments.
+16:56 <@sulix> and macros.
+17:07 < matches> Yeah "just use GMP" is probably the answer
+17:08 < matches> Their Makefiles are pretty intimidating
+17:22 < matches> I like that they seem to store the sign as part of the size
+17:22 < matches> If something has a negative size it is negative and has |size| digits
+17:34 < matches> I guess I will try and write some sort of report about how we implemented Arbitrary Integers but they are terrible compared to existing implementations :P
+--- Day changed Thu Jul 24 2014
+14:44 < matches> So I was going to work on the project but existential dread
+14:45 < matches> About whether my major exists
+14:45 < matches> Do I exist?
+14:49 <@sulix> Are you thinking? Because cogito ergo sum.
+14:50 < matches> I'm not sure I was thinking when I picked this major...
+14:50 <@sulix> I did some project code yesterday and then a bug I thought I'd fixed reappeared so I got distracted failing to fix that.
+14:50 < matches> Haha
+14:53 < matches> Should I upset everyone and recommend freshers for wheel again...
+14:54 <@sulix> I'm all for it, but I think the consensus was that we need to make them actually do wheel-y projects first.
+14:55 < matches> That seems kind of hypocritical though
+14:55 < matches> Because nearly none of active wheel has actually done wheel-y projects
+14:55 < matches> Certainly not before getting on wheel
+14:56 <@sulix> My current random guess is that the problem is that people used to fix the desktops and stuff, and now everyone has their own laptops to break.
+14:56 < matches> But I'll be quiet or people might decide I need to be removed due to lack of doing useful things
+14:56 < matches> Yeah
+14:56 < matches> That too
+14:57 <@sulix> I'll definitely bring it up at the meeting.
+15:02 <@sulix> So which CoderDojo forms do I need to fill out?
+15:02 < matches> Ooh!
+15:02 < matches> http://coderdojowa.org.au/volunteer
+15:02 < matches> This one
+15:03 < matches> But now you've said that I'm already adding you to the mailing list...
+15:04 < matches> There's a thing on Saturday in 2.01 in CS at 12:00pm
+15:04 < matches> I hope people actually show up because we are pretty short on presenters
+15:04 <@sulix> Yeah, I've got a programming competition then. I'm trying to work out how much of the schedule for the competitions exists.
+15:06 <@sulix> Okay, apparently there are programming competitions every saturday in August, which will be fun.
+15:07 <@sulix> Although half of them are "details TBD," which sounds ominous.
+15:07 <@sulix> Also there is a round 2 and a round 4 but no round 3.
+15:11 <@sulix> Okay: it looks like the only weeks I don't have programming competitions on are the last 3 on the form.
+15:13 <@sulix> Also I suspect they're running out of names for the programming competitions, because this Saturday's is called the "South Pacific Winter Programming Carnival".
+15:21 < matches> Haha
+15:27 <@sulix> Form submitted. Sorry for the snarkiness.
+15:40 < matches> Brilliant
+15:40 < matches> You can do a C or C++ workshop or something :P
+15:40 < matches> Or just talk about Commander Keen that'll work
+15:40 < matches> Or "Why Javascript is awful and you should forget all the lessons"
+15:42 <@sulix> "Intro to DOS programming." :P
+18:38 < matches> I did a sort of half hearted attempt at writing more about Arbints
+18:39 < matches> Maybe I'll try put fonts in
+18:39 < matches> That seems vaguely like not what I am supposed to be doing right now :P
+18:43 < matches> There's that virtual FPU sitting there doing nothing
+18:43 < matches> That I promised to do things with in my lit review
+18:43 < matches> That Tim is marking
+18:43 < matches> When I haven't actually done anything with it and he knows it...
+18:44 < matches> I can't help but feel like we need a more impressive thing to zoom in on
+18:44 < matches> Or even a way to draw things once we have zoomed in
+18:46 < matches> Does "We implemented Arbitrary Precision Integers but GMP did it better" count as research?
+19:13 < matches> Do we have a memory leak?
+19:13 < matches> I've been running it for a while and things are slowing down
+19:25 <@sulix> matches: With GMP or just doubles?
+19:27 <@sulix> My quick check has us not leaking memory with doubles.
+19:27 <@sulix> Well, X leaks memory and the nVidia driver leaks memory, but we're fine.
+19:35 < matches> I was actually running with singles :S
+19:35 < matches> See push to documents repo
+19:35 < matches> There is a pdf
+19:35 < matches> I did a thing
+19:38 < matches> I'm basing the assumption that x86-64 is IEEE compliant on the fact that it passed the "paranoia" program
+19:39 <@sulix> Yeah, x86_64 is IEEE compliant.
+19:39 <@sulix> x86_32 is "mostly" IEEE compliant if I recall.
+19:41 < matches> Well a picture tells a thousand words
+19:41 < matches> So I think I wrote 8000 words today
+19:41 < matches> Progress!
+19:43 <@sulix> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_defines.h?id=9d6166880da83887e3246fb4498c3a07d979cc3b#n162
+19:43 <@sulix> I'll see if I can find where they actually set it to non IEEE.
+19:43 < matches> Oh I was going to say fglrx did different things to nVidea but as I don't have nVidea that's difficult to do
+19:45 <@sulix> Although there's this: http://lists.freedesktop.org/archives/mesa-dev/2013-July/041555.html
+19:45 <@sulix> Yeah, nVidia, Intel and fglrx all seem to do different things.
+19:45 <@sulix> fglrx does the strangest things.
+19:45 <@sulix> nVidia does the most consistant things.
+19:45 <@sulix> Intel sits nicely in the middle.
+19:46 < matches> If we can get four screenshots of the different things at the same view bounds that might be useful
+19:47 < matches> Also working out more about what the jagged edges implies about the precision/rounding might be helpful
+19:47 < matches> All I've got is "This is clearly not a circle"
+19:48 < matches> So it's still doing that with the quad trees enabled, so I assume the quad trees aren't amazingly quadifying everything yet :P
+19:48 <@sulix> The quadtrees are basically doing nothing but occasionally causing bugs.
+19:48 <@sulix> http://davidgow.net/stuff/ipdf-nvidia.png
+19:48 < matches> That is progress at least
+19:49 < matches> Thanks
+19:49 < matches> I will update the others to be the same view bounds
+19:49 < matches> I *think* we have code to set the view bounds at start?
+19:51 <@sulix> http://davidgow.net/stuff/ipdf-intel.png
+19:51 < matches> Haha
+19:51 < matches> Well it's really obvious that that's different
+19:52 < matches> Can you rerun it with -b 0.0869386 0.634194 2.63295e-07 2.63295e-07
+19:52 < matches> Obsessive compulsive...
+19:52 < matches> Must all be same view bounds...
+19:53 < matches> I'd run it on my other laptop with intel integrated graphics except the keyboard still doesn't work
+19:55 < matches> Actually don't bother
+19:55 <@sulix> http://davidgow.net/stuff/ipdf-nvidia1.png
+19:57 <@sulix> http://davidgow.net/stuff/ipdf-intel1.png
+19:59 < matches> oah wierd stuff is happening with the quad tree
+19:59 < matches> There is a big circle and a little circle
+19:59 < matches> Is that supposed to be here...
+20:00 < matches> The distance between them is not constant :S
+20:09 <@sulix> Yeah, that doesn't happen on intel and is the bug I've been hitting my head against.
+20:09 <@sulix> Pretty certain I'm trying to render one more object than there actually is somewhere, maybe corruping memory in the process.
+20:32 < matches> Ok so it turns out the CPU is actually about as terrible as the GPU at those view bounds when you replace the "double" with "float" in the Circle Renderer :S
+20:32 <@sulix> That's what I expected.
+20:32 <@sulix> It looks like the nVidia one, right?
+20:32 < matches> But it does slightly different wrong things!
+20:34 < matches> It looks similar-ish
+20:35 < matches> It is blocky as opposed to zig zaggy
+20:39 < matches> As in it doesn't look as whack as intel
+20:43 <@sulix> Hmm... I'm not sure what I'm doing wrong, but I can't see any artefacts at all with CPU rendering w/ those bounds.
+20:55 < matches> They are hard coded as doubles
+20:55 < matches> Not floats
+20:55 < matches> Or reals rather
+20:56 <@sulix> Ah.
+20:56 <@sulix> This explains much.
+21:08 < matches> I have pushed a thing
+21:09 < matches> It almost sounds like a real paper
+21:09 < matches> Until you realise all it is is "we drew some circles and they look different"
+21:09 < matches> Also your screenshots had some kind of crazy blue glowy border
+21:10 <@sulix> Yeah, that's the KDE window shadow.
+21:10 < matches> Fancy
+21:10 <@sulix> It used to make the nVidia driver corrupt screenshots, but it seems to work now.
+21:11 < matches> I'm pretty pleased with that 4 way comparison figure...
+21:12 < matches> "One of these things is not like the others..."
+21:12 < matches> *cough* intel
+21:12 <@sulix> The conclusion is brilliant.
+21:15 < matches> If we assume the nVidia and x86-64 figures are what things are supposed to look like
+21:15 < matches> fglrx tries really hard
+21:15 < matches> But doesn't quite make it
+21:16 < matches> (I'm pretty sure that's just a particularly good view for it)
+21:16 < matches> (If you move it around it goes insane)
+21:16 < matches> I can respect the intel shader
+21:16 < matches> It isn't afraid to blatantly disregard the rules
+21:17 < matches> intel driver rather
+21:17 < matches> Not sure why I put "shader" there
+21:17 < matches> This has not been as productive as I hoped
+21:18 < matches> Still
+21:18 < matches> We finally have something written that Tim can pass judgement on
+21:18 < matches> He's still in the country right?
+21:19 < matches> He might want to finish passing judgement on my literature review first :S
+21:21 <@sulix> I think he's still in the country, but don't hold me to that.
+21:22 < matches> Ok, so if you translate around with the CPU things don't go insane, but they do on the GPU. That might be caused by something else though.
+21:23 < matches> I'll be at University tomorrow
+21:24 <@sulix> I might head in, too, then.
+21:25 <@sulix> Do things still "go insane" on the GPU with CPU-side coordinate transforms.
+21:26 < matches> Yeah
+21:26 < matches> It looks like there is a tear
+21:27 < matches> So you get this rectangle pattern
+21:27 < matches> If you move it around on the CPU it maintains its shape
+21:28 <@sulix> I think that fglrx (or maybe just the AMD hardware) calculates the coordinates per-triangle rather than per-vertex or something.
+21:28 < matches> Under fglrx the bottom part of it sort of maintains its shape but there is a big diagonal line and the stuff above that changes
+21:28 <@sulix> That's pretty weird.
+21:29 < matches> Also the bottom part doesn't have concave bits but the top occasionally gets one
+21:29 < matches> concave/overhanging whatever
+21:29 <@sulix> The whole thing maintains its shape on nvidia (and even intel)
+21:29 < matches> Well, the bottom half (and also the CPU/nVidia entire thing) looks kind of like a stair case
+21:29 < matches> The top bit gets all these sticky out bits and overhangs
+21:30 < matches> Which brings us to our next paper
+21:30 < matches> The geology of fglrx
+21:30 <@sulix> Intel also does the "staircase" on the other side of the circle.
+21:30 < matches> On the other side...
+21:30 < matches> Hmm the plot thickens
+21:31 < matches> Oh well I need to sleep
+21:31 < matches> Why do I feel like I have actually lost sleep over the holidays...
+21:32 < matches> I am not ready for semester to start :(
+21:32 <@sulix> I know exactly what you mean.
+21:33 < matches> I seem to have been roped into unpaid work with physics
+21:34 <@sulix> Oh dear. More lab demonstrating or something more interesting?
+21:34 < matches> Hopefully if I visit ECM they won't make me do GENG5505 yet
+21:34 < matches> Fixing my honours experiment I think...
+21:35 <@sulix> Another pipe corroded through?
+21:35 < matches> Haha
+21:35 < matches> They were wondering where all the electronics went
+21:35 < matches> (I have most of it)
+21:35 < matches> (Also it's no longer functional)
+21:36 < matches> (I may have taken some of it apart...)
+21:36 < matches> (Although really the sensible option would have been to burn it with fire)
+21:37 < matches> Goodnight anyway
+21:37 <@sulix> I'm required to "correct" anything they want to change with this project after submitting it.
+21:37 <@sulix> On the morrow, then!
+--- Day changed Fri Jul 25 2014
+11:24 < matches> I'm at UCC
+11:39 <@sulix> Okay, I'll show up once I've sorted out this acedemic record stuff.
+12:05 < matches> I went to ECM but apparently just a few other people are having difficulties...
+18:24 < matches> So steam browser supports html5 canvas but not keyboard events
+18:24 < matches> This seems to happen with a lot of browsers
+18:25 < matches> We support html5 canvas (which is pretty much solely designed for web based games)
+18:25 < matches> But we don't support any way to actually pass input to the page that doesn't suck
+18:25 < matches> (I'm looking at you Safari)
+18:31 < matches> It sort of spoils the "HTML5 is AWESOME" message the HTML5 people are aiming for
+18:31 < matches> The best bit of html5 is <canvas> and that you no longer need to use html because you can just draw everything in the canvas...
+18:32 < matches> Which is scarily similar to using PostScript
+--- Day changed Mon Jul 28 2014
+10:05 < matches> In 2.07 now
+10:07 < matches> You removed SDL from contrib
+10:07 < matches> So now it won't compile on the lab machines
+10:07 * matches gets out the laptop then
+--- Day changed Tue Jul 29 2014
+09:59 < matches> I seem to have this bizarre illness
+10:00 < matches> Where half my head feels fine
+10:00 < matches> And the other half feels like I've been trying to read brainfuck
+10:00 < matches> I hope you don't catch it
+10:00 < matches> The side that is sick is the side that was closest to the group hug
+10:00 < matches> Coincidence!?
+10:00 < matches> I think not!
+10:08 < matches> You know how there's this theory about the two halves of the brain being semi independent and sort of subconsciously able to think by themselves
+10:08 < matches> I think the left side of my brain is dead
+10:08 < matches> It's not responding to pings
+10:09 < matches> I think the project working side might be the alive one though, so we shall see if I can actually do something useful
+--- Log closed Tue Jul 29 23:13:08 2014
+--- Log opened Wed Jul 30 12:03:38 2014
+12:03 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+12:03 -!- Irssi: Join to #ipdf was synced in 0 secs
+--- Day changed Sun Aug 03 2014
+12:43 < matches> So I found my moronic mistake with the virtual FPU and it seems to actually work
+12:44 < matches> I think it's even slower than using Rational<Arbint>
+12:44 < matches> Unless everything's slow because of the QT now
+12:45 < matches> There's an awful lot of "Rendering QT node" debug
+12:46 < matches> No its the VFPU that makes sense
+12:47 < matches> Since every floating point operation now requires writing 18 hex characters over a unix domain socket
+12:47 < matches> Hooray VHDL
+12:48 < matches> (I'm sure if you have $$$$ and like Enterprise(TM) software VHDL is great)
+12:48 < matches> I'll just do some miscellaneous things and hopefully some of them will be useful
+12:48 < matches> Bye
+14:14 < matches> So with the VFPU and doing everything on the GPU we have 2.2 FPS
+14:14 < matches> It seems to be able to cope with rectangles on the CPU
+14:15 < matches> The circle may present some difficulties
+14:16 < matches> It would be have been pretty cool to change the vfpu and see if anything makes it look like intel
+14:16 < matches> But ultimately useless I suppose
+14:37 < sulix> There might be some info in the hardware docs, though they're pretty incomprehensible: https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family
+14:38 < sulix> AMD also have manuals: http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
+14:38 < sulix> nVidia are sworn to secrecy.
+--- Day changed Tue Aug 05 2014
+12:38 < matches> I'm looking at the atril source
+12:38 < matches> To see if I can compile it without the oppressive 400% max zoom
+12:39 < matches> It is rather intense
+12:39 < matches> I think the zooms are set depending on the language?
+12:41 < matches> There are po files which are definitely not position independent object files
+12:43 < matches> #define ZOOM_MAXIMAL(zoom_levels[n_zoom_levels - 1].level)
+12:43 < matches> The plot thickens!
+12:45 < matches> Heh this is actually sort of making sense
+12:45 < matches> They have a "cut-n-paste/zoom-control" directory
+12:48 < matches> I'm confused as to how the maximum zoom is 6400% and yet my version will only zoom to 400%
+12:48 < matches> But I guess I shall compile it from source and see what actually happens
+12:51 < matches> They also have a script to configure their configure script...
+12:51 < matches> Oh dear xml is involved
+12:53 < matches> There needs to be a way to save the status of configure so you don't have to rerun it from scratch every time you fix an error
+12:56 < matches> Our document viewer may only be able to render beziers and circles
+12:56 < matches> But at least it doesn't have any dependencies!
+12:56 < matches> Well many
+12:56 < matches> I suppose since SDL is in contrib we should put GMP in contrib too
+12:57 < matches> But yes, I don't care about caja plugins dammit I want to zoom on a pdf
+13:00 < matches> "Warning: Comparison between pointer and integer"
+13:00 < matches> Aaaah
+13:00 < matches> It compiles...
+13:01 < matches> But where did it put the binary...
+13:02 < matches> Oh great it expects things to be in /usr
+13:03 < matches> I guess I will run "install-sh" and hope I will still have a usable pdf viewer
+13:07 < matches> There's a LOT of G_ and g_ variables
+13:07 < matches> Actually functions
+13:07 < matches> I think g_ does not mean global in this context
+13:07 < matches> Maybe
+13:11 < matches> So it's not just a matter of ZOOM_MAXIMAL being redefined to ridiculously huge numbers having any effect
+13:11 < matches> I guess they use some other library that has zooming
+13:13 < matches> It somehow detects what the maximum zoom should be based on the document as well
+13:13 < matches> This is just over engineering!
+13:19 < matches> ev_view_can_zoom_in (EvView *view)
+13:19 < matches> return view->scale * ZOOM_IN_FACTOR <= ev_document_model_get_max_scale (view->model);
+13:19 < matches> Let
+13:19 * matches casually makes it return true
+13:19 < matches> Also wtf
+13:19 < matches> They have a "gboolean" type
+13:19 < matches> Is "bool" inferior?
+13:19 < matches> What more do you need than true and false
+13:20 < matches> Is bool used as a variable name for something
+13:20 < matches> sigh
+13:24 < matches> No ok it still won't let me zoom in more
+13:25 < matches> g_return_if_fail in the zoom functions
+13:25 < matches> They don't look important
+13:28 < matches> There are a surprising amount of places with a "if zoom or scale is bigger than the maximum, return"
+13:28 < matches> Like, are three checks really necessary
+13:29 < matches> I think you can set model->sizing_mode to "EV_SIZING_FREE" but I have no idea what that will do
+13:29 < matches> So I'll just continue commenting out anything that looks like it will return early from the zoom process...
+13:30 < sulix> Sounds like a plan!
+13:31 < matches> The use of g_ for function names makes me want to stab someone :P
+13:31 < matches> I assume it's related to gtk or maybe just gnome
+13:32 < matches> Also about half their doubles are "gdouble"
+13:32 < matches> And the other half are "double"
+13:32 < matches> :S
+13:32 < sulix> gtk had their own crazy, let's implement everything from scratch idea.
+13:32 < sulix> They have their own "classes" in C, IIRC.
+13:32 < matches> It's pretty object orientated yes
+13:34 < matches> Ok I seem to now be able to zoom in a *bit* more and then it just stops drawing things
+13:35 < matches> No wait it's just hopelessly slow
+13:37 < matches> It also zooms in on the wrong spot and then draws it and then moves the view back to the mouse and draws again
+13:38 < matches> But yes, it doesn't cope well with zooming at all
+13:38 < matches> I was kind of hoping it would work
+13:39 < matches> Maybe if I use a simpler document
+13:43 < matches> Congratulations anyway
+13:43 < matches> We can zoom further on a circle than atril can
+13:44 < matches> Unfortunately the reasons atril can't zoom are probably not related to precision
+13:44 < matches> Maybe I need to find some "if zoom > thing don't draw anything" and comment those out too
+13:44 < matches> Sigh
+14:07 < matches> It is resistant to my valgrind attempts
+14:07 < matches> It seems to have spawned 9 processes
+14:10 < matches> Oh "atril" is actually a series of hideous bash scripts that load libraries or something
+14:12 < matches> You know
+14:12 < matches> I'm sure if we tried
+14:12 < matches> We could make a less shitty pdf viewer out of our program
+14:29 < matches> Interesting
+14:30 < matches> "ev_document_render" got called 10.6 Billion times
+14:30 < matches> I don't think I changed the view that many times...
+14:32 < matches> Ok, so just working on our own viewer is probably better at this point than working out why atril has a heart attack if you zoom
+14:33 < matches> I'm going to pretend this wasn't a waste of time...
+14:41 < matches> "existing pdf viewers cap the view because otherwise they break due to bugs that aren't actually related to precision"
+15:43 < matches> So I suspect the GPU Bezier rendering is buggy
+15:44 < matches> Or maybe it's a quad tree thing
+15:45 < matches> Or both...
+15:46 < matches> I'm pretty sure the appearance of an individual bezier should not depend on what other beziers are in the document :P
+15:47 < matches> Yeah there's wierd quad tree shit going on
+15:48 < matches> I'm going to try and add some sort of glyph/font like thing
+15:49 < matches> It's either that or create hand drawn beziers in the current view
+15:50 < matches> But I feel it desperately needs an example of being able to actually zoom in and create something at an "arbitrary" level
+18:54 < matches> So we sort of have a very broken, very badly written, SVG parser
+18:55 < matches> A bunch of bugs showed up in the bezier rendering
+18:56 < matches> Although it might just be fglrx
+22:23 < sulix> The GL code is now consistantly broken, rather than sporadically broken.
+22:24 < sulix> Trying to render SVGs with it might count as modern art, though.
+22:39 < sulix> Man, the buggier the bézier code gets, the more beautiful its output.
+22:53 < sulix> Voilà: http://davidgow.net/stuff/ipdf-koch-svg.png
+23:11 < sulix> And on the CPU: http://davidgow.net/stuff/ipdf-koch-svg1.png
+--- Day changed Wed Aug 06 2014
+11:00 < matches> That looks amazing!
+11:04 < matches> I'm sorry
+11:04 < matches> All I seem to do is add bugs :S
+11:05 < matches> And XML
+11:13 < sulix> I suspect you removed a lot of bugs with the -DQUADTREE_REMOVED. :P
+11:14 < matches> It's the bit where parts of my Bezier code have been wrong for more than a month that make me feel guilty :S
+11:14 < sulix> The GPU code was wrong in the same way.
+11:15 < sulix> Also it used to corrupt all of the memory.
+11:23 < matches> So you're not using the koch.svg file?
+11:23 < matches> That breaks for me
+11:23 < matches> Which isn't surprising considering the svg parsing code
+11:24 < sulix> I was using koch1.svg from your Lit Review
+11:25 < matches> Oh right
+11:25 < matches> koch.svg isn't actually a valid svg file :S
+11:26 < sulix> I tried it with a random, complex SVG from the internet, and segfault.
+11:27 < matches> Haha
+11:27 < matches> Yeah it works
+11:27 < matches> We can zoom in further than atril!
+11:28 < sulix> Victory!
+11:34 < matches> So I was trying to think about shading things... and stroke thickness... and all those other things in SVG...
+11:34 < sulix> Yeah, I thought about those.
+11:35 < sulix> I came to the conclusion that I should probably try to make the quadtree work first.
+11:37 < matches> Probably :P
+11:58 < sulix> btw, your computer's clock is slightly out.
+11:58 < sulix> alternatively there is a lot of time travel going on
+11:58 < sulix> (secretly, I'm hoping it's the latter)
+11:59 < sulix> (im my mind, I'm good enough to have bugfixed the SVG code before it was written)
+17:10 < matches> Yeah I removed ntpd because my boot kept stalling at it for several minutes
+17:17 < matches> The GPU Bezier renderer seems a lot more conservative about how many lines it uses
+17:18 < matches> I thought I remembered just copying the GPU algorithm for the CPU but maybe I didn't
+17:20 < matches> Oh
+17:38 < matches> Some of the shader stuff confuses me...
+17:38 < matches> Like: "pixize = vec2(pixel_w/bounds_w, 100*pixel_h/bounds_h)"
+17:39 < matches> Random factor of 100 ?
+17:39 < matches> As far as I can tell pixel_w,pixel_h is always 640,480
+17:57 < matches> Hmm
+17:57 < matches> But the window isn't 640,480
+17:57 < matches> Wait
+17:57 < matches> Is it
+17:58 < matches> Yeah
+17:58 < matches> The screen is 800 x 600
+17:58 < matches> That is only slightly confusing...
+17:58 < matches> Should I change all the 640,480 to 800,600 ...
+17:59 < matches> Or will this break things
+18:01 < matches> We are actually passing the width and height of the viewport around so I figure that should probably be used instead of 640 and 480
+18:02 < matches> Also I suspect we want just a few more lines on the beziers since they often start looking more like trapezoids
+18:04 < matches> But only if they are big to begin with
+18:05 < matches> We can probably also do a "if x1,y1 == x2,y2 just use one line"
+18:06 < matches> Or alternately actually implement lines as distinct from beziers but that's silly :P
+18:06 < matches> If I can work out how to do shading then we won't even need rectangles and circles any more
+18:06 < matches> I should probably focus on precision of things but I sort of want to be able to draw something cool first
+18:15 < matches> Oh damn merge
+19:19 < matches> So a series of curveto commands isn't just a series of individual beziers for each three points
+19:20 < matches> I guess it's time to actually read the SVG spec a bit
+19:20 < matches> Oh maybe they are cubic beziers
+19:21 < matches> I thought they were just quadratic unless you used a special command
+21:08 < matches> The order of your coefficients in the bezier geometry shader seems reversed...
+21:08 < matches> But maybe that's because I reversed it in the CPU first...
+21:08 < matches> I don't know
+21:08 < matches> I will leave it in this order and hope it doesn't break
+21:08 < matches> (I'm making the beziers cubic because it seems like a thing we want)
+21:08 < matches> And is required for SVG paths
+21:27 < matches> Hmm
+21:27 < matches> SVGs also have quadratic beziers and as much as setting (x3,y3) == (x2,y2) *almost* looks the same...
+21:29 < matches> Close enough I guess
+21:30 < matches> I don't particularly want to add seperate objects for quadratic beziers since I've only ever seen cubic ones in SVGs anyway
+21:49 < matches> http://szmoore.net/ipdf/svgshape.png
+21:49 < matches> Woo!
+21:50 < matches> I'm actually pretty excited about having a semi usable svg viewer that can zoom, if not indefinitely, a lot further than any of the open source image viewers will let you zoom :P
+21:51 < matches> Shading... that's hard
+21:51 < matches> Stroke thickness is kind of hard too...
+21:51 < matches> Blergh
+--- Day changed Thu Aug 07 2014
+21:24 < sulix> So it turns out ttf fonts were not very difficult to add at all: http://davidgow.net/stuff/ipdf-ttf.png
+21:42 < sulix> And fixed the glyphs.svg rendering: http://davidgow.net/stuff/ipdf-glyphs.png
+22:06 < sulix> So all of those Béziers make Gmpint very slow.
+22:07 < sulix> It also runs out of memory very quickly.
+22:11 < sulix> About 30 second of dragging an svg around uses ~15G of ram.
+22:13 < sulix> It takes (with Rational<Gmpint> CPU rendering) ~10 G to render the default frame of glyphs.svg
+22:18 < sulix> Okay, it just broke a computer w/ 32 GB of ram.
+22:20 < sulix> Code is pushed, btw, for your computer-wreckingly-awesome enjoyment.
+22:32 < sulix> I tried fixing Rational::ToDouble() and using GPU w/ CPU coordinate transform.
+22:32 < sulix> Still runs out of memory.
+22:33 < sulix> But it works, even if it's still a tad slow.
+22:45 < sulix> Okay, memory use is not a problem at all if we delete out GMP integers after we're finished with them.
+22:46 < sulix> (There was a TODO: to that effect)
+--- Day changed Fri Aug 08 2014
+16:11 < matches> Wait you just did the things *I* was supposed to do for this week :P
+16:11 < matches> I hope you don't want me to fix quadtrees...
+16:13 < matches> Ah sorry about the GMP
+16:14 < sulix> I gave the QuadTrees another go as well, but random half-letter-"b"s were everywhere.
+--- Day changed Mon Aug 11 2014
+10:56 < matches> Ok I think I need to throw all design principles out the window adding a keyboard handler
+10:57 < matches> I know you were keen on having a mouse handler independent of the Screen class
+10:57 < matches> But the Screen class detects the events
+10:57 < matches> It really makes sense for the event handlers to just be member functions
+10:57 < matches> Maybe virtual in the unlikely event that there are ever different types of Screen
+10:58 < matches> Probably the View should handle the events
+10:58 < matches> Then we wouldn't have this convoluted thing where View has a reference to a Screen but Screen has a pointer to a View...
+10:59 < matches> But I need to let that go and actually do useful things
+10:59 < matches> So KeyboardHandler is now a member of Screen
+10:59 < matches> Delicious spaghetti
+11:02 < sulix> I think I can bring myself to forgive you. :)
+--- Day changed Tue Aug 12 2014
+13:48 < matches> I can draw rabbit_simple.svg
+13:48 < matches> !
+13:48 < matches> Almost
+13:50 < matches> IT IS BEAUTIFUL
+13:52 < matches> Wait I think quad trees are enabled
+13:53 < matches> Nope they aren't
+13:53 < matches> Oh wel
+13:54 < matches> http://szmoore.net/ipdf/infinite-precision-document-FOX.png
+13:54 < matches> That didn't take very long
+13:55 < matches> I suspect the wierd bits in the wrong spot are because there are translations applied to things
+13:55 < matches> Because inkscape
+13:57 < matches> Hmm yeah
+13:58 < matches> I wonder why there are random straight lines between things though
+13:58 < matches> They are filled regions of the same colour and no stroke but obviously we just read the beziers and draw the outlines
+14:50 < matches> Dammit SVG
+14:50 < matches> So the y coordinate of text refers to the bottom
+14:50 < matches> The y coordinate of *everything* *else* refers to the top
+14:51 < matches> It's alright this is ipdsvg we aren't constrained by stupid standards
+14:59 < matches> Ergh somehow fonts are broken in eye of mate...
+14:59 < matches> How did I even...
+15:00 < sulix> Fonts are usually handled with y=0 being the "baseline" of characters.
+15:10 < matches> There are a few wierd things going on with straight lines
+15:11 < matches> Hmm only at the default zoom
+15:11 < matches> Horizontal lines on both cpu and gpu are kind of wobbly
+17:23 < matches> Ok I am suffering from an attack of matrix algebra
+17:23 < matches> It was bound to happen sooner or later I guess
+17:24 < matches> The spaghetti is cooking nicely
+17:26 < matches> The fact that our document is all in GL coordinates and SVGs are not is causing me way more confusion than it really should be
+17:27 < matches> All I need to do is set an initial transformation matrix then everything else should Just Work
+17:27 < matches> Of course it does help if you actually use matrices instead of Rect's
+17:29 < matches> Also I think functions that modify arguments passed by references is one of the things that tpg hates
+17:29 < matches> But there are a lot of them here
+17:29 < matches> They are so convenient!
+22:03 < matches> If I can get transforms and groups actually working properly, we can probably hack some sort of recursive thing together and use view reparenting
+22:03 < matches> Somehow
+22:05 < matches> I'm thinking putting the fox in the rabbit's eye and so on recursively would actually be pretty damn awesome
+22:05 < matches> It is easy to say these things though...
+22:06 < sulix> So, I have view reparenting "working" in the quadtree code.
+22:06 < matches> :O
+22:06 < matches> Cool
+22:06 < sulix> (The rest of the quadtree doesn't work, so the point is somewhat moot, though)
+22:06 < matches> Wait you already had that working, but you have rendering bugs
+22:06 < matches> Yeah
+22:06 < matches> :P
+22:08 < sulix> I will push that now, actually.
+--- Day changed Wed Aug 13 2014
+00:34 < matches> Yes
+00:34 < matches> I have defeate
+00:34 < matches> d
+00:34 < matches> Basic matrices
+00:36 < matches> So it is pretty ugly and inefficient but meh
+00:36 < matches> We have translate, scale and matrix
+00:37 < matches> skew will be pretty easy to add but probably useless
+00:37 < matches> rotate is a bit harder
+00:38 < matches> Also the skewing operations obviously don't work on rectangles
+00:38 < matches> Or anything that isn't defined in terms of bezier paths I guess
+00:38 < matches> But translating and scaling will
+00:40 < matches> Ok, so SVG has a "defs" thing that lets you define groups without drawing them
+00:41 < matches> And a "use" thing that lets you insert a group
+00:41 < matches> Actually element in general
+00:41 < matches> Doesn't have to be a group
+00:41 < matches> So
+00:41 < matches> I wonder if doing recursive magic with that works
+00:48 < matches> Not in normal svg viewers it would seem
+00:49 < matches> Hmm
+00:51 < matches> (eom:7883): librsvg-WARNING **: Circular SVG reference noticed, dropping
+00:51 < matches> That's just boring!
+00:52 < matches> So I think we will need some fairly major changes to our Document structure to get much more SVG stuff working
+00:53 < matches> I wonder if we actually need to store a DOM if we want that to work
+00:53 < matches> Also I thought I fixed transformations but they still break for fox-vector.svg :(
+00:58 < matches> I think "broken" will probably be the most commonly occuring word in our git commit messages
+11:05 < matches> Oooh
+11:06 < matches> svg-tests/recursive.svg is slightly recursive viwed in firefox
+16:10 < sulix> The QuadTree works again!
+16:10 < sulix> (I have finally worked out how to multiply by two, it seems...)
+16:11 < sulix> Also s/ again//
+17:23 < matches> Project complete!
+18:05 < sulix> Man, nVidia has an OpenGL extension where you can just pass the "d" attribute of SVG paths in and have it render them for you.
+18:05 < matches> Oh
+18:05 < matches> Welp
+18:07 < sulix> It's like: glPathStringNV(path, GL_PATH_FORMAT_SVG_NV, strlen(d), "M100,180, L40,10, etc...")
+18:08 < matches> Presumably you could just replace 90% of the SVG stuff with that then :S
+18:09 < sulix> It only works on nVidia hardware, though, so it's not really practical.
+18:10 < matches> I think I need to actually do the Bezier's bounding rectangles correctly
+18:10 < sulix> I was just about to add that, actually.
+18:10 < matches> But its not just (x0,y0,x3-x0,y3-y0)
+18:10 < matches> Ok
+18:10 < matches> Go ahead then
+18:10 < sulix> Nah, you have to take the x and y components separately and solve for min and max.
+18:11 < matches> Yes google is a lot faster than actually doing maths
+18:13 < matches> I can add that unless you've already written it?
+18:13 < sulix> Sure.
+18:13 < sulix> The internet seems to claim that you should use newton-raphson to find the roots of the derivatives, but I'm not really comfortable with doing that for cubic béziers,
+18:31 < matches> I just differentiated the parametric formula
+18:31 < matches> And got a quadratic
+18:31 < matches> Unfortunately there is a slight problem with Real
+18:31 < matches> Since we don't have a general "sqrt"
+18:31 * matches adds that to the growing list of "fix later"
+18:32 < matches> It doesn't compile for Rational<Gmpint> anymore anyway
+18:38 < matches> I am writing code that sjy would probably not consider elegant
+18:50 < matches> Well that totally broke everything
+18:53 < sulix> So it turns out that the view reparenting was only working by chance.
+18:55 < matches> :(
+19:20 < matches> Hmm it turns out finding the bounding box of a bezier has really annoying edge cases
+19:43 < sulix> Okay, automatic generation of new quadtree nodes "works" when zooming in.
+19:44 < sulix> It doesn't do any fancy clipping, so the actual rendering code hits precision issues, but it's still pretty cool.
+19:48 < sulix> It also get a bit buggy if you try to pan over the edges of quadtrees, as it only renders one node at a time.
+19:59 < matches> Nice
+21:14 < sulix> I have just achieved infinite precision with the quadtree!
+21:14 < sulix> Only on rectangles, only when zooming in, and only when the camera doesn't cross a quadtree boundary, but it works!
+--- Day changed Thu Aug 14 2014
+09:50 < matches> cool
+10:37 < matches> I'm beginning to suspect whoever said to use the Newton Raphson method to find Bezier bounding boxes was right
+10:43 < matches> I love how the sites I looked up said "Obviously there is a problem if a = 0 or b^2 - 4ac < 0, but we can just make sure we always pick beziers that don't cause those problems
+10:44 < matches> Ok
+10:44 < matches> I have at least got an algorithm that returns finite sized bounding boxes now
+10:45 < matches> I think it even works!
+10:45 < matches> But only on the CPU
+10:45 < matches> Presumably the GPU does something to cope with the fact that the bounding boxes were totally wrong before?
+10:53 < matches> Oh it wasn't doing anything because they were {0,0,1,1}
+10:54 < matches> I have to transform the Bezier coefficients before they are uploaded to the GPU
+10:54 < matches> Blergh
+10:55 < matches> What I've basically done is change it to be the opposite of how it was designed
+10:55 < matches> -_-
+10:56 < matches> So before, the Bezier control points were relative to some bounding rectangle but when I parsed the SVG I just made it always {0,0,1,1} so the coordinates were absolute
+10:56 < matches> Now I have changed the Bezier control points to be absolute and then calculated a bounding rectangle from them
+10:56 < matches> I can maths
+10:57 < matches> So I could make the Beziers still have the {0,0,1,1} bounds which will fix the GPU renderer without having to transform the coefficients
+10:57 < matches> And just leave this "SolveBounds" function in for actually getting the bounds
+10:58 < matches> Except SolveBounds is disgusting
+10:58 < matches> And slow
+10:58 < matches> So I could add a Bounds member variable to the Beziers
+10:58 < matches> And then we have two bounds
+10:58 < matches> I seem to have coded myself into a catch 22 "No matter what you do it is terrible" situation
+10:59 < matches> Adding a Bounds member variable to the Bezier struct sort of defeats the whole point of the "Object of Arrays" idea
+10:59 < matches> You know what
+11:00 < matches> I think the "Object of Arrays" approach has caused more problems than it solved :P
+11:02 < matches> (Probably not actually)
+11:09 < matches> Spaghetti
+11:09 < matches> I'm going to transform the coordinates before uploading to the GPU shaders
+11:09 < matches> Because I think that is the least objectionable?
+11:09 < matches> I don't know
+11:09 < matches> I still don't like any of the solutions
+11:10 < matches> But having more than one bounding rectangle definitely seems dumb
+11:10 < matches> Especially if the other is *always* {0,0,1,1}
+11:11 < matches> I hope this doesn't totally break your quad tree
+11:15 < matches> Actually looking at the quad tree it seems that is the best way to make it more likely to work
+11:21 < matches> I feel like we should use SVGMatrix more and Rect less
+11:21 < matches> But oh well
+11:29 < sulix> Ah: so the Quadtree kinda relies on the Bézier coordinates being relative to the bounding rectangle.
+11:29 < matches> Yep
+11:29 < matches> I'll do that
+11:29 < matches> It's easier to do the transform when the coordinates are uploaded to the GPU
+11:29 < matches> Although probably less efficient
+11:30 < matches> On the other hand, the CPU renderer relies on having absolute coordinates
+11:30 < matches> Two renderers
+11:30 < matches> TWICE the matrices
+11:30 < matches> TWICE the confusion
+11:31 < matches> And Rects are not really convenient because they aren't a proper transformation matrix
+11:31 < matches> I can't just multiply some Rects together
+11:31 < matches> Or calculate an inverse
+11:32 < sulix> Yeah, there are problems there.
+11:34 < matches> Hmm
+11:34 < matches> I *almost* fixed it
+11:34 < sulix> Rects are really good for the QuadTree, though.
+11:34 < matches> We should leave it as rects
+11:34 < matches> You just manually work out what it needs to be anyway
+11:35 < matches> I think the inverse of the equivelant matrix will always work as a rect
+11:35 < matches> So there are random lines missing from the beziers now
+11:35 < matches> But the ones that are there are in the right spot!
+11:36 < matches> (On the GPU)
+11:36 < sulix> So, I looked at that. I see random missing lines on Intel, not on nVidia.
+11:37 < matches> Oh were they missing before?
+11:37 < matches> Well I don't recall them being missing before
+11:37 < matches> Oh
+11:37 < matches> I know what it is
+11:38 < matches> When the bounding rectangle has width or height of zero
+11:38 < matches> Sigh
+11:38 < matches> Wait that can't be it
+11:38 < matches> Most of the missing lines aren't straight horizontal or vertical
+11:38 < matches> :S
+11:39 < sulix> I think it's just dodgy rounding on the GPU.
+11:40 < matches> I will push what I have I guess
+11:40 < matches> I have nice pretty debug rectangles (in *colour*) around the beziers when they are rendered on the CPU
+11:40 < matches> Somehow I don't think that is going to be sufficiently impressive progress in the meeting
+11:41 < sulix> Oooh... I'm looking forward to trying that.
+11:41 < sulix> I have an impressive Quadtree demo to do!
+11:41 < sulix> Assuming the bezier stuff doesn't suddenly break.
+11:41 < matches> ... it might
+11:41 < matches> Ok, I will `git stash` and then `git pull` as opposed to merging
+11:42 < matches> Yes, there are definitely not randomly missing beziers in your code
+11:44 < matches> Wait, was your quad tree working with beziers before?
+11:44 < matches> It wouldn't have been?
+11:44 < matches> All the bounds were wrong
+11:48 < matches> Ooh
+11:48 < matches> H and V
+11:48 < matches> What are they
+11:49 < sulix> Horizontal and Vertical lines
+11:49 < matches> Ah
+11:50 < sulix> The QuadTree works with beziers, but doesn't increase precision.
+11:52 < matches> Hmm, now to work out which of the 5 or 6 edge cases is breaking the Bezier bounds algorithm
+11:53 < matches> It's kind of hard to debug
+11:53 < matches> The edge cases apply seperately to the y and x directions
+11:53 < matches> So you can't tell just by looking at a curve that it is an edge case
+11:54 < matches> Unless you are a mathemagician I guess
+11:55 < matches> I don't understand
+11:55 < matches> The bounds for the beziers that disappear look right
+11:59 < matches> Maybe I'm not uploading the data correctly anymore
+12:03 < matches> Ok now it only breaks for the horizontal and vertical lines which I at least understand
+12:03 < matches> I was iterating over the object bounds and uploading the ones that had a type of BEZIER
+12:03 < matches> Oh
+12:03 < matches> Oh
+12:04 < matches> Yeah because I added a GROUP as well
+12:04 < matches> And every <path> gets a GROUP now
+12:04 < matches> So the order of indexes must be off
+12:14 < matches> Face palm
+12:14 < matches> This is why we have objects.data_indices
+12:19 < matches> I wish I'd added the SVG stuff earlier
+12:19 < matches> It makes it a lot easier to do stuff when you can mess around with actual documents
+12:42 < matches> I have pushed some stuff
+12:43 < matches> Mostly it just looks like I added a bunch of colourful rectangles to the CPU rendering
+12:43 < matches> I think I broke the Quad tree too
+12:43 < matches> Go team
+12:43 < matches> Oh and there are a bunch of not so colourful GPU rectangles
+12:43 < matches> Due to the "GROUP" object just using the outline rectangle shaders
+12:44 < matches> So part of the quad tree seems to work on the GPU but not all of it
+12:44 < matches> And none of it seems to work on the CPU?
+12:48 < matches> Also instead of rendering a slightly broken fox it now renders a segfault
+12:48 < matches> Similarly for the koch snowflake
+12:48 < matches> It's alright we can still draw Humphrey
+12:53 < matches> Oh
+12:53 < matches> It's just the quad tree that segfaults on the more complicated svgs
+13:38 < sulix> I have returned from the committee meeting, and that stupid 2/3rds majority thing has been revoked!
+13:38 < matches> Hooray!
+13:39 < matches> I should head towards University for the project meeting
+13:39 < matches> It is tempting to just stay home
+13:40 < matches> But that would probably not be wise
+13:41 < sulix> You should come.
+13:41 < sulix> I'm going to see if I can fix the Quadtree, but it looks like your changes have thoroughly broken it.
+13:41 < matches> Sorry!
+13:41 < sulix> By which I mean, it probably was only working if everything had bounds (0,0)-(1,1)
+13:41 < matches> Haha
+13:42 < matches> You can just undo my changes to demonstrate it if you want
+13:42 < matches> To the bus
+13:43 < sulix> I may yet do that...
+14:54 * sulix -> CSSE
+19:08 < matches> So shading on the CPU sort of totally breaks
+19:08 < matches> But it exists
+19:08 < matches> Progress!
+19:10 < matches> Bezier bounds are not as good as I'd hoped
+19:10 < matches> I think they only work if the end points form the bounds
+19:17 < sulix> Ah...
+19:21 < sulix> Btw, in the default "c" glyph, there are _two_ curves with bounds (0,0)-(1,1)
+19:21 < sulix> Numbers 9 and 18
+19:22 < matches> Yeah I found the wierd ebounds
+19:22 < matches> It's in the font code
+19:22 < matches> There is an AddBezierData with (0,0,1,1) instead of AddBezier (which automatically works out the bounds)
+19:22 < matches> For vlines
+19:22 < sulix> That'd do it.
+19:23 < matches> shape.svg seems to lose part of the curve now
+19:23 < matches> I've made the bezier control points relative
+19:23 < matches> Things mostly sort of work
+19:23 < matches> But the quad tree still looks fantastically broken
+19:25 < sulix> It always looks broken if you pan around or zoom out: it's my ugly baby.
+19:28 < matches> http://szmoore.net/ipdf/brokenbeziers.png
+19:28 < matches> To be fair the beziers are actually fine
+19:28 < matches> It's just the bounding rectangles that are broken
+19:28 < matches> Also shading should probably not be turned on unless it is actually a closed path
+19:29 < sulix> Hmm...
+19:29 < matches> Wait
+19:29 < matches> The beziers are rendering fine
+19:29 < matches> But the bounding rectangles are wrong
+19:29 < matches> Does this mean
+19:29 < matches> If I *fix* the bounding rectangles
+19:29 < matches> It will break something
+19:29 < matches> :-(
+19:29 * matches forges ahead nevertheless
+19:30 < matches> It does look suspiciously like it is only ever using P0 and P3 for the bounds
+19:30 < matches> Despite all that horrible solving for the turning points
+19:31 < sulix> Yeah.
+19:31 < matches> Oh
+19:32 < matches> I suspect if I fix this it will totally break the absolute to relative bezier transform then
+19:35 < matches> The file for those beziers is kind of interesting
+19:35 < matches> inkscape has used absolute commands for all except one of the beziers
+19:35 < matches> Why?
+19:35 < matches> The first one was copied and pasted with the control points moved
+19:35 < matches> Also for some reason random "translate" applied to the whole group
+19:36 < matches> It might make some sense if it caused the coordinates of the actual paths to come out as integers maybe
+19:36 < matches> But they don't
+19:37 < matches> There is translate and then the initial "moveto" is not 0,0
+19:37 < matches> I guess we shouldn't be trusting an svg editor that segfaults if you try recursion anyway
+19:59 < matches> Ok, high school maths:1, 5th year science/engineering student:0
+20:15 < matches> Also my amazingly clever shading algorithm has
+20:15 < matches> ...
+20:15 < matches> issues
+20:15 < matches> When the paths are not in the view
+20:16 < sulix> Ah...
+20:18 < matches> In fact it has many issues in many cases
+20:27 < matches> Hmm
+20:27 < matches> I wonder if this is what causes problems with evince/atril
+20:27 < matches> Ok not this
+20:28 < matches> I mean, if they use a similarly terrible except actually working shading algorithm
+20:28 < matches> And just draw everything to a really big texture so they can use it
+20:28 < matches> As opposed to clipping things
+20:28 < matches> That seems a little unbelievable though
+20:29 < matches> Surely that would crash long before you even got to >1600%
+20:30 < matches> I suppose what I should really do is look up some papers on shading
+20:30 < matches> Blergh
+20:35 < matches> Things are pushed
+20:37 < matches> Ah crap
+20:38 < matches> Things will be pushed in 8 hours according to my clock
+20:38 < matches> Just don't do anything until after 4am tomorrow and everything will be in the right order
+20:38 < matches> :P
+20:39 < sulix> That shading is _amazing_
+20:40 < matches> Try replacing the colour with rand()%255 for even more amazingness
+20:40 < sulix> If you zoom in _just_ the right amount, all hell breaks loose. I love it!
+20:40 < matches> Haha
+20:40 < sulix> Slowly panning across it is also magical!
+20:41 < matches> Try it on rabbit_simple.svg
+20:42 < sulix> I think Humphrey might have come down with a case of stripey binary myxomatosis.
+20:43 < matches> So I will have to think about shading a bit more :P
+20:43 * sulix braves the unholy combination of shading and quadtree.
+20:43 < matches> Oh I didn't try that
+20:44 < sulix> It actually doesn't look any different.
+20:44 < sulix> I think the quadtree only breaks w/ the GPU.
+20:44 < matches> Yes
+20:45 < matches> You lose the debug message if the node # > 9 it seems too
+20:46 < matches> At least the quad tree works on the CPU
+20:46 < matches> But why doesn't it work on the GPU they are now using the same bounds
+20:47 < matches> So should I prepare a report for Tim?
+20:47 < matches> Progress Report: Arbitrary precision numbers are unsurprisingly, totally infeasible
+20:47 < matches> Therefore, we implemented random bits of SVG
+20:47 < matches> Figure 1: A totally broken shading algorithm
+20:48 < sulix> You should include this image of the quadtree: http://davidgow.net/stuff/ipdf-humphreys-ghost-face.png
+20:48 < matches> Yes
+20:48 < matches> I wonder if since we're allegedly engineers we should document what bugs go with what images
+20:48 < matches> Hmmm
+20:49 < sulix> That's why I name the screenshots like that, I know this goes with the "Humphrey's Ghost Face" bug.
+20:49 < matches> Haha
+20:49 < matches> So we have the svg-test images
+20:50 < matches> Would it be worth while to have a commit script that automatically drew them and did screnshots
+20:50 < matches> It might be tricky though because you have to test panning and zooming and things
+20:50 < sulix> Yeah... perhaps videos?
+20:51 < matches> We'd need to be able to control the view automatically
+20:51 < matches> Which is actually required for that list of things in the proposal we are supposed to do anyway
+20:52 < sulix> I think we'll want that feature at some point anyway for doing proper performance tests
+20:54 < matches> I kind of want some sort of debug overlay for things like the bounding boxes too
+20:54 < sulix> Hmmm... the bounds look right: http://davidgow.net/stuff/ipdf-humphrey-bounds-ahead.png
+20:54 < matches> And a menu system
+20:54 < matches> And the ability to "insert SVG here"
+20:54 < matches> And open a file browser
+20:54 < matches> And...
+20:54 < matches> And...
+20:54 < matches> Yeah
+20:54 < sulix> I've been seriously considering doing a menu system.
+20:54 < matches> Too bad christmas is after the thesis is due
+20:54 < matches> Do it!
+20:55 < matches> We're running out of mouse buttons to toggle things :P
+20:55 < matches> Are there any SDL based menu systems that we can use easily?
+20:55 < sulix> There are a couple of OpenGL-y ones that might work.
+20:56 < matches> Let's not port the project from SDL -> FreeGlut
+20:56 < sulix> No.
+20:56 < sulix> Let's not.
+20:57 < sulix> (I'm looking for an SDL/OpenGL menu system so that I can replace FreeGLUT in the Graphics project(
+20:57 < matches> Could we use Qt or is that overkill?
+20:57 < sulix> I suspect it's probably overkill.
+20:59 < sulix> I've got a couple of old GUI libraries for SDL/OpenGL I wrote in high school I could dig up as a last resort.
+20:59 < matches> ... I have seen your high school code
+20:59 < matches> :P
+20:59 < sulix> (I think one of them uses a tiny bit of boost, though, so I'd rather avoid it)
+21:03 < matches> I kind of want to look at Qt at some point
+21:03 < matches> Maybe if we have the menu in a seperate window...
+21:03 < matches> Then we need threads...
+21:03 < matches> Then we have two problems...
+21:09 < matches> All the links to SDL libraries are broken
+21:34 < sulix> I'm not sure what changed, but now ipdf crashes my OpenGL debugger.
+21:42 < sulix> The QuadTree/GPU code works again!
+21:42 < sulix> Somehow the bug I fixed last night reappeared, but I've added the needed *2s back in.
+--- Day changed Fri Aug 15 2014
+08:43 < matches> So it seems to work well but things still go wierd on the GPU
+08:44 < matches> I'm in Quadtree node 32 looking at the tip of Humphrey's eyebrow
+08:44 < matches> The bottom line moves normally
+08:44 < matches> Vertically only sorry
+08:44 < matches> It doesn't move horizontally
+08:44 < matches> The top line stays still and every so often jumps to a new (wrong) position
+08:45 < matches> On the CPU it appears fine though
+08:45 < matches> Although on the CPU it doesn't show the "Current View QuadTree Node: 32"
+08:46 < matches> Hrm, I should add a 2d view of a car to the svg-tests
+08:47 < matches> Then I can be like "IT IS RELEVANT TO MECHANICAL ENGINEERING BECAUSE BEZIERS"
+08:47 < matches> In the conference/thesis offense
+08:48 < matches> My concern is actually more how I'm going to present the arbitrary precision number representations because they don't even work
+08:49 < matches> Well I should probably try Gmp rationals and Gmp floats before totally giving up I guess
+08:49 < matches> And also those p-adic things
+08:50 < matches> I never looked them up
+--- Day changed Sun Aug 17 2014
+14:38 < matches> Hey Qt has a lot of stuff in it
+14:38 < matches> They have their own iostreams that seem identical to std::iostream
+14:39 < matches> It's kind of cool I guess except there are "Qs" everywhere
+14:41 < matches> Ok we need a window icon
+14:41 < matches> This is vital
+15:54 < sulix> I've got SDL2 window icon setting code if you want it: https://github.com/sulix/omnispeak/blob/master/src/icon.c#L555
+16:04 < matches> Cool
+16:39 < matches> I'm bringing in spaghetti
+16:39 < matches> I mean Qt
+16:40 < matches> In theory this means the Debug functions should have a mutex if we want to debug things in the Qt stuff
+16:40 < matches> But in practice screw it
+16:40 < matches> What could go wrong?
+16:41 < matches> (Don't worry, I have a CONTROLPANEL_DISABLED define)
+16:42 < matches> This View/Document/Screen thing could probably be tidied up a lot
+16:42 < matches> But effort
+16:42 < matches> I think I'll just give ControlPanel direct access to document, screen and view
+16:42 < matches> Currently everything has to go through view
+16:43 < matches> Which would make more sense if some of screen was in view maybe
+16:43 < matches> Bah screw design
+16:51 < matches> So now we have 4 main classes!
+16:51 < matches> 4 x the fun!
+17:29 < matches> Bargh Qt needs its own version of make
+17:29 < matches> That's stupid
+21:09 < matches> So
+21:10 < matches> I have a mysterious LMS deadline that suddenly appeared
+21:10 < matches> "Progres Report"
+21:10 < matches> Description
+21:10 < matches> "asadf"
+21:10 < matches> Due
+21:10 < matches> 19th August, 11:01PM
+21:10 < matches> What
+21:14 < sulix> Oh dear.
+21:15 < matches> I have sent an email
+21:15 < matches> I hope that's not the conference abstract
+21:15 < matches> I also really hope we're allowed to use our own computer and things in the conference
+21:16 < matches> Also I really hope that if I can use my own computer it doesn't decide to shit itself anyway just to spite me
+--- Day changed Mon Aug 18 2014
+17:06 < matches> Good news and bad news!
+17:07 < matches> The kerning now appears to kern in the right direction
+17:07 < matches> But this means "BleedingCowboys.ttf" works
+20:30 < sulix> It's a pain to look up clipping of beziers, because there's a separate technique for doing something else called "bézier clipping"
+20:40 < matches> Baha
+20:41 < matches> I'm basically just procrastinating with Qt
+20:41 < matches> I mean
+20:41 < matches> Doing *awesome* things with Qt
+20:48 < sulix> I am looking with considerable envy at SolveQuadratic().
+20:49 < sulix> SolveCubic() will get very ugly.
+20:49 < sulix> Assuming I don't just sample the cubic at 100 points and look for roots.
+20:49 < matches> Haha
+20:49 < matches> Newton Raphson?
+20:50 < sulix> Very tempting.
+20:50 < matches> Then you can solve any bezier!
+20:50 < matches> Then we can put in Quintics!
+20:50 < sulix> Solving cubics exactly is not fun.
+20:50 < sulix> Dear god no.
+20:50 < matches> Imagine how many loops a quintic could have...
+20:51 * sulix cries quietly in the corner.
+20:53 < matches> So I'm calling AddText with sane values and nothing is happening :(
+20:56 < sulix> With or without quadtree?
+20:56 < sulix> With quadtree, everything is broken if you try adding things.
+20:56 < sulix> Because they won't be added to a node.
+20:57 < matches> No quad trees I think
+20:57 < matches> Yeah no quad tree
+21:00 < matches> Wait I think we need to rebuild the buffers or something
+21:07 < matches> Ah, ForceRenderDirty()
+21:14 < matches> I don't think the scale of our text is quite right?
+21:14 < sulix> Well, the scale of everything is wrong, but it's entirely possible that the text is _extra wrong_
+21:16 < sulix> In theory, the "scale" input to addText is the "height" of a character.
+21:19 < matches> Mmm
+21:19 < matches> I'm trying to add text relative to the current view
+21:19 < matches> But it isn't consistent
+21:19 < matches> When I go to a different view it is definitely not adding it in the same relative place
+21:20 < matches> The scale and positions aren't *already* relative are they?
+21:22 < sulix> Not to the view...
+21:24 < matches> What are they relative to?
+21:24 < matches> Anyway instead of fixing that bug I'm adding more
+21:25 < sulix> Umm... The bounding box maybe?
+21:25 * sulix investigates.
+21:26 < sulix> Scale and position should (I think) be normal, document coordinates.
+21:26 < matches> Odd
+21:26 < matches> Oh well
+21:26 < matches> Having Qt is totally worth it by the way
+21:27 < matches> Although it is still slightly embarrassing that it has its own SVG parser
+21:27 < matches> Ours is better!
+21:27 < matches> It has Reals everywhere!
+21:27 < matches> Except where it constructs Real from floats...
+21:27 < matches> And converts them to floats...
+21:28 < sulix> Thesis title should be "Keepin' it real: Staying afloat on the sea of document precision"
+21:31 < matches> Bahaha
+21:31 < matches> That is brilliant
+21:32 < matches> The Qt stuff is never deleting anything
+21:32 < matches> I suppose I should fix that at some point
+21:33 < matches> So basically it is a state machine and you use the menu to change the state
+21:33 < matches> Pressing OK does something depending on the state
+21:34 < matches> And there is a single text edit you can type stuff into
+21:34 < matches> In theory it can hide/show different widgets depending on the state
+21:34 < matches> I feel like I should add a "Generate Thesis Title" widget now...
+21:35 < matches> Also I can sort of see the appeal of lambdas for GUI programming now
+21:35 < matches> But I have a feeling they would totally break Qt anyway
+21:49 < matches> ...
+21:49 < matches> Ok sometimes the text gets added upside down...
+21:49 * sulix disclaims any and all responsibility for that.
+21:51 < matches> Yes!
+21:51 < matches> I finally did that thing I was saying I'd do for like 3 weeks
+21:51 < matches> Zoom in to floating point limit
+21:51 < matches> Add SVG
+21:51 < matches> Watch it explode!
+21:52 < sulix> Oooh...
+21:52 < matches> It is glorious
+21:54 < matches> We need to be a bit careful with thread safety in qt
+21:55 < matches> Really we should be able to request that the qt thread call UpdateAll itself
+21:55 < matches> Rather than calling it directly from the viewer thread
+21:55 < matches> But I'm not sure how that's done
+21:55 < matches> There's all this stuff about "Cross thread signals" on the internet
+21:56 < matches> It seems you can hide/show things but not much else
+22:47 < matches> Bah you pushed things!
+22:55 * sulix proclaims the new features as excellent and promptly goes to bed.
+--- Day changed Tue Aug 19 2014
+18:08 < matches> My conference is in the week starting 13th October
+18:08 < matches> Is Tim back then?
+18:08 < matches> "your supervisor will be invited to attend and mark your presentation"
+18:09 < matches> So if he can't go... I don't get a mark?
+18:12 < matches> It sounds suspiciously like they are going to get everyone's supervisors to mark them and then just scale everyone :S
+18:13 < matches> Surely at least one other person is going to read the final report...
+18:13 < matches> I've heard bad things about the engineering scaling system
+18:14 < matches> Your mark becomes inversely proportional to how well your supervisor's students did the previous year or something like that
+18:15 < matches> Anyway, two months left to accomplish something!
+20:05 < sulix> Worked out why the font bounds were weird.
+20:06 < sulix> AddText takes (msg, scale, x, y) not (msg, x, y, scale), so the coordinates were all bunk.
+20:09 < sulix> Fonts looks _amazing_ with floating pt errors, too.
+20:09 < sulix> http://davidgow.net/stuff/ipdf-i-think-you-mean-comic-fail.png
+20:29 < sulix> The Art of Computer Programming briefly mentions the Stern-Brocot tree, btw.
+20:29 < sulix> I can't see it being really useful, though.
+21:06 < sulix> My difficulty clipping bézier paths may be because it is actually impossible.
+21:06 < sulix> I think I've just found a paper saying that it is only possible for béziers which happen to be straight lines.
+22:55 < sulix> Never mind, it is possible, it's just very nasty.
+23:15 < sulix> Also C++14, because we need more lambdas: https://isocpp.org/blog/2014/08/we-have-cpp14
+--- Day changed Wed Aug 20 2014
+12:05 < matches> I guess we've accomplished the goals for this week's meeting then!
+12:05 < matches> (That shading algorithm totally counts as a "first attempt")
+12:07 < sulix> I'm about 2/3rds of the way through deriving the reparametrisation of béziers.
+12:08 < sulix> It basically just boils down to pages and pages of rearranging polynomials.
+12:38 < sulix> I managed to get the qt4/qt5 monstrosity compiling on my laptop.
+12:38 < sulix> It has a "moc-qt4" program, which works, whereas "moc" is qt5.
+16:28 < matches> I think I need to stop adding this log to git...
+23:08 < sulix> matches: But then, how would history record that I've finally got a maybe-correct derivation for cubic bézier reparametrisation: http://davidgow.net/stuff/cubic_bezier_reparam.pdf
+23:08 < sulix> (Code is in git)
+--- Day changed Thu Aug 21 2014
+12:57 < sulix> So it turns out that quadtrees are hard, and reparametrising béziers is why.
+13:03 < matches> I don't seem to see anything anymore with the quad tree enabled
+13:10 < sulix> The quadtree doesn't let you add things in realtime.
+13:10 < sulix> Quadtree nodes are immutable once created.
+13:12 < matches> Ah
+13:35 < sulix> debug: ReParametrise (bezier.h:190) - (0.000000,0.000000),(1.000000,1.000000),(1.000000,1.000000),(1.000000,1.000000) -> (-nan,-nan),(-nan,-nan),(-nan,-nan),(-nan,-nan)
+13:36 < sulix> Looking good!
+13:54 < sulix> Clearly, the quadtree rendering is now perfect: http://davidgow.net/stuff/ipdf-this-is-definitely-a-fox.png
+--- Day changed Sun Aug 24 2014
+17:51 < matches> ...
+17:51 < matches> I am parsing CSS in the SVGs
+17:51 < matches> WHAT HAVE I DONE
+17:52 < matches> Blame inkscape for always using css to control the properties
+17:57 < matches> http://szmoore.net/ipdf/death-by-shading.png
+17:59 < matches> Anyway there is a proper "Group" data type like with the Beziers
+18:00 < matches> So if you want to cache things related to groups you can put them in that I guess
+18:02 < matches> Really it should be called "PATH" not "GROUP" but I vaguely thought it might be able to be used as either
+--- Day changed Mon Aug 25 2014
+10:39 < matches> I was thinking about how to do shading more
+10:40 < matches> And I basically arrived at the idea Loop and Blinn have that you kept talking about
+10:40 < matches> Except I didn't realise it at first because my version was all using rectangles instead of triangles
+10:40 < matches> I think I will try to get my scanline fill to work first though
+13:03 < matches> It sort of works
+13:15 < matches> ... or not
+--- Day changed Tue Aug 26 2014
+14:25 < matches> I wonder if I'm going to end up just reverse engineering an algorithm that I was too lazy to understand properly
+14:26 < matches> I really like the idea of flood fill better than doing insane triangulation maths
+14:26 < matches> Surely GPUs can flood fill
+14:28 < sulix> I think they can, but either very slowly or only on very new hardware...
+14:28 < sulix> I think you'd need to do it in several passes, maybe?
+14:28 < matches> The problem I had with flood fill was working out where to start
+14:28 < matches> I have something that almost works
+14:28 < matches> That requires no clever maths...
+14:29 < matches> But it is CPU only
+14:29 < matches> And probably breaks in a bunch of special cases
+14:30 < matches> It doesn't have precision problems though (once you've drawn the boundary that is)
+14:31 < matches> It would still be cool to go through the Loop/Blinn algorithm on CPU and GPU
+14:31 < matches> Because that is going to have floating point maths in it
+14:31 < matches> flood fill has no floats
+14:31 < matches> Therefore it is infinite precision
+14:31 < matches> Objective complete
+14:32 < matches> Actually I don't think my algorithm is proper flood fill, it's sort of scanline flood fill but not?
+14:32 < matches> When in doubt write random code
+14:34 < sulix> How are you handling the case where, due to a path being half offscreen it becomes two paths?
+14:34 < matches> ... I am not
+14:35 < matches> If part of the path is offscreen it is annoying
+14:36 < sulix> Hopefully, once some of the quadtree code is more functional, the path clipping code can be used to clip paths to the screen.
+14:39 < matches> Compositing is also totally broken because the fill just looks for black pixels
+14:40 < matches> But if I can get it doing fonts then that's sort of not totally useless
+18:35 < matches> I am very tempted to implement a "Please click on the location to fill this path from" interface at the moment
+18:39 < matches> Alright, I have shading somewhat stack overflowing
+18:39 < matches> I mean
+18:39 < matches> Working
+18:39 < matches> *
+18:39 < matches> ********
+18:49 < matches> http://szmoore.net/ipdf/shading-the-only-svg-that-doesnt-segfault.png
+20:43 < matches> Argh
+20:43 * matches stabs coordinate transforms
+20:43 < matches> stab stab stab
+20:44 < matches> My filling algorithm is to find the 4 extrema of the path
+20:44 < matches> And try and flood fill inwards from each one
+20:45 < matches> But the extrema pixel coordinates keep transforming to *outside* of the path
+20:45 < matches> By one pixel
+20:45 * matches stabs
+21:52 < matches> I guess I should just actually implement loop and blinn shading
+21:52 < matches> Flood fill is not as easy as I had hoped
+21:53 < matches> I have to start doing annoying geometry maths to work out what point I can start the flood fill at
+21:55 < matches> Sigh
+--- Day changed Wed Aug 27 2014
+22:33 < sulix> Suddenly: ToAbsolute on ToRelative does not give original Bezier
+22:34 < sulix> I may need to rethink what my quadtree code is doing to those poor curves.
+22:51 < sulix> Never mind, that assertion happens _whenever_ trying to load cubicbeziers.svg.
+23:03 < sulix> Oh wow: you should see what happens if you start splitting and reparametrising beziers with bad precision.
+23:03 < sulix> 'tis "whacked"
+23:08 < sulix> http://davidgow.net/stuff/ipdf-a-slight-curve.png
+23:15 < sulix> And the Quadtree infinite precision for béziers now works*
+23:15 < sulix> *for some beziers.
+23:15 < sulix> * for some large finite value of "infinite"
+--- Day changed Thu Aug 28 2014
+11:35 < sulix> What time is it? It's NaN time!
+11:44 < sulix> Ah, so... horizontal lines have a height of zero in their bounds. This makes divides by zero happen in places.
+11:48 * sulix apologieses profusely for his latest "break absolutely everything" commit.
+11:57 < sulix> Yeah, making divide by zero crash rather than generating NaNs breaks a lot of things.
+11:57 < sulix> You'd be surprised by how often we divide by zero.
+11:57 < sulix> Mostly in the Quadtree code.
+11:58 < sulix> Because, damnit, mathematics can't beat me.
+12:20 < matches> Yes, lines have zero width... stupid lines
+12:21 < matches> I stopped the segfaults in shading by adding a depth counter to FloodFillOnCPU
+12:21 < matches> Which makes interesting shading patterns...
+12:22 < matches> I think it's time to fall back to the "Use the second algorithm on Wikipedia" approach
+12:23 < matches> I can still use a Flood Fill but hopefully a less segfaulty one
+12:29 < matches> I'm not sure about ToAbsolute and ToRelative...
+12:29 < matches> I thought they should be inverses but they seem not to be
+12:29 < matches> Oh wait, the divide by zero would do that
+12:30 < matches> That curve looks cool
+12:30 < matches> You should talk about it lots in the meeting
+12:31 < matches> For the whole meeting
+12:31 < matches> Nothing else
+12:31 < matches> Don't mention the total lack of progress I made...
+12:32 < matches> How much can I trust SolveCubic?
+12:40 < matches> Basically I'm going with randomly picking points until I find one inside the shape then starting a flood fill from that point
+12:41 < matches> Checking the pixels for the edges is not feasable
+12:42 < matches> If you scan along a bresenham line you could jump over the edge
+12:42 < matches> ... I see an "if false" in SolveCubic
+12:42 < matches> Slightly worrying
+12:43 < matches> Ah
+12:43 < matches> I approve of SolveCubic
+13:31 < matches> So
+13:31 < matches> Did you introduce the floating point exception or did I...
+13:45 < sulix> I just did.
+13:49 < sulix> SolveCubic may have small problems.
+13:50 < matches> Yes I am trying to rewrite it now...
+13:50 < matches> I swear we did this in CQM
+13:52 < sulix> Solvecubic also sometimes tries to take the square root of a negative number.
+13:52 < matches> Yep
+13:54 < sulix> I've pushed slightly less broken code.
+13:55 < sulix> Ny which I mean slightly more broken.
+13:55 < matches> ...
+13:55 < sulix> I'm avoiding divide by zeros by "if (denominator = 0) denominator = 1" style shenanigans.
+13:56 < matches> I'm slightly scared by the change to Rect::TransformRectCoordinates
+13:56 < matches> Oh right
+13:56 < matches> Yeah
+13:56 < matches> That seems...
+13:56 < matches> Scary
+13:56 < sulix> It works, scarily enough.
+13:56 < matches> Anyway I already ifdef'd the thing out of SolveCubic
+13:56 < matches> It's too slow for me though
+13:57 < sulix> And by works, I mean I haven't found any issues yet.
+13:57 < matches> I am brute forcing a point inside the shape
+13:57 < matches> This requires finding the intersections with horizontal and vertical lines for every single bounding bezier
+13:57 < matches> Then the "even or odd" test
+13:57 < matches> You only have to do it once
+14:05 < matches> I think SolveCubic would best be done by doing Newton Raphson or the Shooting Method between the endpoints and the turning points
+14:05 < matches> I'll see
+14:06 < matches> I'll try implement it and see if it's faster
+14:06 < matches> You may have to demonstrate my totally broken shading for me
+14:06 < matches> I haven't committed in a while
+14:41 < matches> Oh
+14:41 < matches> SolveCubic may not have been the bottleneck there...
+14:41 < matches> -_-
+14:41 < matches> The failure to update the variable for a while loop miiiight be more of an issue
+14:44 < sulix> Good, 'cause I'm thinking of "upping the SolveCubic accuracy" a bit.
+14:44 < sulix> Anyway...
+14:44 * sulix -> CS
+14:46 < matches> I've reimplemented SolveCubic
+14:46 < matches> In theory it works
+14:55 < matches> I reckon Binary Search is the only algorithm I am good at implementing :S
+14:57 < sulix> Oooh...
+14:57 < matches> What?
+18:56 < matches> So, the fact that we are not solving cubics analytically is probably important in terms of precision issues
+18:58 < sulix> Yeah, that's why I started trying to solve them analytically and then stopped and cried.
+18:58 < matches> :(
+18:59 < matches> There is a solution, it's just ugly
+18:59 < sulix> Nah: for the Quadtree, it didn't matter much. As long as the error went in the correct direction, you'd just lost a tiny bit of efficiency.
+19:00 < matches> Hmm
+19:00 < matches> I don't expect shading using arbitrary precision arithmetic will be particularly fast anyway...
+19:01 < sulix> Well, ideally most of the work in the shading will be done in screen-space anyway.
+19:01 < matches> Yes
+19:02 < sulix> And, of course, you don't need infinite precision for that because pixels/integers/etc.
+19:03 < sulix> So, fingers crossed, things shouldn't matter too much.
+19:03 * sulix realises that that is a maddeningly vague statement.
+19:03 < matches> Well
+19:04 < matches> I got the fill point to actually be in the correct location by actually solving the intercepts correctly
+19:04 < matches> But
+19:04 < matches> If you zoom *out* far enough, it can end up no longer inside the shape when transformed to screen space
+19:04 < sulix> Okay, new plan.
+19:04 < sulix> No zooming out.
+19:05 < matches> I wish there were other people in this channel so I could justify putting that in qdb
+19:20 < matches> There is a temptation to not require all those references to be const during rendering
+19:20 < matches> We might want the Path to be able to alter itself based on the view
+19:20 < matches> But I guess we'll take that path when we get to it
+19:22 < matches> It might be worthwhile caching Path's for fonts
+19:22 < matches> But I'd have to change the coordinates to be relative
+19:22 < matches> Too many coord transforms
+19:24 < sulix> Yup, that can be the subtitle of the thesis: "Too many coord transforms"
+19:26 < matches> "A coordinated approach to graphics"
+19:26 < matches> Oh wow
+19:26 < matches> That should be a textbook
+19:26 < sulix> "Transformers: Matrices in disguise"?
+19:30 < sulix> Okay, it turns out (if denominator is zero, make denominator 1) has one flaw.
+19:30 < sulix> Sometimes you should make the denominator... negative 1.
+19:30 < matches> ...
+19:30 < sulix> Somehow, I did not see this coming.
+19:30 < matches> I'm not sure how this maths works
+19:30 < matches> 1/0 != 1/-1
+19:30 < sulix> That's what they want you to think.
+19:31 < sulix> (Or maybe the bug I'm having is unrelated to that, but it seems like a fun guess)
+21:16 < matches> Floating Point Exception in fglrx!
+21:16 < matches> glXDestroyContext
+21:16 < matches> It only happens when the program is about to close
+21:16 < matches> So I'll be fine
+21:18 < sulix> Ah, maybe enabling floating point exceptions was a bad idea.
+21:18 < sulix> ...if it causes lots of "fglrxceptions"!
+21:21 < matches> Well fglrx is exceptional
+21:37 < matches> I'm falling back on just testing a crap tonne of points for "inside" and adding all the ones that are to a vector
+21:37 < matches> I think there are some false negatives in Path::PointInside
+21:37 < matches> Also FloodFill misses some edge pixels which makes no sense
+21:38 < matches> If it's next to a filled pixel it should get filled!
+21:47 < matches> So the disadvantage of using a breadth first search is that when your queue gets really big instead of getting a segfault you just get OOM
+21:48 < matches> segfaults are quick
+21:48 < matches> segfaults are like a pistol and oom is like drowning
+21:54 < sulix> There is no way a BFS floodfill should ever OOM
+21:54 < sulix> How many pixels are there, and how much are you storing per one?
+21:58 < matches> Probably max 256x256 pixels, 4 way fill
+21:58 < matches> It does not like rabbit_simple.svg
+22:04 < matches> Yeah there is *something* causing it to get in a loop
+22:04 < matches> Because obviously my BFS didn't check for loops
+22:14 < matches> -_-
+22:14 < matches> It is in a loop
+22:14 < matches> Because there is a region with fill colour of white
+22:14 < matches> And the flood fill is just "If it isn't white, stop"
+22:14 < matches> Maybe I should set the background to have 0 alpha or something
+22:15 < matches> Alpha seems to not actually do anything at the moment
+22:27 < matches> http://szmoore.net/ipdf/who-the-hell-needs-antialiasing-anyway.png
+22:44 < matches> http://szmoore.net/ipdf/shady-the-fox.png
+22:47 < matches> rabbit_simple.svg actually doesn't work as well as rabbit.svg
+22:48 < matches> I think one of the fill points of the outer ear is inside the inner ear
+22:54 < sulix> Oh my... They're beautiful!
+23:07 < matches> Ah crap
+23:07 < matches> I will be pushing
+23:07 < matches> 8 hours in the future
+23:07 < matches> I really should fix my system clock
+23:07 < matches> One of these days...
+--- Day changed Mon Sep 01 2014
+17:05 < matches> The wobbly lines on things are irritating me
+17:10 < matches> There doesn't seem to be anything wrong with Bresenham, which means the actual line endpoints are wrong
+17:11 < matches> The GPU does everything from floats and magically they go to the right spot in the buffer
+17:11 < matches> The CPU has to calculate integer pixel coordinates
+17:16 < matches> I need a magnifier I can't see the pixels that are in the wrong spot
+17:16 < matches> I know they are there
+17:21 < matches> ... ok maybe the Bresen Ham was a little past its use by date
+19:48 < matches> The more I try and get these lines to not look dumb, the more convinced I become that glDrawLines is doing something fancy
+19:56 < matches> You end up with wiggles in the line because the end points round to a different pixel to what you end up at by drawing the line
+19:57 < matches> If you make sure you start from where the last line ended, you still get a bend because of the left over error from the last line
+19:58 < matches> ...
+19:58 < matches> Drawing a single line when you know the Bezier is actually a single line is probably going to be less rage inducing than trying to fix this
+21:01 < matches> The Beziers are now classified according to Loop and Blinn
+21:01 < matches> Well
+21:01 < matches> Maybe
+21:01 < matches> It at least knows what lines are
+21:01 < matches> ...
+21:02 < matches> Ok all the ttf beziers are SERPENTINE and LOOP so that's probably wrong
+21:43 < matches> Ah, floating point precision strikes again
+21:43 < matches> That's kind of annoying
+21:47 < matches> But I suppose it's relevant
+21:47 < matches> Unless I'm totally screwing something up
+21:48 * matches adds in arbitrary fabs(x) < 1e-6 checks
+21:58 < matches> On the other hand, if you use DeCasteljau and stop the sub dividing whenever you get to something that classifies as a line, it's actually pretty cool
+21:59 < matches> But if you zoom in too far it starts to get classifications totally wrong
+22:02 < matches> Yeah I have an abstract due in 2 weeks
+22:02 < matches> so screwed
+--- Day changed Tue Sep 02 2014
+13:42 < matches> Ok, let's not use floating point values for colours
+13:42 < matches> Baad
+13:43 < matches> Bad bad
+13:43 < matches> Bad sheep
+13:43 < matches> The project isn't about precision of representable colours
+13:44 < matches> So I'm perfectly OK with using uint8 for colour components
+18:53 < matches> Is it too late to change the aim of the project to "render svg-tests/fox.svg but without antialiasing"
+18:54 < matches> "Or using the GPU"
+18:55 < matches> Well, I understand why shading doesn't usually use flood fill now anyway
+18:55 < matches> But I still kind of think flood fill is better at high resolutions
+18:56 < matches> Not parallelisable I guess
+18:56 < matches> ... Or is it
+18:57 < matches> I was going to try and do arbitrary precision stuff but it seems we can no longer compile unless Real == double or float
+--- Day changed Wed Sep 03 2014
+17:26 < matches> It would seem Mr Munroe has beaten us...
+17:28 < matches> In Javascript
+17:28 < matches> We should die of shame
+17:29 < matches> Hahaha
+17:29 < matches> "// there is no elegance here. only sleep deprivation and regret"
+17:31 < matches> On the bright side, we now have a reason to reference xkcd
+17:31 < matches> I guess?
+17:59 < sulix> I just saw that, and had planned to use that comment as my next commit message.
+--- Day changed Thu Sep 04 2014
+10:59 * sulix sulix also engages panic mode.
+11:00 * sulix apparently also needs to engage sleep mode.
+11:00 * sulix almost engaged sheep mode by mistake.
+11:49 < sulix> How sure are you that SolveCubic works?
+18:37 < matches> Well, sure within 1e-4
+19:40 < matches> Rational<Gmpint> compiles again
+19:41 < matches> It just takes... several minutes... to load "The quick brown fox jumps over the lazy dog"
+21:04 < matches> I have a new ingenius plan
+21:06 < matches> This will probably not work but hopefully it won't take me too long...
+21:06 < matches> Oh dear what am I saying
+21:06 < matches> It's going to take a month now
+22:24 < matches> I really should be integrating one of those two libraries Rowan suggested into the project
+22:24 < matches> As opposed to implementing what I like to call the "Paranoid Number"
+22:25 < matches> It starts as a float
+22:25 < matches> It checks each operation for an exception, and if it does it adds the operation to a linked list instead
+22:25 < matches> After trying to simplify the next elements in the list
+22:26 < matches> This is going to be awful
+22:26 < matches> But it's been a while since I wrote a good linked list
+22:32 < matches> ... I think the last linked list I wrote had a nasty tendency to randomly segfault...
+22:32 < matches> Nevertheless we shall forge ahead
+23:14 < matches> You know you haven't had enough sleep when you start to terminate lines with ':' instead of ';'
+23:14 < matches> I blame python
+23:14 < matches> Not that it was valid python syntax either
+23:15 < matches> But it's a good scapesnake
+23:42 < matches> Oh recursive list based functions
+23:42 < matches> How I have missed you
+23:42 < matches> void Foo() {if (m_next != NULL) m_next->Foo();}
+23:42 < matches> <3
+--- Day changed Fri Sep 05 2014
+09:26 < matches> It sort of kind of works
+09:26 < matches> Except when it breaks
+09:26 < matches> ParanoidNumber::Simplify needs improvement
+09:26 < matches> Also operator+=
+09:26 < matches> operator-=
+09:26 < matches> operator*=
+09:26 < matches> and operator/=
+09:26 < matches> But it's definitely a number
+09:27 < matches> It just occasionally does things in totally the wrong order'
+09:28 < matches> So basically the idea is if you have an inexact (or overflow/underflow) operation, you delay it, and then in theory you can rearrange the operations so you have a smaller error...
+09:28 < matches> It seems to give better results than floats for tests/paranoidcalculator
+09:29 < matches> But that might be because it is initialised off 3/10 and the float starts at 0.3
+09:30 < matches> It could all be totally useless
+09:30 < matches> It probably is totally useless
+09:31 < matches> I have a hunch that even if it's terrible it might beat true arbitrary precision arithmetic
+09:31 < matches> In terms of actually being able to use it
+09:31 < matches> Who needs mathematics when you have blind intuition...
+--- Day changed Sun Sep 07 2014
+11:37 < sulix> Explicit mentions of hitting floating point precision issues in the xkcd comic: http://chromakode.com/post/notes-on-xkcd-pixels
+17:33 < unmercifulfish> mwahahaha
+17:34 < unmercifulfish> you can't escape my stalkerish tendencies now
+--- Day changed Mon Sep 08 2014
+11:10 < matches> This channel seemed like such a good idea at the time...
+11:19 < sulix> (So did the quadtree...)
+12:08 < Pommers> http://chromakode.com/post/notes-on-xkcd-pixels
+12:10 < sulix> It's gettign crowded in here.
+12:10 < sulix> Pommers: We were looking at that yesterday. The XKCD guys had it easy.
+12:11 < Pommers> Lets get all the people in here
+12:42 < unmercifulfish> IPDF PARTY
+13:49 < matches> Hmm, maths is harder than I thought
+15:41 < Pommers> Speaking of math, I know a guy who is looking for people versed in maths and willing to work on psuedo random number sets
+--- Day changed Wed Sep 10 2014
+11:50 < matches> So, compiling with mpfr reals is not as simple as including the mpfr real header and doing a typedef
+11:50 < matches> As there appear to be compiler errors in mpfr
+11:51 < matches> Does anyone actually check that things compile before including them in debian..
+11:53 < matches> I'd expect this sort of thing from Fedora
+11:58 < matches> Never mind it's namespace issues
+11:58 < matches> I'm sorry debian
+12:15 < matches> Something is horrendously broken about mpfrc++
+12:16 < matches> Oh
+12:17 < matches> #if REAL >= REAL_RATIONAL was not a wise choice
+12:21 < sulix> Ah...
+12:24 < matches> mpfrc++ is at least as precise as doubles but slower
+12:24 < matches> I never actually found the limit for doubles
+12:24 < matches> I should do that first
+12:26 < matches> Hmm, things start to disappear at around 4e-11 but you can still add stuff and it looks fine
+12:27 < matches> Ok doubles go crazy at 1e-17
+12:27 < matches> 1e-15 even
+12:30 < sulix> Is that zooming in on the origin, or somewhere further away?
+12:31 < matches> Somewhere further away
+12:31 < matches> If you translate towards the origin you can actually see the shapes start to get better
+12:31 < matches> It's actually pretty cool
+12:35 < matches> There's something dodgy with starting the View with low width/height as opposed to zooming in to the same width/height
+12:37 < matches> mpreal doesn't seem to want to show anything
+12:39 < matches> I think it's well past time we automated the zooming/translating process
+12:39 < matches> Sitting here zooming for 20 minutes is not really an effective use of time...
+12:47 < matches> Speaking of which, the CPU shading evaluates the fill points lazilly now, so you don't have to wait 5 minutes even with doubles just to load an SVG
+15:39 < sulix> For all of the hangers on... quadtrees are now slightly more functional.
+15:39 < Pommers> "functional"
+18:40 < iceweaselOS> Apparently talking in ICC isn't allowed
+18:41 < iceweaselOS> ICC
+18:41 < iceweaselOS> dammit
+18:41 < iceweaselOS> it has autocorrect
+18:42 < iceweaselOS> Humphrey the rabbit does not work :(
+18:42 < iceweaselOS> it gets stuck in pause
+--- Day changed Thu Sep 11 2014
+10:53 < matches> I wonder who that was
+10:59 < matches> "... for some reason in irram they decided to let x<y loop forever if x=y ..."
+10:59 < matches> That's...
+10:59 < matches> Ok
+10:59 < matches> Fine
+11:00 < matches> sulix: How many "x < y" checks do we have?
+11:10 < sulix> A finite number..., I guess?
+11:10 < matches> iRRAM appears to do some sort of fancy wrapping of MPFR
+11:11 < matches> So I'm not hopeful
+11:11 < matches> Considering MPFR seems to slow down hideously
+11:11 < sulix> Wrap all of the numbers inside other numbers.
+11:11 < matches> I did some more ParanoidNumber stuff
+11:11 < matches> Maybe one day it will actually give the correct result
+11:11 < matches> Then I can actually implement Simplify() ...
+11:12 < sulix> http://en.wikipedia.org/wiki/Binary_GCD_algorithm
+11:12 < sulix> (If you want fast gcd for bigints, btw)
+11:14 < matches> Should I plead "I had assignments due" or "I was seeing if Humphrey The Rabbit would work on a Firefox OS phone" in the progress meeting...
+11:14 < matches> iRRAM does seem to have a friendly install script
+11:15 < sulix> As long as you don't plead the FITH, you're probably fine. :P
+11:16 < matches> I'm fairly certain that floats are the best possible number representation and you need to do something more clever than just change your number representation if you want an arbitrary precision document
+11:16 < matches> Something like... some kind of... quad... tree
+11:17 < sulix> Do not use those words. You may not be able to vanquish what you summon.
+11:23 < matches> I need to write an abstract...
+11:24 < matches> "We compare different number representations and find them all to be useless"
+11:24 < matches> Hmm, something non commital
+11:25 < matches> "By the date of this conference we will hopefully have something interesting to say"
+11:25 < matches> "We discuss the drawbacks of adding IRC channel logs to git repositories"
+11:26 < matches> Ah nooo
+11:26 < matches> iRRAM uses "REAL"
+11:28 < matches> Also someone's been using too much javascript because there are all these extra ';' in their headers and it annoys -Werror=pedantic
+11:58 < sulix> ... :-(
+15:04 < matches> Spot the slight mathematical flaw in iRRAM
+15:04 < matches> inline LAZY_BOOLEAN operator == (const REAL& x, const REAL& y){ return (y<x)&&(x<y) ; }
+15:05 < matches> inline LAZY_BOOLEAN operator != (const REAL& x, const REAL& y){ return (y<x)||(x<y) ;}
+15:06 < matches> inline LAZY_BOOLEAN operator <= (const REAL& x, const REAL& y){ return (x<y); }
+15:06 < matches> They don't seem to have equality
+15:06 < matches> But that doesn't stop them implementing the operators...
+18:21 < sulix> Clearly the way to fix your computer's clock issues: http://jackf.net/bezier-clock/
+18:22 < matches> Against all better judgement I am still trying to fix ParanoidNumber
+18:22 < matches> And oh my goodness that is amazing
+18:23 < matches> But
+18:23 < matches> It still thinks it's 02:23:31
+18:23 < sulix> Unless I fix the quadtree view code, infinite precision only works if the coordinate you're zooming in on can _not_ be represented as a float.
+18:24 < matches> ?
+18:24 < matches> ??
+18:25 < sulix> So if you zoom in on a coordinate that is exactly representable as a sum of powers of two, then you're always zooming in on the boundary between two quadtree nodes.
+18:25 < matches> Haha
+18:26 < matches> Could you use an extra "centre" node?
+18:26 < matches> That would be redundant though
+18:26 < matches> Hm
+18:26 < sulix> Nah, I just need to actually get around to supporting displaying content from more than one node at a time.
+18:32 < matches> ParanoidNumbers seem to actually construct properly now
+18:32 < matches> At least, if you construct them and convert back to doubles, they are within 5% of the double
+18:33 < matches> Now... simplifying...
+18:33 < sulix> With float ParanoidNumbers or double ParanoidNumbers?
+18:33 < matches> doubles
+18:33 < matches> But I'm testing the traversal of the list(s) when converting back
+18:34 < sulix> Ahhh...
+18:34 < matches> You need two recursive functions and I really hope I don't get stack overflows...
+18:35 < matches> You start with "value = Head.value * Head.MultiplyFactors + Head.AddTerms"
+18:35 < matches> Then define MultiplyFactors as "1 * f1.AddTerms * f2.AddTerms * ..."
+18:36 < matches> Then AddTerms is "0 + t1.MultiplyFactors + t2.MultiplyFactors + ..."
+18:36 < matches> It gets confusing how you deal with division and subtraction...
+18:37 < matches> I'm sure you can write that as a non recursive function... somehow...
+18:37 < matches> I don't seem to be overflowing the stack though
+18:38 < matches> So 666 operations have taken 5 minutes
+18:38 < matches> But that's without simplifying anything
+18:38 * sulix is currently traversing quadtree nodes via needlessly complicated recusion.
+18:38 < matches> I am quitely confident that I may be able to render a frame in at most 10 years
+18:39 < sulix> Clearly in your seminar, you should start zooming in and when it gets slow just say "If you'll bear with me for a moment" and then just leave the room.
+18:39 < matches> The thought has crossed my mind...
+18:41 < matches> Something that is kind of cool is I can change the digit to be something like uint8_t and see how well it converts to floats
+18:41 < sulix> That is pretty cool.
+18:41 < matches> It will be when I implement it that is
+18:41 < sulix> How well _does_ it convert to floats?
+18:42 < sulix> (Also, sudden thought: is NaN a valid mark for this project, as I am getting the feeling it should be...)
+18:42 < matches> My paranoid number tester does occasionally fail with "NaN != NaN"
+18:42 < matches> That's good!
+18:42 < matches> They both got NaN!
+18:43 < matches> Well, ideally I will be able to make it so that the ParanoidNumber *doesn't* get NaN
+19:17 < sulix> Hmm... I think the ext4 driver just crashed on my computer.
+19:18 < matches> :S
+19:18 < sulix> I didn't know that was possible.
+19:25 * sulix -> other computer
+19:31 < matches> I'm inventing cool terminology
+19:31 < matches> Paranoia
+19:31 < matches> Is the number of ParanoidNumbers...
+19:33 < sulix> "Peeking around corners looking for NaNs, wearing a tinfoil hat to guard against surious SIGFPEs, it's... ParanoidNumber!"
+19:33 < matches> That is the best description
+19:33 < matches> Well
+19:34 < matches> It actually kind of blindly walks around the corner into the SIGFPE and then freaks out and runs back around it
+19:35 < sulix> It's like running away from the fireball in slow motion.
+19:37 < matches> I'll at least win an award for most original number representation
+19:37 < matches> (He hopes)
+19:37 < matches> (It's probably not)
+19:38 < matches> (It's probably equivelant to one of the many alternative number representations that I didn't look up...)
+19:38 * sulix also hopes there is an award for most buggy implemention of a quadtree.
+19:38 < matches> (Specifically, the ones in the Handbook of Floating Point arithmetic that were described as "curiously useless")
+19:40 < sulix> (Googling "curiously useless" yields the phrase: "My boss is curiously useless. He fanatically creates an abundant amount of work for everyone while at the same time manages to get nothing done.")
+19:40 < sulix> (I suspect they're referring to iRRAM)
+19:40 < matches> Bahaha
+19:43 < matches> I think that simply replacing floats with int8_t actually does work
+19:44 < matches> Which is cool because it is easier to test if an operation with int8_t can be represented exactly
+19:44 < matches> But on the other hand there will be fewer operations that can be represented exactly
+19:45 < matches> I think this may actually work
+19:46 < matches> You don't need arbitrary precision to represent screen space and you are converting from view space to screen space
+19:47 < matches> So maybe it won't be that terrible, even though it would need a lot more digits to represent the same arbitrary precision value
+19:47 < matches> I think
+19:47 < sulix> You need more than an int8_t to represent screen space.
+19:47 < sulix> (An int16_t would do it, though)
+19:48 < matches> You just need to be able to represent each individual factor in the operation
+19:48 < matches> factor and term
+19:48 < sulix> You may (probably will) need factors > 127
+19:48 < matches> Probably
+19:50 < matches> If I just implement an "Exact" template function...
+19:50 < matches> Uh oh, templates
+19:51 * sulix thinks that he's approaching the worst recursive subroutine ever written.
+19:52 < sulix> (It has four switch statements in it so far)
+19:57 < matches> Template errors
+19:57 < matches> Aargahasdf
+19:58 < matches> Compilers are so good at identifying exactly what error you made and so useless at actually providing any hint of how you can fix it
+19:58 < matches> It's totally different from like "expected ';' before ..."
+19:59 < sulix> I saw a feature request for Google translate to support "gcc -> English".
+19:59 < matches> I want to specialise some template static member functions...
+19:59 < matches> That was my first mistake...
+20:00 < matches> Ok, they don't need to be static member functions, they can just be ... whatever you call a function that has no namespace associated with it
+20:01 < sulix> Functions...?
+20:01 < matches> Bah
+20:01 < matches> I would say "Regular functions" but they tend to be less common in C++
+20:02 < sulix> I've heard them called "first-class functions" before.
+20:03 < matches> That's a little elitist
+20:03 < sulix> I'm sort-of enamoured with the idea of "business-class functions" and "economy-class functions," though.
+20:11 < sulix> BTW, I just commited something that doesn't compile. Fixes will come shortly, it was just the easiest way to get it from computer A -> computer B.
+20:13 * sulix has made a typo and copy-pasted it into 16 places.
+20:13 < matches> copy-paste is best practice...
+20:14 < matches> It irks me that "a -= b" is equivelant to "a += (-b)" but there is no "a /= b == a *= (-b)"
+20:14 < matches> Well there is sort of, but only for rationals
+20:14 < sulix> The operator you're looking for is (1 / b)
+20:14 < matches> Yes, but - is quicker
+20:14 < sulix> This is true.
+20:15 < matches> I mean 3 can be represented exactly but 1/3 cannot
+20:15 < matches> With floats
+20:15 < matches> Most annoying
+20:15 < matches> I'm currently trying to reduce all the superflous "{0 + ...}" in ParanoidNumber
+20:16 < matches> It likes to create 1000 element lists with 900 zeroes in a row
+20:35 < unmercifulfish> this is gripping reading
+20:35 < unmercifulfish> so glad I am a part of this
+20:35 < matches> This is the cutting edge of useless research
+20:41 < sulix> "The bézier tiptoed out of bed. What an adventure it would be to go beyond the quadtree node in which it had lived its entire life. Its mother had told it sternly that it was dangerous to wander the dark wastes beyond the root node. Bobby Bézier had never believed the stories, though: there were no such things as wild NaNs that ate all of the coefficients of naughty boys. Bobby looked up at the sky: the infinite void of night penetrated only by the deb
+20:43 < Pommers> Oh yeah. One of the people in cs has a nice post on their door about rabbits that I want to grab a copy of
+20:50 < matches> I have a "TrustingOp" and "ParanoidOp"
+20:50 < matches> I think I'm having too much fun...
+20:54 * sulix has decided to give up actually coding and take up writing bézier curve fanfiction full time.
+20:55 < sulix> (People say it's derivative, but it's just about to reach a turning point)
+21:15 < unmercifulfish> qdb
+23:09 < matches> Oh dear
+23:09 * matches curses kahan
+23:10 < matches> I do not understand how this works, but if I delete terms that are "-0" things break
+23:13 < matches> So I got to the point where ParanoidNumber gave results that were reasonably close to just using a normal double without simplifying them
+23:14 < matches> And now I am basically adding random lines of code and running the tester and seeing if it still works :S
+--- Day changed Fri Sep 12 2014
+00:15 < matches> This reminds me of the James Micken comment about addition and multiplication basically being the same thing...
+01:19 < matches> Oh my goodness
+01:19 < matches> I think ParanoidNumber just worked for one very specific case!
+01:19 < matches> ParanoidNumber: 0.3 + 0.3 + 0.3 = 9/10, ToDouble() -> 0.9000000000000000222044604925031308084726
+01:20 < matches> double: 0.3 + 0.3 + 0.3 = 0.9000000000000001332267629550187848508358
+01:20 < matches> And strtod("0.9") = 0.9000000000000000222044604925031308084726
+01:23 < matches> For 0.2+0.2+0.3 = 7/10 it has an error of 1e-16 compared to doubles which apparently have no error
+01:24 < matches> But as floats it has an error of 1e-8 compared to 4e-8
+01:24 < matches> Hmm, why does 7.0 / 10.0 give a bigger error than 0.2 + 0.2 + 0.3
+01:24 < matches> Oh
+01:24 < matches> It'll be denormals probably
+01:25 < matches> That is... quiet irritating
+01:27 < matches> So... it is sometimes better than a float but only if there is a full moon and you sacrifice thrice the number of one tenth of unity goats three times
+01:28 < matches> The other times it breaks because subtraction is totally FITH
+01:29 < matches> Oh, it should be able to do 1/3 + 1/3 + 1/3 except my calculator tester doesn't allow me to enter non decimal numbers
+01:32 < matches> I think 0.3+0.3+0.3 is the only thing it can do better than regular floats
+01:32 < matches> Woo
+01:40 < matches> Ah it is better at beating doubles when it is using doubles as the digit type
+01:40 < matches> But it still is sometimes worse if you have a small number of operations
+01:40 < matches> Probably because one division is less precise than several additions
+01:42 < matches> I'm going to keep telling myself that this is useful
+01:42 < matches> After I sleep
+01:51 < Pommers> It isn't currently a full moon...
+01:51 < Pommers> Also
+01:51 < Pommers> Go to bed
+11:27 < matches> It was a full moon after I sacrificed the goats
+11:40 < Pommers> Stop toying with space matches
+--- Day changed Sat Sep 13 2014
+09:25 < unmercifulfish> I feel that the logs for this chat should just be added to qdb
+09:25 < unmercifulfish> < matches> It was a full moon after I sacrificed the goats
+12:36 < Pommers> Should make a QDB bot for submitting them
+16:20 < matches> When sulix is awarded the nobel prize for his work on quad trees, I will be proud to be a part of this channel
+16:21 < Pommers> Until then you won't be?
+16:23 < matches> I've been thinking of adding a "grep -v matches" before the automatic log commit
+17:45 < matches> I am a horrible person
+17:45 < matches> I am exploiting that "delete" acting on a NULL pointer has no effect
+17:46 < matches> "delete Operation(new ParanoidNumber(a), ADD)"
+17:47 < matches> Where Operation will either return the first argument or NULL
+17:50 < matches> At the moment I'm very pleased with how cleverly I am about to shoot myself in the foot
+17:50 < matches> We'll see how I feel after I pull the trigger
+17:53 < matches> I have either written an extremely elegant or an extremely segfaulting function
+17:57 < matches> The latter is looking more and more likely
+17:57 < matches> But I'm sure there is beauty underneath
+17:57 < matches> Like the ugly duckling!
+17:59 < matches> There's still hope, it turns out I'm segfaulting way before I even get to that
+18:01 < matches> Apparently 2+1 is 6, but doubles think 2+1 is 5
+18:02 < matches> "Freedom is the freedom to say 2+2=4, if that is granted, all else follows"
+18:06 < matches> Ok, 1 + 1 is 2
+18:06 < matches> I think we can call that a result
+18:06 < matches> Write the thesis and we're done here
+22:18 < matches> 1 + 0.3 = 13/10 and 13/10 + 0.2 = Segfault
+22:18 < matches> Getting close
+22:19 < matches> Now I'm doomed to not sleep until it works because I'm never going to remember how this works
+22:20 < Pommers> Got a whiteboard?
+22:20 < matches> I do actually but it's in the other room
+22:20 < matches> And it does not have space for this
+22:22 < matches> I don't think I've ever used so many delete operators...
+22:23 < matches> Also constructing a 4 diretional list on the stack then stealing one of the branches
+22:23 < matches> It's a game of "dodge the double delete!"
+22:24 < matches> Which reminds me, we have copious memory leaks in an external library
+22:24 < matches> 'ld' ?
+22:25 < matches> /lib/x86_64-linux-gnu/ld-2.19.so
+22:25 < matches> Not sure if that's something I'm doing wrong
+22:26 < matches> Turns out you can't pipe valgrind's output to less
+--- Day changed Sun Sep 14 2014
+18:23 < matches> http://szmoore.net/ipdf/sam/abstract.txt
+18:24 < matches> You know
+18:24 < matches> It sounds a lot more boring than it has been
+18:24 < matches> I also need a title
+18:24 < matches> "Number Representations and Precision in Vector Graphics" ?
+18:24 < matches> I'm too scared to pick something punny...
+18:26 < matches> Libreoffice thinks that is 147 words and pluma thinks it is 150...
+18:26 < matches> Oh
+18:26 < matches> hyphenated IEEE-754
+18:28 < matches> I think the first sentence could probably be less mind numbingly boring
+18:28 < matches> My last thesis started with "In this project" which seems terribly not academic
+18:29 < matches> (Every time I read that thesis I get a little more convinced that the markers didn't actually read any of it)
+18:29 < matches> ParanoidNumbers are not going well
+18:30 < matches> Like, it's hard to debug where things go wrong when you have a list like this:
+18:30 < matches> debug: main (tests/paranoidcalculator.cpp:75) - a is: {3*(23*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))+(3*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))/10+(4*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))/100+(1*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))/1000+(2*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))/10000+(3*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))/100000))))))/10+(1*(23*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/100000+(2/1e+06+(2/1e+07+(3/1e+08)))))))))+(3*(398123+(1/10+(2/100+(3/1000+(5/10000+(1/1 ...
+18:31 < matches> That's without simplifying it
+18:31 < matches> But when it gives the wrong results before you even simplify it, that's bad
+18:32 < matches> I'm preeety sure it's not just giving the wrong results because it has a stupid number of terms/factors
+18:32 < matches> It's wrong enough that there's an extra factor or a factor missing or I don't even
+18:34 < matches> Hmm
+18:34 < matches> I want to add "Unlike paper, ..." before the third sentence
+18:34 < matches> I'm going to Captain Obvious
+18:38 < matches> :(
+18:38 < matches> Panic mode is well and truly activated now
+--- Day changed Mon Sep 15 2014
+14:00 < sulix> matches: You need to put the title in: "Keepin' it real: Staying afloat on the sea of document precision"
+--- Day changed Tue Sep 16 2014
+12:25 < matches> I think I'm sinking
+12:27 * sulix has failed to come up with a suitable sinking/syncing pun.
+12:27 < sulix> Or, for that matter, a reason why the quadtree clipping sometimes breaks.
+12:33 < matches> Hey, at least multiplication doesn't sometimes break
+12:33 < matches> That's fairly major
+12:34 < matches> My graph traversal for the paranoid number is somewhat flawed
+12:34 < matches> Yeah it's a giant graph
+12:34 < matches> Smell the memory cooking
+12:34 < matches> I should do some performance tests
+12:34 < matches> Even if I don't have anything to performance test...
+12:34 < matches> We did promise graphs
+12:35 < matches> (The other kind of graph)
+12:35 < sulix> How are you traversing the graph?
+12:35 < sulix> (The first kind)
+12:36 < matches> Originally I was alternating between multipying and adding, but that doesn't work if the first term in a factor has factors of its own
+12:36 < matches> I could probably still use that but I'd have to add zeroes or something
+12:37 < matches> Thinking of it as a linked list is wrong anyway, as factors can have terms and terms can have factors and I'm not making any sense am I
+12:37 < matches> Maths can be made up of maths
+12:37 < matches> I kind of regret basically promising to have this done in my abstract...
+12:37 < sulix> Hmmm...
+12:40 < matches> Anyway, either I am creating the graph wrong and traversing it correctly, or creating it right and traversing it incorrectly, or they are just both totally wrong
+12:41 < matches> Leaning towards the latter
+12:43 < sulix> You need to traverse it from the bottom-up, I think.
+12:50 < matches> Yeah, I need to change both the creation and traversal
+12:50 < matches> Repeated divisions need to change into a division of a number multiplied by a number
+12:51 < matches> Then the traversal is relatively trivial
+12:55 < matches> Division is annoying
+12:55 < matches> Why does maths need division
+12:55 < matches> All the other operations make sense
+12:56 < matches> Someone should reinvent mathematics without a concept of division
+12:56 < matches> We'd all be happier
+12:56 < sulix> I'm pretty certain there's a formal proof of that.
+12:57 < sulix> Most number systems don't have the concept of division.
+12:57 < matches> Haha
+12:57 < sulix> (The integers, for example)
+12:57 < matches> They have division with remainder though?
+12:58 < matches> Ah
+12:58 < matches> But you don't get a single number out
+12:58 < matches> You get two
+12:58 < matches> So it's not a proper operation?
+13:00 < sulix> It's not a binary operation, and it's not the inverse of division.
+13:00 < sulix> *multiplication
+13:07 < Pommers> Guild debate. Pretty sure I have the best camera angle here
+13:43 < matches> Guild debates are beyond the scope of this project
+13:44 < matches> Urgh I'm regretting distinguishing between ADD and SUBTRACT now
+13:44 < matches> Just ADD and MULTIPLY should be all the universe needs
+13:51 < matches> You have to be doing something wrong when you are using a triple pointer
+13:57 < matches> Delicious triple pointers
+13:57 < matches> Now I feel like a triple chocolate milkshake
+13:58 < matches> Ok, I have integers 0->9 adding and subtracting preeettty well now
+14:13 < sulix> Ah, the power of modern technology!
+14:29 < sulix> When in doubt, more debug output!
+14:55 < sulix> Ah ha! I have solve (read: hacked horribly around) the quadtree bug.
+14:56 < Pommers> http://xkcd.com/859/
+14:56 < sulix> Basically, adding a bunch of fake roots in fixes it.
+14:56 < sulix> Details at 11.
+14:56 < sulix> Pommers: You are a terrible person.
+14:57 < Pommers> Oh wait. It's there. I should sit closer to my screen
+15:32 < matches> Ok, I'm pretty sure Paranoid Numbers are the worst idea ever
+15:32 < matches> Possibly worse than iRRAM
+15:32 < matches> I mean, in theory you can simplify things
+15:32 < matches> But when you can't, you just use ridiculous amounts of memory
+15:33 < matches> I don't think you can simplify that many things either
+15:33 < matches> If I get it working enough I can demonstrate that it is a terrible idea at least...
+16:46 < matches> Oh my goodness it is kind of working
+16:46 < matches> I've said this before...
+16:47 < matches> But it's at least at the point where it gives suspiciously similar answers to the right answer
+16:48 < matches> As opposed to suspiciously off by factors of a random number
+17:31 < matches> So I think all I have to do now is simplify the damn things
+17:31 < matches> There are all sorts of amazing optimisations like not using a std::vector for the terms and not using seperate std::vector for + and -
+17:31 < matches> And I think you can probably optimise it even more if you just use doubles
+17:31 < matches> But
+17:31 < matches> It is better at repeated division/multiplications
+17:32 < matches> See TestMulDivIntegers
+17:32 < matches> By better I mean slower
+18:50 < matches> I have pushed a thing
+18:50 < matches> Try not to judge me too harshly
+18:51 < matches> Also there's no way it will compile on Cabellera anymore
+23:06 < matches> So
+23:06 < matches> I just made SVGs load into the centre of the view...
+23:06 < matches> And then I realised that is exactly the sort of thing that will break sulix's quad tree
+23:06 < matches> Sorry sulix
+23:07 < matches> My role in this project is basically to make sulix have to do more work...
+23:21 < Pommers> Why'd you break cabellera?
+23:30 < matches> I didn't break cabellera
+23:30 < matches> I used C++11 auto range iterators
+23:30 < matches> for (auto add : m_next[add])
+23:31 < matches> As opposed to: for (vector<ParanoidNumber*>::iterator i = m_next[ADD].begin(); i != m_next[ADD].end(); ++i) ParanoidNumber * add = *i; ...
+23:31 < matches> Cabellera's g++ is too old for such amazing things
+23:32 < matches> But I was at a point where I needed to change like 50 things from iterating over linked lists to iterating over some kind of hideous graph of std::vectors
+23:32 < matches> Stuff typing all that
+23:32 < matches> I broke the quad tree because I thought it would be nice to have SVGs automagically appear in the middle of the screen
+23:33 < matches> As opposed to the top left underneath all the debug output
+23:49 < sulix> matches: You are too kind.
+23:49 < sulix> The quadtrees are actually working fine at the moment, by virtue of me modifying SolveCubic to no longer solve cubics.
+23:51 < Pommers> return null;?
+--- Day changed Wed Sep 17 2014
+00:03 < matches> Wait what
+00:04 < matches> Did you remove Cubic Beziers
+00:04 < matches> Because I liked having Cubic Beziers
+00:04 < sulix> I'm still trying to work out why it works myself.
+00:04 < sulix> Nope, still cubic béziers, solvecubic now just returns some things which I'm pretty certain actually aren't roots as well.
+00:05 < Pommers> Do either of you want to trade? I'll work on iPDF and you can fix my housemates computer
+00:05 < matches> Hah
+00:05 < matches> Set up that Jenkins server and we'll talk
+00:06 < Pommers> The Container exists for Jenkins
+00:06 < Pommers> So it's been started
+00:06 < matches> I wish CS would stop thinking up names for things that are also names for other things
+00:06 < matches> Container
+00:06 < matches> Puppet
+00:06 < matches> Orchestration
+00:06 < matches> For god's sake
+00:06 < matches> Paranoid Number is totally a legit name
+00:07 < Pommers> Stop being paranoid about things matches
+00:07 < matches> "Tree" is acceptable because it at least looks like a tree
+00:07 < Pommers> Also, coming to dinner?
+00:07 < matches> There is dinner?
+00:07 < matches> When?
+00:07 < matches> It's midnight...
+00:07 < Pommers> Thursday
+00:07 < matches> Oh
+00:07 < matches> I suppose
+00:08 < matches> Thursday is typically the post meeting freak the hell out day
+00:08 < matches> Monday Tuesday and Wednesday being the pre meeting freak the hell out days
+00:08 < matches> Friday is the I should really prepare for my Physics tute day
+00:09 < Pommers> Saturday is "o god coderdojo day"
+00:09 < matches> Yeah
+00:09 < matches> Sunday is I should really not be playing computer games but I will anyway day
+00:09 < matches> No wait last sunday was a freak the hell out day as well, until they made me play monopoly
+00:09 < matches> Sorry, monotony
+00:10 < matches> Anyway how do you get valgrind to print number of flops
+00:10 < sulix> I'm just s/.*day/PANIC day/g at the moment.
+00:10 < matches> Your thing works!
+00:10 < matches> Sort of
+00:11 < sulix> thing?
+00:11 < matches> Quadtrees
+00:11 < Pommers> "thing"
+00:11 < sulix> Technically it works*
+00:11 < Pommers> "it"
+00:11 < matches> I have about 4 things I still haven't even tried yet
+00:11 < matches> And a couple of things that will work if you wait the lifetime of the universe
+00:12 < Pommers> Hmm... I should make my bed while this backup happens
+00:12 < matches> Bed is tempting
+00:12 < sulix> *The roots I'm using might not actually be roots, it doesn't work if you either pan, zoom out or anything other than zoom in on a single point forever.
+00:12 < Pommers> But having too much fun coding?
+00:13 < matches> I'm working towards actually making graphs of something
+00:13 < matches> I'm still working out exactly what I will graph
+00:13 < matches> flops seems important
+00:13 < matches> I'm basically replacing a single inexact flop with a lot of usually but not always exact flops
+00:14 < matches> And several hundred MB of memory...
+00:18 < matches> Ok, this can't be right
+00:18 < matches> To render one frame of an empty document takes 137,708 F64 operations
+00:18 < matches> I assume that means double
+00:19 < Pommers> That could use some optimizing...
+00:19 < Pommers> Make all the functions return null and see how that speeds it up
+00:19 < matches> -_-
+00:19 < matches> This is using regular doubles
+00:19 < matches> Not Paranoid Numbers
+00:20 < matches> ParanoidNumbers takes about 5 minutes to do 20000 operations at the moment...
+00:20 < sulix> I could believe it.
+00:22 < Pommers> I'd be paranoid if it took that long
+00:22 < matches> Don't make fun of the Paranoid Numbers
+00:22 < matches> They are a work of art
+00:23 < sulix> Part of me really wants to try compiling the quadtree with them, and part of me is terrified at the prospect.
+00:23 < matches> There isn't a REALTYPE for them yet
+00:25 < matches> They might work better if you had a giant Trie of them but I have no idea how to structure that
+00:25 < matches> At the moment there is one tree per number and the tree can have a variable number of children for each node... :S
+00:31 < matches> Anyway what performance metric do we want
+00:31 * matches consults the proposal
+00:32 < Pommers> What will be easier to do? Time or space?
+00:32 < matches> Time
+00:32 < matches> But Rowan was kind of keen on Space
+00:32 < matches> Number of flops is probably the best
+00:32 < Pommers> Just put some ascii art daleks in
+00:34 < matches> Ok, so 1 frame = 30,897 F32, 129,042 F64 and 1000 frames = 4,364,459 F32, 6,933,526 F64
+00:35 < matches> 6800 doubles to render a blank document
+00:35 < matches> Actually
+00:35 < matches> !
+00:35 < matches> There is a rectangle in it!
+00:35 < matches> Of width and height 0
+00:40 < Pommers> I almost have the container for jenkins fully set up now
+00:43 < Pommers> I just need to give it an IP and then just set up jenkins
+00:45 < matches> I was joking about Jenkins...
+00:46 < Pommers> I actually have a use for it...
+01:16 < Pommers> Housemates computer is fixed
+01:16 * Pommers sleeps
+01:29 < matches> Dammit
+01:29 < matches> I entered a timestamp of 10:56 instead of 22:56 and now my commit is at 13:27
+01:30 < matches> I tried git commit --amend --date= but it didn't quite work
+01:31 < sulix> Would it count as cheating on the performance metrics if time travel was involved?
+01:31 < matches> Nooo
+01:32 < sulix> As you can see, ParanoidNumber actually takes only -12 hours to render a frame by being so cautious it violates causality.
+01:32 < matches> So, the "spatial" metric can be: Number of pixels not the same, and mean minimum distance horizontally/vertically to the nearest set pixel in the original
+01:32 < matches> Because I said so
+01:32 < matches> A possible other metric would be the Fourier Transform
+01:33 < matches> But that's stupid
+01:33 < matches> -12 hours is pretty good
+14:43 < Pommers> Jenkins is set up and I can let you create an account if you want to play with it
+17:01 < matches> Best idea ever
+17:02 < matches> A performance test that saves the graph as an svg
+17:02 < matches> Then runs itself on the graph...
+17:05 < Pommers> recursive testing?
+17:05 < matches> Yes!
+17:07 < Pommers> Set your testing up in jenkins
+17:08 < matches> This is performance tests not sanity tests
+17:08 < matches> Or whatever they're called
+17:08 < matches> We don't need to make sure things work...
+17:08 < matches> We just need them to not work fastly
+18:35 < matches> SDL_WINDOW_HIDDEN is useful
+18:36 < matches> Actually I'm surprised it works
+18:37 < matches> As much as having ipdf constantly flashing up and stealing my window focus is exciting, I am relieved to be able to stop that
+18:37 < matches> Now I just need to stop the monitor from randomly flashing its menu and/or turning off...
+18:42 < matches> So I can show some graphs tomorrow, although they may not be graphs of actually useful things
+19:44 < matches> I hope you like ipython because we're using ipython
+19:50 < matches> git.ucc seems sick...
+--- Day changed Thu Sep 18 2014
+11:40 < matches> Good news!
+11:40 < matches> You can run ipdf on motsugo
+11:40 < sulix> I heard.
+11:40 < sulix> My good news is that I just added something to the quadtree.
+11:40 < sulix> (Sort-of)
+11:41 < matches> The GPU rendering doesn't work on motsugo though
+11:41 < sulix> I fail to be surprised.
+11:42 < matches> Does the quadtree work with the centred SVGs?
+11:44 < sulix> I haven't been brave enough to do the horrible merge that needs to happen.
+11:45 < sulix> I'm currently trying to work out how I'm going to pass which node that you want to add something to through all of the Add* code.
+11:52 < matches> Ah
+11:57 < matches> I'm about to hack around C++ 'const' correctness
+11:57 < matches> What could possibly go left
+11:57 < matches> I mean wright
+11:57 < matches> I mean lng
+11:57 < matches> asdf
+11:58 < matches> segmentation fault
+12:00 < matches> Well it compiled at least
+12:00 * matches notes that if he ever sees a function declared 'const' again he should not assume that it is actually const...
+12:01 < matches> Now to overload the new and delete operators...
+12:04 * sulix hides quietly in a corner.
+12:05 < matches> ParanoidNumber needs to call new and delete an excessive amount
+12:05 < matches> Because you might need to create a new one but you might not, but you can't tell in advance :S
+12:06 < sulix> So: pool or arena?
+12:06 < sulix> (I'd probably recommend an arena)
+12:06 < matches> I've not heard of an arena, which probably means its better
+12:07 < matches> It sounds traumatic though
+12:07 < matches> Remember these numbers are paranoid as it is
+12:08 < sulix> Basically allocate a large block of memory, every time you allocate return the next <n> bytes of it.
+12:08 < sulix> Delete is a no-op, everything is freed when you delete the entire arena.
+12:10 < matches> Hm I thought that was a pool
+12:11 < sulix> A pool is basically an array of objects of the same type that get reused.
+12:12 < sulix> Though nomenclature is pretty dodgy generally wrt memory management.
+12:12 < matches> SO thinks they are the same
+12:12 < matches> http://stackoverflow.com/questions/13381123/whats-the-difference-between-a-memory-arena-and-a-memory-allocator
+12:12 < matches> Actually no that's not quite the question I was looking for
+12:13 < matches> I said pool and it says "allocator"
+12:13 < matches> (But some guy with upvotes says arenas are also called pools)
+12:13 < matches> (Democracy has decided!)
+12:13 < matches> Ok I see the difference
+12:13 < matches> Yeah, I was going to use a pool, but I guess arena would be better
+12:14 < sulix> http://en.wikipedia.org/wiki/Memory_pool
+12:15 < sulix> http://en.wikipedia.org/wiki/Region-based_memory_management
+12:28 < matches> So, PN gives "inf" for an operation that doubles do fine
+12:29 < matches> But on the plus side, Wolfram Alpha gives "Wolfram alpha does not understand your query -344+(6+8/10 +...)"
+12:29 < matches> "Showing results instead for "6+8/10 +3/100"
+12:30 < matches> (The maths is syntactically correct, or at least, I'm fairly sure it is. I'm not actually going to count all those brackets...)
+12:31 < matches> I find it amusing that there is a number representation that is just "That number is too complicated, here is a similar looking one"
+12:32 < matches> Actually, correction
+12:32 < matches> *addition rather
+12:32 < matches> "Insert more money to calculate the number"
+12:32 < sulix> "Upgrade to wolfram alpha pro to use numbers with more factors"
+12:32 < matches> Yes
+12:32 < matches> That is pretty much what it says
+12:34 < matches> Hmm, I think PN should take a couple of minutes per frame at the moment
+12:34 < matches> I should probably actually test it
+12:39 < matches> That's a whole lot of compiler errors
+12:39 < matches> Argh
+12:39 < matches> I hate the "overloaded call to ClassConstructor(int) is ambiguous" errors
+12:40 < sulix> I think the idea of "compiler errors" is clearly too negative.
+12:41 < sulix> We should have "constructive compiler feedback" instead.
+12:41 < sulix> "warnings" should become "suggestions"
+12:41 < matches> I don't understand that type of eror
+12:41 < matches> The compiler is supposed to silently typecast the primitive types right?
+12:41 < sulix> Yes*
+12:41 < matches> So if you have a constructor for a double it will cast "0" to "0.0" and use that
+12:41 < sulix> Yes*
+12:42 < matches> If you implement constructors for *both* it will get confused
+12:42 < sulix> (If there isn't another constructor that is equal or better)
+12:42 < matches> If you implement constructors for only *one* it *still* gets confused
+12:42 < matches> Aaskdfasdf
+12:43 < matches> It's totally confused
+12:43 < matches> I think
+12:43 < matches> It sees the int
+12:44 < matches> Then goes "I can construct a ParanoidNumber off that"
+12:44 < matches> Then goes "But I can construct a ParanoidNumber off the const ParanoidNumber &"
+12:44 < matches> That doesn't make sense
+12:44 < matches> Why is the copy constructor ambiguous
+12:45 < sulix> That's exactly what I hate about c++.
+12:45 < sulix> (Also boost)
+12:51 < matches> It gets Real(0) mixed up with Real(const char * str)
+12:51 < matches> Really
+12:51 < matches> Why
+12:51 < matches> FFS
+12:52 < matches> std::string it is then
+12:52 < matches> Don't know why it had to complain about every single other constructor being ambiguous as well
+13:01 < matches> I've just realised
+13:01 < matches> ParanoidNumber is going to have to be thread safe
+13:01 < matches> As long as we want the control panel to work anyway
+13:01 < matches> Blergh
+13:05 < matches> Oh boy
+13:05 < matches> You know you are in trouble when "this == NULL"
+13:06 < matches> I feel like I am messing with forces beyond my ken
+13:06 < matches> I haven't even overloaded new yet
+13:06 < sulix> this == NULL is actually perfectly possible.
+13:07 < matches> Yeah but where is it coming from
+13:07 < sulix> It's the correct result if you call a member function of a null pointer.
+13:07 < matches> Yeah I know
+13:07 < matches> But
+13:07 < matches> But
+13:07 < sulix> (Is it time for captain valgrind?)
+13:07 < matches> That spits out so many errors due to other libraries :(
+13:07 < matches> I'm learning to use gdb more effectively
+13:07 < matches> I finally learned how to set breakpoints
+13:08 < matches> And print variables
+13:08 < matches> You can even get it to call functions
+13:08 < matches> That's cool
+13:08 < sulix> Yeah, gdb is pretty amazing.
+13:08 < matches> So I have this four dimensional tree of death
+13:08 < sulix> What you should do is setup the libstdc++ pretty printers.
+13:08 < matches> The child links are implemented as a std::vector of pointers
+13:08 < sulix> It makes gdb print stl containers nicely.
+13:09 < matches> Somehow there are null pointers in the vector
+13:09 < matches> That should really not happen
+13:09 < matches> I could check that the pointers are not null but I suspect that won't solve the underlying issue
+13:09 < matches> Of null pointers ending up in places
+13:10 < matches> Couldn't I do something like: 'p (Pointer*)vector.data()'
+13:10 < matches> I should try that
+13:11 < sulix> PANIC PANIC PANIC
+13:12 < sulix> Apparently my draft dissertation is due tomorrow.
+13:12 < matches> Wahtasdfasdf
+13:12 < matches> What
+13:12 < matches> When did this happen
+13:13 < sulix> http://undergraduate.csse.uwa.edu.au/year4/Current/dates.html
+13:14 < matches> :S
+13:14 < matches> I thought Rowan said you had two weeks...
+13:14 < matches> Or was that two weeks ago..
+13:14 < matches> Also I know I don't technically have to submit a draft dissertation but I share some level of panic
+13:15 < sulix> Yeah, I thought I had more time, too.
+13:15 < matches> I'm sure you can organise it with Rowan
+13:16 < matches> My last thesis was somewhat of a blur
+13:16 < matches> I'm not sure there was a draft
+13:17 < matches> You'll get through it
+13:20 < sulix> (The question is not so much if I'll get through it, but if I'll get through it in the next hour and forty minutes... :P)
+13:22 < matches> I give you permission to copy/paste my lit review
+13:22 < matches> Although to be honest it could do with less rambling about svg and postscript
+13:26 < sulix> btw, I've found a way to make the quadtree run as slowly as the rationals.
+13:28 < matches> How?
+13:28 < sulix> Totally broken linked lists?
+13:28 < sulix> (I think)
+13:29 < sulix> QuadTree nodes can now "overlay" other quadtree nodes, which is the way I'm hacking mutability in.
+13:29 < sulix> For some reason, if you zoom in and then zoom back out again, it ends up creating a new overlay for each individual curve.
+13:30 < sulix> Each overlay runs the entire View::Render function again, independently.
+13:30 < matches> Damn
+13:30 < matches> I don't understand how these vectors have NULL in them
+13:30 < matches> I have "assert(b != NULL)" before the only two places where things get added to them
+13:31 < sulix> Are asserts enabled? :P
+13:32 < matches> I thought that was Java
+13:32 < matches> Also python
+13:34 < sulix> I'm not actually sure about the standard asserts, but most of them do get disabled if you're not in a debug build.
+13:34 < matches> Ooh
+13:34 < matches> oh oh oh
+13:34 < matches> I always do this
+13:34 < matches> std::vector::vector does not construct with a size
+13:35 < matches> It constructs with elements
+13:35 < matches> So vector n(0) is baad
+13:35 < sulix> I always use vector(size, initialvalue)
+13:35 < matches> Nope that isn't it...
+13:35 < sulix> Or just use the default constructor if I want "empty".
+13:36 < matches> I'm already wrapping the billions of 'new's in a check that it isn't null
+13:36 < matches> What is going on
+14:40 < Pommers> matches: Fix your NTP already
+16:28 < matches> sulix: "That's actually not too bad, I may be rationalising it, but..."
+16:28 < matches> (We wouldn't want the spectators to miss any of the puns)
+16:28 < sulix> (For context: talking about the performance and correctness of rational numbers)
+23:35 < matches> Your predictions of Simplify leading to infinite loops were remarkably accurate
+23:36 < matches> That just means the number can be infinitely Simplified!
+23:49 < sulix> Simplify() { return 0; /* it can't get much more simple */ }
+23:49 < matches> Haha
+23:50 < matches> Well I just spent 15 minutes learning why I had the stupid ".test" extension on all the testers in the first place
+23:50 < matches> (Which I recently removed because it was stupid)
+23:50 < matches> Turns out it was there so that make clean could remove all the testers without needing to keep a list of them all
+23:51 < matches> And that no matter how many times I ran make clean, I was still running the same buggy executable from 7 hours ago...
+23:51 < matches> "Not so stupid after all!" says past matches
+23:51 < matches> "Shut up" says present matches
+23:52 < matches> "When are we going to sleep" says future matches at approximately 3am
+23:53 < matches> Things get wierd when you remove NTP
+23:53 < matches> I have a watch on my wrist but it's not the same
+23:55 < matches> "You know what the .test extension is still dumb, I'll just remember to rm them when they need rebuilding" says a slightly older present matches
+--- Day changed Fri Sep 19 2014
+00:00 < matches> Ah, good old copy paste and naming variables 'n' and 'm'
+00:01 < matches> Mever fails to segfault
+01:05 < matches> PN Yields: 1.0000000000000000000000000000000000000000
+01:05 < matches> PN is: 1
+01:06 < matches> Doubles Yield: inf
+01:06 < matches> TAKE THAT KAHAN
+01:06 < matches> Hmm
+01:06 < matches> I could multithread the paranoid number...
+01:07 < matches> At least, the Convert to double part of it
+01:11 < matches> Ah, it fails on the very next test though
+01:11 * matches regrest uncommenting the "return 0;"
+01:11 < matches> grects
+01:11 < matches> regrects
+01:11 < matches> dammit
+01:11 < matches> it is too aerly for this
+01:21 < matches> So ipython stores pngs as giant base64 encoded strings
+01:21 < matches> In JSON format
+01:21 * matches shudders at the commit diff
+01:23 < matches> Good luck sulix
+09:47 < sulix> "Bang, zoom, straight to the rounding error"?
+12:17 * sulix falls over in a heap of insanity and shame.
+17:20 -!- mode/#ipdf [+o matches] by OperServ
+17:20 -!- matches changed the topic of #ipdf to: IPDF: A Document Precision Playground
+17:20 <@matches> This is good reading
+17:21 <@matches> I just read "At its core, IPDF breaks documents" and choked on my drink
+17:22 * sulix thinks we might have a new slogan.
+17:23 <@matches> I think it's important that you don't specify what the initials actually stand for
+17:23 <@matches> People will think it's a fancy PDF viewer
+17:23 <@matches> Except it's really a broken SVG viewer
+17:25 < sulix> I don't intend to give any more explanation than IPDF™.
+17:25 < sulix> Or possible IPDFⓇ
+17:25 <@matches> I am jealous of your compose key
+17:26 < sulix> Mwäháhà!
+17:33 <@matches> Ah yeah, precision vs zoom doesn't work to well for doubles for some reason
+18:24 <@matches> Look at ParanoidNumber go
+18:24 <@matches> Look at it go!
+18:24 <@matches> Well you can't because you're not here
+18:24 <@matches> I should do a live stream
+18:24 <@matches> It is so exciting
+18:24 <@matches> It's been going 5 minutes but it hasn't failed any tests since I commented out the comparison against doubles
+18:25 <@matches> Yes
+18:25 <@matches> Eat all the memory
+18:25 <@matches> Soon you will grow strong
+18:27 <@matches> Actually I probably *want* it to start failing tests
+18:28 <@matches> Because if it gives the same result as a double it's not any better than a double...
+18:28 <@matches> At the very least it is mathematically interesting
+18:29 <@matches> I'm not sure Mathematically interesting and "Chemical Engineering Conference" go together
+18:29 <@matches> Also I don't have enough Maths training to say anything about it other than it is interesting
+18:29 <@matches> It is a ring of complete hidden sets of fields
+18:29 <@matches> Yeah
+18:29 * matches uses maths
+18:30 < sulix> Technically, I don't think that things which use floats can ever be rings or fields due to the whole rounding error thing.
+18:34 <@matches> Well
+18:34 <@matches> It's a tree
+18:34 <@matches> I can hold on to that
+18:34 <@matches> I understand trees
+18:35 <@matches> They have trunks and bark and leaves
+18:35 <@matches> Hmm, I should add a Bark sub class
+18:35 <@matches> I wonder if I can bring myself to implement the same test algorithm in Mathematica and compare the results
+18:36 <@matches> I think using Mathematica in research requires you to sell your soul though
+18:41 <@matches> Also Frames thinks that enabling optimisation will magically make PN less terrible
+18:41 <@matches> I'm somewhat skeptical
+18:41 <@matches> But here goes
+18:42 <@matches> (I am anticipating it will make it much faster, in that it will segfault after 2 operations)
+18:45 <@matches> Well it didn't segfault, but apparently "219123 != 219123"
+18:48 <@matches> Actually
+18:48 <@matches> It seems a lot faster
+18:48 <@matches> Hooray Frames
+18:48 <@matches> Thesis done
+18:49 < sulix> Does it speed up the GMP and/or Arbint rationals much?
+18:49 <@matches> Haven't tried yet
+18:49 <@matches> I need to adapt Paranoidtester into a general tester
+18:49 <@matches> Or was that realops
+18:49 <@matches> I forget
+18:49 <@matches> I have a lot of testers that I suspect do basically the same thing
+18:57 <@matches> Compiling with -Ofast does lead to
+18:57 <@matches> WARNING: main (main.cpp:29) - __STDC_IEC_559__ not defined. IEEE 754 floating point not fully supported.
+18:57 <@matches> (I am the best programmer I put in all the warning messages!)
+18:58 <@matches> And ipdf segfaults
+18:58 <@matches> But not the tester
+18:58 <@matches> In stbtt_FindGlyphIndex
+18:59 <@matches> Are we going to need to submit another pull request...
+19:17 <@matches> Ah
+19:17 <@matches> Adding all those "SanityCheck" calls may have slowed things down a tad
+19:17 <@matches> IPDF::ParanoidNumber::SanityCheck (this=0xe80a640, visited=std::set with 9775 elements = {...})
+19:23 <@matches> Sanity-Check-this - out
+19:24 <@matches> I think I need more sleep
+19:53 < Pommers> goto bed matches
+--- Day changed Sat Sep 20 2014
+21:22 <@matches> Overloading operator new and delete is kind of terrifying...
+21:25 <@matches> Things run blindingly fast
+21:25 <@matches> Until they segfault
+21:26 <@matches> I suspect std::vector does not take kindly to being destructed multiple times
+21:33 <@matches> Hmm
+21:33 <@matches> I need to make std::vector pointers instead?
+21:33 <@matches> That's getting a little convoluted...
+21:35 <@matches> Or what I really need is a delete operator that doesn't actually call the destructor automagically
+21:35 <@matches> (Even when you overload delete it still calls the destructor?)
+21:36 <@matches> I'm noticing a bit of a trend here
+21:36 <@matches> You can overload C++ operators but if you do it totally breaks everything
+21:36 <@matches> eg: You could implement a double() operator for casting to double but you're better off just writing Double() and using it everywhere because otherwise the compiler goes insane trying to use your operator in places
+21:37 <@matches> You can implement your own delete operator but that won't stop the compiler from doing everything it does with the standard delete...
+21:38 <@matches> The only operators you can overload (mostly) are the arithmetic ones
+21:39 <@matches> Also the compiler seems to occasionally just use the standard delete anyway which just makes everything TOTALLY INSANE
+21:39 <@matches> WHY
+21:39 * matches grumbles and prepares to write "Delete" and "New"
+--- Day changed Sun Sep 21 2014
+16:43 <@matches> I think I'm just an idiot
+16:47 <@matches> Arena doesn't help that much
+16:47 <@matches> Which is odd
+16:48 <@matches> If anything it is slower :(
+16:49 <@matches> It's hard to profile something that doesn't work in valgrind
+17:00 <@matches> On the other hand, removing all the "SanityCheck" calls is surprisingly effective...
+17:48 <@matches> Damn
+17:48 <@matches> I guess new and delete isn't as expensive as just doing a craptonne of branches
+22:33 <@matches> So, probably a better idea is to stop the CPU renderer from recalculating the object bounds every single frame
+22:33 <@matches> And update the object bounds when the view is changed instead
+22:34 <@matches> Since we don't really care what the original bounds are
+22:37 <@matches> This is basically what the quad tree does...
+22:37 <@matches> Well it changes coordinate systems as well
+22:37 <@matches> But I can zoom in a lot further now than I could before...
+22:38 <@matches> Until eventually there is a sigfpe
+23:19 <@matches> Ok
+23:19 <@matches> This is slightly worrying
+23:19 <@matches> I can zoom to {0.5,0.5,1e-41,1e-41} and insert things without any problem
+23:21 <@matches> The CPU renderer does tend to sigfpe
+23:27 <@matches> Man I feel really foolish now
+23:27 * matches makes plans to delete the IRC logs again
+23:32 <@matches> So
+23:33 <@matches> The good news is that GMP rationals are pretty effective when you do cumulative transforms on the object bounds as opposed to keeping the bounds static and transforming them to view coordinates
+23:34 <@matches> The bad news is that so are regular floats
+23:34 <@matches> I'm pretty sure it just means we need a better tester
+23:38 <@matches> Or
+23:38 <@matches> We lie
+--- Day changed Wed Sep 24 2014
+12:33 <@matches> Ok, sulix do you want to help design these comparisons that we were going to use
+12:35 <@matches> We've got the "qualitative" comparisons pretty well...
+12:36 <@matches> It's the other 4 things
+12:36 <@matches> Performance vs number of primitives
+12:36 <@matches> Like
+12:36 <@matches> Do we add N primitives randomly?
+12:36 <@matches> Are our "test" documents just going to be Humphrey The Rabbit and Shady the Fox
+12:36 <@matches> Not that I have any objection to using them
+12:36 < sulix> I think so.
+12:36 <@matches> I'll add Emma the Cat and Mitch the Panda
+12:37 < sulix> Number of primitives should just be number of curves/objects.
+12:37 < sulix> I could do with some panda-monium. :P
+12:37 <@matches> Pommers beat you to that one
+12:37 <@matches> That's the name of the club's panda
+12:38 <@matches> I don't think I'll add Sam the Girraffe
+12:38 <@matches> It's embarrassing
+12:38 <@matches> Oh also did you read the wall of text?
+12:39 <@matches> Because I think we need a new way to demonstrate how much better the quad tree is than regular floats other than just zooming forever
+12:39 <@matches> Regular floats do quite well now
+12:39 <@matches> I should probably commit this
+12:39 < sulix> What about adding objects?
+12:39 <@matches> I also tried to get it to run without X for bus purposes
+12:39 <@matches> Well
+12:40 <@matches> Basically I threw out the idea of the view and just applied the transforms directly to all the object bounds
+12:40 <@matches> It will still print the equivelant view coordinates
+12:40 < sulix> Can you zoom out and then back in again?
+12:41 <@matches> I suspect if you go far enough there will be issues
+12:41 <@matches> The problem is going far enough takes a long time
+12:41 <@matches> We need to make ipdf take input so we can automate it?
+12:41 * sulix will do that this afternoon.
+12:41 <@matches> Or implement a "tester" that does it
+12:42 <@matches> HFP has a chapter on reducing error which boils down to rearranging the operands
+12:43 <@matches> Although they don't have anything as insanely dumb as ParanoidNumber
+12:43 < sulix> Isn't that what ParanoidNumber does?
+12:43 <@matches> Yeah
+12:43 <@matches> But ParanoidNumber doesn't assume any knowledge over what you are trying to do
+12:43 <@matches> Hence it is horribly inefficient
+12:44 < sulix> I suspect we need to sit down with Kahan and work out what the exact mathematical properties of floating-point error.
+12:44 <@matches> Their examples are like "If you know you are going to sum all these numbers, you sort them"
+12:44 <@matches> HFP goes through them
+12:45 <@matches> Sometimes you can represent the error as another float but with twice the precision?
+12:45 <@matches> It might be worth looking at whether MPFR includes the "Inexact" exception
+12:45 <@matches> Then you could just double the precision every time it occured?
+12:46 * sulix will be back shortly.
+12:47 <@matches> It's going to be a fun study break :S
+12:54 <@matches> Also PN manages to pass realops but somehow give totally whack behaviour when you actually use it
+12:54 <@matches> ...
+12:54 <@matches> And this is enforcing a size limit of "0" (which means it should just be equivelant to doubles!)
+12:55 <@matches> Also I should probably also write a draft thesis
+12:55 <@matches> Also other units suck, why can't the project count as 4 units
+12:56 <@matches> I'm finally starting to understand this properly, as we are running out of time at an alarming rate
+12:56 <@matches> I guess there probably won't be any experts on floating point arithmetic at my conference so I can probably pretend I know things
+13:02 <@matches> http://szmoore.net/ipdf/i-think-there-might-be-a-slight-maths-error-rabbit.png
+13:03 <@matches> I strongly suspect Copy/Paste errors
+14:07 < Pommers> Yeah. We have a club Panda
+14:10 -!- matches changed the topic of #ipdf to: IPDF: Infinite Panda Document Format
+14:13 <@matches> Um
+14:13 <@matches> cat.svg causes a segfault
+14:23 <@matches> It has an empty path?
+14:23 <@matches> I regret somewhat making the path be from m_start to m_end *inclusive*
+14:37 <@matches> Have a git push
+14:37 <@matches> Possibly with a correct timestamp
+14:47 <@matches> Ok, things still go whack when you apply transforms to objects instead of the view
+14:48 <@matches> But because you can add objects in screen space rather than converting to view space and back, you don't get the precision issues adding a new object
+14:48 <@matches> I suspect
+14:48 <@matches> If you add a new object at say 1e-6
+14:48 <@matches> It looks fine
+14:49 <@matches> Then you zoom back out to 0.5,0.5,1,1 or something
+14:49 <@matches> Then zoom back in
+14:49 <@matches> It *should* look all wierd again
+14:49 <@matches> Then again it might not
+14:49 <@matches> Because floating point errors are crazy
+14:51 <@matches> It does!
+14:51 <@matches> YES
+14:52 <@matches> It looks totally screwed up in a different way
+14:52 <@matches> So, I guess this just makes it more important that you can actually add elements to the quad tree
+14:53 * sulix feels the pressure mounting.
+14:54 <@matches> Is the quad tree kind of equivelant to applying the transformations to the objects but making sure you don't lose the original bounds
+14:54 <@matches> When you zoom back out you get the original bounds back
+14:54 < sulix> Yeah, largely.
+14:54 <@matches> Cool
+14:54 <@matches> I'm sure someone trained in maths can say smart stuff about that
+14:55 <@matches> Applying transformations to the object bounds is probably the best way if you have an arbitrary precision number representation
+14:55 <@matches> You can use a lower precision representation when you work in screen space then
+14:55 <@matches> Although I'm not sure how I would actually implement that...
+14:56 <@matches> With some kind of
+14:56 <@matches> Quad tree...
+14:56 <@matches> maybe
+14:56 <@matches> I guess if two methods end up with the same pixels in the same spot then they are mathematically equivelant
+14:58 <@matches> You could also speed things up
+14:58 <@matches> If you exploited the Path bounds
+14:58 <@matches> Express all the beziers within a path relative to {0,0,1,1} then just apply your transformation to the path
+14:58 < sulix> This is a much better design.
+14:59 <@matches> Well that's sort of a compromise between transforming the view or transforming all the bounds
+14:59 < sulix> But it's sort-of too late to change it all now.
+14:59 <@matches> I think I might have to though
+14:59 <@matches> If I want to make GMPrat performant
+15:00 <@matches> Lets face it, I'm doing a better job at redesigning the document structure to be less terrible than I am at actually implementing arbitrary precision number types :S
+15:01 <@matches> I could probably redesign the CPU renderer, but the GPU renderer would be harder
+15:01 <@matches> PathRenderer already does everything BezierRenderer does, but it adds shading
+15:02 <@matches> I think right now I will try to stop PN from being quite so broken
+15:02 <@matches> I am perplexed
+15:03 <@matches> As there is basically an "assert(equivelant to double)" after every single operation
+15:03 <@matches> None of them fail
+15:03 <@matches> And it gives a totally wrong result
+15:45 <@matches> It is rendering at 666 FPS
+15:46 <@matches> :O
+16:49 <@matches> Ok
+16:49 <@matches> There should be postive paranoid numbers soon
+16:49 <@matches> s/postive/negative
+16:49 <@matches> That thing that happens when you put a '-' sign in front of a number
+16:49 <@matches> Very important
+16:50 < sulix> Negative _and_ paranoid? I'm waiting for the "Number Theropy" classes next... :P
+16:50 <@matches> I've learned some valuable lessons about implementing number classes I guess
+16:50 < sulix> At least it isn't complex?
+16:50 <@matches> Make sure you test every single function against doubles
+16:51 <@matches> (Including constructors)
+16:51 <@matches> I'm really over bug fixing this class
+16:51 <@matches> I just want to make it faster dammit
+16:51 <@matches> I have ideas about how to make it faster
+16:53 <@matches> Admittedly they are mostly not good ideas
+16:53 <@matches> I'm expecting the arena may help more when I don't enforce a size limit of zero though
+16:54 <@matches> YES
+16:54 <@matches> I can render a paranoid rabbit
+16:54 <@matches> Oh wait
+16:54 <@matches> I didn't increase the size limit from zero
+16:54 <@matches> That will be the real test...
+17:02 <@matches> So are you going to implement a magical automated zoomer? :P
+17:03 <@matches> We kind of need to be able to choose what point to zoom in on depending on the particular test svg though :S
+17:04 <@matches> Right now it's hard to tell whether I am getting precision issues or I just accidentally moved the mouse a bit
+21:02 < sulix> That's about the most terrifying email it's possible to get, I think.
+21:59 < sulix> Very simple scripts for automating actions now exist.
+--- Day changed Thu Sep 25 2014
+08:27 < sulix> matches: Thoughts on a meeting time?
+10:58 <@matches> Ah
+10:58 <@matches> I sort of slept in
+10:59 <@matches> Well actually I didn't sleep in I just started practicing the piano and then it was 2 hours later...
+10:59 <@matches> Yeah that's a pretty terrifying email
+11:05 <@matches> I am excited by the script
+11:06 < sulix> Cool. I just added support for toggling some things to it.
+11:06 < sulix> When's best for you meeting-wise?
+11:06 <@matches> I can't make 11:15
+11:06 <@matches> Was there any other time that wasn't 5:45pm?
+11:07 <@matches> It'll be a struggle to make 9am
+11:07 <@matches> In fact apparently it's 7pm now
+11:07 <@matches> I must have really overslept
+11:07 <@matches> I'm sure I made progress this week
+11:07 <@matches> I just can't remember what it was
+11:07 < sulix> Well, I can make any time after ~12:00, now.
+11:08 < sulix> You did the whole cumulative transforms thing.
+11:08 <@matches> Yes, I'm not sure whether that was good or not
+11:08 <@matches> It sort of invalidates a whole bunch of earlier things
+11:09 <@matches> It is probably the only way that arbitrary precision bounds will ever be practical though
+11:09 <@matches> I also fixed ParanoidNumbers a bit I guess
+11:09 <@matches> But they are still terrible
+11:09 <@matches> I doubt it will get to the point where they ever aren't terrible
+11:12 <@matches> Do I do my GENG4402 assignment that's due on Friday or do I sacrifice it for the glory of IPDF?
+11:13 < sulix> I was going to say "IPDF is not a cult", but I'm not so sure.
+11:16 <@matches> On the one hand I feel sorry for you because you have the entire trip to Sydney as a meeting time
+11:16 <@matches> On the other hand I feel sorry for me because I haven't actually achieved anything
+11:17 <@matches> I have an abstract that says what I'm going to achieve...
+11:17 <@matches> It hasn't been achieved
+11:17 <@matches> Achievements are locked
+11:18 * sulix hasn't achieved anything but the scripting stuff in the last week. :/
+11:19 <@matches> You have a quad tree!
+11:19 <@matches> Did I tell you, GMPrat takes 5 seconds to pass tests/addsub and doubles take 5ms
+11:20 <@matches> Wait GMPrat was only 500ms
+11:20 <@matches> PN was 6 seconds
+11:20 <@matches> When restricted to size 1
+11:20 <@matches> There's a bug somewhere
+11:22 <@matches> They seem to grow a lot bigger than the size limit
+11:22 <@matches> Ah, probably because I don't check "m_size + b->m_size"
+11:27 <@matches> -_-
+11:27 <@matches> You need to stop adding Debug messages that assume Real is a double
+11:27 <@matches> :P
+11:28 <@matches> Some of us are trying to compile with other number representations here
+11:29 <@matches> I guess it does seem to actually work even though it's horrendously slow
+11:29 <@matches> That's an achievement of some sort
+11:30 <@matches> GMPrat also works and is horrendously slow but less horrendously slow, but I didn't actually invent that representation
+13:45 <@matches> The script has loadsvg now
+13:45 <@matches> It's tempting to make it turing complete... like some kind of... Post... Script
+13:45 <@matches> But that would be silly
+13:50 <@matches> I am loving this script thing
+13:50 <@matches> Think of all the calories I can save
+13:51 <@matches> My goodness I can even eat food whilst watching it zoom
+13:51 <@matches> My hand is freed
+13:51 <@matches> Freed from the tyranny of endless zooming
+13:56 < sulix> Cool: I was going to add loadsvg, but it still has some quadtree problems.
+13:58 <@matches> I think I will add "label" and "goto" so that I can zoom into the rabbit's eye *forever*
+13:58 <@matches> Well
+13:58 <@matches> Hmm that's actually work
+13:58 <@matches> But I still think it's necessary
+13:59 <@matches> You need to see at which point the Quad tree breaks
+13:59 <@matches> Note that we don't need it for anything I've done because everything I've done breaks before single precision floats
+13:59 <@matches> :(
+14:10 <@matches> I have just implemented goto
+14:10 <@matches> However there is still time to rename it to "goat"
+14:11 <@matches> Once you have a goto you really need a branch...
+14:15 <@matches> Go GMPrat
+14:15 <@matches> A mighty 3 FPS
+14:16 <@matches> The downside of my hands being free is I can type more things into IRC
+14:17 <@matches> You can do it GMPRat
+14:17 <@matches> Noo
+14:17 <@matches> 2.5FPS
+14:17 <@matches> We're still going strong
+14:18 <@matches> Oh that's the total accumulated average
+14:18 <@matches> It's actually at 0.8 FPS now
+14:18 <@matches> And falling rather dramatically
+14:20 <@matches> The fundamental flaw with these arbitrary precision types is the representation never gets smaller
+14:21 <@matches> GMP rationals would calculate the GCD which could get smaller (when you zoom back out for example)
+14:21 <@matches> But the GMP integer representation will still only ever increase in size
+14:21 <@matches> I think they just always use the largest precision
+14:22 <@matches> I was hoping that ParanoidNumber would do better since it actually has the ability to shrink
+14:22 <@matches> But it's not amazing
+14:22 <@matches> Hmm, I seem to have lost the rabbit
+14:22 <@matches> That's not meant to happen
+14:22 <@matches> GMPrat is supposed to be exact
+14:22 <@matches> Where did he go!
+14:34 <@matches> Every frame is agonising
+14:39 <@matches> Maybe it's time to switch to motsugo for CPU rendering tests
+14:40 < sulix> At least we now have a good way of burning up time in meetings?
+14:44 <@matches> I'm somewhat confused
+14:44 <@matches> With the cumulative transforms, the GPU renderer should work
+14:44 <@matches> (It is equivelant to using CPU for transformations)
+14:44 <@matches> But it seems to still break around 1e-6
+14:44 < sulix> Yes...
+14:45 <@matches> Oh
+14:45 <@matches> Right I commented out the TRANSFORM_OBJECTS_NOT_VIEW line
+14:45 * matches tries again...
+14:45 * sulix is really regretting the 4-switch statement, 16-case recursive function in the quadtree at the moment.
+14:46 <@matches> I'll make a deal, I won't look at quadtree.cpp if you don't look in paranoidnumber.cpp
+14:47 < sulix> Fair enough.
+14:49 <@matches> I'm not seeing anything in the GPU renderer past 1e-7
+14:49 <@matches> With GMPrat
+14:50 <@matches> I think I'm going to have to go through and fix the more obviously terribly designed parts of things
+14:50 <@matches> For GMPrat to have any chance
+14:53 <@matches> I'm wishing I had a quad tree so I didn't have to transform the bounds of things that would end up outside the screen space :P
+14:53 <@matches> Maybe there's hope for an unholy union of Quadtree and GMP rationals yet
+14:56 < sulix> "And the fifth angel sounded, and I saw a star fallen from heaven to earth: and to him was given the key to a bottomless abyss."
+15:00 <@matches> I think the GMP rational -> float conversion is fith?
+15:00 <@matches> It doesn't make any sense :S
+15:00 <@matches> An object that is visible should always have bounds somewhere in {0,0,1,1}
+15:00 <@matches> Which should be totally fine
+15:01 <@matches> Oh
+15:01 <@matches> Is this the bit where I made GMPrat::ToDouble return 0 if it was too big...
+15:02 <@matches> No it returns mpq_get_d
+15:02 <@matches> Blergh
+15:03 < sulix> An object which is visible should have bounds that _intersect_ {0,0,1,1}
+15:03 < sulix> Perhaps not contained within {0,0,1,1}
+15:03 <@matches> Yeah that
+15:04 <@matches> Maths
+15:04 <@matches> 0 <= x <= 1
+15:04 <@matches> No not that
+15:04 <@matches> Thing
+15:04 < sulix> Unless you're using the Quadtree, which does clip everything to {0,0,1,1}
+15:04 <@matches> Anyway
+15:04 <@matches> It should work
+15:05 <@matches> Wait
+15:05 <@matches> There is this blen thing in the shader
+15:05 <@matches> Is that passed via the view width or something
+15:05 <@matches> Hmm
+15:05 < sulix> That's kinda FITH.
+15:07 <@matches> Anyway, somehow there is a multiplication by width/height and then probably a division afterwards somewhere else
+15:07 <@matches> I'm rather confused
+15:09 * matches struggles to navigate the treacherous waters of view.cpp
+15:10 <@matches> That's right, RenderRange does the actual things
+15:10 <@matches> We've got PrepareRender -> Render -> RenderRange/QuadtreeNode
+15:11 < sulix> RenderQuadtreeNode just calls RenderRange a bunch of times and then breaks the document.
+15:13 <@matches> It's alright, we can save to bitmap, we don't need the document structure to not break
+15:13 <@matches> So how the hell is the shader getting rounding errors
+15:13 <@matches> It should always get glbounds of {0,0,1,1}
+15:13 <@matches> (With cumulative transforms)
+15:15 <@matches> Then RenderRange -> ObjectRenderer::RenderUsingGPU...
+15:17 <@matches> This does not make sense
+15:17 <@matches> Things cannot be broken in this way such that they work
+15:18 <@matches> Hello
+15:18 <@matches> GraphicsBuffer::BufferUsageStaticDraw
+15:18 <@matches> Does that do a thing?
+15:19 <@matches> Also
+15:19 <@matches> Should //m_objbounds_vbo.Invalidate(); be commented out
+15:19 <@matches> I'm still confused as to how it works at all
+15:20 < sulix> BufferUsageStaticDraw tells the driver that we're not planning to modify this buffer frequently.
+15:21 < sulix> The Invalidate() stuff should be commented out, IIRC.
+15:23 <@matches> Hmm when in doubt make clean
+15:30 <@matches> Anyway
+15:30 <@matches> I hope you get the quadtree working with adding stuff
+15:30 <@matches> Because the only point at which doubles fail is when they get a sigfpe
+15:31 <@matches> Floats do start to do strange things before that
+15:32 <@matches> Actually no, doubles would screw up it's just the script is not testing in that range
+15:33 < sulix> I'm still trying to get panning working with the quadtree at the moment.
+15:33 < sulix> I was scratching my head for quite a while before I realised TRANSFORM_OBJECTS_NOT_VIEW was on.
+15:34 <@matches> Sorry
+15:34 <@matches> It really helps the non quad tree rendering
+15:34 < sulix> (You'd be surprised how totally it breaks the quadtree)
+15:34 <@matches> Oh I'm not that surprised
+15:34 <@matches> The quad tree is basically doing cumulative transforms after all
+15:34 <@matches> In a very loose sense
+15:35 < sulix> The quadtree does both.
+15:35 < sulix> It's an equal-opportunity data structure.
+15:37 <@matches> The more I think about this, the more I am convinced the quadtree is the only sensible solution
+15:37 <@matches> Which is unfortunate
+15:37 <@matches> I had hoped to actually have something to present
+15:37 <@matches> Other than "And you should all attend my partner's presentation next week!"
+15:38 <@matches> I guess I should produce some performance graphs or something
+15:38 <@matches> What I did was a terrible idea and this is why
+15:39 <@matches> Sort of thing
+15:40 <@matches> I wonder where the bottleneck is though
+15:40 <@matches> GMPrats get very slow even with the GPU renderer
+15:40 < sulix> Converting to doubles?
+15:40 < sulix> Doing gcd() all day?
+15:40 <@matches> Maybe
+15:40 <@matches> gcd is 50% of execution time according to perf
+15:41 <@matches> perf is pretty cool but it is not as easy to use as valgrind
+15:41 <@matches> Unfortunately valgrind doesn't fully emulate the FPU
+15:41 <@matches> So ParanoidNumbers don't work at all using it
+15:42 <@matches> Which is very frustrating because there have to be things I can speed up in them
+15:42 <@matches> I have a git stash where I tried to implement Copy-On-Write but it was a bit of a disaster
+15:42 <@matches> It was so much of a disaster that even with COW disabled they still broke (despite working fine in the previous commit...)
+15:43 <@matches> They do spend an excessive amount of time copy constructing each other though
+15:50 <@matches> If I can express bezier bounds relative to the containing path it might speed things up slightly
+15:51 < sulix> Ideally we'd ditch the "BEZIER" object and just have paths.
+15:51 < sulix> But that sounds like a lot of work.
+15:53 <@matches> I'd be less inclined to want to do it if things weren't so amazingly slow
+16:00 <@matches> It looks like Bezier::GetType is slowing the CPU rendering down at least
+16:01 <@matches> Clearing pixels is also slow
+16:01 <@matches> Although that doesn't depend on the zooming
+16:02 <@matches> GPU rendering isn't much better though, hmm
+16:46 <@matches> The Arena sort of helps things
+16:47 <@matches> Until it gets to allocating 40 million x 180 Bytes ...
+17:25 <@matches> Protip, #define and spelling mistakes and #ifdef do not work together well...
+--- Day changed Fri Sep 26 2014
+01:40 <@matches> I came up with a compromise between not doing GENG4402 to work on IPDF and doing GENG4402
+01:40 <@matches> The only casualty was sleep
+01:41 <@matches> And no one likes him anyway
+01:41 <@matches> All sides were pleased by the deal
+16:21 * matches regrets upgrading debian jessie after the shellshock thing
+16:21 <@matches> fglrx is gone again
+--- Day changed Sat Sep 27 2014
+12:28 <@matches> 5 minutes to go in ACM...
+12:29 <@matches> You can do it Dijkstras on Bijkstras
+12:30 <@matches> Oh 5 minutes until they freeze the score board
+12:30 < Pommers> 5mins? Timer says an hour
+12:30 <@matches> Apparently they freeze the score board
+12:30 <@matches> I don't know how these work
+12:30 <@matches> I only just started watching
+12:31 <@matches> An hour is plenty of time
+12:31 < Pommers> So teams can't see each others scores change?
+12:31 <@matches> Yeah
+12:31 <@matches> Mickelback just got C wrong
+12:31 < Pommers> They secretlyu have them all solved and are just waiting to waste time
+12:31 <@matches> Yes
+12:31 <@matches> Nice camera work...
+12:31 < Pommers> Getting it right won't get them into first though
+12:32 <@matches> I can't see them
+12:33 < Pommers> UWA needs labs like that
+12:33 <@matches> It's still anyone's game!
+12:33 <@matches> They said it
+12:33 <@matches> You can do it Dijkstras on Bijkstras
+12:33 < Pommers> Cmon Dijksras in Kijkstras
+12:34 * Pommers fails
+12:34 <@matches> Go for G
+12:35 < Pommers> Yeah. Be the winner and Get G right now
+12:35 <@matches> Also D
+12:35 <@matches> and E
+12:35 < Pommers> B D E G
+12:35 <@matches> All you need to do is get all the hard ones right without anyone else getting them right...
+12:35 < Pommers> Nah
+12:36 < Pommers> You want to get all the easy ones as soon as possible
+12:36 < Pommers> Then work out the harder ones
+12:36 <@matches> It's a bit late now..
+12:36 <@matches> Sink everything into the hard ones!
+12:37 < Pommers> The teams still get feedback in the last hour right?
+12:37 <@matches> I assume so
+12:37 <@matches> This camera is totally biased
+12:37 <@matches> I haven't seen sulix yet
+12:37 <@matches> Just shots of people eating sandwiches
+12:38 < Pommers> Sandwich eating stream
+12:38 < Pommers> Best Stream
+12:39 < Pommers> I saw Rowan before
+12:39 <@matches> ANU is doing well
+12:39 <@matches> I think this calls for some sabotage
+12:40 < Pommers> Where's axtens when we need him
+12:40 <@matches> In Canberra
+12:40 <@matches> Also he'd probably be supporting ANU
+12:41 < Pommers> Probably
+12:42 <@matches> I'm waiting for it to all come together
+12:42 <@matches> And all the boxes to turn blue
+12:42 <@matches> Commentator is a bit behind
+12:42 < Pommers> So they've submitted but no public feedback
+12:42 <@matches> Or the stream is a bit behind I guess
+12:42 < Pommers> 45 seconds
+12:42 <@matches> ANU made that submission 3 minutes ago
+12:43 <@matches> Singing!
+12:43 <@matches> This stream has it all
+12:43 < Pommers> I have the stream muted
+12:43 <@matches> Ooh a shot of the other room
+12:44 <@matches> sulix: Stand up!
+12:44 < Pommers> Move out the way so we can see into the room
+12:44 < Pommers> up and down the bolevard
+12:44 <@matches> Hahaha
+12:45 <@matches> That *could* be sulix in the background
+12:47 <@matches> I guess it would be intrusive to have the camera in the room with the contestants
+12:47 <@matches> Also for 14 viewers
+12:48 <@matches> I love the sign off
+12:51 <@matches> Gozz!
+12:51 <@matches> Gozz what are you doing!
+12:51 <@matches> Get back to the desk!
+12:54 <@matches> These coaches(?) look rather worried
+12:55 <@matches> Oh well, I guess I should actually work on IPDF
+12:55 <@matches> Not all of us get free trips to Sydney :P
+13:00 < Pommers> So yeah. They get there own score line
+13:01 < Pommers> I missed Gozz!
+13:03 <@matches> They must be doing well if they have time for sandwich breaks
+13:03 <@matches> Have all the solutions ready to submit in the last 5 minutes
+13:03 <@matches> Shock victory
+13:03 < Pommers> Or they have given up
+13:03 <@matches> No!
+13:03 <@matches> How do you read the scores anyway?
+13:03 <@matches> The first column is number of problems solved
+13:03 <@matches> What's the second
+13:04 < Pommers> I explained in #ucc before
+13:04 <@matches> Ah damn
+13:04 < Pommers> 12:09 <@Pommers> Ranking is number of challanges sorted: More is better
+13:04 < Pommers> 12:09 <@Pommers> Numeric number: Less is better
+13:04 < Pommers> 12:09 <@Pommers> Cause the number is minute challenmge was solved + 10 * number of failed attempts
+13:04 < Pommers> 12:10 <@Pommers> 20, not 10
+13:04 <@matches> I thought they were doing well because they had a high number
+13:04 < Pommers> 12:10 < bob> so those teams who haven't finished anything and have a score of zero are winning?
+13:04 < Pommers> 12:11 < bob> oh I get you now
+13:04 < Pommers> 12:11 <@Pommers> Nope. Because number of challenges sorted is more important
+13:04 < Pommers> 12:11 < bob> really shittily labeling on that table
+13:04 < Pommers> 12:11 < bob> so mickelback is coming second
+13:04 <@matches> Yes yes I can change windows
+13:04 < Pommers> 12:11 <@Pommers> The numbers on the left show their current position
+13:04 < Pommers> 12:11 <@Pommers> Yep
+13:04 < Pommers> 12:12 <@Pommers> The scoring system is pretty much the same for all coding competitions
+13:04 < Pommers> 12:12 <@Pommers> GCJ is different though
+13:04 < Pommers> 12:16 <@Pommers> Numbers down the bottom are attempts/correct/time was first solved
+13:04 < Pommers> Nope
+13:05 < Pommers> But now it's in your logs too!
+13:05 <@matches> Meh anything that skews the statistics away from me talking to myself is fine by me
+13:05 <@matches> Just copy paste all of #ucc in here please
+13:06 <@matches> Mikelback could still win
+13:06 < Pommers> 13:05 <@matches> Just copy paste all of #ucc in here please
+13:06 < Pommers> If you say so
+13:06 <@matches> Nonononono
+13:07 <@matches> I'
+13:07 <@matches> ll just delete the git repository when this is over
+13:08 < Pommers> Sounds like a good idea
+13:13 <@matches> So you can go back to earlier parts of the stream
+13:13 <@matches> "I tell you, in this life there are only two things to die for: Your country, and these sandwiches"
+13:15 < Pommers> Yep
+13:15 <@matches> Back to live action, and there is a close up of someone eating a sandwich
+13:27 <@matches> There's still time!
+13:28 <@matches> Why are things not turning blue
+13:29 <@matches> Mickelback appears to be struggling on B
+13:29 <@matches> Haha
+13:29 <@matches> "It could be anyone... anyone... well probably not Auckland Queensland or Adelaide"
+13:29 <@matches> Anyone of the top five
+13:31 <@matches> I'm still waiting for the 5 simultaneous submissions from Dijkstras on Bijkstras
+13:32 <@matches> More sandwiches
+13:34 < Pommers> Now we wait
+13:36 <@matches> Reading these logs back it sounds a lot wierder when you don't notice the timestamps
+23:23 <@matches> So, after much spaghetti bolognaise
+23:24 <@matches> I managed to perform the arbitrary precision transformations only on the bounds of paths as opposed to the bounds of every single object.
+23:24 <@matches> It helps a lot but at the end of the day it's still fantastically useless.
+23:24 <@matches> Project complete I guess.
+23:24 <@matches> Just Use Quad Trees
+23:25 <@matches> If I had some way to clip the objects to the view so I only had to transform things that would be shown...
+23:25 <@matches> I would have a quad tree
+23:25 <@matches> If I don't do that, then you still have the exponentially growing Gmprat
+23:26 <@matches> Oh
+23:26 <@matches> Oooh
+23:26 <@matches> Actually
+23:26 <@matches> I had the CPU renderer on
+23:27 <@matches> The GPU renderer loves this
+23:27 <@matches> The CPU renderer seems to generally just suck
+23:27 <@matches> I suspect there is actually a bug in it
+23:27 <@matches> It shouldn't be so slow
+23:28 * matches is getting really excited
+23:28 <@matches> I actually zoomed in to 1e-9 using floats for everything except the Path bounds
+23:29 <@matches> It would be nice the CPU renderer didn't suck, but I guess "Transform the bounds with arbitrary precision on the CPU and do rendering with floats on the GPU" is actually the better approach
+23:32 <@matches> Also... I think somehow I got an updated fglrx that is less shit at rounding floats
+23:32 <@matches> Because eye_of_the_rabbit doesn't go all funny anymore...
+23:32 <@matches> Unless you make it zoom a little bit more
+23:36 <@matches> I still think the quad tree will beat this in terms of performances
+23:36 <@matches> But at least it's like, in the game
+23:36 <@matches> As in it doesn't take so long to do the performance test that it's not worth bothering actually doing a comparison
+23:36 <@matches> Now we can have a graph at least
+23:46 < Pommers> Very nice
+23:51 <@matches> The CPU renderer is stalling in DeCasteljau
+--- Day changed Sun Sep 28 2014
+00:18 <@matches> sulix: You need to get eye_of_the_rabbit working under the quadtree so I can compare it with my horrible hacks to View,Path,BezierRenderer,PathRenderer...
+00:18 <@matches> Document...
+00:18 <@matches> Not a single class escaped the wrath of the #ifdef
+00:18 <@matches> No pressure, glhfdd
+00:19 <@matches> Unfortunately I still get a bunch of SIGFPEs but I think those are in places that don't affect the rendering, so I can probably fix them
+00:19 <@matches> Or set the program to ignore them
+00:20 <@matches> I never really worked out how you turned them on in the first place :S
+00:20 <@matches> Also well done at ACM and all that
+00:21 <@matches> The #define's you'll want to turn off to get the quadtree working again are both the ones in view.h and path.h
+00:21 <@matches> Oh wait I put in a check just for you
+--- Log opened Sun Sep 28 09:58:47 2014
+09:58 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+09:58 -!- Irssi: Join to #ipdf was synced in 0 secs
+10:04 -!- matches changed the topic of #ipdf to: Motsugo OOMed, this would be a great excuse to extend the project if we were actually using Motsugo
+--- Log closed Sun Sep 28 10:08:08 2014
+--- Log opened Sun Sep 28 10:08:20 2014
+10:08 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+10:08 -!- Irssi: Join to #ipdf was synced in 2 secs
+--- Day changed Wed Oct 01 2014
+15:13 <@matches> Urgh the code is disgusting
+15:13 <@matches> I can't look at it
+15:16 <@matches> The quadtree does some... interesting things
+15:17 < sulix> I think by "interesting," you mean "horrible."
+15:18 < sulix> ... or possibly "wrong"
+15:22 <@matches> Well, you appear to be able to add things to the document
+15:22 <@matches> They are just in the wrong spot
+15:22 <@matches> Also things seem to disappear as well
+15:28 <@matches> Also I can't seem to compile without the quadtree anymore
+15:29 <@matches> You're going to have to deal with the Makefile because I'
+15:29 <@matches> m moving quadtree.o out of the defaults
+15:29 <@matches> It expects things in IPDF::Document that won't exist if the quadtree is disabled
+15:35 < sulix> Oops...
+15:35 < sulix> I have started using the makefile, though, so that's good.
+15:39 <@matches> I'm somewhat regretting the use of Real in the Bezier
+15:39 <@matches> I need another Real
+15:39 <@matches> Real2 ?
+15:39 <@matches> Or I can do terrible hacks with #undef
+15:39 <@matches> Hmmm
+15:39 <@matches> Terrible hacks with #undef it is!
+15:40 <@matches> Possibly we need a seperate header for all these defines
+15:40 <@matches> I have #defines in path.h that only work if there is also a #define in view.h ...
+15:41 <@matches> But the #define in view.h will still work without the one in path.h
+15:43 <@matches> Possibly using different branches would have been cleaner
+15:43 <@matches> Possibly I should really stop writing code and start writing a report anyway
+15:43 <@matches> So many regrets
+15:44 <@matches> I explained the project to some Engineers today!
+15:44 <@matches> They understood it!
+15:44 <@matches> They questioned the point of it all...
+15:44 <@matches> I said "The point is that you can zoom into this point here..."
+15:44 <@matches> "And it turns into a rabbit!"
+15:44 <@matches> :S
+15:46 <@matches> Also "Why isn't there any shading"
+19:24 <@matches> I'm having a little trouble with the performance metrics
+19:24 <@matches> How do I pick something that is a legitimate performance metric
+19:24 <@matches> "We decided to render this Fox and this Rabbit"
+19:25 <@matches> Also I really wish ipdf were good enough to do the report in it, because then it could demonstrate itself
+19:25 <@matches> Now I have to link to a video?
+19:26 <@matches> I mean
+19:26 <@matches> "Figure 1 is the rabbit and Figure 2 is the rabbit that looks exactly the same when you zoom in!"
+19:26 <@matches> Is not really impressive
+19:26 <@matches> "Figure 1 is the rabbit and Figure 2 is the rabbit that looks terrible when you use floats and you'll just have to trust us when we say we fixed this"
+19:26 <@matches> :S
+19:28 <@matches> Also causing difficulty...
+19:28 <@matches> The zoom level I am at is not representable as a double
+19:28 <@matches> Which means it cannot be plotted in gnuplot unless I scale it to the range of doubles first...
+19:28 <@matches> Which sort of defeats the point...
+19:29 <@matches> I guess I could plot "Exponent"
+19:29 <@matches> If you clear the document after every 3 rabbits, eye_of_the_rabbit appears to go for a very long time
+19:30 <@matches> So that's the performance vs zoom I guess
+19:30 <@matches> But only take a data point after every 3 rabbits otherwise you are also altering number of primitives
+19:30 <@matches> Panning is pretty much the same
+19:33 <@matches> I'm just going to sit and watch it zoom for a while I guess
+19:33 <@matches> Mesmerising
+19:34 <@matches> Should I help fix the quad tree?
+19:34 <@matches> I'd like to be able to compare it to the "actually we'll only use arbitrary precision for *some* things" approach
+--- Log opened Thu Oct 02 13:55:13 2014
+13:55 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+13:55 -!- Irssi: Join to #ipdf was synced in 3 secs
+14:44 <@matches> Hello
+14:44 <@matches> Are we having a meeting today?
+14:45 < sulix> Rowan is still in Sydney.
+14:45 <@matches> Oh
+14:45 <@matches> That would make it difficult
+14:45 <@matches> Well, I'
+14:45 < sulix> (Also every time I touch the quadtree it ends up more broken)
+14:45 <@matches> m in UCC trying to actually get some sort of performance graphs
+14:45 <@matches> :(
+14:46 <@matches> Yeah, it turns out Gmprat may beat floats considerably but it isn't that great compared to doubles
+14:46 <@matches> It's interesting actually
+14:46 <@matches> It only really starts to slow down right at the limit of double precision
+14:46 <@matches> Then again, doubles will screw up before that (I hope)
+14:47 <@matches> You can represent 1e-38 with a float but it still screws up at 1e-6 after all
+14:47 <@matches> Also no one understands the eye_of_the_rabbit demo
+14:48 <@matches> I don't know why
+14:48 <@matches> It's pretty obvious it's *zooming to infinity*
+14:48 <@matches> (TM)
+14:48 <@matches> Righht?
+14:48 <@matches> :(
+14:48 < sulix> Their puny minds cannot contain the majesty that is eye_of_the_rabbit.script
+14:50 <@matches> A demo that actually added text where the text was the scale might be cool
+14:50 <@matches> Except debugscript is not that advanced
+14:50 < sulix> If you want to add string formatting to debugscript, I will not be involved. :P
+14:51 <@matches> I would probably just hack on a command
+14:51 <@matches> "Do this one particular demo"
+14:51 <@matches> Instead of making the scripting language turing complete...
+14:53 <@matches> In other news, Gozz taught me the difference between %d and %i :P
+14:53 < sulix> My greatest shame...
+14:54 <@matches> I normally use %d but I never actually realised they were differenc
+14:54 <@matches> Well they aren't when printf'ing
+14:55 < sulix> Four hours (+ an 80 minute penalty) because of random octal...
+14:55 <@matches> Well, if you'd won you wouldn't be able to finish IPDF
+14:57 < sulix> (Yeah, but maybe I'd've been good enough to not make the QuadTree horribly buggy...)
+14:58 <@matches> I should look at it
+14:58 <@matches> When I tried it, it was adding objects but they were appearing in totally whack places
+14:58 <@matches> Also different places depending on what renderer was used
+14:59 <@matches> I'm pretty much in favour of just focussing on the GPU renderer now though
+14:59 < sulix> At the moment it should only add things to the root node.
+14:59 <@matches> I have encountered the issues you mentioned where the CPU renderer suddenly decides to crash X
+15:00 < sulix> It seems to just suddenly start eating all of the ram in the world.
+15:00 <@matches> I don't know why though
+15:00 <@matches> It does it with regular floats as well
+15:01 <@matches> Unless it's allocating the pixel buffer every frame but why the hell would I have done that
+15:06 <@matches> Also! Really annoying! GMP can only print rationals as num/den
+15:06 < sulix> I guess that's because not all rationals have a finite decimal expansion.
+15:06 <@matches> It has Rational -> Double but not Rational -> Arbitrary Precision Double
+15:07 <@matches> Yeah, but I wish you could go "Print in scientific notation to 4 sig fig"
+15:08 <@matches> I resorted to log(a/b) = log(a) - log(b)
+15:08 <@matches> Except it doesn't actually have logarithm either
+15:08 <@matches> It has "Number of digits needed in base X"
+15:08 <@matches> Close enough...
+15:09 <@matches> Actually no it's awful
+17:32 <@matches> I'm going to have to do some disgusting template-yness things to Rect and Bezier I think
+17:47 <@matches> Blergh
+17:47 <@matches> Having a universal Real type is really damn annoying now that I don't want a universal Real type
+17:48 <@matches> I can do: template <struct T = IPDF::Real> struct Rect {...};
+17:48 <@matches> But then you have to replace Rect with Rect<> everywhere
+17:49 <@matches> I could make very single class a template class with Real as the template
+17:49 <@matches> Because that isn't horrifying
+17:52 * matches sobs and makes Rect a typedef for "TRect"
+18:22 <@matches> A is for ambiguous
+18:31 * matches curses templates
+18:31 <@matches> They attempt to solve the flaws in preprocessor macros by not actually solving anything
+18:32 <@matches> So that you will give up and just not write the program
+18:32 <@matches> The purpose of templates is to stop people from programming
+18:42 <@matches> Maybe don't pull the latest commit if you want anything to work at all
+--- Day changed Fri Oct 03 2014
+14:53 <@matches> The GMP attitude to logarithms seems to be "You can just write your own" which is nice, except that writing your own is not actually that easy to do well
+15:39 <@matches> This is rather annoying
+15:39 <@matches> When running the "Performance vs View Bounds" test, the bottleneck is in printing the View bounds
+15:40 <@matches> Because it requires a log of logs
+15:40 <@matches> *log of lots
+15:40 <@matches> *lot of logs
+15:40 <@matches> *lots of lumberjacks
+15:40 <@matches> *whatever
+15:41 <@matches> At least I seem to have made it O(1) where 1 is depressingly large constant
+15:55 <@matches> And so, after a day and a half, I can hopefully actually print bounds that are outside the range of representable doubles
+15:56 <@matches> Then I guess I'll have to do some kind of hack to get the "e-XXX" part so I can actually import them in numpy/gnuplot
+--- Day changed Sat Oct 04 2014
+13:55 <@matches> So, time investment
+13:55 <@matches> Do I make graphs
+13:55 <@matches> Or do I draw a turtle.svg
+13:55 <@matches> So that we can make the "Turtles all the way down" reference
+13:55 <@matches> Tough decision
+13:56 < Pommers> Turtles
+14:19 <@matches> I think fglrx must have a memory leak
+14:20 <@matches> Even after the program quits everything dies
+14:20 <@matches> And stays dead
+14:21 <@matches> Apparently I only have 80MB of memory left, yet the most anything in top is using is 100MB
+14:21 <@matches> ...
+14:21 <@matches> It's still decreasing
+14:21 <@matches> I have 10 MB left ?
+14:22 <@matches> Farewell
+14:26 < Pommers> glhfdd
+15:23 <@matches> http://szmoore.net/ipdf/code/src/svg-tests/turtle.svg
+15:23 <@matches> Can't be bothered colouring it in
+15:23 <@matches> It occurs to me that if we had recursive SVG support we would be Winning (TM)
+15:24 <@matches> I wonder how hard it would be to hack that on...
+15:24 <@matches> Need to map SVG "id" attributes to a Path
+15:24 <@matches> Need to allow Path to include Path
+15:24 <@matches> Hmm...
+15:24 <@matches> It's probably going to be as hard as shading
+15:25 <@matches> ie: Significantly harder than it should be due to the somewhat flawed design of our Object representations
+15:25 <@matches> We really only need Path and none of these other shaders
+15:26 <@matches> Maybe one Path shader per path too
+15:26 <@matches> As opposed to one Bezier shader for every single Bezier
+15:26 <@matches> Well, same shader but with different VBOs
+15:26 <@matches> Or IBOs
+15:26 <@matches> whatever
+15:28 <@matches> The problem is I can't implement Turtles all the Way Down in such a way that it shows all the turtles without either a) Making the DebugScript turing complete, or b) Implementing recursive SVGs
+15:29 <@matches> And option b) has the advantage of the document still being interactive whilst option a) restricts the view to what the script is doing
+15:30 <@matches> Also if the quad tree was working, turtles all the way down would be a good test of it, because the Arbitrary Precision bounds gets really slow since it has to always transform every path even those that are off screen
+15:31 <@matches> I should probably start writing a thesis but I really want to actually have something impressive to write about
+15:31 <@matches> I mean I still have to write about all the other stuff as well
+15:31 < Pommers> Yay off by one errors!
+15:32 <@matches> What, with the Log10 ?
+15:32 <@matches> It shouldn't be off by that much
+15:32 <@matches> Wait how are you running this
+15:32 <@matches> Wait you're talking about something else -_-
+15:32 < Pommers> Yes
+15:32 < Pommers> I've spent the past day looking for this error
+15:34 <@matches> Good job?
+15:34 < Pommers> Nope. So annoying. THought I just had it. Nope.
+15:35 <@matches> Sounds like we could make you an honarary IPDF developer
+15:35 < Pommers> I thought I already was :P
+15:38 < Pommers> Nope. Now my numbers are more off :/
+16:07 <@matches> Try ParanoidNumber
+16:07 <@matches> Guaranteed to give semi-accurate segfaults
+16:10 <@matches> Trying to look up some paper to justify my Logarithm approximation (because doing maths myself is hard)
+16:10 <@matches> "Computing discrete logarithms with the parallelized kangaroo method"
+16:10 <@matches> I... don't... even...
+16:11 <@matches> Why isn't there a paper on this
+16:11 <@matches> It shouldn't be hard, ergo, someone should have written a paper
+16:14 * matches really regrets only getting 60% in applied maths
+16:14 <@matches> I'm fairly sure this sort of thing was in it
+16:14 <@matches> Series approximations and stuff
+16:45 <@matches> Argahsdgf
+16:45 <@matches> It's actually hard to define what we *want* from our arbitrary precision document
+16:46 <@matches> Hmm
+16:46 <@matches> You have a view port, and you want primitives that are scaled to the view port to appear identical, regardless of where the view port is
+16:46 <@matches> Does that work
+16:46 <@matches> sulix are you alive
+16:46 <@matches> Is the quad tree going to be ok
+16:48 < sulix> Alive might be overstating it slightly. The quadtree is still kind-of functional.
+16:48 < sulix> (None of your commits have broken anything obvious, which is nice)
+16:49 * Pommers stabs floating point ints
+16:49 < Pommers> 0.0000000001 off
+16:50 <@matches> Most of my commits affect stuff that's wrapped in a bunch of #ifdef QUADTREE_DISABLED
+16:50 <@matches> I added some typedef's but they are all just equivelant to Real if QUADTREE_DISABLED
+16:51 <@matches> Pommers: Are you using floats or doubles? And if so, change to long doubles
+16:51 < sulix> That was very kind of you. I'm not sure how many drastic changes the quadtree can take at this point.
+16:52 < sulix> Was is SPARC that supported "quads"?
+16:52 <@matches> I'm kind of curious as to whether anything actually supports Base 10 floats
+16:52 < Pommers> Doubles
+16:52 < Pommers> I could try long doubles
+16:52 <@matches> Because it's in the standard
+16:53 <@matches> long doubles will probably help
+16:53 <@matches> I haven't run out software with long doubles yet because I'm really expecting it to do amazingly better than Gmp rationals
+16:54 <@matches> In theory, with enough memory, GMP rationals will win
+16:56 * matches suddenly realises just how much stuff there is that needs to be done
+16:57 * matches cries
+16:57 < Pommers> My great commit log... https://github.com/mpomery/CITS3402/commits/master
+16:57 * sulix sobs sympathetically
+16:58 <@matches> That has nothing on the IPDF commit logs I'm sorry
+16:59 <@matches> I should really stop deliberately making the commit messages over dramatic
+16:59 < Pommers> Probably not
+16:59 < Pommers> Definately
+17:01 < sulix> The more I think about the quadtree, the more certain I am that it should just be crashing all the time.
+17:10 * sulix quietly wonders if he can steal some code from that xkcd comic.
+17:18 <@matches> So, it only works if you give it a starting SVG because it loads the whole thing into the root node and then builds the other nodes as you zoom
+17:18 <@matches> And inserting things at some arbitrary point is hard
+17:18 <@matches> Could you... brute force... recreate the entire thing from the root node
+17:19 < sulix> The plan (after the great minus-sign move of '14) is to simply create a new document from wherever you add something, and "overlay" it.
+17:20 <@matches> Ah
+17:20 <@matches> sounds clever
+17:20 <@matches> Hmm
+17:20 <@matches> There's a whole bunch of definitions and obvious assumptions that I need to state
+17:20 <@matches> How do I even explain this
+17:21 <@matches> So, bresenham lets you draw a line exactly given the end points => You only care about rounding the end points
+17:21 <@matches> Bezier = decompose into Bresenham => You care about rounding in the Bezier decomposition
+17:21 < sulix> Well, bresenham doesn't let you draw a line exactly at all.
+17:21 <@matches> Pfft
+17:21 <@matches> Exactly shchmexactly
+17:22 <@matches> To pixel accuracy I guess
+17:22 <@matches> If the Bezier is in screen space and the buffer is small enough, then the bezier decomposition is accurate-enough to within the nearest pixel
+17:22 <@matches> So you care about transforming the bezier control points
+17:22 <@matches> They can be written relative to the bounds so you care about transforming the bounds
+17:23 <@matches> The bounds can be written relative to the path ergo you only need to transform the path bounds
+17:23 <@matches> Ergasdfadfg
+17:23 <@matches> It's all relative
+17:24 <@matches> There's no point being able to render something in bounds 1e-100000 if you don't also want to store something up at width 1
+17:24 <@matches> Otherwise you may as well just use bounds with width 1 and then do a multiplication before you printf them
+17:24 <@matches> Problem solved!
+17:29 <@matches> What I am trying to do makes perfect sense in my head and absolutely no sense translated to english
+17:29 <@matches> And translating it to maths is just asking for trouble
+17:29 < Pommers> #pragma omp single means that I'll start up a single thread to do something right?
+17:30 <@matches> Well, it won't create a new thread, it means a single thread out of the current pool will do it
+17:30 < Pommers> Okay. How can I get OpenMP to create a thread to do one of several for loops?
+17:31 <@matches> #pragma omp parallel for
+17:31 <@matches> Divides the loops up evenly amongst the threads
+17:31 <@matches> Is that what you want?
+17:31 < Pommers> Nah, multiple for loops, not the one
+17:32 <@matches> Is the loop inside a parallel secion already?
+17:32 < Pommers> Unless I am misunderstanding what parallel for does
+17:32 < Pommers> Nope, not inside a loop yet
+17:32 <@matches> Unless you explictly use a #pragma omp parallel, the code will be executed by the main thread
+17:33 < Pommers> So if I go:
+17:33 < Pommers> #pragma omp parallel
+17:33 < Pommers> #progma omp single
+17:33 < Pommers> for loop
+17:33 < Pommers> #progma omp single
+17:33 < Pommers> for loop
+17:34 < Pommers> #pragma omp barrier
+17:34 < Pommers> The for loops with get executed by potentially different threads?
+17:34 <@matches> Yes
+17:34 <@matches> And they only get executed once
+17:34 <@matches> But you can't predict the order
+17:34 < Pommers> Cool
+17:34 <@matches> Anything outside the "single" gets done by all threads
+17:35 <@matches> I don't think you need the barrier
+17:35 <@matches> There are implicit barriers at the end of each parallel section
+17:35 <@matches> Oh, also make sure the scope is correct
+17:35 <@matches> Put {} around things
+17:35 < Pommers> Okay
+17:35 < Pommers> Imma come back to it in a moment
+17:35 < Pommers> Forgot to go pick up my housemate :/
+17:36 < Pommers> ty matches
+17:36 <@matches> (You don't need the {} if you have a loop immediately after the parallel directive though)
+17:37 <@matches> Using OMP with certain text editors is a nightmare because they want to automatically put preprocessor directives in the first column
+17:37 <@matches> Which totally screws up indentation
+17:37 <@matches> Certain uses of OMP don't actually use indentation in the first place though, which I can't understand at all
+17:37 <@matches> They indent the for loop but not the parallel directive that applies to it
+17:38 * matches shudders
+17:38 <@matches> These are the same lecturers that discouraged us from using functions because function calls slow the program down
+17:38 <@matches> Whole program should be in main()
+17:38 <@matches> Goto if necessary
+17:42 <@matches> (I compiled something with and without a function call and saw that it was the exact same assembly and then proceeded to totally ignore any programming advice they gave us from then on)
+17:43 <@matches> I guess it would be true if you had an ancient compiler
+17:46 < sulix> (Secret: function calls _are_ slow. So is goto, though, so the point is moot.)
+18:07 <@matches> Baha
+18:08 <@matches> There is some kind of deep maths behind why transforming things relative to Path bounds works
+18:08 <@matches> I guess
+18:08 <@matches> It is both obvious and not obvious
+18:08 <@matches> It is very frustrating
+18:09 <@matches> I think this project is somewhat more appropriate for a maths major than mechatronics engineers...
+18:09 <@matches> I guess I don't have to go into the maths, but if I don't then I'm basically just saying "I tried this because it seemed like it would work, and it did!"
+18:10 <@matches> Even the Logarithm I implemented has nice maths in it
+18:11 <@matches> Which is just slightly beyond my ability to explain satisfactorily
+18:14 < sulix> I don't think maths-majoring has helped me much. It gives me snarky things to say about floats vs rationals, but doesn't stop the fact that I've now spent over a week trying to work out where the -ve signs need to go in the quadtree.
+18:16 <@matches> :(
+18:18 < sulix> On the bright side, by the power of trial, error, cribbing from the xkcd comic, and forcibly recreating all of the GPU buffers 4 times a frame, panning around the quadtree now seems to work.
+18:18 <@matches> Yay!
+18:18 <@matches> Can you zoom yet
+18:19 < sulix> Almost*
+18:19 <@matches> Zooming is just panning but with different numbers
+18:19 <@matches> Or is panning just zooming but with different numbers
+18:19 <@matches> Something
+18:19 <@matches> Some of the numbers are zero
+18:19 <@matches> Or possibly 1
+18:20 <@matches> Let me know when eye_of_the_rabbit works and we will have a performance show down!
+18:20 < sulix> Zooming in works about as well as it did before. Zooming out works as long as you don't try to zoom out beyond the original view.
+18:20 < sulix> Panning around the document works, though might have some problems if you try to pan outside (0,0)-(1,1) from the original view.
+18:20 <@matches> Who needs to zoom out anyway
+18:22 <@matches> I'm going to make the debug font more dramatic to answer some criticism
+18:22 <@matches> Apparently I need to indicate the width of the view in SI units
+18:22 <@matches> (And in really big text)
+18:25 < sulix> But there are no units for the view!
+18:25 <@matches> On my monitor the view is 22mm
+18:25 <@matches> window rather
+18:25 <@matches> So just multiply the view width by that
+18:25 < sulix> Just short of an attoparsec...
+18:33 < sulix> Okay, fixed the "you have to zoom in on non-binary-fraction boundaries for infinite precision issue that's plagued the quadtree for months.
+18:33 < sulix> Now we can see: discontinuities at quadtree node boundaries!
+18:33 < sulix> Fortunately, I have an excuse for leaving them there!
+18:34 < sulix> "The object wasn't added at that resolution."
+18:34 <@matches> Heh
+18:34 < sulix> (Also: we totally don't solve cubics analytically, so they're worse than they need to be)
+18:35 * sulix smells a "further work" section.
+18:35 <@matches> You have a "current work" section? Jealous
+18:36 * sulix didn't say that.
+18:36 <@matches> Apparently as long as I make something pretty people will be impressed
+18:36 <@matches> I wonder if it's too late to implement shading (again)...
+18:36 < sulix> Maybe different-coloured outlines?
+18:36 <@matches> Haha
+18:36 < sulix> More demo svgs?
+18:36 <@matches> I quite like the turtles demo
+18:37 <@matches> Unfortunately for reasons mentioned earlier it can't actually add turtles forever
+18:37 <@matches> Well it could
+18:37 <@matches> But you couldn't stop it and go look at them
+18:37 <@matches> You'll only ever see the bottom one
+18:37 <@matches> The demo that draws 20 and then zooms back out and then in again is probably good enough
+18:38 < sulix> Hmm... eye_of_the_rabbit is segfaulting the quadtree.
+18:38 <@matches> It clears the document every so often
+18:38 <@matches> Try commenting that out first?
+18:38 < sulix> That'd probably do it.
+18:38 <@matches> I thought we probably wanted to test zooming without altering the number of primitives, and that was the only way I could think of doing it
+18:38 < sulix> It also made the quadtree slow down, though that's a side effect of something I like to call "shitty coding".
+18:39 < sulix> The quadtree is full of it.
+18:45 * sulix is merging now. I love the #pragma message that happens for every file!
+18:48 < sulix> Code is up for your enjoyment/horror.
+18:48 * sulix breaks for dinner.
+21:01 <@matches> Yeah the #pragma message probably wasn't that good an idea
+21:02 <@matches> The problem was there are 3 different "Reals" now :S
+21:02 <@matches> So I wanted to make sure I knew which ones it was using
+21:08 < sulix> Fair enough.
+21:11 < sulix> Oh dear god, what have you done to the debug text?
+21:13 * sulix shudders.
+21:14 <@matches> It's readable!
+21:14 <@matches> Through the automerge seems to have forgotten the #ifdef 0
+21:15 <@matches> Oh that stuff is printed somewhere else...
+21:16 <@matches> Anyway, adding stuff seems to work!
+21:16 <@matches> But not from the script for some reason
+21:16 <@matches> Oh right, the clearing
+21:17 < sulix> It shouldn't work totally in the quadtree, I've just made it break more quickly.
+21:17 < sulix> Basically, you can (a) only add to the root node and (b) nodes are not yet updated with new objects if they already exist.
+21:17 <@matches> It doesn't work when things overlap nodes?
+21:17 <@matches> Right
+21:17 <@matches> I was getting excited for a minute
+21:18 < sulix> On the bright side, it no longer creates an entirely new quadtree for every individual object and it actually adds new things to new child nodes.
+21:20 <@matches> Running eye of the rabbit I see a LOT of "Recreate buffers" messages but no actual rabbits
+21:21 < sulix> It now recreates the buffers every frame because that was easier than getting it to recreate the buffer in arcane parts of quadtree code.
+21:29 <@matches> Well, it does work when you add something to the root node I guess
+21:30 < sulix> Almost.
+21:31 < sulix> If you zoom in, zoom out, add something to the root node and then zoom in again it isn't there.
+21:31 < sulix> But that will (fingers crossed) soon be resolved through the power of recursive functions.
+21:31 <@matches> Hmm, that's almost what happens when you use IEEE singles!
+21:34 < sulix> I'm still trying to work out how I can delay the generation of new child overlays until after all new objects have been added.
+21:34 < sulix> If I do things the obvious way, it'll generate thousands of overlays and totally kill performance.
+21:35 <@matches> Damn
+21:35 <@matches> I think I just need to write lots of stuff and fast
+21:35 <@matches> Well
+21:35 <@matches> Some form of result would be nice
+21:35 <@matches> A graph
+21:41 < sulix> I think I've managed to make the quadtree even slower than ParanoidNumber<GmpRat> would be.
+21:42 <@matches> How though? It seemed like it would be efficient
+21:43 <@matches> It doesn't have to render the whole document
+21:43 <@matches> s/render/transform
+21:44 < sulix> Well, it has to regenerate the entire quadtree everytime there is a new bezier, and there are lots of O(n) linked lists and recursive functions there.
+21:44 < sulix> And doing this the naïve way generates a pathalogically-worst case situation.
+21:45 < sulix> (I'm still waiting for my first "add something test" to complete.
+21:45 < sulix> )
+21:45 <@matches> Hmm
+21:46 <@matches> I guess once you already have a document with lots of detail in it, a quadtree is good
+21:46 <@matches> But actualy making the document with lots of detail in it...
+21:46 * sulix suspects it might just be infinite looping.
+21:46 <@matches> Why does it have to rebuild the entire quadtree? Can't it just modify the current node + nearest neighbours?
+21:47 <@matches> Or go up to the parent and add all the objects in the parent, then split them up for the children
+21:47 <@matches> Hmm
+21:48 <@matches> You need to be able to add objects to the ancestors as you zoom out I guess
+21:48 <@matches> But you should be able to do it lazily?
+21:48 <@matches> In theory
+21:48 < sulix> In theory.
+21:48 * matches is glad he is not writing the quadtree after all
+21:48 < sulix> The big problem is that adding things to the quadtree needs to be done in bulk to be efficient.
+21:49 < sulix> i.e. If you add a whole bunch of things to one node, and then a whole bunch of things to another, it's okay.
+21:49 < sulix> But if you alternate (add something to one), (add something to the other) repeatedly, you fragment the quadtree and it treats each bézier as it's own overlay from then on.
+21:49 < sulix> The easy way to do things is the latter way.
+21:50 < sulix> Because it's hard to get all of the info you need about what things have changed in bulk at the end of an entire operation.
+21:51 < sulix> But clearly doing things curve by curve is not going to cut it if even the simplest examples take over 5min/frame to render.
+21:52 <@matches> Well if it's any condolance, ParanoidNumbers are still worse than that
+21:53 * sulix should say "5min and counting"/frame.
+21:53 < sulix> I've not yet had a frame render.
+21:53 <@matches> Hey, at least you can still type into a terminal
+21:54 <@matches> When I run ParanoidNumbers I can't even kill the process for 5 minutes...
+21:54 < sulix> I am thankful for these small mercies.
+21:55 <@matches> I'd hoped they'd be a bit better with the more efficient transformation model but apparently not enough
+21:55 <@matches> In fact they are segfaulting again
+21:56 <@matches> I thought I stopped that
+21:56 <@matches> The plot thickens!
+21:57 <@matches> They segfault when std=c++0x
+21:57 <@matches> But not when std=c++11
+21:57 < sulix> Oh dear god.
+21:57 <@matches> I suspect it is related to the use of "auto"
+21:57 <@matches> And it is probably why google told you not to use it
+22:00 <@matches> Actually it's more likely because I forgot to make clean
+22:01 <@matches> Well I guess I will come back to them once I actually have something resembling a thesis draft
+22:01 <@matches> Hahaha
+22:02 <@matches> The turtles script is way cooler than the rabbit one by the way, if you haven't run it yet
+22:02 <@matches> (But it breaks the quad tree even more)
+22:04 <@matches> And PN do work if you restrict the size to like, 3
+22:05 <@matches> News in 5 minutes: Is it actually better than just using doubles
+22:06 <@matches> It seems to speed up every so often and then slow down again
+22:06 <@matches> Aaamd
+22:06 <@matches> Yeah that turtle rounded to the wrong spot
+22:07 <@matches> I should see how well our custom Rational implementation does too
+22:12 <@matches> I am confused by PN
+22:12 <@matches> A size limit of >= 5 causes apocalyptic memory usage
+22:12 <@matches> A size limit of 4 is totally fine and actually not much slower than Gmprat
+22:13 <@matches> Also I have a sudden urge to compile this with MinGW so that the Engineers who mark it can actually run it
+22:13 <@matches> I mean, they probably won't run it
+22:13 <@matches> But the last thing I want is for them to try and not be able to
+22:13 <@matches> And then just assume I fudged the results
+22:14 <@matches> I mean, a rabbit scaled to 1e-6 and then viewed under 1e6 magnification looks the same as the original rabbit...
+22:14 <@matches> It's not really even worth including both images
+23:56 <@matches> One does not simply cross compile for MinGW
+23:57 <@matches> Although I must say I was bracing for it to be worse
+23:58 * matches stares in shocked amazement at NO ERROR MESSAGES
+23:58 <@matches> COULD IT BE
+23:58 <@matches> COULD I HAVE SUCCEEDED?
+23:59 < Pommers> Nope.
+23:59 <@matches> -_-
+23:59 <@matches> If we didn't need spectators I'd totally /kick you
+23:59 < Pommers> 99 commits in my assignments repo >.>
+23:59 <@matches> Pfft
+23:59 <@matches> Commit them all to IPDF
+--- Day changed Sun Oct 05 2014
+00:00 < Pommers> I can kill your percentage of lines here. That's what you asked me to do
+00:00 < Pommers> Also
+00:00 < Pommers> First
+00:00 <@matches> err:module:import_dll Library SDL2.dll (which is needed by L"Z:\\home\\sam\\Documents\\University\\2014\\ipdf\\code\\src\\ipdf") not found
+00:00 <@matches> Hmm
+00:03 <@matches> If I try link with static SDL2 everything goes to hell though :(
+00:04 <@matches> I guess I can just add SDL2.dll
+00:05 <@matches> It runs in Wine
+00:05 <@matches> Does that make it more or less likely to run under windows
+00:05 <@matches> Ah crap the Qt stuff isn't compiled in though
+00:05 <@matches> Qt is annoying
+00:05 <@matches> They appear to ask you for money if you try download their source
+00:06 <@matches> Also they don't like you using Qt4 and I really can't remember why I picked Qt4 instead of Qt5 now
+00:07 <@matches> I guess I assumed it would be better, after experiences with GNOME 2 -> GNOME 3
+00:07 <@matches> New = terrible
+00:08 <@matches> Oh dur this is what apt-get source is for
+00:10 <@matches> I will just feel a lot safer if I know that the marker can actually run the software without needing to know linux
+00:10 <@matches> Call me a Paranoid Number...
+00:10 <@matches> (Ho ho ho)
+00:11 <@matches> (This is probably a sign that it is bed time)
+00:13 < Pommers> Yeah, you should probably go to bed matches
+00:17 <@matches> What about you?
+00:18 < Pommers> I'm already in bed
+00:18 <@matches> SULIX
+00:18 <@matches> THERE IS A GOTO
+00:18 * Pommers grabs out his pitchfork
+00:20 <@matches> I only saw it because it is also outside an #ifdef and raises an "unused label" warning
+00:20 <@matches> How many others are there...
+00:24 <@matches> There is also a goto in stb_truetype.h but I'll let that one slide since sulix didn't write it
+10:01 < sulix> Gah: runs fine, no warnings in valgrind, crashed with memory corruption errors outside of valgrind.
+10:02 < sulix> This is clearly karmic retribution for the goto.
+10:25 <@matches> Ah
+10:25 <@matches> Are you compiling with or without the quadtree?
+10:25 <@matches> Because I set the VReal and PReal typedef to ParanoidNumber
+10:26 <@matches> Running in valgrind ParanoidNumber is equivelant to a double since the FE_INEXACT exception isn't raised
+10:26 <@matches> Running outside of valgrind... anything could happen
+11:31 <@matches> One does not simply compile with MinGW and have things actually work
+11:32 <@matches> Wine likes it
+11:32 <@matches> Actual windows seems to have some difficulty with OpenGL functions
+11:32 <@matches> Also thank goodness for gdb compiled for windows
+11:33 <@matches> Because "ipdf.exe has experienced an error, would you like to send Microsoft a report?"
+11:33 <@matches> Is really not helpful
+11:33 <@matches> Command prompt won't even tell you "Segmentation fault"
+11:39 <@matches> Hmm, needs more "-lopengl32" ?
+11:39 <@matches> But why weren't there "undefined reference" errors
+11:39 <@matches> So confuzled
+11:40 <@matches> I bet even if it runs it won't work due to geometry shaders or something
+11:49 <@matches> Oh dear
+11:49 <@matches> This is to do with the several thousand lines of autogenerated stuff in gl_core44.*
+11:50 <@matches> Isn't this what GLEW was supposed to be for
+11:50 <@matches> Except GLEW is ancient so nobody uses it
+11:50 <@matches> Shouldn't someone reinvent a less shitty GLEW then
+11:50 < sulix> Apparently glew works again.
+11:50 <@matches> Ah
+11:51 < sulix> I did get glew working under mingw32 yesterday, as it happens.
+11:51 <@matches> Commit please?
+11:51 <@matches> Oh right for something else :P
+11:51 <@matches> What magical incantations are required
+11:51 < sulix> Yeah. And by working, I mean compiling, not running.
+11:51 <@matches> Baha
+11:52 < sulix> (Though I think it was another bit of the code that segfaulted)
+11:52 <@matches> Why is getting OpenGL working so horrifying
+11:52 <@matches> It's supposed to be a standard
+11:52 < sulix> So the gl_core44.* file was supposed to be basically glew, but hooked into SDL.
+11:52 <@matches> It's not working on Windows though
+11:53 < sulix> Do you have OpenGL drivers on windows?
+11:53 < sulix> They're not installed by default.
+11:53 <@matches> Yeah on my desktop
+11:53 <@matches> Although I did switch to Maaxen
+11:53 < sulix> Hmmm...
+11:53 <@matches> There were other things wrong
+11:53 <@matches> I wasn't liking with -lopengl32
+11:54 <@matches> Although wine didn't seem to care
+11:54 < sulix> In theory, the glcore44 and SDL stuff should load opengl32 at runtime if needed.
+11:54 < sulix> So you shouldn't, in theory, need to link to them.
+11:54 < sulix> But that's very much "in theory".
+11:55 <@matches> I will investigate the driver situation on Maaxen
+11:55 <@matches> Urgh why can't windows just have `apt-cache search`
+11:55 <@matches> And `lspci | grep vga`
+11:55 <@matches> Lets see... "Device Manager"
+11:55 < sulix> Maaxen will almost certainly not have working GL 3+ drivers.
+11:56 <@matches> Oh it's a VM
+11:56 * matches backs away very quickly
+11:56 <@matches> Well I can't keep rebooting every time I try and fix a segfault
+11:56 <@matches> Bloody scope broke my other laptop
+11:57 <@matches> I used to have Windows XP...
+11:57 <@matches> Oh wait I smashed the hard drive open so I could draw it for an assignment
+11:58 < sulix> You should subscribe to the "if it works under wine, it's good enough" philosophy.
+11:58 * sulix has shipped things that way.
+12:00 < sulix> Anyway, the quadtree is still segfaulting when not run under valgrind by (I think) getting the video card to somehow corrupt unrelated system memory or something.
+12:00 <@matches> :S
+12:01 < sulix> It always crashes when trying to glDeleteBuffers() which is really disturbing.
+12:02 <@matches> I've noticed that when there are a lot of objects, and you kill the program, you never get the memory back ever
+12:02 <@matches> And your system stays slow
+12:02 <@matches> Which is a bit of a problem
+12:02 <@matches> Need to reboot every hour or so of testing...
+12:02 < sulix> Okay, I haven't had that happen.
+12:02 <@matches> I guess that's just fglrx amazingness
+12:03 < sulix> Guess so.
+12:03 <@matches> For example, I can run turtles_all_the_way_down.script without anything crashing but then I am left with like 20MB and when I open Iceweasel everything goes to hell
+12:03 < sulix> On the bright side, the fglrx developers are planning to get rid of the fglrx kernel module and just have their closed-source GL driver talk to the open-source kernel driver.
+12:04 <@matches> Is that... good
+12:04 < sulix> We'll see, but I can't imagine it making fglrx _worse_
+12:04 <@matches> The open source driver doesn't work that well either
+12:05 <@matches> I sense another few days trying to get X working again after an `apt-get upgrade` at some point in the future then :(
+12:08 < sulix> Don't worry, they're still in the "have meetings" phase.
+12:37 <@matches> I think the glDebug stuff is giving windows issues
+12:37 <@matches> At least running in actual windows not a VM
+12:37 <@matches> Running in a VM is not conductive to working
+12:37 <@matches> Sanity tells me to give up
+12:38 <@matches> It can do glCreateProgram though!
+12:38 <@matches> glObjectLabel seems broken
+12:39 < Pommers> http://th01.deviantart.net/fs70/PRE/i/2012/076/1/2/oh_my_glob__by_tsubasaangel-d4t0g68.jpg Oh my glOb
+12:39 <@matches> Yes
+12:40 <@matches> It would be nice if the extension manager (if you could call gl_core44 that?) used stubs instead of NULL
+12:41 <@matches> I mean for debugging
+12:41 <@matches> Then you can have it print "This function doesn't actually exist guys"
+12:41 <@matches> gdb is nicer I supose
+12:41 <@matches> In fact if I weren't trying to cross compile on linux and then reboot and test in windows this would be a lot easier
+12:58 <@matches> Ok screw this
+12:58 <@matches> I need to write a thesis
+12:58 <@matches> :(
+12:58 <@matches> But after lunch
+13:51 <@matches> http://thecodelesscode.com/case/57
+14:12 < Pommers> Lunch sounds good
+14:23 <@matches> I'm currently reading codelesscode using the excuse that the turtles tester takes a very long time to sigfpe
+14:23 <@matches> (But it sigfpe's nonetheless)
+14:24 <@matches> Can we disable sigfpe for overflow/underflow casts from double to float
+14:24 <@matches> That would make things easier
+14:24 <@matches> Well
+14:24 <@matches> Assuming that the float casts to FLT_MAX or FLT_MIN if it would underflow/overflow
+16:09 <@matches> sulix: I can no longer load anything into the document
+16:09 <@matches> Congratulations though, this means it always renders accurately...
+16:20 <@matches> Ok...
+16:20 <@matches> We now have
+16:20 <@matches> #ifdef
+16:20 <@matches> ...
+16:21 <@matches> m_count++;
+16:21 <@matches> return m_count;
+16:21 <@matches> #else
+16:21 <@matches> return m_count++;
+16:21 <@matches> #endif
+16:22 <@matches> Because I don't know if the quadtree *needs* to return an invalid array index (it doesn't even use the same array...) but over in monotree land we like our array indices to be valid
+16:24 <@matches> Now what was I doing
+16:24 <@matches> Ah, seeing if OpenGL really could do Wu lines
+16:25 <@matches> So when I say it is in my report I am not lying
+16:25 <@matches> Report...
+16:25 <@matches> The thing I'm writing
+16:25 <@matches> Write
+16:25 < Pommers> How long is the report going to be matches?
+16:25 < Pommers> And when are you going to finish it?
+16:25 <@matches> It has to be 6000 words
+16:26 <@matches> My LitReview is ~8000 ...
+16:26 <@matches> Although that might be including the SVG and postscript examples
+16:26 <@matches> I think I should take those out?
+16:26 <@matches> You'd think having a huge pre-written document would make it easier but no
+16:27 <@matches> Enabling LINE_SMOOTH leads to, of all things, SIGFPE
+18:25 <@matches> I am making a whole lot of no progress here
+18:25 <@matches> Draft due on Friday...
+18:26 <@matches> I need to produce a Design Process
+18:26 <@matches> The software wasn't so much designed as congealed
+18:27 <@matches> I forgot this is an Engineering Project not CS and therefore needs to be done in such a way that future Engineers can improve upon the work...
+18:27 * matches sobs some more
+18:27 <@matches> Rectangles and Circles don't even work anymore
+18:28 <@matches> I sacrificed them for the glory of the Bezier To Path transformations
+18:29 <@matches> Also, instead of a transformation per path, it would make more sense to use one per SVG
+18:30 <@matches> It's basically the localised coordinate approach but not as fancy as a quadtree
+18:30 <@matches> If you were building up a document one bezier at a time by drawing them, you'd have to do something fancy to make your paths
+18:31 <@matches> (Un)Fortunately we don't have an editor anyway
+18:47 <@matches> Hmm, that really needs reverse parenthesis to indicate that the word is "Unfortunately" but the "Un" is removed
+18:47 <@matches> )Un(Fortunately
+18:47 <@matches> I have invented a new gramatical construct-thing
+18:47 * matches adds it to the list of results
+--- Day changed Mon Oct 06 2014
+18:02 <@matches> So the good news is I worked out the transform, the bad news is it's yet another horrible hack
+18:03 <@matches> Which will undoubtably be extremely slow if I use Gmprat
+19:01 <@matches> It's amazing how useful a "grid.svg" that is just lines which should in theory be one pixel apart is
+19:01 <@matches> If we could draw it in a different colour it would be even more useful
+19:01 <@matches> But the clock of doom is counting down to the epsilon of time
+19:17 <@matches> A quick bit of <commenting out large parts of the shading algorithm and enabling shading anyway> later: http://szmoore.net/ipdf/fox-vector+grid.png
+19:20 <@matches> Wow that took 16 minutes
+19:20 <@matches> ... 19 if you count the last 3...
+19:20 <@matches> I'm running out of epsilons
+19:21 <@matches> If I represent the amount of time I have left on the project as a floating point number, then a single second is below the epsilon for floats, therefore each second will not affect the amount of time I have left, therefore I will never have to finish
+19:21 * matches resists the urge to verify if a single second is actually below epsilon or not
+--- Day changed Tue Oct 07 2014
+13:52 <@matches> http://ieeexplore.ieee.org.ezproxy.library.uwa.edu.au/stamp/stamp.jsp?tp=&arnumber=5577902
+13:52 <@matches> Uh oh
+13:57 < sulix> We did look at that briefly, IIRC, but ignored it because it was only integers, I think.
+16:05 <@matches> Yeah, although a rational is just two integers
+16:05 <@matches> But too late now
+16:05 <@matches> I am not making progress
+16:05 <@matches> I have deleted words
+16:05 <@matches> That is not progress
+16:05 <@matches> (I had 8000 words, I require 6000 words...)
+16:06 <@matches> I should probably get some performance tests done, but every time I try there ends up being something I have to code first
+17:25 <@matches> I have a somewhat less awful explanation of number representations that still manages to carefully not actually define a number
+17:26 <@matches> I wonder if I need a citation though
+17:28 <@matches> Does it classify as "blindingly obvious" or "known since the dawn of time" that you can write numbers as "\sum_{i=-\infty}^{\infty} d_i B^i" where "d_i" and B are also numbers (it's so meta)
+17:28 <@matches> You're the maths guy, surely there is a paper
+17:29 <@matches> If it's blindingly obvious, I probably shouldn't state it, so I guess it's not blindingly obvious...
+17:29 <@matches> But on the other hand it's just a fancy way of talking about what you learn in primary school...
+17:43 <@matches> http://thecodelesscode.com/case/137
+17:50 <@matches> Dear goodness it's hideous
+20:08 < sulix> matches: It's actually kind-of more complicated than that.
+20:08 < sulix> You might find it interesting to look up Cantor's diagonal argument.
+20:09 < sulix> (Which is technically a proof that the size of the set of rationals is different to the size of the set of reals, but it uses the idea of infinite sequences of digits)
+20:09 < sulix> For example \sum_{i=-\infty}^{\infty} d_i B^i actually gives you the reals, not the rationals.
+20:10 < sulix> But you have to be super-careful about what "infinity" is.
+21:11 <@matches> Did I say Rational
+21:11 <@matches> I thought I said real
+21:11 <@matches> No I said "number"
+21:11 <@matches> Wel
+21:12 <@matches> I will look up Cantor's diagonal bishop
+21:12 <@matches> I mean argument
+21:13 <@matches> But basically anything you are going to represent on a computer is either written as that sum or based on components that are
+21:13 <@matches> A float is like changing where the "0" is
+21:13 <@matches> An integer is starting the sum from zero
+21:14 <@matches> An arbitrary integer uses the same sum, but the digits are smaller integers
+21:14 <@matches> (In another base, and then the base of the arbitrary integer is 2^{N})
+21:14 <@matches> I don't know how much I am expected to explain this sort of thing
+21:15 <@matches> And of course a rational is two integers written using the sum
+21:15 <@matches> Infinity is...
+21:16 <@matches> Yeah
+21:17 <@matches> Screw that, if people don't like me writing a number as an infinite sequence of digits I will point out the name of my major (and then hope they don't ask why I am doing a project about numbers considering my major)
+21:17 <@matches> Other things I don't really want to include in my report are the 4 operations for floats
+21:18 <@matches> But I feel like some sort of explanation of why "(x - view.x) / view.w" totally dies
+21:18 <@matches> Is needed
+21:18 <@matches> I'll commit "grid.svg", you might find it useful
+21:18 < sulix> "If view.w is zero, you're in trouble."
+21:18 <@matches> Yeah
+21:19 < sulix> I'm sure grid.svg will lead me to much confusion!
+21:19 <@matches> No it's really cool
+21:19 <@matches> It is a 1px by 1px grid
+21:19 < sulix> But how will I know where I am?
+21:19 <@matches> So, because we add SVGs scaled to the view, whenever you insert it the view should be black
+21:19 <@matches> Ah
+21:20 <@matches> But if you zoom in, you can resolve the lines that are 1px apart in the original view
+21:20 * sulix really needs to get on that "adding SVGs scaled to the view" thing.
+21:21 <@matches> So, if you add it scaled to the view at some point and you *don't* see total blackness, it's showing you the locations in the document that can be represented when scaled to the view
+21:21 <@matches> ... If that makes any sense
+21:22 < sulix> Ah.... that's cool.
+21:22 <@matches> For example using single precision, at {5,5,1e-6,1e-6} you only get 4 lines (and also, the distance between the lines is the amount you need to move the mouse in order to translate)
+21:22 <@matches> Yeah, and hopefully it will be good for my bounds measurement test
+21:23 <@matches> I know it's a shitty measure but it's better than just saying "This picture looks funny!"
+21:23 <@matches> "This graph indicates how funny a picture will look"
+21:23 <@matches> I feel like graphs make things *look* more legitimate even if they aren't actually
+--- Day changed Wed Oct 08 2014
+12:48 <@matches> Writing up these "results" it really doesn't feel like I've achieved much of consequence...
+12:49 <@matches> It feels like I spent 9.5 months not understanding anything and then stumbled accross the blindingly obvious solution that should have taken a week.
+12:50 <@matches> Then again, we were talking about local vs global coordinate systems right at the start...
+12:51 <@matches> Anyway all I've done is introduce a local coordinate system which is expressed with arbitrary precision relative to the global coordinate system.
+12:51 <@matches> The only advantage I can see with the quadtree is that it clips things
+12:51 <@matches> Which is admittedly a really huge advantage
+12:51 <@matches> Since GMP rationals grow exponentially...
+12:51 <@matches> It's a very big time constant thanks to GCD though
+12:52 <@matches> I wish shading worked because these figures would look so much more awesome with colour
+12:57 <@matches> I really hate that I can't just include a pixel perfect copy of the png figures
+12:58 <@matches> There's a massive amount of antialiasing going on
+13:01 <@matches> ...
+13:01 <@matches> I've been writing too much LaTeX when I start using '%' as comment in our debug script
+22:57 <@matches> I must say, the one place where PDF's magical blurring of things makes them look better is the figures from back when shading almost worked
+22:57 < Pommers> LaTeX <3
+22:57 <@matches> It's not even something you can control in LaTeX
+22:58 <@matches> The PDF viewer will do whatever the hell it wants
+22:58 <@matches> Although I've realised that the screenshot tool in debian is also adding antialiasing of its own
+22:59 <@matches> So at some point between the draft thesis and the final thesis I guess I need to go through IPDF's own screenshot function
+22:59 <@matches> szmoore.net/ipdf/sam/presentation/presentation.pdf
+23:00 <@matches> The presentation with a big gap where I in theory explain Rational numbers, arbitrary precision integers, the GMP library, Why we only care about the bounds of beziers, the different ways you can apply bounds transforms to get better results, and all the graphs that I am going to make that don't exist yet
+23:00 < Pommers> Oh yeah, did you see the Github pack that I posted in #UCC last night?
+23:00 <@matches> Well no I was too busy crying myself to sleep
+23:01 <@matches> Thesis' are harder than regular assignments mainly because there isn't a set goal
+23:01 <@matches> You have to set your own goal
+23:01 < Pommers> https://education.github.com/pack
+23:02 <@matches> And it tends to end up as not actually thinking about the goal until the end and then realising that you didn't meet it
+23:02 <@matches> Huh what's that
+23:03 <@matches> I see many "cloud" and "crowdsourcing" references and "$" signs
+23:03 < Pommers> All free stuff for students
+23:04 <@matches> Cool
+23:04 <@matches> Goodnight
+23:04 < Pommers> Night
+23:06 <@matches> Hmm, I should probably have removed the Western Australian Marine Science Institution logo from that presentation template I stole
+23:07 <@matches> Or it will haunt my dreams
+23:07 < Pommers> Probably. Whena re you presenting?
+23:10 < sulix> I'm just disappointed that your presentation isn't "CONFIDENTIAL" like some of th others on the list.
+23:17 < Pommers> Nice presentation
+--- Day changed Thu Oct 09 2014
+09:22 <@matches> I'm kind of worried that my live demo takes about 10 minutes to run
+09:23 <@matches> Also there are so many things that don't work
+09:23 <@matches> Like actually loading an SVG with arbitrary precision
+09:24 <@matches> The bottleneck in the live demo seems to be the shear number of objects in it though
+09:24 <@matches> Maybe I just need fewer turtles
+09:25 <@matches> Also is Rowan in Perth
+09:25 <@matches> I think he might be supposed to mark it
+09:26 <@matches> Although they listed Tim and not Rowan on the supervisors list
+09:26 <@matches> :S(
+10:43 < sulix> Rowan is here.
+10:50 <@matches> Excellent
+10:50 <@matches> "Record yourself presenting as practice" they said "It will make you feel more confident" they said
+10:51 <@matches> They never mentioned that it will make you realise just how stupid your voice sounds, just how boring you are at presenting, and just how many things you don't have time to cover
+10:51 <@matches> Well that last one I guess they did mention
+10:51 <@matches> They didn't mention the crushing despair...
+10:59 * sulix is in desperate need for a suitably punny title for his seminar.
+11:17 <@matches> I didn't use a pun
+11:17 <@matches> I used a very mundane title
+11:17 <@matches> Which is probably why I am on last...
+11:17 <@matches> Whoops I'm not supposed to give Pommers hints as to when it is, or he might show up
+11:22 <@matches> I make such a leap in my presentation
+11:22 <@matches> I go from "Look this PDF viewer has a zoom limit of 800%" to "The standards specify IEEE-754 floats"
+11:22 <@matches> Quietly ignoring that you really should be able to go further than 800% with IEEE-754 floats
+11:22 < sulix> Sounds good!
+11:23 <@matches> I guess if someone calls me out I have the backup "Look, I can zoom further but then X crashes"
+11:23 <@matches> "What a shame, looks like I can't do the rest of the presentation!"
+11:23 <@matches> Also
+11:23 <@matches> Where am I supposed to mention the collaborative aspect
+11:24 < sulix> Just point at me and go: "the bugs are all his fault".
+11:24 <@matches> Currently it is in "References"
+11:24 <@matches> - David did things
+11:24 <@matches> - Go see David talk about Quadtrees
+11:25 < sulix> - He used a goto, get the pitchforks.
+11:27 <@matches> "So I'm going to do some live demos now"
+11:27 <@matches> "And as you can see, if I zoom in
+11:27 <@matches> "Oh fuck SIGFPE"
+11:29 <@matches> Also, if you have any time to set up some of the performance tests that would be kind of awesome
+11:29 <@matches> Since we both need them, but I appear to need them sooner :P
+11:30 <@matches> I guess I can leave them out and just have the spots in the draft where I want them to go, but I'm getting exponentially nervous about them
+11:30 <@matches> We can compile with MPFR C++ mpreal now
+11:30 <@matches> You can set the precision, but it appears to be fixed
+11:30 < sulix> Oooh...
+11:31 < sulix> Is it faster that gmprat?
+11:31 <@matches> I don't know yet
+11:31 <@matches> That's one of the performance tests I want to do
+11:32 <@matches> I think mpreal with a fancy algorithm for how you increase precision *might* beat GMP rat
+11:32 < sulix> So do I.
+11:32 <@matches> The problem is, if you use a fixed precision then you can always choose some view bounds for which things aren't rendered correctly
+11:32 <@matches> Also I do not have time to implement a fancy algorithm for how you increase precision...
+11:33 <@matches> I feel like I have achieved half of the project
+11:33 <@matches> Rather than the whole thing
+11:33 <@matches> :S
+11:34 <@matches> I do suspect that if you just go "I will use a 1000 bits" for mpreal, then for ranges where you don't need that precision you're wasting a lot of time
+11:36 < sulix> You can't do "I'll use n*zoom bits" or something?
+11:37 <@matches> I think I would be better off analysing the implementation that works rather than implementing the implementation that might work better...
+11:37 <@matches> I guess there's still some time *after* the presentation
+11:44 <@matches> sulix: People are getting lunch at the tav because it's Pommer's birthday, you should come
+11:45 <@matches> I went in the tav once and didn't die
+11:45 <@matches> (Not counting the quiz night, at which I'm pretty sure I did die)
+11:45 < sulix> I guess I could eat some lunch.
+18:32 <@matches> I have pushed the horrible python/debugscript combo
+18:32 <@matches> Featuring totally inconsistent naming conventions in the python scripts
+18:36 <@matches> I do recommend you learn how to use python for horrible hacky scripts like this because it is about to save my life
+18:38 <@matches> Maybe you can write one that demonstrates the flaw by zooming in on an intersection :P
+18:39 <@matches> Hmm
+18:39 <@matches> I wonder if the use of "cin" and "stdout" for input to the DebugScript and output from the DebugScript does anything wierd
+18:40 <@matches> Conshmistency
+18:40 * matches goes into super draft mode
+--- Log closed Thu Oct 09 18:40:43 2014
+--- Log opened Thu Oct 09 18:41:03 2014
+18:41 -!- Irssi: #ipdf: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
+18:41 -!- Irssi: Join to #ipdf was synced in 0 secs
+18:41 < matches> (You might say something important that I overlooked I guess?)
+19:47 < sulix> Okay, so the grid is totally breaking the quadtree.
+19:47 < sulix> Because it has lines that coincide _exactly_ with the edge of the quadtree.
+19:48 < sulix> So the quadtree doesn't know what nodes to put them in.
+19:48 < sulix> Will there be two copies of them? Will there be none?
+19:48 < sulix> (Also you broke debugscript reading from a file, but I've fixed it and will push shortly)
+19:49 < sulix> (The power of iostreams!)
+20:00 < sulix> Okay, so not solving both the x and y cubics for vertical/horizontal lines didn't help.
+20:00 < sulix> (On the bright side, it doesn't seem to have broken anything too significant)
+20:19 < sulix> Interesting things from Knuth.
+20:20 < sulix> - "The origins of floating-point notation can be traced back to Babylonian mathematicians ~1800 BC" (who used bas 60, but didn't explicitly state the exponent)
+20:30 < sulix> - Bigints have O(N) addition/subtraction, multiplication/division O(N^2)
+20:32 < sulix> - Knuth writes the idea of "positional number systems" as (...a_3 a_2 a_1 a_0 . a_{-1} a_{-2} ...)_b = ... + a_3 b^3 + a_2 b^2 + a_1 b^1 + a_0 + a_{-1} b^{-1} + a_{-2} b^{-2} +...
+20:32 < sulix> i.e. neatly using "..." to avoid ever writing infinity.
+20:33 < sulix> He also uses the term "radix point" to mean decimal/binary/whatever point.
+20:33 < sulix> (and then gives about four pages of history of ancient civilisations counting)
+20:35 < sulix> There is then some discussion of negative and complex bases and the different ways of representing negatives.
+20:45 < sulix> - The "ulp" is a unit of floating-point error equal to one unit in the last place of the fraction (mantissa) part of a float.
+20:45 < sulix> Floating point operations are correct to within half an ulp.
+20:46 < sulix> The associative law for multiplication is holds within about 2 ulps.
+20:47 < sulix> (Provided no exponent overflow or underflow occurs)
+20:47 < matches> Cool
+20:47 < matches> Well, I've got a graph showing that mpfr reals with 6 bits of precision are (somewhat unsurprisingly) worse than either doubles or singles
+20:47 < matches> Also FPS
+20:47 < matches> FPS goes all over the place with everything
+20:48 < sulix> ulps are only valid for normalized floats.
+20:48 < sulix> Yeah, FPS is a totally terrible unit.
+20:49 < matches> SPF might be better
+20:49 < sulix> You should try for ms/frame, but even that will probably be a bit broken.
+20:50 < matches> FPS is in the code now, it can change later
+20:50 < matches> "This wobbly line is slightly lower than this one, indicating WORSE"
+20:50 < matches> Ok, what other performance tests did I need
+20:51 < matches> Oh yeah, ones that actually alter the view with things in it, as opposed to ones that import an svg at a fixed scale
+20:53 < matches> Man explaining how all these tests are actually valid will be a pain
+22:34 < matches> I am too tired to work out how to skip the tests that are essentially pointless for various transformation settings
+22:35 < matches> I guess they'll just be in the figures as straight lines thus proving my point
+22:35 < matches> (Or confusing the figure)
+22:35 < matches> The fact that there is a graph should be good enough for a draft
+22:36 < matches> Yes, they are straight lines, thus proving my point
+22:36 < matches> (Actually they just make the figure confusing)
+22:38 < matches> I think what I've actually invented is just a very convoluted way to demonstrate things that everyone has known since Knuth
+22:39 < matches> And less of a useful SVG viewer
+22:40 < matches> Either that or an epileptic siezure machine
+22:41 < matches> So many flashes
+22:42 < matches> Hmm it looks like the grid cumulated error is really not as noticable with the grid
+22:42 < matches> s/grid//
+22:42 < matches> s//grid/
+22:42 < matches> skdfjhasdf
+22:50 * matches prepares the "hairy fox" hypothesis
+22:58 < sulix> No relation to the hairy ball theorem? http://en.wikipedia.org/wiki/Hairy_ball_theorem
+23:07 < matches> That is... an unfortunate name
+23:08 < matches> Oh, it turns out to produce the hairy fox you need to do a lot of cumulative transforms (dur)
+23:08 < matches> Not just two really big transforms
+23:08 < matches> So the ulp thing is useful
+23:08 < matches> For understanding the rounding errors for small widths
+23:10 < matches> The subtraction of x - v_x gives you up to 1 ulp and then the division by 1e-6 increases it to 1e6 ulp and if 1 ulp \approx 5e-5 or more, suddenly it is half your view width
+23:10 < matches> Increasing the exponent of (v_x, v_y) will double the ulp
+23:10 < matches> So for the same width you get half the precision
+23:20 < matches> Hairy fox syndrome appears to work best if you use pxzoom
+23:20 < matches> I won't question it...
+23:41 < matches> Yeah you have to try really hard to get the hairy fox
+23:42 < matches> My greatest fear is that someone will realise to achieve these "errors" by using the mouse (which is what it simulates) it would take you several days of determined scrolling
+23:42 < matches> Wow it makes interesting patterns in the grid though
+23:43 < matches> It affects both the position and the dimensions of the lines so your grid gradually disappears
+23:55 < sulix> pxzoom will have more error because it randomly calls expf() on its input, so you've got some dodgy approximation of 'e' messing things up.
+--- Day changed Fri Oct 10 2014
+00:16 < matches> Well that would have been nice to know before I ran a 20 minute test
+00:16 < matches> I thought it was equivelant to using the mouse
+00:17 < matches> Oh well
+00:17 < matches> The test still proves the point
+00:17 < matches> Even though there's the dodgy approximation of e going on
+00:17 < matches> GMP rationals give a very small error
+00:17 < matches> Cumulative transforms give a very large error
+00:17 < matches> Direct transforms give an increasing error and also have the issue with precision
+00:18 < matches> I should probably distinguish between error and precision a bit more
+00:18 < matches> We want precision and we don't want error
+00:19 < matches> So the GMP rationals applied to Path bounds pass both tests
+00:19 < matches> Whereas the other two approaches pass one test and fail the other
+00:19 < matches> Or fail both
+00:19 < matches> s/two/three/however many I had I lost count
+00:45 < matches> New draft is pushed
+00:45 < matches> Enjoy the graphs
+00:46 < matches> Try not to have too much fun questioning the validity of the results, they are all that's keeping me going
+00:46 < matches> I wish path-rat gave no error
+00:46 < Pommers> When do you need iPDF working on windows/
+00:47 < matches> It's not really a priority
+00:48 < matches> I'll probably try and get it working after the final report is due
+00:48 < matches> I will link to it anyway see
+00:49 < matches> The odds of anyone actually following the link are slim
+00:49 < matches> If it doesn't work I'll tell people to run it in wine
+09:33 < sulix> Those are damn nice graphs!
+09:34 < sulix> I take it there's no 'rat' measurement because it's too slow.
+09:35 < sulix> pxzoom is actually the same as the mouse, the mouse still does random expf() calls to work out the zoom amount.
+09:35 < sulix> (I thought I'd changed that, but apparently not)
+09:37 < sulix> Also, thank god we don't use 'sin': http://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
+09:38 < matches> There should be a rat measurement?
+09:38 < matches> In the loss of precision graph, the path-rat program loses no precision
+09:39 < matches> But it's underneath all the other implementations that also lose no precision
+09:39 < matches> They are all on the same line...
+09:39 < matches> In the accumulated error graph, it is down near 10^{-2}
+09:39 < matches> I'm not sure why it isn't at zero...
+09:39 < matches> I'm just going to point vaguely at the expf function
+09:41 < matches> I'll probably add MPFR with 10 bits (half floats...) and X bits where X is a lot
+09:41 < matches> But not today
+09:41 < matches> My draft fleshes out a lot more when I uncomment things...
+09:41 < matches> I mean the idea of commenting them was that they'd be removed
+09:42 < matches> Also there are two sources of error in the Direct transformation
+09:42 < matches> I need to think about whether they are both equally bad or one is worse
+09:42 < matches> You need to apply the inverse view transformation to express the svg in document space
+09:43 < matches> *Then* you apply the view transformation to render it
+09:43 < matches> Either of those could be the one that breaks it, but I suspect the rendering transformation is worse
+09:46 < matches> Maybe some of the ipython figures don't have path-rat in them, I forget
+11:40 * sulix sighs.
+11:40 < sulix> cssubmit requires my abstract to be in ASCII, so the é in Bézier means cssubmit rejects it.
+11:51 < matches> Haha
+11:51 < matches> I got excited when Rowan said "Looks great to me" and then I realised he was talking about your abstract not my draft... :P
+11:52 < matches> That would have been impressive speed reading
+11:52 < matches> My abstract is sort of really terrible
+11:52 < matches> It clings to the whole "document formats" thing that the project was alledgedly about but has moved well away from
+11:53 < matches> It also promises that I'll compare arbitrary precision floats as well, so I guess I better hack something together with those...
+11:53 < matches> Maybe a graph showing how you can increase the precision but then the FPS goes down
+11:54 < sulix> That'd ve really good, actually.
+11:55 < matches> Yeah I think I did something similar for CQM once
+12:06 < matches> Hmm, I can probably hack together a CPU renderer only binary for windows
+12:06 < matches> He says, ignoring the tendency for the CPU renderer to shit itself and die
+12:07 < matches> It'd be a Cool Feature for it to fall back to the CPU renderer instead of just segfaulting
+12:08 < matches> Falling back to the backup renderer always sounds impressive
+12:08 < matches> Everyone loved it when HTR did that
+12:08 < matches> (And then I realised the "backup" renderer was actually better)
+12:17 < sulix> I've fixed (hopefully) the OpenGL version detection. It should now Fatal() when the driver doesn't have needed extensions.
+13:43 < sulix> Excellent: the é has gone through!
+--- Day changed Sat Oct 11 2014
+10:02 * sulix -> Perth Games Festival
+14:52 < Pommers> Is it good there?
+18:22 < matches> The "fix" to OpenGL version detection now means I don't have a valid version of OpenGL.
+18:23 < matches> It was working perfectly fine before
+18:24 * matches -> s/Fatal/Error/ and hopes it still works anyway
+18:25 < matches> Should you be setting the GL minor version to 1 and then failing if it isn't 3
+18:26 < matches> I am confused how this even works
+18:26 < matches> My OpenGL version is apparently 3.1 and the if statement apparently checks "IsVersion" 3.2
+18:26 < matches> And then says "We want 3.3"
+18:28 < matches> I get no error if I set the minor version attribute to 3
+18:28 < matches> So I take it we required 3.3 functions but were specifying that we only needed 3.1 or something
+18:28 < matches> And somehow the 3.3 functions still worked?
+18:29 < matches> Anyway, I'm in favour of the "Instead of terminating the program, report an error and then see whether it will crash anyway" approach
+18:29 < matches> If it *does* crash, then at least we warned them
+18:29 < matches> If it doesn't crash, hey it's running! Everyone wins!
+18:43 < matches> Using integer indices for different types of Real seemed like *such* a good idea at the time
+18:43 < matches> And then there was the ability to have up to three different types of Real...
+18:45 < matches> -std=c++11 -g -Wall -Werror -Wshadow -pedantic -rdynamic -I../contrib/include/SDL2 -I`pwd` -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -Itests -I. -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DREALTYPE=1 -DQUADTREE_DISABLED -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DTRANSFORM_OBJECTS_NOT_VIEW -DTRANSFORM_BEZIERS_TO_PATH -DPATHREAL=Gmprat -c -MMD
+18:45 < matches> Truly our Makefile is a thing of beauty
+18:47 < matches> It's so beautiful that there is now a Python function to invoke it with different arguments
+18:57 * matches stabs indentation errors
+18:59 < matches> "Unindent does not match any outer indentation level" What the fuck
+18:59 < matches> What the hell is an undindent
+18:59 < matches> It is pointing at a ':' character
+19:00 < matches> Oh
+19:00 < matches> It's because I copied it from ipython which magically converts your tabs to spaces
+19:00 < matches> And then tried to add things to it indenting with tabs
+19:01 < matches> I think it's a conspiracy to make the tabs vs spaces war even worse
+19:02 < matches> Now people have no option to compromise
+19:02 < matches> Or, in my case, use tabs where we bloody well typed tabs in the first place
+19:35 < matches> My clock says it's 3am, that's about how I feel...
+19:42 < matches> "Just use MPFR" is looking more and more likely to be the conclusion
+19:42 < matches> Wait...
+19:42 * matches eats hat
+19:43 < matches> Well, GMP rationals applied to path bounds is faster than mpfr with 1024 bits applied directly
+19:43 < matches> That's probably not a fair test though
+--- Day changed Sun Oct 12 2014
+14:53 < matches> Setting up the performance tests is a real pain if you want to actually include the really slow methods
+14:53 < matches> Well, restarting them can be painful
+14:54 < matches> Which means if you screw them up...
+14:58 < matches> Placing a limit of 30s per frame was perhaps a bit too generous
+15:05 < Pommers> THis is why you should use a build server
+15:05 < matches> Yeah except that's more effort to set up than it would save
+15:05 < matches> We even have one
+15:06 < matches> Motsugo could potentially run all these tests
+15:06 < matches> But it has to use a CPU renderer and is therefore shit
+15:06 < matches> Seeing the results in real time is a huge advantage
+15:06 * Pommers really needs to set up a proper Jenkins set up for UCC
+15:06 < matches> Oh, I'm not allowed to use my own laptop in the conference
+15:07 < matches> So if you want to fix the MinGW build for me... :P
+15:07 < matches> I'll see if sulix's magical GL version changes fixed anything later
+15:08 < matches> Ah
+15:08 < Pommers> I can give it a shot tonight. If you proof read some stuff for me right now
+15:08 < matches> I'm querying the FPS once the view has stopped being scaled
+15:08 < matches> Ok
+15:09 < matches> (I should record performance in the python script I think)
+15:09 < Pommers> tonight means after I finish work that is
+15:09 < matches> So 3am?
+15:09 < Pommers> Nah, like 6.30ish
+15:09 < matches> Honestly I'm probably just going to run a video
+15:10 < matches> But it'd be nice to say "Here's the binary with which you can reproduce the results"
+15:18 < matches> It's probably going to need to run on a Windows 95 presentation PC or something
+15:19 < matches> It has geometry shaders so it's probably beyond hope that it would work
+15:19 < matches> Hmm, do I need to prepare a response do a "Why didn't you just use <insert name of a language that isn't C++ here>"
+15:20 < matches> I seem to get that question every time I use C++ for anything
+15:20 < matches> Or alternately "Why didn't you use boost"
+16:19 < matches> sulix: What black magic should I do if I want to include the debug font in a screenshot...
+16:45 * matches resorts to ffmpeg instead
+16:45 < matches> With the disadvantage that 1 frame in a screen grap != 1 frame in the demo :(
+16:45 < matches> grap
+16:45 < matches> grape
+16:45 < matches> grab
+--- Day changed Tue Oct 14 2014
+00:17 -!- bobgeorge33 is now known as Pommers
+13:34 < matches> My presentation is tonight
+13:34 < matches> Looks like Tim is back just in time to watch it!
+14:50 < sulix> In order to break things at exactly the wrong moment, IPDF has a profiler now.
+14:50 < sulix> It dumps the time spent in various functions at the end of each frame.
+15:10 < matches> That's pretty awesome
+15:11 < matches> Ok, time to test this pdf in adobe reader...
+15:11 < matches> And scream if it doesn't work
+15:19 * matches screams
+15:20 < sulix> Oh dear...
+15:20 < sulix> The power of adobe!
+15:24 < matches> I bet the videos don't work either
+15:26 < sulix> What format are they in?
+15:26 < matches> mkv
+15:26 < matches> They work
+15:26 < matches> I guess it was too much to expect pdflatex to produce a valid pdf
+15:35 < Pommers> Latex PDF? Got it working yet?
+15:55 < matches> No
+15:56 < matches> I have narrowed it down to
+15:56 < matches> "Cannot include graphics in slides"
+15:56 < matches> Which will make for an amazing presentation
+15:58 < matches> Ah
+15:58 < matches> Adobe doesn't support including pdfs within pdfs
+15:58 < sulix> What!?
+15:59 < sulix> Man, I've included pdfs within pdfs in pretty much every assignment I've submitted ever.
+15:59 < matches> I don't know
+15:59 < matches> That's the first place it shits itself
+15:59 * sulix ponders whether or not this may have affected marks.
+15:59 < matches> Debugging by repeatedly commentint out bits of TeX and recompiling is not very efficient and/or fun
+16:00 < sulix> Worst comes to the worst, take screenshots of all of your slides, I guess...
+16:00 < sulix> (Or download a windows binary for evince/etc and put that on the thumb drive)
+16:02 < matches> Yeah I'm supposed to be registering now
+16:25 < Pommers> matches: Send me the tex source and I'll try
+--- Day changed Wed Oct 15 2014
+10:38 < matches> Frames compiled it for me on Windows, so I survived
+10:40 < Pommers> Yeah. That's what I was going to do
+10:40 * Pommers should really set up that build server properly
+13:18 < matches> I might have promised a Windows version in the talk...
+13:18 < matches> Also saving, loading
+13:18 < matches> And...
+13:18 < matches> Shading
+16:05 < matches> I wonder if I can hack in a "draw" mode...
+16:05 < matches> Now that the conference is over, ANYTHING IS POSSIBLE
+16:06 < matches> (Except there's only two weeks left)
+16:06 < matches> ... < 2 weeks left
+--- Day changed Sun Oct 19 2014
+14:48 < sulix> Far out: I'm looking up some IEEE GPU stuff, and Google keeps pointing me to your lit review.
+17:01 < matches> :S
+17:02 < matches> I need to muster the courage to write more of my report
+17:02 < matches> So tired
+--- Day changed Mon Oct 20 2014
+22:45 < sulix> So it turns out that the crazy multithreadedness of the control panel totally bollockses up the profiler.
+22:46 < sulix> Which explains the random crashing due to "impossible things happening" like "functions returning before their parents do".
+22:49 < sulix> The everything gets bollocksed when adding text bug is also fixed.
+22:50 < sulix> The magical invisible turtles bug remains.
+22:51 * sulix wonders if he should see the teenage mutant ninja turtles movie for an explaination.
+23:48 < sulix> For reasons unknown, I'm generating a lot of quadtree overlays with the exact same objects in them.
+23:48 < sulix> By which I mean the same {object_begin, object_end} pairs.
+23:49 < sulix> So lots of things are being rendered ~40 times, and many things aren't being rendered at all.
+23:51 < sulix> Actually, never mind, I'm just printing out the wrong thing in my debug statement.
+--- Day changed Tue Oct 21 2014
+00:48 * sulix has a lot of writing to do tommorrow.
+00:48 < sulix> By which I mean today.
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au