+--- Day changed Thu Apr 24 2014
+14:40 -!- You're now known as notmatches
+14:40 -!- You're now known as matches
+14:41 <@matches> Ok, less spammy channel time
+14:41 -!- mode/#ipdf [+b m:matches!*@*] by matches
+14:41 <@matches> Spam
+14:41 <@matches> Dammit
+14:42 -!- mode/#ipdf [-o matches] by matches
+14:42 < matches> Spam
+14:43 < matches> Yay
+14:43 < matches> ... this will all appear in the next git commit won't it -_-
+14:52 -!- You're now known as notmatches
+14:52 -!- You're now known as matches
+--- Day changed Sat Apr 26 2014
+00:45 -!- mode/#ipdf [+o matches] by OperServ
+00:46 <@matches> Incoming "at least it is self consistent in its wrongness" floating point conversion
+00:48 -!- mode/#ipdf [-o matches] by matches
+00:48 < matches> Still can't talk
+00:48 < matches> Excellent
+--- Day changed Sun Apr 27 2014
+17:10 < sulix> I finally got ipdf working on my laptop again by porting everything to OpenGL 3.1.
+17:10 < sulix> I'm so sorry about how ugly the code now is, by the way.
+18:04 -!- mode/#ipdf [+o matches] by OperServ
+18:05 < Pommers> You know what a really good feature for a PDF reader would be? The ability to have it completely borderless without menus, so you just see the page!
+18:06 <@matches> Wat
+18:06 <@matches> Well we've got that
+18:06 <@matches> We just can't read pdfs
+18:07 <@matches> Did you get much done not going to the cleanup?
+18:07 <@matches> I managed to transfer some dust from one location to another location, and then the wind blew it back in my face
+18:08 <@matches> Then I looked at Frames' proposal and despaired at how much it is actually complete and has words in it
+18:08 <@matches> I think he's onto something with his plan of actually writing things
+18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf
+18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf but the df stands for df
+18:14 -!- matches changed the topic of #ipdf to: Sort of
+18:15 <@matches> I need a script to auto mute me...
+18:15 < sulix> I spent basically all of today on that one commit.
+18:15 -!- mode/#ipdf [-o matches] by matches
+18:15 -!- mode/#ipdf [+o matches] by OperServ
+18:15 < sulix> Whether or not that was more useful than the cleanup remains to be seen.
+18:16 <@matches> I should look at it I guess :P
+18:16 < sulix> It compiles*
+18:16 < sulix> *but has lots of warnings.
+18:16 <@matches> It can't be worse than my tester that converts floats to floats
+18:17 < sulix> I'm pretty certain it can be and is worse.
+18:17 <@matches> However I've realised I kind of actually do need to be able to do that
+18:17 <@matches> Woah 3k+ lines
+18:17 <@matches> * 4k+ lines
+18:18 < sulix> Most of it was autogenerated, but still...
+18:18 * matches weeps for OpenGL 1
+18:18 < sulix> You don't realise how much you miss it until it's gone...
+18:19 <@matches> So what does all this stuff actually do
+18:19 <@matches> Because I could see rectangles and things just fine without it
+18:19 < sulix> Exactly the same thing as before but it works on my laptop now.
+18:19 <@matches> I see a shader program, that's obviously good
+18:20 <@matches> Actually I see code for a shader but no shader yet
+18:20 < sulix> The shaders are all #defines, I'm afraid.
+18:22 <@matches> What was wrong with your laptop?
+18:23 < sulix> It doesn't support the OpenGL compatibility mode, so --- as I was using the OpenGL 3.1 feature of "primitive restart", I had to code the entire thing in OpenGL 3.1
+18:23 < sulix> On the bright side, this paves the way for doing things like getting the GPU to use doubles.
+18:26 <@matches> Ooh
+18:27 < sulix> (also halves)
+18:27 < sulix> (halfs?)
+18:27 <@matches> Do GPUs use IEEE floats? I had a reference that seemed to be complaining they didn't
+18:27 <@matches> Although it was circa 2007
+18:28 < sulix> I don't think that there's a requirement that they internally use them, but they do read and write them.
+18:28 < sulix> A bit like how x86 processors use(d) 80 bit reals internally and rounded when reading/writing to memory.
+18:28 <@matches> Do halves have a different mantissa encoding
+18:29 <@matches> The examples given on wikipedia seem wrong
+18:30 < sulix> I think this is the canonical description: http://www.opengl.org/registry/specs/NV/half_float.txt
+18:33 <@matches> That would be before IEEE specified half (binary16) but its the same summation for the mantissa anyway
+18:33 <@matches> binary16 is (briefly) in the 2008 revised 754
+18:34 <@matches> So I think wikipedia is giving a wrong example, but I'm not confident enough to go and change wikipedia
+18:35 <@matches> Also I just realised my conversion of the mantissa to a Real is horrible
+18:35 <@matches> Oh well, it can get fixed later
+18:36 <@matches> Hopefully I can finish my fluid mechanics assignment quick enough to actually work on my progress report / proposal / thing
+18:36 <@matches> (Hah)
+18:36 -!- mode/#ipdf [-o matches] by matches
+18:37 < sulix> Yeah, I'm going to see how much Lit review I can write for tomorrow. :/
+--- Day changed Mon Apr 28 2014
+22:06 -!- mode/#ipdf [+o matches] by OperServ
+22:10 <@matches> Must find motivation to work on Lit Review at 10pm...
+--- Day changed Tue Apr 29 2014
+10:06 <@matches> Must find motivation to work on Lit Review at 10am...
+--- Day changed Wed Apr 30 2014
+13:04 <@matches> I wanted to rasterise a vector image so I could compare them at the same scale ("These look the same!") and zoomed ("This one looks crappier!)
+13:04 <@matches> But because vector graphics editor/viewers don't use pixels as units but they do when they export to a bitmap, it's difficult to actually get them to look the same
+13:04 <@matches> Before scaling
+13:05 <@matches> I guess a screenshot tool might be the best way
+13:06 <@matches> I don't know if I need to do this really
+13:07 <@matches> I guess Mechanical and Chemical engineers marking this will probably benefit from having an example
+13:07 <@matches> Doesn't everyone know the difference between vector and raster graphics
+13:07 <@matches> Where was that paper that had tux vector and rasterised
+13:10 <@matches> Ah, worth2003xr.pdf
+13:11 <@matches> If it's in a paper I guess it can go in a Lit Review
+13:11 <@matches> At least until I have something better
+13:15 <@matches> Kind of ironic that the image I am using was actually scanned first as a bitmap and then converted to vector using Trace Bitmap
+13:57 <@matches> Ah, it's actually impossible to get it to be exactly the same, because even taking a screenshot on my own screen it will then be different depending on the display of whoever reads the digital pdf
+13:57 <@matches> Oh well
+13:58 <@matches> I suppose "It looks shittier" will have to suffice without trying to make them look exactly the same before scaling
+13:59 <@matches> I have spent WAY too long making this example
+13:59 <@matches> I could have just gone "See \cite{worth2003xr.pdf}"
+16:00 <@matches> So it might be worth talking about dpi in pdf viewers and how it SUCKS
+20:17 -!- mode/#ipdf [-o matches] by matches
+21:14 -!- mode/#ipdf [+o matches] by OperServ
+21:46 <@matches> I have perpetrated XML on the codebase
+21:47 <@matches> I have grand visions of our code supporting SVGs
+21:47 <@matches> I also have grand visions of actually doing a Literature Review
+21:50 * sulix git pull's with some trepidation.
+21:52 < sulix> Never heard of pugixml before but it looks okay.
+21:55 <@matches> The W3C XML specification is pretty terrifying
+21:56 <@matches> I will feel more like I've satisfied the "Document Formats" part of the Literature Review if I say some things about it
+21:57 <@matches> Well SVG in particular
+21:57 <@matches> SVG defines a "minimum" precision of IEEE binary32
+21:58 <@matches> But there's a specification for "High Quality" viewers that have to use binary64
+21:58 <@matches> That's probably the only real thing relevant directly to our problem
+--- Day changed Thu May 01 2014
+01:23 <@matches> It's May 1st
+01:23 <@matches> This means we can no longer say "The Literature Review is due Next Month"
+01:23 <@matches> IT'S DUE THIS MONTH
+01:23 * matches freaks out
+01:23 <@matches> ... but after sleep
+01:25 <@matches> Page 12 of my Literature Review by the way
+01:25 <@matches> Is the only page I like
+16:34 <@matches> The C version of paranoia compiled for me
+16:34 <@matches> Not terribly exciting (I have an IEEE 754 compatible processor! Amazing)
+22:17 <@matches> W Kahan's website is a very interesting if slightly difficult read
+22:24 <@matches> He appears to have written this 80 page pdf in a day
+22:27 <@matches> It kind of reads like one of those religious propaganda pamphlets
+22:27 <@matches> "Java is the Work of Satan"
+22:27 <@matches> "Kernighan-Ritcie C floating-point semantics are the light"
+22:28 <@matches> But every so often he has a graph or example that makes him seem less crazy
+22:34 <@matches> "And now Java forbits you to mention or use extra-precise long double arithmetic, though IEEE Standard 754 recommends its use and over 95% of computers on desktops have it built into their hardware. You paid for it, but Java denies you its benefits."
+22:34 <@matches> Java has long double now right?
+22:34 <@matches> Although that JOP I was looking at was just 32 bit
+22:36 <@matches> Ah, java.lang.math.BigDecimal
+22:37 <@matches> "But be careful with division, because it will throw exceptions if it's like 1/3, then it will be Non-terminating decimal expansion."
+22:37 <@matches> That sounds horrifying
+22:40 -!- mode/#ipdf [-o matches] by matches
+--- Day changed Sat May 03 2014
+22:01 < sulix> My crazy idea to you would be to research p-adic number representations.
+22:01 < sulix> It's been a while, but they were mentioned a couple of times in pure maths units and seemed interesting/crazy and I can't remember much about them.
+22:28 -!- mode/#ipdf [+o matches] by OperServ
+22:29 <@matches> I will look at them, the "just use a float but with more bits until you run out of memory" doesn't seem a very well thought out approach
+22:29 <@matches> Maybe someone actually cares enough to research better ways
+22:29 <@matches> I mean, something's wrong with an idea when you can write "1/3" and have a runtime exception (re: Java BigNumber)
+22:30 <@matches> I plan to write some nasty things about Java based on Kahan's rants so as to gloss over the fact that it has BigNumber built into it and forstall the inevitable "Why didn't you use Java!"
+22:31 < sulix> I think we want to truncate to whatever the most accurate you can see at the given zoom level.
+22:31 <@matches> Yeah
+22:32 <@matches> It annoys me that XML and HTML specs don't have a PDF version
+22:32 < sulix> I've been printing to pdf for some of those things.
+22:33 <@matches> None of the links to different sections would work though
+22:35 <@matches> Specifications are thrilling
+22:35 <@matches> "How to read this specification"
+22:35 <@matches> "This specification should be read like all other specifications"
+22:35 <@matches> Oh wait
+22:35 <@matches> It actually gets better
+22:35 <@matches> Is that...
+22:35 <@matches> Humour!
+22:36 <@matches> I thought that wasn't allowed!
+22:36 <@matches> "First it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross references"
+22:37 <@matches> As much as I love the idea of reading 626 pages of specification backwards...
+--- Day changed Tue May 06 2014
+00:39 <@matches> http://szmoore.net/ipdf/sam/rate-my-litreview.py
+00:39 <@matches> Tim will be thrilled!
+00:40 <@matches> I'm probably going to really regret making that
+00:41 <@matches> The regret is rising to the surface
+00:41 <@matches> It's an example of an interactive document format
+00:41 <@matches> The pixels or perish guy would approve
+00:43 <@matches> So much regret
+00:43 -!- mode/#ipdf [-o matches] by matches
+23:37 -!- mode/#ipdf [+o matches] by OperServ
+23:38 <@matches> So, I have this book called "Computer Graphics" that is pretty amazing
+23:38 <@matches> Funnily enough it has all the algorithms in it
+23:38 <@matches> For computer graphics
+23:38 <@matches> Probably should have been reading it ages ago but I thought we were worrying more about precision
+23:38 <@matches> I don't even know anymore
+23:39 <@matches> Have to read 500pg textbook on graphics, 500pg textbook on floating point numbers, 500pg PDF/PostScript standards...
+23:39 <@matches> Too many pages
+23:39 <@matches> Anyway it has a section on Octrees
+23:39 <@matches> But don't worry
+23:39 <@matches> It mentions Quad trees
+23:39 <@matches> It also actually mentions fractals
+23:39 <@matches> As a thing
+23:40 <@matches> In other news, extending the document we have at the moment to allow anything other than rectangles will be interesting
+23:41 <@matches> Did you do this on purpose? :P
+--- Day changed Wed May 07 2014
+12:32 <@matches> We need to do something about all the warnings generated by the magic OpenGL 3 stuff
+12:32 <@matches> It's making it hard to sport warnings that I actually care about
+12:33 <@matches> Like: You forgot to return a value in this function :S
+13:52 <@matches> Gah I did it again
+13:52 <@matches> auto is dangerous
+13:53 <@matches> Possibly because it's buggy
+13:53 <@matches> I can't actually see any compiler warnings at all
+17:39 <@matches> So you can almost maybe see a difference between beziers calculated using floats and doubles
+17:40 <@matches> If you squint
+17:40 <@matches> And view them on different monitors
+17:41 <@matches> Ah there we go
+17:41 <@matches> I successfully broke it
+17:42 <@matches> When you round to pixel positions it doesn't make a difference
+17:43 <@matches> But on the other hand if you calculate beziers using really big numbers they look wierd :P
+17:43 <@matches> That's important
+17:43 <@matches> Because if you have an arbitrary infinite document you might be at coordinate positions that are really big
+17:43 <@matches> Captain Obvious strikes again
+17:45 <@matches> I think I will make a video of a circle moving towards infinity
+17:45 <@matches> This probably won't help the literature view much but it's too tempting to resist
+17:46 <@matches> I gave up trying to deal with our document format so I currently just generate vector<pair<T, T> > and then map that to a bitmap :P
+--- Day changed Thu May 08 2014
+10:57 <@matches> So circle was a terrible example
+10:57 <@matches> It stays as a circle
+10:58 <@matches> Hopefully the first curve I tried wasn't just a bug
+12:31 <@matches> I think it was a bug
+13:35 <@matches> There are bezier things in ipdf/code/src/tests now
+13:57 < sulix> I am very confused.
+13:57 < sulix> It generates bitmaps of circles in varying shades of red?
+13:58 * sulix decides to actually read the code.
+14:03 < sulix> Ah: I see what it's doing now.
+14:16 <@matches> Your first comment was pretty accurate :S
+14:17 <@matches> I was trying to obtain some amazing animation of a circle that hopelessly collapsed or exploded or something
+14:19 < sulix> I'm slightly terrified that it's generating a vector of points.
+14:19 < sulix> On the other hand, it looks like the rest of the world is realising what a mistake making OpenGL 3 terrifying was.
+14:19 <@matches> Yeah that's a bit lazy
+14:19 <@matches> Although, is returning a vector optimisable?
+14:20 < sulix> In C++11 it is.
+14:20 < sulix> (But not C++98)
+14:20 <@matches> C++11 is growing on me
+14:20 < sulix> Yeah: I've found the same thing.
+14:21 < sulix> I'm a bit scared about what that means, though.
+14:21 < sulix> Maybe one day I'll think boost was a good thing, and then I'll truly be lost.
+14:21 <@matches> Hahaha
+14:21 <@matches> The lambdas remind me of Javascript :S
+14:22 < sulix> I think lambdas are one of those things that are good for you in moderation, but poisonous in large quantities.
+14:22 <@matches> Probably
+14:23 < sulix> I won't be around on Monday, btw, so I'll miss the meeting.
+14:23 < sulix> (Also I'm missing out on Codejam, sadly)
+14:23 <@matches> No!
+14:23 <@matches> (To both of those things)
+14:24 <@matches> Oh god that means I need to make double the progress
+14:25 < sulix> I spoke to Tim, he said that it might be worth cancelling the meeting altogether.
+14:26 <@matches> Haha
+14:26 <@matches> I'm not sure if I should take that as a good or bad sign
+14:27 <@matches> I'm not going great with the literature review
+14:28 < sulix> I rated a bit of it.
+14:28 < sulix> (Though there wasn't a submit button, and it took me a few goes to get through the Turing test)
+14:28 <@matches> Page 20?
+14:28 <@matches> Haha
+14:28 <@matches> The turing test defaults to the accepted answer though!
+14:28 <@matches> You have to actually change it to get it wrong
+14:29 < sulix> Yeah, I thought it was a trick question.
+14:29 <@matches> Maybe I'll give Tim a slightly less joke-worthy version of Rate My LitReview when the draft is done
+14:29 <@matches> ... when hell has frozen over...
+14:29 <@matches> Whichever comes first
+14:31 < sulix> You should read James Mickens' USENIX articles: mkdir -p vogl/vogl_build/bin/release64 && cd $_
+14:31 < sulix> cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_X64=On ../../..
+14:31 < sulix> make -j 10
+14:31 < sulix> (Also I should paste the right thing in)
+14:31 < sulix> http://research.microsoft.com/en-us/people/mickens/
+14:32 <@matches> Ah yes, I will read those at some point
+14:32 * matches downloads the first one, telling himself he will not read it until working on the lit review
+14:33 * matches reads it anyway
+14:33 * sulix feels guilty about not doing lit review at the moment, too.
+14:40 <@matches> Have you heard of /read Computer Graphics by Hearn and Baker?
+14:40 <@matches> I have the ancient "In the dawn before OpenGL 1.0" version
+14:41 <@matches> There is a section mentioning "GL"
+14:41 <@matches> I don't think they use GPU anywhere, they call them "Display Rasterisers" or something
+14:42 <@matches> Display Processor
+14:43 <@matches> A Display Processing Unit is a Display Processor for a Random Scan (vector) display system
+14:43 <@matches> Input devices are interesting too
+14:44 <@matches> "Input Dials"
+14:44 <@matches> A box of variable resistors basically
+14:45 <@matches> Working with computers in the 70s/80s would have been interesting although probably just as horrible as it is today
+14:45 <@matches> But at least it would have been less "webby"
+14:46 <@matches> Where "How do I centre a div" is a deep philosophical question
+14:48 <@matches> I should probably obtain / read a newer edition of this if I want to put it in my lit review?
+14:48 <@matches> Although it is referrring to the same papers we had about Bressenheim
+15:14 <@matches> Oh my god they mention precision!
+--- Log closed Thu May 08 17:04:49 2014
+--- Log opened Thu May 08 18:56:39 2014
+18:56 -!- Irssi: #ipdf: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+18:56 -!- Irssi: Join to #ipdf was synced in 3 secs
+19:55 < matches> Bresenham made a tutorial on rasterisation
+19:56 -!- mode/#ipdf [+o matches] by OperServ
+19:56 <@matches> Bresenham has a nice tutorial about rasterising
+19:56 <@matches> Ties in with the "Since mankind came down from the trees" angle
+19:57 <@matches> "Needlepoint or counted cross-stitch, such as that popularised by the image on a box of Whitman Sampler chocolates..."
+19:57 <@matches> I'm not sure how to relate the rasterisation stuff to the precision stuff
+19:58 <@matches> You have to make a pretty big rounding error to end up in the wrong pixel
+19:59 <@matches> Hearn and Baker mention rounding errors as being one reason why you don't want to use floats and then round them when rasterising things
+19:59 <@matches> The (bigger) reason being that floating point operations are expensive
+20:00 <@matches> They say pixels could move from the line in the DDA algorithm for long lines... I wonder how long they mean... 1e38 pixels? :P
+20:02 <@matches> I want to actually make a drawing of things that look different due to rounding errors dammit!
+20:03 <@matches> None of this "here is a sentence or two of handwaving"
+20:04 <@matches> Maybe rounding errors were a problem on computers with 8 bit floats and terrible resolution displays :P
+20:04 <@matches> Except the worse your resolution the less you'd notice rounding errors
+20:04 <@matches> Well the more you'd notice them, the less they'd happen?
+20:04 <@matches> I don't know
+20:05 -!- mode/#ipdf [-o matches] by matches
+20:30 < sulix> These were recommended: http://www.amazon.com/Forman-S.-Acton/e/B001IYTXGY/?_encoding=UTF8&tag=mollrock-20&linkCode=ur2&qid=1358713701&camp=1789&sr=8-3&creative=390957
+20:30 < sulix> (By a blog post, which turned out not to be about floating point precision, but does mention it: http://mollyrocket.com/casey/stream_0009.html )
+21:21 < matches> I'll look at them at some point
+21:22 -!- mode/#ipdf [+o matches] by OperServ
+21:22 <@matches> I'll look at them at some point
+21:22 <@matches> I sort of got bogged down explaining how lines are drawn :S
+21:22 <@matches> Graphics is complicated dammit
+21:22 <@matches> I'll probably get more done if I just write about everything no matter how irrelevant
+21:23 <@matches> Sooner or later I'll actually write something important and the rest can be appendicised
+21:23 <@matches> Hopefully
+21:25 <@matches> Oh dear, I have located some primitive form of blog
+21:26 <@matches> Well, it talks about things, so I'll reference it...
+21:26 <@matches> "The good-looking textured light-sourced bouncy fun smart and stretchy page"
+21:26 <@matches> It's generally best to not go up a directory from the page you are looking at
+--- Day changed Sun May 18 2014
+15:47 <@matches> So things are due soonish
+15:47 <@matches> :S
+20:09 <@matches> Are you alive, because I don't think I'm alive
+20:10 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+20:11 <@matches> I'm feeling pretty guilty about all that work I didn't do last week...
+20:47 * sulix agrees entirely.
+22:11 <@matches> I give up
+22:11 <@matches> I will just have to face disappointment O'clock tomorrow
+22:22 < sulix> I still have to put more work in before I feel I even deserve disappointment, I think... :/
+22:23 < sulix> I made the mistake of deleting the irrelevant bits from my lit review, and now there's almost nothing left!
+--- Day changed Mon May 19 2014
+08:03 < sulix> At the risk of causing terror: is your final Lit review due on Friday too?
+08:05 * sulix has discovered that his is, and is currently trying to work out how to type in the foetal position.
+09:59 <@matches> Yeah it's due on Friday
+09:59 <@matches> Today is not off to a good start
+10:00 <@matches> I missed an 8am lab but I can't blame the 2 buses I missed because I actually forgot about it
+10:00 <@matches> Then I missed the 2 buses
+10:00 < sulix> Ouch.
+10:00 <@matches> I think missing my tutorial this afternoon is a bad idea but on the other hand... lit review
+10:02 < sulix> I'm frantically writing irrelevant stuff now.
+10:03 < sulix> I'm a little concerned about my entire section on "Document Formats" basically only referencing some specs and "Pixels or Perish".
+10:03 <@matches> That's what I do
+10:03 < sulix> Whereas I have like 20 references for graphics papers that are almost totally irrelevant.
+10:04 <@matches> I have a reference for shading on a vector display
+10:04 <@matches> That's pretty irrelevant
+10:04 < sulix> I've started referencing data structures that are "kinda similar I guess" to the Quadtree, as well. :/
+10:05 <@matches> I ham fisted it in with the paper about embedding 3d figures in documents
+10:05 <@matches> Like "in the 70s even though people had algorithms for things they still drew the diagrams by hand!"
+10:05 < sulix> Peasants!
+10:06 <@matches> My section on number representations is pretty shite
+10:06 <@matches> I still haven't finished floats
+10:06 < sulix> Mine is currently under construction, as it were.
+10:06 <@matches> And the whole point is supposed to be that floats are not good enough
+10:07 < sulix> I've got a terrible thing about floats, but have started talking about arb. precision floats now.
+10:07 <@matches> All I know about the alternatives are that they are basically still floats
+10:07 <@matches> But with more bits...
+10:07 < sulix> I also have some maths I made up that is maybe wrong.
+10:07 <@matches> Will you be here in time for doom O'clock?
+10:08 <@matches> *cough* I meant eleven
+10:08 < sulix> We can but hope.
+10:08 < sulix> I'm sort-of counting on the meeting not happening until 11:20 or so. :/
+10:09 <@matches> I'll show him Rate My Lit Review
+10:09 <@matches> That'll distract attention from the lack of Lit Review
+10:09 <@matches> I'm also assuming no one is ever going to read these IRC logs
+10:09 < sulix> We can but hope.
+10:10 < sulix> I'm feeling dirty because I've just referenced the java standard library.
+10:10 < sulix> Out damnéd
+10:10 < sulix> java.math.BigDecimal.
+10:15 <@matches> I was going to reference that at some point
+10:16 <@matches> I feel like you've made more progress than I have been
+10:17 <@matches> Possibly the decision to sleep last night was a poor one
+10:26 < sulix> Having done the opposite: it wasn't.
+10:30 <@matches> Argh I just got the icedove reminder for the meeting
+10:32 <@matches> So I washed out my Guild (TM) Keep Cup (TM) this morning and now my tea tastes like detergent
+16:37 <@matches> We didn't get the random asking about photoshop in here
+16:37 <@matches> I feel left out
+22:49 <@matches> sjy in #ucc mentioned Knuth's Metafontbook in regards to rendering fonts at infinite precision
+22:49 <@matches> Yet another thing to get around to reading :S
+22:49 <@matches> Before Friday :S
+22:50 <@matches> Wednesday I guess if we meet Tim's deadline for a draft :P
+23:08 <@matches> I guess I was meaning to reference the TeX book at *some* point
+23:08 <@matches> So many things
+23:08 <@matches> Oh dear it's 11pm already
+23:08 <@matches> :-(
+23:09 <@matches> Ok, so
+23:09 <@matches> Metafont seems to basically be symbolic ways to define fonts
+23:10 <@matches> Also Beziers
+23:10 <@matches> All the beziers
+23:10 <@matches> Good
+23:11 <@matches> I was on the right track when I said Beziers were really important
+23:11 <@matches> Knuth is so detailed
+23:12 <@matches> Now I feel guilty about my cartesian line
+23:12 <@matches> That I didn't reference Rene Descartes La Geometrie 1637
+23:12 <@matches> I'm a monster
+23:15 <@matches> I think instead of thinking of things as either interpreted or dom-y like Hayes does, the best way is to think about "What is in the document (eg: DOM)" and "How it is drawn" and you can either have your format care about both things or just one but obviously the most useful formats allow for both
+23:16 <@matches> Actually scratch that
+23:16 <@matches> I don't know anymore
+23:16 <@matches> It's too philosophical
+23:16 * matches goes back to floating point nubers
+23:18 <@matches> So I wonder how much of PostScript is a shameless rip off of METAFONT
+23:18 <@matches> It's not like you have to give credit when you are trying to sell something
+--- Day changed Tue May 20 2014
+09:29 <@matches> So it's quite easy to do a
+09:29 <@matches> "fractal" in SVG/Javascript
+09:29 <@matches> Where easy does not necessarily mean it isn't horrifying
+09:30 <@matches> Aaand there goes all my RAM
+21:43 <@matches> Casually slipping in a footnote directing the reader to rabbitgame.net in my lit review...
+21:43 <@matches> So my webby documents section is probably my least shitly written, or maybe that's just because it has pointless pretty pictures in it
+21:44 <@matches> It is basically
+21:44 <@matches> "Here are the w3c standards"
+21:44 <@matches> "Here are some pretty pictures made with SVGs, can't you just see the DOM leaching out of them?"
+21:44 <@matches> :S
+21:45 <@matches> I'm not sure how well I am treading the line between actually reviewing literature and just giving examples of things
+--- Day changed Wed May 21 2014
+12:09 <@matches> PDF is a mess of a "standard"
+12:09 <@matches> As are all useful things I suppose
+12:09 <@matches> As far as I can work out
+12:09 <@matches> It is not a DOM but a graph
+12:10 <@matches> However, it is also PostScript-y
+12:10 <@matches> But they deal with "interactivity"
+12:10 <@matches> By including XHTML
+12:10 <@matches> And having an "action dictionary" which is literally just a string of javascript
+12:11 <@matches> I just
+12:11 <@matches> Can't even begin to understand how it all works
+12:12 <@matches> But yeah, not really "Crippled Postscript" so much as "Everything including the kitchen sink except for a few bits of Postscript"
+12:13 <@matches> So the Postscript part of it is no longer turing complete, but I don't think you can pretend something in which you can stick arbitrary Javascript isn't turing complete :S
+12:13 <@matches> Oh and even though they have XHTML-ish stuff their Javascript API is totally different to W3Cs
+12:13 <@matches> Hooray
+12:14 <@matches> I suppose the fact that nothing except Adobe products seem to actually use Javascript/XHTML stuff is telling us something about this approach
+12:15 <@matches> I reckon the ideal standard
+12:15 <@matches> Would probably be the DOM but with the "we actually care about efficiency" parts of PDF
+12:18 <@matches> The interactivity of web pages combined with the actually professional looking type setting of PDF
+12:18 <@matches> Or just plain text files
+12:19 <@matches> Plain text files are an underapreciated Document Format
+12:23 <@matches> Ah, I think it sort of makes sense now
+12:23 <@matches> PDF uses what is essentially PostScript to construct this graph thing
+12:24 <@matches> And the graph thing can have elements in it that are just "Make this part of the graph the equivelant DOM from this XHTML"
+12:25 <@matches> And it can also have elements that are "Execute this Javascript to dynamically change this graph"
+12:25 <@matches> But the normal elements are just like PostScript as it would be sent to a printer to show the thing statically
+12:26 <@matches> So when it's rendered it is interpreting the Postscripty bits and when its being interacted with it is updating the Postscripty bits
+12:26 <@matches> I *think*
+12:26 <@matches> This is different from the webby standards which don't really specify how things are actually drawn
+12:27 <@matches> No wait it's not
+12:27 <@matches> Argh I don't know
+12:27 <@matches> You can't classify this shit
+12:27 <@matches> Document Goes In -> Pixels Come Out
+12:28 * matches despairs
+12:49 < sulix> You will find (slightly) less despair if you relegate javascript to the footnote where it belongs. :P
+13:07 < sulix> Hmm... the HTML 2 spec looks like it almost got properly IETF standardised. Might just reference that.
+13:12 < sulix> Oh, they obsoleted it and replaced it with a "Just look at w3c" standard...
+13:17 <@matches> But PDF isn't just flattened PostScript
+13:17 <@matches> It is like, everything
+13:17 <@matches> All merged into one horrifying standard
+13:18 <@matches> Oh well
+13:18 <@matches> I made my shape example in PostScript by removing the alpha
+13:18 <@matches> I'm not sure whether there's any point in including it as a figure
+13:18 <@matches> Most of the PostScript file is taken up by the header
+13:19 < sulix> Holy balls, I just looked up the CSS spec. There are like 200 of them.
+13:19 <@matches> Yeah I just used CSS2
+13:19 <@matches> The others are like
+13:19 <@matches> Colours
+13:19 <@matches> Or something
+13:20 < sulix> That's what I'm using, too.
+13:20 < sulix> The tired and tested "what gets top result on google" method of paper selection.
+13:20 <@matches> Closer examination reveals that most of the PostScript header is defining commands to be shorter :P
+13:20 <@matches> Amazing
+13:20 <@matches> Cairo probably needs to get referenced somewhere
+13:21 <@matches> If only so I have a way out of my Javascript in PDF section by saying that Cairo doesn't support it
+13:21 <@matches> I desperately need to escape the Javascript
+13:25 < sulix> I think the secret is to use the phrase "rendering model" wherever possible.
+13:51 <@matches> Dammit
+13:51 <@matches> So I have that wierd shape in both SVG and PostScript now
+13:51 <@matches> The SVG version fits beautifully and is wonderfully concise and you can see how SVG works
+13:51 <@matches> The PostScript version is just like, BLARGH WALL OF TEXT
+13:51 <@matches> ALSO WE DON'T HAVE ALPHA
+13:52 <@matches> So I'm not sure whether to cut just the PostScript one or both of them now :S
+13:53 <@matches> PDF looks distinctly not like it is just PostScript the more I think about it
+13:53 <@matches> It's like "We are using the same model as PostScript in that commands go in and pixels come out"
+13:54 <@matches> By that logic SVG is also the same
+13:54 <@matches> I think what I should do is just make an appendix
+13:54 <@matches> "A Shape in 20 Document Formats"
+13:56 <@matches> SVG really is the most concise compared to PS and PDF
+14:53 <@matches> Right I can simplify the god awful mess of PS a bit
+14:54 <@matches> I'm hoping I can just say "Here is the PS reference and here is some PostScript as you can see it is interpreted-ish"
+14:54 <@matches> Cairo appeared to draw each element backwards and reverse it after drawing it
+14:54 <@matches> It is stupid
+14:57 <@matches> Like, why bother doing definitions like m == moveto etc
+14:57 <@matches> If you're just going to stick pointless crap in
+14:57 <@matches> My document is half the size without using single letter definitions
+15:31 < sulix> Welp. The wrath of Tim is upon us...
+15:41 <@matches> I'm choosing to latch onto the "quite good" rather than "some way to go"
+15:45 <@matches> It sort of sounds like "Well at least you gave me a pdf file" :P
+15:48 < sulix> One day, all anyone will use are ipdf files...
+15:50 <@matches> Right, TeX is very different from PostScript I think
+15:50 <@matches> At least, pure tex
+15:50 < sulix> Also, holy mackerel, I might have just found a paper on precision in document formats...
+15:50 <@matches> :O
+15:50 < sulix> It even quotes Kahan
+15:50 <@matches> :OOO
+15:50 < sulix> https://www.tug.org/TUGboat/tb28-3/tb90beebe.pdf
+15:50 <@matches> What is it
+15:50 <@matches> Emergency rewrite of entire lit review
+15:51 < sulix> It's a bit TeX specific, but still.
+15:51 <@matches> That's alright
+15:51 <@matches> It ties in amazingly with my decision to hamfist TeX and Metafont into the lit review
+15:52 <@matches> Although I'm not sure it is wise because it means I have to talk about fonts and things
+15:53 <@matches> I wonder if "Fonts are just bezier curves" is sufficient
+15:53 <@matches> They are always treated seperately to curved paths
+15:53 <@matches> Which is understandable because it's a bit inconvenient if you want text in a document to have to define the paths for each glyph
+15:54 <@matches> Anyway I'm glad my assertion that Beziers are the only curves we care about is proving true
+16:33 <@matches> Are you in a position to retrieve this "envelope"
+16:57 < sulix> Not tonight: I'm going to pick it up tomorrow morning.
+16:58 < sulix> And hopefully replace it with a sparkling, glorious review of literature.
+17:00 <@matches> :(
+17:00 <@matches> I cannot concentrate now
+17:00 <@matches> Because I haven't read the comments, I could be doing everything wrong!
+17:02 <@matches> Admitedly I'm technically "working" right now
+17:27 < sulix> My "Document Format Taxonomy" is almost complete... Just need to add SVG.
+17:28 < sulix> (And close my eyes and assert that Microsoft Word documents are not actually documents or something)
+17:28 <@matches> I am jealous
+17:29 <@matches> I just added PostScript it's not particularly well written
+17:29 < sulix> (I don't have any pretty pictures or code, though)
+17:29 < sulix> I've discovered that, despite having totally different numbers for "implementation limits", the PostScript and PDF specs are (a) talking about the same data types and (b) lying.
+17:32 <@matches> Bahaha
+17:32 < sulix> Do you know where the SVG spec mentions precision?
+17:33 <@matches> Ah, I regret not noting the page number
+17:33 <@matches> But a text search should find it
+17:33 <@matches> It specifically says things
+17:33 <@matches> I am interested in whether or not Javascript is subject to the same requirements
+17:34 < sulix> All I've found is "must be correct within 1px at 1:1 zoom", and "It is suggested that viewers attempt to keep a high degree of accuracy when zooming".
+17:35 <@matches> There's something that is about IEEE floats
+17:35 < sulix> Aaah... and a "High-Quality Viewer" must support at least double precision on coordinate system transforms.
+17:35 < sulix> But "IEEE" does not show up in a search of the spec.
+17:36 <@matches> Ah right
+17:36 <@matches> My brain just inserts IEEE whenever I hear "single" or "double" now
+17:36 <@matches> "An IEEE Double Episode of MasterChef!"
+17:36 <@matches> (Which would probably be infinitely more exciting)
+17:37 < sulix> (Or would it be NaNly more exciting...? :P)
+17:38 <@matches> Speaking of "where things are" are we meant to reference page numbers in standards?
+17:38 <@matches> I guess I'll find out when I read Tim's comments
+17:39 <@matches> Excellent my lab finished 20 minutes early
+17:39 <@matches> And also 40 minutes later than the other demonstrators :S
+17:40 <@matches> Do you want me to pick up your comments and scan them and email them to you? :P
+17:40 < sulix> That'd be great.
+17:40 < sulix> Also probably depressing.
+17:41 < sulix> But great.
+17:41 <@matches> Alright, ETA Transperth + Scanner is probably broken O'clock
+17:42 < sulix> I'll savour the blissful ignorance.
+19:50 <@matches> I don't think scanning is worth it, I'll just spam the feedback into this channel
+19:50 <@matches> First up, David's Lit Review
+19:50 <@matches> There is either "Gool" or "Cool" or possibly "Good" written and underlined on the first page
+19:51 <@matches> The opening paragraph is "A little overdramatic?"
+19:51 <@matches> (Since it's a question, I'd like to voice a "No" opinion here)
+19:51 <@matches> The DOM in a footnote is not defined
+19:52 <@matches> Page 2
+19:52 <@matches> There is a tick
+19:52 <@matches> A question mark in regards to the hyphenated bit in the rendering paragraph
+19:53 <@matches> Say "avoid" instead of lack
+19:53 <@matches> Add what the "basic primitives" actually are
+19:53 <@matches> There appears to be an issue with hyphenated phrases the hyphens are circled
+19:53 <@matches> Another tick!
+19:54 <@matches> Oh, you have a $2^64 - 1$\footnote{} which is unfortunate because it looks like $2^64 - 1^2$
+19:54 <@matches> That footnote (probably others?) would work in the paragraph without being footnote
+19:54 <@matches> Fullstops go after \cite{}
+19:55 <@matches> A tick (in regards to the quadtree diagram)
+19:55 <@matches> The concluding comment
+19:56 <@matches> "OK, Much to do (underline) There doesn't seem to be much scholarly references used. You have enough, but you seem to cite them in the context of their contributions to standards as opposed to how they addressed a research question or open problem"
+19:57 <@matches> And (not even our references lists are safe!)
+19:57 < sulix> Oh dear.
+19:57 <@matches> Where referencing web pages, include the date retrieved
+19:57 <@matches> That's it
+19:57 <@matches> I shall move on to my own for completeness although you might not need to care
+19:58 < sulix> Phew, that's not quite as horrible as it could have been, I guess.
+19:58 <@matches> I also have "Good"
+19:58 <@matches> There are some "I didn't read this bit but it had words that seemed vaguely relevant" ticks in Chapter 1 (Introduction) and 2 (Proposal)
+19:59 <@matches> Sorry Tim if you read this
+19:59 <@matches> But when I mark lab reports for Physics that's usually where I put the ticks :P
+19:59 < sulix> (The secret comes out)
+20:00 <@matches> (In my defence I did spend two hours marking the reports this morning and I am paid for none of them, so...)
+20:01 <@matches> (It's the bits that I scribble all over that are where the marking gets done)
+20:01 <@matches> (I think I've covered myself in case the lawyers of any of my students read this channel now, so I will resume my story...)
+20:02 <@matches> Attention is called to the many glaring instances of [?] and "Refer to Section ?"
+20:02 <@matches> :S
+20:02 <@matches> I should probably define a vector image before comparing it to a raster image
+20:02 <@matches> Incidentally my Fox looks amazing
+20:02 <@matches> On printed paper
+20:03 <@matches> (Tim didn't say that, that's just my modest opinion)
+20:03 <@matches> Ahem.
+20:03 < sulix> Can you see the difference between the vector and bitmap versions easily?
+20:04 <@matches> At the original scale there is, alas, a very slight fuzziness
+20:04 <@matches> But I reckon the markers will be old and blind
+20:04 <@matches> Hmm, I should either be more careful about what I say here or stop logging this channel...
+20:04 * sulix hopes they don't read that.
+20:04 <@matches> Sorry markers
+20:04 <@matches> I worship your power
+20:04 <@matches> Please do not smite me
+20:05 <@matches> The scaled up version is interesting
+20:06 <@matches> It looks a bit like your circle with the blocky non-anti-aliased bit but actually anti-aliased by the pdf viewer
+20:06 < sulix> I guess the scaling would be done by the printer's postscript RIP.
+20:06 <@matches> Yeah I guess
+20:07 < sulix> (Side note: I find the whole idea of Postscript interpreters being called RIPs somewhat fitting)
+20:07 <@matches> The PDF decides not to antialias it and converts it to Postscript and then the postscript interpreter adds its own antialiasing?
+20:07 <@matches> I don't know
+20:07 * sulix joins the "SVG is the least broken format" club.
+20:07 <@matches> It's very tempting to descend into footnote madness with this lit review
+20:07 <@matches> "By the way, this very document is an example of this thing!"
+20:07 <@matches> Etc
+20:08 <@matches> Moving on
+20:08 <@matches> The point of talking about vector displays at all is questioned (at least I think that's what the "Why?" refers to here)
+20:08 <@matches> Or it could be "Why is there yet another ?? in this paragraph" I guess
+20:09 <@matches> But probably the former
+20:09 <@matches> I do not have space to include Bresenham's algorithm
+20:09 <@matches> Oh boy, he's going to love what I did with the SVG and Postscript images...
+20:09 <@matches> But I am glad I do not have to actually explain Bresenham's algorithm because it's actually annoyingly detailed
+20:11 < sulix> All sane descriptions of Bresenham's algorithm end up being cascades of "By symmetry" anyway.
+20:11 <@matches> I need to actually find a reference that applied Wu/Bresenham directly to a non-straight line
+20:11 <@matches> You said Bresenham adapted his algorithm to circles but I don't think I'll bother unless someone adapted them to beziers
+20:12 <@matches> Bresenham's paper on rasterisation techniques basically says "Compute some points close enough together and then just connect them with straight lines"
+20:12 <@matches> But I think things might have advanced since the 1980s
+20:12 < sulix> Well, we can compute points that are closer together and draw more lines, I guess.
+20:13 <@matches> Next, Tim wants an example of a spline
+20:13 <@matches> (Oh boy have I got that covered)
+20:13 <@matches> My mathematics terminology on Beziers is not really great
+20:14 <@matches> Well it's right but confusing maybe
+20:14 <@matches> Or I just need to say "t is a trajectory parameter"
+20:14 <@matches> Haha
+20:15 <@matches> He found one of my "????" that is actually just me typing question marks and not a broken reference
+20:15 <@matches> The *entire* section on shading and compositing has a big question mark
+20:15 <@matches> Oh dear
+20:15 <@matches> I just finished writing the compositing bit
+20:16 <@matches> I hope the question mark means "Why isn't this written" and not "Why is this in here"
+20:16 <@matches> Because it is quite useful for an excuse to say PostScript can't do alpha
+20:17 <@matches> I need to refer to the IM (I really don't think that's a thing) and DOM when citing Hayes
+20:17 <@matches> "I don't think Turing Completeness is essential" (Big cross through the Crippled Interpreted Model)
+20:17 <@matches> Fair enough
+20:17 <@matches> A tick appears
+20:18 <@matches> Predictably in the web based documents part
+20:18 <@matches> I need to explain why Ipython is cool if I want to talk about it
+20:18 <@matches> My entire section on Precision as defined in the various formats is ?
+20:20 <@matches> My still to be completed/started section on Graphics APIs, GPUs and Arbitrary Precision is three question marks and "How's all this going"
+20:20 <@matches> The progress report gets a single tick
+20:20 <@matches> And the references have similar issues
+20:20 <@matches> Well
+20:21 <@matches> I'll take a few minutes to quiver in terror
+20:21 <@matches> But I think if I can just find a way to not sleep and still maintain productivity, I might be able to pull this off
+20:22 <@matches> Interestingly he didn't call me out for just talking about standards
+20:22 <@matches> But now I realise that's because I didn't have all the crap I've just written on standards in there
+20:23 < sulix> It's going to be a long night, but I think we'll manage it.
+20:23 <@matches> Mine will be too long but I don't care
+20:24 <@matches> I'll ask for an extension to prepare a condensed version if I must :P
+20:28 <@matches> It's kind of funny I've been spending more time making my vector image in SVG and PostScript nice than actually writing about either of those standards
+20:50 <@matches> Argh the idea of making my koch snowflake example for PS just got in my head
+20:50 <@matches> Which would be brilliant I guess if the topic was still "Fractal Document Formats"
+20:50 <@matches> It probably would be useful if I could demonstrate precision issues..
+20:50 <@matches> NO
+20:50 <@matches> MUST WRITE
+20:50 <@matches> WORDS
+20:50 <@matches> NOT PICTURES
+20:51 <@matches> But still it would make the PostScript and SVG sections consistent with each other...
+20:51 <@matches> NO
+20:51 <@matches> Must control urge to put pointless pictures in
+20:51 <@matches> No matter how much it seems like a good idea
+20:51 <@matches> And not pointless
+20:52 <@matches> Help I'm losing this battle
+20:53 <@matches> It is probably actually a better way of making a Koch curve than the hideous Javascript parsing of strings version
+22:50 <@matches> By the way, you can totally have "pre layout" stages in PostScript since you can define your own operators
+22:50 <@matches> Or do I misunderstand your sentence
+22:50 <@matches> Oh well it sounds smart anyway
+22:51 <@matches> In fact it's a lot more concise than my DOM-y section
+22:52 <@matches> I should sign my Lit Review as Captain Obvious
+22:57 < sulix> My current version does have a "PostScript programs typically embody documents which have been type-
+22:57 < sulix> set, though as a turing-complete language, some layout can be performed
+22:57 < sulix> " sentence.
+22:57 < sulix> by the document.
+23:01 * sulix is still a little bit concerned about how he should reference things for their solutions to open problems rather than their contributions to standards.
+23:03 <@matches> I think I am managing to do it
+23:03 <@matches> I will commit something at some point
+23:03 < sulix> I'm hoping that rewriting most of the rendering section with painful discussions of algorithms will do it.
+23:03 <@matches> An example is Porter and Duff Compositing
+23:04 <@matches> Because PostScript doesn't have alpha and I am really hoping that's just because Adobe had moved on to PDF by the time alpha was a thing
+23:04 <@matches> And not because they thought alpha was dumb :P
+23:05 <@matches> So I can relate Porter and Duff's model to the standards that do use it and say how it solves a problem that the standards that don't use it still have
+23:05 <@matches> And then I can sit back in satisfaction
+23:05 <@matches> And realise this says fuck all about precision
+23:06 <@matches> But at least by talking about it, I have eliminated it from the set of things we need to worry about when talking about precision :P
+23:06 < sulix> I've got a section which basically goes through all of the different document formats and looks at what their specs say about precision now.
+23:06 <@matches> Yeah I have that, but it was dot-pointed
+23:06 <@matches> I thought that would be OK actually but it has a question mark here... :S
+23:06 < sulix> Basically most of them say "implementation-defined" anyway.
+23:06 <@matches> Oh right because I was saying random stuff about how Postscript *used* to not have IEEE
+23:07 <@matches> Yeah it is odd that the standards don't actually reference IEEE
+23:07 <@matches> You'd think, since it's a standard...
+23:07 <@matches> Instead they just say "single" or "double" or "it might be single if you're lucky but we don't care really"
+23:08 <@matches> I assume "single" is widely accepted to mean IEEE single
+23:08 < sulix> From my reading of the Postscript spec, it says basically "We've put IEEE here, but ask your printer manufacturer because they could be using anything for all we care."
+23:08 <@matches> Ah I will check that more carefully
+23:08 <@matches> But it sounds about right
+23:08 < sulix> They give "typical limits" for their data types, but specifically do not specify what they are to be implemented as.
+23:08 <@matches> I don't think I have the time to look at what PostScript did historically before IEEE-754 although it would be kind of interesting to know
+23:09 <@matches> PostScript also does a bunch of silly maths because of units
+23:09 < sulix> The idea being that each postscript interpreter could do whatever they liked.
+23:09 <@matches> Cool
+23:09 <@matches> I should know this already :S
+23:09 <@matches> I just included a single character as a figure
+23:10 <@matches> But I want to actually work out how to do it in LaTeX by setting the size of the font appropriately
+23:10 < sulix> The PDF spec says pretty much the same thing, but notes that Adobe's implementation uses "Mostly IEEE singles" but "used to use 16.16 fixed point" and "still uses it for some things"
+23:10 <@matches> I did see that
+23:10 < sulix> TeX using 14.16 fixed point.
+23:10 < sulix> DVI uses "up-to 32bit" signed integers.
+23:11 <@matches> So basically no one actually uses IEEE for anything :P
+23:11 <@matches> Good work
+23:11 <@matches> I shall panic a bit and then try and actually do that work myself
+23:11 < sulix> SVG uses "implementation defined" or "double-precision floating point" "for coordinate transforms" if you want to be certified "High Quality"
+23:12 <@matches> I saw that one
+23:12 <@matches> But I'm skeptical about how this plays with Javascript
+23:12 <@matches> Not for High Quality even, just in general
+23:12 < sulix> Javascript numbers are always IEEE 754 doubles.
+23:13 <@matches> Ah thanks
+23:13 < sulix> (Even their integers are IEEE 754 doubles, which just happen to be integers)
+23:13 <@matches> Yes I have heard this before
+23:13 <@matches> From you probably :P
+23:14 < sulix> I don't have a source for that, and I'm not going to read the ECMAscript spec to find one, though.
+23:16 <@matches> Oh right, Javascript is actually ECMAscript
+23:16 <@matches> I forgot that
+23:17 <@matches> Dammit I am struggling to stay awake here
+23:17 <@matches> I'm not sure whether it's healthier to try to not sleep and give Tim a draft tomorrow and demand he read it in enough time to make last minute changes
+23:18 <@matches> Or sleep and then be more coherant tomorrow
+23:18 <@matches> I guess I'll try and finish a couple more sections
+23:19 < sulix> I'm going to try to finish this tonight.
+23:20 * sulix has another assignment due Friday that needs significant work.
+--- Day changed Thu May 22 2014
+00:47 <@matches> So X just managed to totally shit itself
+00:47 <@matches> Time to see when I last pressed Ctrl-S
+00:48 <@matches> Oh good (I typically press it once per sentence)
+00:48 <@matches> I hope it wasn't one of my SVGs that broke everything
+00:49 <@matches> Making all my figures in SVG
+00:49 <@matches> Lovingly hand written
+00:49 <@matches> I'm not sure that was a good idea
+01:43 <@matches> Heh, converting SVG to PS in Inkscape appears to introduce rounding errors of up to 0.1 of whatever unit PS is using
+01:44 <@matches> 1.25*56
+01:45 <@matches> Disregard I appear to have mistaken this terminal for a calculator
+01:45 <@matches> They do look similar at this hour in the morning
+01:49 < sulix> I'm seriously doubting whether starting to write stuff about how all of the rasterizing algorithms work was a good idea.
+01:49 <@matches> Haha
+01:49 <@matches> I don't really have much rasterising as such
+01:49 <@matches> Straight lines
+01:50 <@matches> Beziers aren't really "rasterising" so much as defining curves
+01:50 <@matches> Then I mention fonts and how they are all bezier-ish
+01:50 < sulix> I've just spent about an hour trying to prove that bresenham's algorithm can be made to not depend on any coordinates outside the screen.
+01:50 <@matches> Then I have a bit on shading that I can't do
+01:50 <@matches> :S
+01:50 <@matches> That's probably not important
+01:50 <@matches> To quote Tim in my thesis regards to actually explaining algorithms
+01:50 < sulix> It turns out that if you clip the endpoints (even correctly), you adjust the slope of the lines slightly.
+01:51 <@matches> "No you don't have space. [...] details should be left to where they are useful"
+01:51 <@matches> Having said that absolutely none of this is "useful"
+01:51 < sulix> To fix it you have to initialize bresenham's "accumulated error" properly.
+01:51 <@matches> That sounds sort of relevant
+01:52 <@matches> Well I just copied some SVG into PostScript and discovered that the coordinates are all reflected :S
+01:52 < sulix> My choices for referencing this is either a textbook I don't have that "apparently mentions this" or a blog post which rants about it a bit.
+01:52 <@matches> Bahaha
+01:53 <@matches> That sounds like work for the final lit review rather than this one
+01:53 < sulix> Still need to work out how to actually work in how my references solved problems rather than contributed to standards or whatever.
+02:05 <@matches> minipage for latex is great by the way
+02:06 <@matches> Like <div> but not awful
+02:40 <@matches> Oh year
+02:40 <@matches> The best spline curve example ever
+02:41 <@matches> Fuck it took about 3 hours to do that
+02:41 <@matches> Dear god
+02:41 <@matches> Ergh remind me to go censor the log before Friday 1am
+02:50 <@matches> I pushed my references changes by the way
+02:51 < sulix> Yay merging!
+02:51 <@matches> Oh I forgot the actual pdfs but whatever
+02:51 <@matches> I am jealous of your actual concise and to the point lit review
+02:51 <@matches> Mine suddenly exploded into figures
+02:51 <@matches> I should stop
+02:51 <@matches> I think I will delete the Shading section
+02:52 <@matches> No wait it would be a gap to take it out now
+02:52 <@matches> Argh
+02:53 <@matches> I will just have to resist the urge to put a diagram in showing how shading works
+02:53 <@matches> All these diagrams will probably kill me
+02:53 < sulix> I'm thinking of scrapping chunks of the Rendering section of mine just so I don't have to finish them and can go to sleep.
+02:54 <@matches> Tim did seem strongly in favour of covering the rendering stuff
+02:54 <@matches> At least referencing the papers and giving the definitions of things if not actually how to render them
+02:55 <@matches> Anyway I think Beziers at least are important
+02:55 <@matches> I'm discovering a few interesting things about SVG
+02:56 <@matches> The path definitions are basically exactly the same as postscript's commands except less stack-y
+02:56 <@matches> But it has relative commands as well
+02:56 <@matches> Which is interesting because if you have a really really long curve defined with relative commands
+02:56 <@matches> Maybe, just maybe, it will actually cause a precision issue
+02:57 <@matches> I doubt it though
+03:00 <@matches> Well good luck, I am going to sleep
+03:01 < sulix> Thanks. I will see what I can say about Béziers.
+03:38 * sulix collapses.
+08:07 <@matches> Nice work
+08:07 <@matches> Mine is too detailed I think
+08:07 <@matches> It's horrible because now I'm committed to following through on that level of detail everywhere
+08:09 <@matches> Removing detail feels like murder
+08:12 <@matches> Would you be offended if I cited your lit review as a "more concise" overview for the bored reader? :P
+14:28 < sulix> So apparently the entire internet is talking about Bézier curves today.
+14:28 < sulix> This would have been really useful, say, yesterday.
+14:30 < sulix> Also this page looks amazing... http://pomax.github.io/bezierinfo/
+14:39 <@matches> Haha
+14:39 <@matches> I think I've got the Beziers covered
+14:39 <@matches> If you could just hop over to ratemylitreview and check me on that...
+14:39 <@matches> :P
+14:42 < sulix> Ratemylitreview has broken some of the equations...
+14:46 <@matches> If I had time I would include a "rate ratemylitreview" field
+14:46 <@matches> I sent an email
+14:46 <@matches> Now to fear the wrath
+14:47 <@matches> Half time
+14:48 <@matches> Haha I'm somewhat regretting choosing such condescending ratings
+14:49 < sulix> I got terrified seeing that email before I realised it was from you.
+14:49 <@matches> Bahaha
+14:49 <@matches> Well I have to give him something
+14:50 < sulix> You should clearly make the ratings be all amazing, like: "Good, Great, Amazing, Truly Spiffing, Superlative and \"Everything in creation has been leading up to this page of my Lit review\""
+14:51 <@matches> You can POST your own ratings but expecting that might be a bit much
+14:51 <@matches> They are emailed to me as text and they are also stored in the database as text
+14:51 <@matches> Not the most objective of systems :S
+14:51 <@matches> I thought the ratings covered all the bases though
+14:52 < sulix> You could always do what the Shakespeare proramming lanugage does. Positive adjectives +1, negative adjectives -1.
+20:18 <@matches> I haven't said half of what I thought I should about floats
+20:18 <@matches> Tim has been scarily silent :P
+20:19 <@matches> I guess I will assume that means everything is FINE
+20:19 <@matches> I finally got my Table of Contents and things to not take up 6 pages
+20:20 <@matches> I have to resist the urge to add some snarky comments to my section on LaTeX
+20:22 <@matches> About how in theory you don't have to worry about where things go but in practice you spend hours doing horrible things like arbitrarily adding vertical space to force something into position because the anchor position doesn't take into account your line spacing and thus isn't where you expect and the next element overlaps things as a result
+20:22 <@matches> Blargh
+20:22 < sulix> Just stumbled upon a mention of numerical precision causing issues with Wu's algorithm in a book.
+20:22 <@matches> Cite it
+20:23 <@matches> Also give it to me to cite if I can stay awake long enough to read it
+20:23 <@matches> You have contributed some good last minute references
+20:23 <@matches> I seem to have contributed Javascript
+20:23 <@matches> I should be ashamed
+20:24 < sulix> It's in Abrash's Black Book, end of Chapter 42 ("Wu'ed in Haste; Fried, Stewed at leasure"(
+20:24 <@matches> Haha
+20:24 <@matches> My venerable graphics book doesn't even have Wu in it :S
+20:25 <@matches> It also doesn't really properly reference people's papers, or I guess you don't need to in a textbook?
+20:26 <@matches> It gives De Casteljau's method without crediting him for example. It does credit Bezier with things though.
+20:26 <@matches> But they clearly didn't have to worry about putting \cite{} after every single statement
+20:27 <@matches> I'm not sure how well my "I couldn't find a reference, have a look at my website" footnotes are going to go down
+20:27 < sulix> Casey from the Jeff & Casey show did a video blog on Bézier curves and interpolation this morning.
+20:28 <@matches> I really should start reading blogs more, but I was in no position to be watching blogs this morning
+20:28 < sulix> He claims that Bézier did not invent the Bézier curve, so why the hell are they named after him.
+20:28 <@matches> Had I known
+20:28 <@matches> Oh he didn't
+20:28 <@matches> I know that
+20:28 <@matches> That's in Metafont
+20:28 < sulix> I should read Metafont.
+20:28 <@matches> They were named after him because he was the first guy that said "These look useful for things"
+20:28 <@matches> However
+20:28 <@matches> I can't find the paper in a peer reviewed journal
+20:29 <@matches> I think it was for Industry (TM)
+20:29 <@matches> And also in French
+20:29 <@matches> I just cited a paper he did write in English about his experiences with Computer Aided Design
+20:29 <@matches> He doesn't define anything, just shows pictures of nice bezier curvey car bodies
+20:30 < sulix> I saw a bunch of french papers by him, but couldn't be bothered trying to work out which ones were useful.
+20:30 <@matches> De Casteljau's paper is also hard to find
+20:30 <@matches> The order of events was
+20:30 <@matches> 1912 - Bernshtein comes up with the basis polynomials for some sort of mathematical fitting
+20:31 <@matches> 1959 - De Casteljau decides to approximate the curves using his algorithm
+20:31 <@matches> (De Casteljau is only an approximation by the way, but it would converge to the true bezier curve)
+20:31 <@matches> 196? - Bezier does stuff
+20:31 <@matches> 1983/4 - Knuth decides to use them for fonts
+20:32 <@matches> Somehow they ended up in PostScript around that time as well
+20:32 <@matches> Now we're stuck with them
+20:34 <@matches> Hmm I hope my Tensor Equation is right there
+20:34 < sulix> Here's that Wu thing, btw: http://www.jagregory.com/abrash-black-book/#notes-on-wu-antialiasing
+20:36 <@matches> I'm struggling to make my floating point section sound sane
+20:36 <@matches> Too many little details
+20:37 <@matches> Like that you can choose different bases
+20:37 <@matches> What even is a number anyway
+20:38 <@matches> I think the proper way to approach it is talking about a number represented by digits and some numbers take infinitely many digits etc
+20:39 <@matches> Then computers can only fit X binary digits in their registers
+20:39 <@matches> A floating point is basically where you have a fixed point mantissa and then shift the location of the fixed point
+20:39 <@matches> Let's try and ignore the implicit leading one...
+20:40 <@matches> It sort of all falls apart when trying to fit IEEE in there
+20:40 <@matches> This thing is too big as well :(
+20:41 <@matches> Page limits are stupid
+20:42 <@matches> I can't remember what it even is but it's definitely less than what I have
+21:06 <@matches> Ah I see, the aliasing of Wu's line isn't perfect
+21:06 <@matches> I think Wu admits that
+21:06 <@matches> Hmm, that is interesting
+21:11 <@matches> Argh that blog is all like "We should use web based documents instead of PDF"
+21:11 <@matches> Pixels or Perish detected
+21:11 <@matches> To be fair it does actually look nice
+21:14 <@matches> The table of contents in the black book are quite amusing
+21:14 <@matches> No! I finished writing about graphics stuff I need to do floating stuff
+21:15 < sulix> It's a brilliant book, but possibly for another day.
+21:16 <@matches> Dammit I guess I do need to produce more figures
+21:16 <@matches> Sigh
+21:17 <@matches> A picture is worth a thousand words and all that
+21:17 <@matches> And therefore takes at least as long as writing a thousand words to make
+21:27 <@matches> The more I look at SVG files the more convinced I am that they are actually the write way to do things
+21:27 <@matches> right
+21:28 <@matches> Despite all that philosophical guff, you can do the same things as postscript in similar ways, but you also have a DOM that isn't terrifying like whatever PDF supposely does
+21:28 <@matches> I guess PDF would be more efficient though
+21:29 < sulix> That's pretty much the conclusion I've come to.
+21:31 <@matches> Unfortunately now I know more about SVG I keep hand editing my figures
+21:32 <@matches> I don't need to use gnuplot's terrible data point markers anymore!
+21:32 <@matches> I am free!
+21:40 <@matches> I particularly like
+21:40 <@matches> That I can make the points have alpha now
+21:40 <@matches> So if you plot overlapping points it is no longer impossible to see them
+21:40 <@matches> Of course we are restricted by the zoom in the pdf viewer...
+21:41 <@matches> This project is too meta
+21:41 <@matches> It is doing my head in
+--- Day changed Fri May 23 2014
+11:22 < sulix> Welp. Submitting this version: http://davidgow.net/stuff/LitReviewDavid.pdf
+11:23 < sulix> (The introduction has only got more over the top, I'm afraid)
+11:48 < sulix> Do you know what is happening/isn't happening RE: Revised project proposals?
+12:03 < sulix> Well: Literature review is submitted.
+12:03 < sulix> (In person to the coordinator, which is a little bit scary)
+--- Day changed Sun May 25 2014
+15:42 <@matches> No meeting tomorrow by the way
+15:43 < sulix> Ah. Cool. I have like 300 things to do.
+15:43 < sulix> Just pushed fixes for all of the compile warnings, btw.
+15:43 <@matches> Cool
+15:44 <@matches> I want to keep editing my Lit Review :S
+15:44 < sulix> I had thought that Float() always returns a "float", but it sometimes returns a double.
+15:44 <@matches> Oh
+15:44 <@matches> Whoops
+15:44 <@matches> Well a double is technically still a float...
+15:44 < sulix> (Also, it turns out OpenGL actualy breaks the C++ spec, and is therefore impossible to use without hacks if you have -Werror enabled)
+15:45 <@matches> Sigh
+15:45 < sulix> It was warning that I was losing precision from float x = Float(blah);
+15:45 <@matches> One of the things I want to put in my lit review is a snarky paragraph about how no one actually obeys standards anyway
+15:46 < sulix> There are points where you get function pointers as void* pointers, but C++ needs to work on systems where code and data are stored in different bits of memory with different size pointers.
+15:46 <@matches> On the other hand no matter how much better I make the lit review no one will read it because I'm being assessed on a conference paper not a dissertation
+15:46 <@matches> Ah
+15:46 < sulix> So casting any data pointer to a function pointer is apparently illegal.
+15:47 <@matches> That's annoying
+15:47 < sulix> Fortunately, gcc doesn't complain if you start the line that does it with "__extension__", so that's what we do.
+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