[ipdf/documents.git] / irc / #ipdf.log

--- Log opened Mon Mar 17 12:20:15 2014
12:20 -!- matches [[email protected]] has joined #ipdf
12:20 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
12:20 -!- Irssi: Join to #ipdf was synced in 0 secs
12:20 -!- sulix changed the topic of #ipdf to: Angry Strawberry Summer
12:20 -!- mode/#ipdf [+o matches] by sulix
12:39 <@sulix> This is sensible discussion about the project.
12:39 <@matches> The suspense
12:39 <@sulix> Anyone up for lunch?
12:39 <@matches> Yes
12:40 <@sulix> drumroll...
12:41 <@matches> I don't think it worked
12:42 <@matches> Yes I did it manually
12:42 <@matches> Maybe cron is broken on motsugo
12:43 <@sulix> We shall find out next time at 12:40, I guess.
12:43 <@sulix> (Or the next time cron emails errors out, maybe)
12:52 <@matches> Let the record show that it didn't work because I didn't install the crontab
--- Day changed Wed Mar 19 2014
10:59 <@matches> Some guy asked me if he could use the whiteboard, so I let him rub out our timeline
10:59 <@matches> And all he did was write "hello world"
10:59 <@matches> >:(
19:10 <@matches> Testing
19:25 <@matches> So the IRC commits should have a different author
19:25 <@matches> So that I don't get a ridiculous number of daily IRC commits
19:26 <@matches> I could rebase the first three of them but I think that might break things
19:45 <@matches> Ok, and now it will only commit when there is more than one new line, so we won't get one every day when no one says anything
19:54 <@matches> Alright, and in theory
19:54 <@matches> If I spam this some more
19:54 <@matches> There will be a commit soonish
19:56 <@matches> Any second...
19:56 <@matches> Yes
19:56 <@matches> Now that is sorted out I can attain maximum productivity
19:56 <@matches> (Sorry)
--- Log closed Mon Mar 24 01:12:25 2014
--- Log opened Mon Mar 24 08:40:12 2014
08:40 -!- matches [[email protected]] has joined #ipdf
08:40 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
08:40 -!- Irssi: Join to #ipdf was synced in 3 secs
13:26 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
13:27 < matches> Uh oh
13:29 -!- Netsplit over, joins: @sulix
13:31 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:32 -!- Netsplit over, joins: @sulix
13:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:40 -!- Netsplit over, joins: @sulix
16:19 < matches> Well that will make a nice automatic commit
--- Day changed Tue Mar 25 2014
21:33 < matches> So, I am pretty much free all day tomorrow
21:33 < matches> Also Thursday
21:34 <@sulix> I'm pretty busy Thursday, but I'm free all tomorrow so long as I can get some maths done at some point.
21:34 -!- mode/#ipdf [+o matches] by sulix
21:35 <@matches> I'm supervising a test from 2-3pm but that's it
21:35 <@matches> So, I will try and get to UWA as early as I can
21:35 <@matches> It might be a good idea to have some kind of start on a code base
21:35 <@matches> Even though we're supposed to be focusing on a literature review, I don't really like not having any code done yet
21:36 <@sulix> Yeah. I agree.
21:36 <@sulix> Code + fixing git stuff + preparing for this "talk" on Friday.
--- Day changed Wed Mar 26 2014
11:32 <@matches> I am in the super secret room
11:36 <@sulix> Okay, I'll head in shortly. Had a small "parents fell for a scam email and entered passwords on dodgy websites" crisis here this morning.
11:37 <@matches> Oh dear
11:42 <@matches> The phone is ringing :O
11:43 <@matches> Phew, it stopped
22:42 <@matches> I think I have a way to do tests in the Makefile without using cmake
22:42 <@matches> You can alter a variable for a target
23:20 <@matches> Well, that ended badly
23:21 <@matches> With me erasing my own Makefile using make
23:21 <@matches> :P
23:24 <@sulix> Better than erasing the source code, I guess.
23:34 <@matches> This is why we have git
--- Day changed Thu Mar 27 2014
00:15 <@sulix> Crazy templated loading and saving!
00:15 <@sulix> And now for bed!
00:30 <@matches> Well
00:30 <@matches> It doesn't break the test
01:22 <@matches> We now have an arbitrary precision float
01:22 <@matches> Where in this case arbitrary precision means I have no idea what the precision is but it is very bad
01:35 <@matches> Ok I think I made a half precision float
01:35 <@matches> They are quite bad
01:36 <@matches> Um, I can probably make a graph of it being terrible as my contribution for Friday
01:36 <@matches> Assuming I've done it right
--- Day changed Wed Apr 02 2014
09:41 <@matches> Dammit codejam is coming up again
09:41 <@matches> There goes productivity
09:42 <@matches> If you are not busy this afternoon we should do work
09:42 <@matches> On the project I mean
09:45 <@matches> Although it is tempting to just practice codejam problems for the next week
12:44 <@matches> If I work on the project it will help when the inevitable "64 bits is not enough" problem comes up!
12:45 <@matches> Maybe
--- Day changed Sun Apr 06 2014
13:40 <@matches> I get the feeling my part of the project could just be "typedef Real to something from boost"
14:15 <@matches> I suppose I could talk about FPU and hardware
--- Day changed Mon Apr 07 2014
21:42 <@matches> I had a horrible horrible thought... implement a FPU in VHDL and then somehow run all our floating point operations on it :P
21:42 <@matches> (This is not a good idea at all but it might be fun)
21:42 <@matches> You know, for some definition of fun
21:44 <@matches> So my lit review will probably be 1) We need higher precision documents because science (Pixels or Perish) 2) This is how FP works in hardware 3) This is how you can get higher precision in software
21:45 <@matches> Oh, and 4) Document formats and rendering them (PDF/PostScript etc)
21:46 <@matches> That is starting to sound suitably ridiculously broad?
21:46 <@matches> Can always cut things out I guess
21:47 <@matches> To reflect what we actually end up doing
22:05 <@sulix> From what Tim was saying, I don't think "too broad" is a possibility.
22:05 <@sulix> We could be talking about Aztec history and it'd probably not be "too broad."
22:05 <@sulix> I do need to remember to read "Pixels of Perish," though.
22:19 <@matches> I'll have a look into VHDL stuff, there seem to be compilers and simulators for linux
22:20 <@matches> For a minute I was afraid I'd have to use the UWA EE VHDL environment
22:20 <@matches> Which is like, running a Java program in a Windows XP VM
22:20 <@matches> I heard you liked simulations of hardware so I simulated some hardware in your simulated hardware
--- Day changed Tue Apr 08 2014
10:46 -!- Netsplit arctic.uniirc.com <-> mits.mits.au.uniirc.com, services.uniirc.com, irc.cassa.au.uniirc.com, mussel.ucc.au.uniirc.com quits: @sulix
10:46 -!- Netsplit over, joins: @sulix
11:31 <@matches> The "Experiment Running" sign seems to have worked
11:31 <@matches> Also open source VHDL stuff is less "actually compiles" than I had hoped
11:32 <@matches> The two I've tried so far seem to generate absolute monstrosities of C or C++ files and then fail to compile and/or link
--- Day changed Wed Apr 09 2014
15:27 <@sulix> So I've been hitting my head against my desk for about half an hour trying to work out where some bugs were in some ipdf code I'm writing.
15:27 <@sulix> Turns out to have mostly been precision issues due to the lack of precision in your Real data type.
15:28 <@sulix> Switching it to double fixes them all.
15:32 <@matches> Oh
15:32 <@matches> Sorry
15:37 <@sulix> Nah: it's good. It means that precision actually is important!
15:37 <@sulix> (I was getting a little bit concerned for a while :P)
15:40 <@matches> Well
15:40 <@matches> I have rediscovered just how awful VHDL is
15:41 <@matches> It seems like you can't define anything without typing it three times
15:42 <@matches> You define an entity
15:42 <@matches> Then you define a component with identical ports
15:42 <@matches> Then you tell it to use the entity for that component
15:42 <@matches> Then you tell it to map the identical ports to the entity ports
15:42 <@matches> adder_0 : adder port map (a=>a, b=>b, cin=>cin, s=>s, cout=>cout);
15:44 <@matches> Pretty much all the hardware papers I found talk about using VHDL for things
15:46 <@matches> Let's see if I can make any sense of this jop-devel thing that appears to be a JVM implemented in VHDL
15:47 <@matches> Uh oh, .bat files
15:48 <@matches> This looks ominous
15:51 <@sulix> The whole swapping out main thing breaks the makefile in a few ways btw.
15:51 <@sulix> Because none of main.cpp's dependencies are listed.
15:51 <@matches> Ah
15:51 <@sulix> So if you change main.h, nothing gets recompiled.
16:02 <@sulix> Okay, just pushed support for click+drag and zoom in and out in the viewer.
16:03 <@sulix> (I did change the default precision to single, rather than half, as zoom out was totally broken with half-precision)
16:05 <@matches> The half precision implementation is broken itself anyway
16:07 <@matches> Hmm
16:07 <@matches> I can't seem to compile anymore
16:07 <@matches> Hang on
16:07 <@matches> That would be because `uname -i` reports "unknown"
16:12 <@matches> I have made unknown default to x86_64 :S
16:13 <@matches> I can see the precision issues! Good work
16:14 <@matches> These lecture notes seem useful: http://www.cs.berkeley.edu/~demmel/cs267/lecture21/lecture21.html
16:14 <@matches> Lecture notes > Blog post in terms of suitable reference?
16:16 <@sulix> It's got fortran in it, it must be suitably acedemic.
16:18 <@matches> Haha
16:18 <@matches> The VHDL compiler I am experimenting with uses Ada
16:18 <@sulix> I'm getting my fill of new languages by trying out some c++11 features.
16:20 <@sulix> I think I broak realtofloat by changing things to be single precision by default.
16:22 <@sulix> (Hopefully fixed)
16:49 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
16:49 -!- Netsplit over, joins: @sulix
16:54 <@matches> What's with the netsplits
16:55 <@matches> You're on mussel? I'm on mantis? They are VMs on the same host?
16:55 <@matches> I don't know what this uniirc nonsense is
16:56 <@matches> What is "arctic"
16:56 -!- matches changed the topic of #ipdf to: Happy Bannana Netsplit
17:33 <@matches> Well I compiled the VHDL FPU
17:33 <@matches> It seems to work quite well
17:33 <@matches> Except for the part where it never actually finishes an operation
17:34 <@matches> One of the virtual transistors must have overheated
17:43 <@matches> Oops it might help to actually give it a valid operation
18:27 <@matches> Alright, so I'm going to experiment with getting our Real operations to run on the virtual FPU
18:28 <@matches> Then I can look into both hardware and software ways of getting arbitrary precision.
18:30 <@matches> VHDL appears to have text I/O so I could make everything read and write from pipes, but this seems like a terrible idea
18:30 <@matches> On the other hand the compiler is using Ada
19:21 <@matches> Oh wow
19:21 <@matches> To open stdout
19:22 <@matches> You pass it a string "STD_OUTPUT" for the filename
21:40 <@matches> Ok, I give up trying to link this thing
21:40 <@matches> fork() and exec() is seeming more and more elegant
22:11 <@matches> Nooo, buffering
22:11 <@matches> Ok, screw this
--- Day changed Thu Apr 10 2014
00:00 <@matches> Note: Actually exec'ing the program instead of just going straight to "exit(EXIT_FAILURE)" is generally important
00:00 <@matches> Wall of text commit message incoming
00:01 <@matches> Horribly inefficient interface to virtual FPU sort of implemented
00:02 <@matches> I would have made it based on binary read/write rather than hex strings but I could not work out how to do that in VHDL
00:08 <@matches> I still can't believe what I have just done, it seems ludicrous
00:08 <@matches> Using an entire executable and stdio operations
00:08 <@matches> To do a floating point addition
00:10 <@matches> You should see how much is involved in compiling the VHDL FPU...
00:11 <@matches> I'm very pleased that it actually compiled from the version in jop's github without much effort, but still
00:11 <@matches> It's like 30 object files
00:11 <@matches> This is why it isn't in the code repo
00:19 <@matches> Whoops, there are some blatantly wrong comments in vfpu.cpp
00:19 <@matches> Oh well
--- Day changed Fri Apr 11 2014
13:38 <@matches> Warning! I am about to make a ipdf/vfpu repo
13:43 <@matches> You know what's really cool
13:43 <@matches> You can run it as `vfpu --vcd=output.vcd`
13:43 <@matches> And it will create a gtkwave file as it runs showing all the operations
13:44 <@matches> You only get the simulated time from the point of view of the device
13:44 <@matches> Which is probably useful
13:46 <@matches> Or it would be if I wanted to compare different devices
13:47 <@matches> To do that I need to actually make different devices...
17:12 <@matches> Would you prefer seperate repos for the individual reports or just sub directories in the documents repo?
17:12 <@matches> I can't decide
17:12 <@matches> On the one hand 5+ repos is getting a bit out of hand
17:12 <@matches> On the other hand they are individual work
17:24 <@matches> Individual seems best
20:31 <@matches> Hmm
20:31 <@matches> The sqrt op in the fpu appears to have been commented out
20:31 <@matches> Also despite having constants for the sizes of things they have just used magic numbers everywhere
20:34 <@matches> I need an IRC script to prevent myself from saying stuff unless someone else has said things, or this channel will just be me ranting
--- Day changed Mon Apr 14 2014
13:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:43 -!- Netsplit over, joins: @sulix
14:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
14:43 -!- Netsplit over, joins: @sulix
18:32 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:32 -!- Netsplit over, joins: @sulix
18:34 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:35 -!- Netsplit over, joins: @sulix
18:36 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:38 -!- Netsplit over, joins: @sulix
18:40 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:41 -!- Netsplit over, joins: @sulix
18:41 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:43 -!- Netsplit over, joins: @sulix
18:45 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:45 -!- Netsplit over, joins: @sulix
18:46 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:47 -!- Netsplit over, joins: @sulix
18:54 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:56 -!- Netsplit over, joins: @sulix
18:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:00 -!- Netsplit over, joins: @sulix
19:03 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:04 -!- Netsplit over, joins: @sulix
19:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:08 -!- Netsplit over, joins: @sulix
19:10 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:10 -!- Netsplit over, joins: @sulix
19:13 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:13 -!- Netsplit over, joins: @sulix
19:15 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:15 -!- Netsplit over, joins: @sulix
19:17 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:18 -!- Netsplit over, joins: @sulix
19:21 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:22 -!- Netsplit over, joins: @sulix
19:23 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:23 -!- Netsplit over, joins: @sulix
19:26 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:26 -!- Netsplit over, joins: @sulix
19:27 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:29 -!- Netsplit over, joins: @sulix
19:30 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:31 -!- Netsplit over, joins: @sulix
19:32 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:35 -!- sulix [[email protected]] has joined #ipdf
19:35 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
19:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:42 -!- Netsplit over, joins: @sulix
19:44 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:48 -!- sulix [[email protected]] has joined #ipdf
19:48 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:54 -!- Netsplit over, joins: @sulix
19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:54 -!- Netsplit over, joins: @sulix
19:55 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:56 -!- You're now known as 13VAAAAGJ
19:56 -!- Netsplit over, joins: @sulix
19:57 <@13VAAAAGJ> Why am I now known as 13VAAAAGJ
19:57 <@13VAAAAGJ> WHAT THE FUCK IS GOING ON
19:57 <@13VAAAAGJ> ARE WE UNDER ATTACK
19:57 <@13VAAAAGJ> Oh crap this is #ipdf
19:57 <@13VAAAAGJ> Um, disregard this bit of the totally project related conversation
19:57 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:57 <@13VAAAAGJ> I'd edit the commit script to censor the swear words, but effort
19:57 <@13VAAAAGJ> Oh dear
19:57 -!- Netsplit over, joins: @sulix
19:57 <@13VAAAAGJ> Hello
19:58 <@13VAAAAGJ> I think mantis might be dying?
19:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:00 -!- Netsplit over, joins: @sulix
20:01 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:01 -!- Netsplit over, joins: @sulix
20:04 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:04 -!- Netsplit over, joins: @sulix
20:05 <@13VAAAAGJ> Sigh
20:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:07 -!- Netsplit over, joins: @sulix
20:08 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:08 -!- Netsplit over, joins: @sulix
20:08 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:09 -!- Netsplit over, joins: @sulix
20:09 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:10 -!- Netsplit over, joins: @sulix
--- Log closed Mon Apr 14 20:11:29 2014
--- Log opened Mon Apr 14 20:18:05 2014
20:18 -!- matches [[email protected]] has joined #ipdf
20:18 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
20:18 -!- Irssi: Join to #ipdf was synced in 0 secs
22:04 < matches> Ergh
22:06 < matches> http://szmoore.net/ghdl.bug
22:06 < matches> Pretty
22:10 < matches> Looks like we'll be sticking with ASCII input files for the FPU
--- Log closed Mon Apr 14 22:29:33 2014
--- Log opened Mon Apr 14 22:44:34 2014
22:44 -!- matches [[email protected]] has joined #ipdf
22:44 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
22:44 -!- sulix [[email protected]] has joined #ipdf
22:44 -!- Irssi: Join to #ipdf was synced in 12 secs
22:53 <@matches> Someone's VPS was compromised and killing our network
22:53 <@matches> For reference
22:53 <@matches> It affects this project because
23:07 <@matches> Argh
23:07 <@matches> So I thought I was being really clever
23:07 <@matches> I had files of type "bit" and everything
23:07 <@matches> Guess how a "bit" is represented...
23:08 <@matches> It's an ASCII "0" or "1"
23:09 <@matches> I guess I will just conclude that ASCII strings treated as hex is the only way
--- Day changed Wed Apr 16 2014
00:10 <@matches> I'm either about to perpetrate horrible things on your nice View class or give up and go to sleep
00:28 <@matches> Yeah... the problem is if we want to overlay objects rendered using different precision's over each other
00:28 <@matches> It leads towards templates
00:29 <@matches> And templates lead towards fear
00:29 <@matches> And fear leads towards anger
00:29 <@matches> And anger leads to hate
00:29 <@matches> I think
00:29 <@matches> Saving an image
00:29 <@matches> Recompiling the program
00:29 <@matches> Overlaying the image
00:29 <@matches> Is going to lead to less hate
00:30 <@matches> Otherwise pretty much every occurance of "Real" needs to be come a template
00:50 < sulix> So there are a couple of problems with doing that.
00:51 < sulix> - You'd need some way of storing objects of different precision. Possibly an extra "high-precision bounds" struct.
00:51 < sulix> - View also uses real for its internal bounds, which is where many of the problems appear.
00:52 < sulix> (I guess you could have a "high-precision viewport" as well.)
00:52 < sulix> - The actual upload of graphics data to OpenGL is done as 32-bit floats, no matter the type of real, as that's all OpenGL supports.
00:53 < sulix>   (At some point we'll have to actually do some view transforms on the CPU rather than just passing all of the bounds and viewport straight to OpenGL)
01:02 <@matches> Yeah I don't want to replace Real with templates
01:02 <@matches> That'd be horrible
01:03 <@matches> By the way, the introduction of SDL_Renderer in SDL2 is confusing
01:05 <@matches> I thought it was replacing Surface with Renderer and Texture
01:05 <@matches> But Surface seems to still be a thing
01:13 < sulix> Yeah: basically Surfaces are in CPU memory, textures in GPU memory.
01:13 <@matches> Right
01:14 <@matches> And renderers magically put stuff on surfaces/textures
01:14 < sulix> Yeah.
01:14 < sulix> So it basically represents the graphics card.
01:15 < sulix> But if you want to just use OpenGL yourself, you don't need to create a renderer at all.
01:15 <@matches> Ah, but the plot thickens
01:15 <@matches> I'm saving the window to a bmp
01:16 <@matches> Which requires a renderer
01:16 < sulix> Hmm... I'm not sure if that will work.
01:16 <@matches> It does
01:16 <@matches> It seems rather convoluted though to be honest
01:16 < sulix> (In theory, it shouldn't, but it probably actually does)
01:16 <@matches> I seem to remember it not being this convoluted in SDL1.2
01:16 <@matches> -_-
01:16 <@matches> So the procedure is
01:17 <@matches> 1. Get a surface associated with the window
01:17 <@matches> 2. Allocate buffer of unsigned char for the pixels
01:17 < sulix> Yeah, TBH I prefer SDL1.2's rendering API, but I generally just use OpenGL anyway.
01:17 <@matches> 3. Get renderer from the window (NB: Don't use SDL_CreateRenderer, only the (undocumented) SDL_GetRenderer works because the Window already has a Renderer because it has been created with an OpenGL flag)...
01:18 < sulix> In theory we should probably use glReadPixels.
01:18 <@matches> 4. Use the magical renderer power to put pixels into the pixel array
01:18 <@matches> 5. Create an RGB surface from the pixel array
01:18 <@matches> 6. Now you can call SDL_SaveBMP, congratulations
01:18 <@matches> What's this about a glReadPixels
01:18 <@matches> I was just about to commit this
01:19 < sulix> Well, you can use glReadPixels instead of steps 1,3 and 4.
01:19 < sulix> (This is what SDL is doing behind the scenes)
01:20 < sulix> Unfortunately, the SDL wiki is still down thanks to heartbleed. :/
01:20 <@matches> :O
01:20 <@matches> It was up when I looked at it before
01:20 <@matches> Throwing python exceptions when I tried the search function though
01:21 < sulix> Ryan said that it was up, but I'm still getting revoked certificate errors.
01:22 <@matches> Hmm, I needed to do step 1 in order to know the size of the pixel array in step 2...
01:23 < sulix> Screen::ViewportWidth(), Screen::ViewportHeight()
01:26 <@matches> Yeah this is looking a lot shorter than what I had
01:33 <@matches> It doesn't seem to work though
01:35 <@matches> I'm getting a segfault
01:35 <@matches> And of course valgrind automatically exits when it gets more than 1000000 errors from the flgrx driver
01:38 <@matches> First call to glReadPixels is OK but the bmp is just white, second call segfaults
01:39 < sulix> Hmm... what's the call?
01:44 <@matches> Segfault was due to me forgetting about the pixels needing 4 bytes for RGBA
01:44 <@matches> Still white though
01:45 < sulix> (That was going to be my guess)
01:45 <@matches> The advantage of getting the SDL_Surface
01:45 <@matches> Was that you just pass all the surf->format->format->stuff
01:45 <@matches> Everywhere
01:45 <@matches> Also makes it rather verbose
01:46 < sulix> The white screen might just be an fglrx bug.
01:46 <@matches> There we go
01:47 <@matches> No, it helps to remember that the pixels need 4 bytes for RGBA
01:47 <@matches> I have very selective memory
01:47 <@matches> I had to remember it for each line individually
01:47 <@matches> Right I guess it is slightly nicer now
01:47 <@matches> Although it has a bunch of magical "*4" everywhere
01:48 <@matches> I'm going to put this on Stack overflow as an alternative to the answer I was originally following
01:48 < sulix> Well, I'm going to attempt to sleep...
01:48 <@matches> Thank you for fixing my bug without seeing it :S
01:49 < sulix> I have far too much experience breaking glReadPixels...
01:53 <@matches> We need an easy way to compare our document rendering the same thing using a different Real and/or view representation
01:53 <@matches> Templates would only solve changing the Real and really they probably wouldn't actually solve it
01:53 <@matches> They'd just create nightmares
01:53 <@matches> Hmm
01:55 <@matches> Um
01:55 <@matches> Just looking at View::Render
01:55 <@matches> Why is there a seperate loop for each type of object...
01:56 <@matches> With "continue" statements for the other types in each loop
01:56 <@matches> Is this so you can just make one call to glBegin and glEnd...
01:56 <@matches> I am suitable scared
01:57 <@matches> suitably scared and also suitable scared
22:05 <@matches> Ok, trying again. This is the sort of thing a template is supposed to be used for... I just seem to always end up suddenly having to make everything all the way back to Document into a template class :S
22:07 <@matches> blergh
22:07 <@matches> trying again
22:07 <@matches> After getting coffee
22:07 <@matches> I think
22:30 <@matches> Ok, templates is way too complicated
22:30 <@matches> I am going to do the following instead:
22:31 <@matches> 1. Allow a "save this region to bmp" argument
22:31 <@matches> 2. It reads the specified bmp, saves a new bmp with the current view overlayed in a different colour or something
22:32 <@matches> 3. Makefile hacks to recompile the program using a different typedef of Real and then do 1. and 2. for them all
22:32 <@matches> 4. Realise I probably should have used templates
23:02 <@matches> So, according to my timeline that I haven't looked at since submitting the proposal, I will have done a draft literature review by tomorrow...
23:02 <@matches> Hah
--- Day changed Thu Apr 17 2014
00:26 <@matches> I am not good at OpenGL/SDL
00:26 <@matches> I am the master of producing a black screen
00:26 <@matches> Also we have FILLED and OUTLINE the wrong way round still
14:01 < sulix> Bunch of bugfixes incoming.
14:01 < sulix> I'm not proud of what I did to glReadPixels, but it works.
14:02 <@matches> Uh oh
14:02 <@matches> I just worked it out!
14:03 <@matches> The dreaded merge begins
14:03 <@matches> I'm tempted to just delete my changes and merge yours but I should probably do a real merge
14:04 <@matches> I fixed it (on my machine at least) by: Using GL_BGRA instead of GL_RGBA (should probably detect which one to use from the screen's format)
14:04 <@matches> And calling glReadBuffers and glPixelStorei before glReadPixels
14:05 < sulix> glPixelStorei is probably nicer than what I'm doing.
14:05 < sulix> I tried just giving SDL a negative pitch and a pointer to the bottom-right corner of the buffer, but somehow it didn't like that much.
14:07 <@matches> You do actually check the byte order which is good
14:08 <@matches> I worked that out but basically just changed it to match my machine :S
14:08 < sulix> There are a bunch of endian problems in the load-save code anyway if we want it to run on big-endian machines.
14:09 < sulix> (Well, big-endian documents don't load with little-endian code and vice-versa)
14:10 <@matches> http://szmoore.net/ipdf/code/src/screen.cpp
14:10 <@matches> Is the merge
14:10 <@matches> Which one is better?
14:11 < sulix> I think yours will still get the bitmaps upside down?
14:11 <@matches> Ah yes they do tend to be upside down
14:12 < sulix> I'm not sure you should need the front buffer stuff anymore with mine, so if you just keep mine (which is doing the flipping), everything should work.
14:12 <@matches> Woah you fixed the FILLED vs OUTLINE
14:12 < sulix> I did test overlaying bitmaps and it was fine.
14:12 <@matches> Good
14:12 <@matches> Does this seem like a better way to compare approaches than using a template and having View<float> View<double> etc?
14:13 <@matches> It means recompiling
14:13 <@matches> But it means a lot less templates
14:13 <@matches> Pretty much the entire thing has to be templatified that way
14:13 <@matches> And then there's the issue of what type the document is saving with
14:13 < sulix> I think, long term, it'd be worth just extending the view to have a "bounds" and a "high_precision_bounds" or something.
14:14 < sulix> But that is kind-of ugly.
14:14 <@matches> I think it's probably nicer to just have real.h contain nothing but a typedef
14:14 <@matches> And just recompile with a different typedef and overlay the images
14:15 < sulix> Yeah, but there are some artefacts that really show better in motion, so it's probably worth supporting that at some point.
14:15 <@matches> True
14:15 <@matches> But including a video in the pdf will be difficult anyway
14:16 < sulix> (Clearly, we should add embedded videos to ipdf)
14:16 <@matches> You could also make a movie using ffmpeg
14:16 <@matches> Haha
14:16 < sulix> (I've got some OpenGL video playback code somewhere...)
14:17 <@matches> In fact, if you can output a video you can just overlay two videos
14:17 < sulix> Oh... my... god!
14:17 <@matches> I don't know if there's a better way to make a video but I'd just be saving a .bmp every frame and then combine them all with fmpeg
14:17 < sulix> Nope, that's probably a good way.
14:18 < sulix> With some MAGIC it wouldn't even be slow.
14:20 <@matches> Whoops your code isn't giving me a second bmp anymore
14:20 <@matches> At least, not one that has pixels that aren't white
14:20 <@matches> Does my glReadBuffer thing work for you?
14:21 < sulix> Hmm...
14:21 <@matches> Can fix the upside-downness some other way
14:21 < sulix> Did you make clean
14:21 < sulix> Because main.cpp/main.h won't recompile otherwise.
14:21 < sulix> And I moved the glClear() calls.
14:22 <@matches> I did make clean
14:22 < sulix> Which is a less hacky way of solving the problem than reading the front buffer.
14:23 <@matches> So the problem is that the texture rendered by Screen::RenderBMP isn't in the buffer that glReadPixels reads from?
14:23 <@matches> (Even though it gets shown on the screen fine)
14:25 < sulix> Hmm... it works fine here with or without glReadBuffers.
14:27 < sulix> Try changing it to save the screenshot before calling scr.Present() in main.h
14:29 <@matches> That works
14:29 <@matches> But why?
14:29 < sulix> Because when you call Present(), it allocates a new buffer to render into.
14:30 <@matches> Right
14:30 < sulix> This is so that you can start rendering the new frame immediately, rather than having to wait for the window manager to actually re-render the screen.
14:31 <@matches> I have merged it
14:33 < sulix> Excellent.
14:33 < sulix> This is much more fun than literature!
14:33 <@matches> :S
14:35 <@matches> It's important
14:35 <@matches> It's part of the timeline
14:35 <@matches> Just you know
14:35 <@matches> It comes after the Literature Review
14:37 < sulix> Strictly speaking the Lit Review deadline is past, now, isn't it... :/
14:38 <@matches> Well technically it was never a deadline for me... :P
14:38  * sulix sighs
14:38 < sulix> I'm special.
14:39 <@matches> I need to read that last paper on FPUs more
14:39 <@matches> It was talking about how there are all these software techniques from the 1960s that can actually be done on the FPU itself
14:40 <@matches> I'll probably just work on getting our / jop's FPU working for different sized floats instead
14:40 <@matches> In theory that will teach me how they actually work
14:40 <@matches> Then I can actually understand the papers
14:40 < sulix> But can you write about it in a Lit Review?
14:42 <@matches> Maybe not so much the Lit Review, but it means I can write the Background section that explains how they work
14:43 <@matches> There's probably some early papers on them that I can reference at the same time if I try hard enough to find them
14:44 <@matches> The modern papers all have a lot of assumed knowledge
15:59 <@matches> Instead of reading papers I have progressed towards compiling different types and then overlaying them
16:02 <@matches> I didn't know you could do such cool things with Makefiles and flags to the compiler
16:02 <@matches> If people knew more about this maybe we wouldn't have to have python
16:03 <@matches> I will learn to do all my highlevel programming using Make
19:48 <@matches> Our Render/Screenshot combo for overlaying bitmaps and $$$ only works the first time it is done
19:49 <@matches> Or maybe it's RenderBMP that only works once
19:49 <@matches> Hmm
19:52 <@matches> I swear the format was BGRA earlier and now it's RGBA
19:53 <@matches> This can probably get fixed after some Literature Review
20:09 <@matches> Anyway you can now set the type of Real with `make DEF=-DREAL=X`
20:09 <@matches> Or `make single` and `make double`
20:09 <@matches> 0 and 1 respectively
20:09 <@matches> I tried a little bit too hard to get it working with actual C strings
21:32 <@matches> Minutes now have less "~*" in them
21:32 <@matches> Wrong channel
21:32 <@matches> Very wrong channel
--- Day changed Mon Apr 21 2014
12:32 <@matches> Literature Review O'Clock
12:36 < sulix> I have just returned from my Easter holiday and have some horrible code for you to scream at while I have lunch. :P
12:43 <@matches> Uh oh
12:44 <@matches> stb_truetype ?
12:44 <@matches> DejaVuSansMono.ttf ?!
12:44 <@matches> Is this going to render a font...
12:45 <@matches> Woah
12:47 <@matches> Looks good
12:48 <@matches> I think I will avoid looking at stb_truetype too closely...
12:48 <@matches> Too late
12:48 <@matches> Why are all the implementations in the .h file
12:48 <@matches> And the .cpp file just has some defines...
12:48 <@matches> shudder
12:53 <@matches> I particularly like #define STBTT_assert(...) do {} while(0)
12:53 < sulix> That's a standard way of doing that. SDL_assert does the same thing.
12:54 < sulix> It lets you put a semicolon after it or use it in an if() statement without braces, etc, without things breaking horribly.
12:56 <@matches> But... your assert doesn't actually assert anything?
12:56 < sulix> That's because you generally only want it enabled in debug builds.
12:56 <@matches> I guess
12:57 < sulix> So typically you'd have it as do {} while(0) in release builds, and something like a function call in debug builds.
12:57 <@matches> So what is this "more code" going to do :P
12:57 < sulix> Slightly more modern opengl.
12:58 <@matches> Yeah, that would be a good idea
12:58 < sulix> In particular, uploading the content of a document to a VBO, and just re-rendering from that when needed.
12:58 <@matches> Cool
12:58 < sulix> Jumps from 9 fps -> 37 fps with 1024^2 objects.
12:59 < sulix> I've been without internet, though, so it's pretty broken in many ways, still.
12:59 < sulix> Like outline rects don't work.
12:59 < sulix> And it still uses a bunch of OpenGL 1.0 stuff.
12:59 < sulix> And for some reason the glPrimitiveRestartIndex() function isn't working.
13:00 < sulix> Also I need to write shaders at some point, which will be work.
13:00 <@matches> I just found the best comment in an IEEE email list
13:00 <@matches> We should totally use it
13:01 <@matches> "It is too late now to repair the mistakes of the past that are present in millions of installed systems, but it is good to know that careful research before designing hardware can be helpful"
13:01 < sulix> Oh man, that's basically the thesis in one sentance.
13:02 <@matches> Dibs!
13:02 <@matches> Although I doubt anyone will care if we both quote it
13:03 < sulix> One thing I did discover reading my OpenGL book is that I think we can get OpenGL to use doubles with some shader hackery.
13:03 <@matches> :O
13:03 < sulix> Then again, the book was (partly) written by (one of) the authors of fglrx, so take it with the requisite salt.
13:04 <@matches> Ah, so how many goats were required?
13:05 < sulix> Just the two, I think.
13:06 <@matches> This email message seems sort of vaguely relevant? It's the "infamous double rounding problem"
13:06 < sulix> I take it that you worked out how to swap between CPU and GPU transforms with right-click.
13:07 <@matches> I read it in the commit message
13:08 < sulix> I was quite happy with how much nicer things ran with CPU transforms and doubles.
13:08 <@matches> I think I can see a difference zooming in far enough
13:08 <@matches> Yeah that's a huge difference
13:08 <@matches> I had a tester that was going to automatically make images of the difference when you zoomed in really far
13:09 <@matches> But there were issues with the screen shot / bmp rendering
13:09 <@matches> Probably the bmp rendering
13:09 < sulix> .bmp files suck.
13:10 <@matches> They are nice and simple though?
13:10 <@matches> At least, the SDL API is nice and simple
13:10 < sulix> That's more a triumph of SDL than of the .bmp file format.
13:10 <@matches> After looking through gm6 files with a hex editor to try and extract sprites...
13:11 <@matches> Well we could always just fwrite the pixel buffer and fread it back
13:11 <@matches> If you want no one to be able to use our files without compiling our program :P
13:12 < sulix> I'm personally a fan of LodePNG, but I'm too lazy to hack it in at the moment: http://lodev.org/lodepng/
13:13 < sulix> I'm probably going to get around to fixing all of the warnings in stb_truetype one day.
13:13 <@matches> Haha
13:13 <@matches> What about implementing an Oct-tree?
13:14 <@matches> So .bmp is just a header and then the raw pixel data? What's disgusting about that? No compression?
13:16 <@matches> Wait png is also just a header and then an IDAT section
13:17 <@matches> Oh well you can put lodepng in if you want I guess
13:17 <@matches> As long as I can open the images in eom
13:18 <@matches> Ah so PNG is compressed. I missed that
13:19 <@matches> Meh
13:19 <@matches> Oh and alpha channel
13:19 <@matches> Yeah
13:19 <@matches> I remember that now
13:20 <@matches> xpaint is the least shitty of the shitty sprite editors in debian, but it only stores RGB because it was designed around bmp and I guess they just hacked on exporting to other formats later
13:21 <@matches> If you open things with alpha it gets really confused
13:23 < sulix> You can put alpha in .bmp files, but then they sometimes crash KDE.
13:26 <@matches> We can just run all our bmp files through image magick
13:26 <@matches> convert a.bmp a.png
13:26 <@matches> Done
13:27 <@matches> Hmm, maybe if I opened the data from the gm6 files as png they would work, I was assuming they were bmps -_-
13:27 <@matches> Actually gif
13:27 <@matches> Probably
13:28 <@matches> Since it has "Save as gif"
13:28 <@matches> But that is not relevant to this project
13:33 < sulix> Damn, just discovered that the opengl feature I was using for rectangle outlines is not supported by my laptop's hardware.
13:34 < sulix> (This explains one of the bugs I've been seeing, but sadly only one)
13:47 < sulix> Okay, remaining code pushed.
13:47 < sulix> I am sorry.
13:53 <@matches> I'm messing around trying to do something evil so I'll merge later
13:53 <@matches> But you don't seem to call ToggleGPUTransform when there is a right click
13:54 <@matches> Oh wait, I need to make clean
13:54 <@matches> Cool
13:54 <@matches> (So much for our Makefile magically tracking the header files :S)
13:58 < sulix> It does it for every header file except ones included by main.cpp because of the weird main.cpp swapping stuff.
13:59 <@matches> That main swapping stuff is amazing
13:59 <@matches> It is worth it
13:59 <@matches> Except main.cpp ends up eventually including all the header files
14:00 <@matches> I think there is an alternative Makefile that just has every single header file in the current directory as a dependency for each .o file
14:01 <@matches> But I'm normally used to running make clean anyway
14:22 <@matches> Eh I was going to make a video of the difference between GPU and CPU coord transforms but it's not that great
14:23 <@matches> Whatever you have done does not look happy
14:24 < sulix> It takes like 5 minutes to DebugDumpObjects with a million objects, but it works okay* after that.
14:24 <@matches> Yeah ok
14:24 < sulix> *well, sort-of.
14:25 < sulix> If you just want to show off the precision, getting rid of most of those objects is probably the right thing to do.
14:25 <@matches> Interesting things happen when you zoom out really far
14:25 <@matches> Do we care about that
14:25 < sulix> I'm going to go with "no".
14:26 <@matches> Ah, but the rectangles are not all the same size
14:26 < sulix> This is a product of rounding to the nearest pixel. They'd be fine with antialiasing.
14:29 <@matches> I have pushed a single line contribution
14:29 <@matches> I decided not to bother with all the changes I made to make the video prettier
14:29 <@matches> Since I can't actually capture my desktop properly anyway
14:30 <@matches> I suppose I could make it render bmps and ffmpeg them all but that is way too much effort
14:31 <@matches> So
14:31 <@matches> Literature Reviews
14:31 <@matches> They are a thing
14:38 <@matches> I probably should not reference an email thread
14:53 <@matches> In other news, I think this jvm FPU doesn't actually implement sqrt
14:57 <@matches> It always gives 0x0 on sqrt ops
14:57 <@matches> I certainly hope there isn't a jvm somewhere that just doesn't do square roots
14:58 <@matches> They probably hacked it into some other part of their project instead of putting it in the FPU
16:08 <@matches> So fprintf style formatting isn't very clever when it comes to floats vs doubles vs long doubles
16:11 <@matches> Eg: %lf will work for either floats or doubles and %f will work for either floats or doubles (by truncating) but %llf is the only thing that works for long doubles and it only works for long doubles
16:12 <@matches> s/truncating/casting whatever
16:52 <@matches> We can compile with long double
16:52 <@matches> I suspect this may break things but whatever
16:52 <@matches> Running calculatepi on motsugo to see how much difference it actually makes...
17:08 <@matches> Charles Babbage seems like an interesting fellow
17:09 <@matches> "e sought to prove the
17:09 <@matches> reality of the devil by drawing with his blood a
17:09 <@matches> circle on the floor and repeating the Lord’s prayer
17:09 <@matches> backward"
17:09 <@matches> The things one does for science
17:44 <@matches> Reading about Charles Babbage counts as Literature Review...
17:44 <@matches> Actually I'm trying to find a paper written *by* him
17:44 <@matches> Since apparently he came up with Floating Point representations
22:11 <@matches> Found an actual paper talking about floating points on GPUs
22:12 <@matches> It says they don't conform to IEEE and also the manufacturers don't like to tell people what they do do
22:12 <@matches> So they wrote a version of Paranoia, which was a test program for computers in the 1980s before IEEE, to work out the characteristics of flops on various GPUs
22:13 <@matches> This is probably of interest
22:14 <@matches> So far one of the best papers I have on algorithms in software is actually one talking about implementing those algorithms in hardware instead
22:15 <@matches> I also have a random obituary to Charles Babbage just because
22:16 <@matches> Unfortunately UWA directs me to some useless website that just tells me the citation details and doesn't give me a download for any of Babbage's papers
22:17 <@matches> He has some books but they are mostly about economics
22:18 <@matches> Would have been nice if he'd written something that says "I have invented floating point" but I guess not
22:18 <@matches> That's only really of historical interest but it'd be nice
--- Day changed Tue Apr 22 2014
01:17 <@matches> Urgh looking at the git diff
01:17 <@matches> I really have not accomplished much
01:30 <@matches> Oooh, motsugo finally got to a number of intervals where long double is better than double
11:56 < sulix> So it turns out that I've broken the open-source GL drivers.
11:56 < sulix> They don't support one of the features ("primitive restart") we need when in compatibility mode.
11:56 < sulix> So I guess now I've got to rewrite everything to use OpenGL 3.
14:47 <@matches> ?
14:48 <@matches> I should probably look more carefully at what the OpenGL stuff is doing nowdays
14:49 <@matches> Downgrading to OpenGL 3 sounds drastic
14:50 <@matches> Wait 3 is the OK one, 4 is the new one
14:50 <@matches> 1 is the ancient one
14:52 <@matches> I see pointer arithmetic...
14:53 <@matches> banana would be furious
14:53 <@matches> should be using std::super_ptr_unsegfaultable_arith
14:53 <@matches> (I am not a fan of the smart pointers)
14:55 <@matches> *indexData = 0xFFFFFFFF; // Primitive restart.
14:55 <@matches> I do not know what is going on here :S
14:58 <@matches> Ahh I get it now
14:58 <@matches> Reading commit messages turns out to be useful
15:04 <@matches> git blame for view.cpp reveals that I still own the opening braces on some things
15:05 <@matches> That's about it :P
15:06 <@matches> I'm going to keep looking at rounding errors and maybe have a better thing than calculating pi
15:06 <@matches> As a bench mark
15:07 <@matches> I might look at Paranoia
15:07 <@matches> Although it was originally in BASIC
15:07 <@matches> And ~7000 lines
15:07 <@matches> With almost no whitespace characters
15:07 <@matches> And totally no indents
15:08 <@matches> I sometimes get the feeling people used to be smarter than we are now...
15:08 <@matches> Then I remember that those people are ultimately responsible for the tools we use now
15:15 < sulix> Speaking of tools we use now, I think I've just got the debug font code to not only randomly corrupt a varible, but also cause valgrind to crash.
15:18 < sulix> Okay, we need to fix that makefile at some point.
15:38 <@matches> make clean?
15:41 <@matches> It's not actually swapping out main.cpp
15:41 <@matches> It just doesn't have main.o in the link objects and has main in the $(BIN) target and the testers in the tests/% target
15:42 <@matches> I guess that is swapping out main but MAIN is not being changed
15:42 <@matches> derp
15:45 <@matches> I think I fixed it?
15:45 < sulix> Ah. Well, you've got a merge conflict to look forward to.
15:45 <@matches> Not if I just NEVER COMMIT IT
15:46 <@matches> I'm going to call your fix being right and mine being a horrible hack
15:46 <@matches> Ok I pullsd some changes to graphics stuff, is that it or is there more?
15:46 < sulix> I haven't fixed it, I've just gone and bu(gg|ff)ered up the font stuff.
15:47 <@matches> So it's not meant to render unless something changes? But the debug font stuff is changing so it needs to keep rendering?
15:48 <@matches> I see a lot of "Flushing Debug Font arrays"
15:48 < sulix> The debug font stuff is separate from the whole view system.
15:48 <@matches> That makes sense
15:48 < sulix> It's just trying to fill up a buffer of quads with individual characters in it and then draws them when the buffer gets full.
15:49 < sulix> One more step on the path of getting rid of all of the OpenGL 1.1 stuff.
15:50 <@matches> Haha
15:50 <@matches> git stash seems to think I modified graphicsbuffer.h and screen.h
15:51 <@matches> git diff seems to think everything is identical
15:51 <@matches> I'm just going to git reset the things I didn't actually change...
15:52 < sulix> I do that far too often.
15:52 <@matches> Oh there is a comment "//test" for testing the Makefile
15:53 <@matches> And a comment "This isn't the Screen class?" where you copy/pasted the screen class description for the GraphicsBuffer class
15:53 <@matches> I don't think they need to be preserved
15:54 < sulix> Yeah, I should have got rid of that screen class bit by now.
15:55 <@matches> Have a 2 line commit
15:55 < sulix> The best kind.
15:55 <@matches> I really need to cut back on the new line creep
15:56 <@matches> It's like I can't add a line by itself without putting in extra whitespace 
15:57 <@matches> Uh oh we've ran out of coffee here
15:58 <@matches> I'm slightly scared by how much the graphics code has increased since I last actually understood how it worked...
15:59 <@matches> Can you change those *vertexData to *(vertexData++) or is that considered even uglier
16:03 < sulix> I thought of that, but given how much pointer arithmetic debugging I was going to do, I wanted it to be really obvious when the pointer was being incremented.
16:03 < sulix> The plan is to have a nice AppendFloat() function or similar that will do this eventually.
16:05 < sulix> Hmm: "Buffer usage warning: Analysis of buffer object 2 (bound to GL_ARRAY_BUFFER_ARB) usage indicates that the GPU is the primary producer and consumer of data for this buffer object. The usage hint supplied with this buffer object, GL_STATIC_DRAW, is inconsistent with this usage pattern. Try using GL_STREAM_COPY_ARB, GL_STATIC_COPY_ARB or GL_DYNAMIC_COPY_ARB instead.
16:06 < sulix> Thanks nVidia.
16:06 < sulix> Now if only we were using OpenGL 4.4 which got rid of buffer usage hints entirely.
16:29 <@matches> Also I think you forgot the naming scheme :P
16:30 <@matches> vertex_data
16:31 <@matches> I will go back to pretending to be doing a literature review
16:32 <@matches> Instead I will probably plot some graphs
16:48 <@matches> So
16:48 <@matches> If you look up "Handbook of Floating Point Arithmetic" on google (which lots of things like to reference these days)
16:48 <@matches> You can download the entire thing
16:48 <@matches> I was prepared to pay like $20 for it on amazon
16:49 <@matches> Oh amazon doesn't sell actual books anymore though does it?
16:49 <@matches> No they do have it
16:50 <@matches> For $100...
16:50 <@matches> I think I'll just stick with my free pdf thanks
16:55 <@matches> "Handbook" being 579 pages...
17:04 <@matches> I think if a textbook is citing blog posts we can probably get away with it
17:05 <@matches> Oh my god I love this textbook
17:05 < sulix> I was watching a conference talk last night when the presenter just said: "this technique is described on this guys blog. Here's a link."
17:05 <@matches> "Table 1.1 gives the results obtained by compiling Program 1.1 and running on a Pentium4, using the GNU Compiler Collection and the Linux system"
17:06 <@matches> [Complete C code for Program 1.1 follows]
17:06 <@matches> None of this "Pseudo code" crap
17:07 < sulix> Clearly we should get an extra 10% for every line of pointer arithmetic in our theses.
17:07 <@matches> There'
17:07 <@matches> s a problem here
17:07 <@matches> How do I not make the entire literature review just paraphrased from this one text book
17:08 <@matches> Mr Gullible and the Chaotic Bank Society!
17:08 <@matches> It has stories!
17:08 <@matches> Parents should read this textbook to their children
17:09 < sulix> I'm pretty certain I know someone with a data structures and algorithms picture book...
17:09 <@matches> That reminds me of a children's book I wrote about multithreading
17:10 <@matches> I should probably scan it one day
17:10 < sulix> Did it begin "Once upa timeon...
17:10 <@matches> I think it did actually
17:10 <@matches> Once upon a time there was a process who had a lot of work to do...
17:11 <@matches> "I should probably scan it one day" - Why not TODAY!
17:11  * matches goes searching
17:16 <@matches> It is no where to be found
17:16 <@matches> I distinctly remember going to throw it out and deciding not to, but not where it actually went
17:27 <@matches> So maybe compiling a bunch of HFPA's examples using our Real type is a good way to make benchmarks
17:27 <@matches> I don't know
17:27 <@matches> My part of the project seems to move further and further away from the document formats thing
17:27 <@matches> Maybe I'll try and compile the GPU Paranoia
17:28 <@matches> Hah
17:34 <@matches> It seems like whatever Mathematica does is what we should do
17:35 <@matches> I wonder if wolfram is open about how Mathematica actually works
17:35 <@matches> I don't think they are
17:35 <@matches> The CQM lecturer for physics found a bug in Mathematica's number representation once that she showed us
17:35 <@matches> Apparently she reported it years ago and it's still there
17:36 <@matches> This segued nicely into why we should learn fortran
--- Day changed Wed Apr 23 2014
14:00 <@matches> IEEE's float encoding is inconvenient
14:01 <@matches> The mantissa is like, reversed
14:01 <@matches> b_{23-i} * 2^{-i}
14:19 <@matches> And the implicit extra 1 except when it isn't is a pain in the ass as well
14:19 <@matches> It's like
14:19 <@matches> I can't just copy the right bits I have to think
14:19 <@matches> What is this
14:19 <@matches> Mental effort
14:19 <@matches> Blargh
14:20 <@matches> I should have just stuck with the 8 bit floats with their 2 sign bits
14:20 <@matches> The hydra float
15:17 <@matches> Wow you get really different representations with an IEEE encoding of the bits
15:17 <@matches> ...
15:17 <@matches> I think I liked just treating the two parts as integers in the order they were stored better
15:18 <@matches> I have to call pow(3) and a floating point division for every '1' in the mantissa to get it to agree with IEEE
15:19 <@matches> Unless I'm missing some obvious trick
15:20 <@matches> But in IEEE the mantissa is not an integer
15:37 <@matches> Ooookkk
15:38 <@matches> You're precision doesn't disappear as fast when you do it that way
15:38 <@matches> Your
15:38 <@matches> Whatever
--- 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:04 -!- Pommers [[email protected]] has joined #ipdf
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:05 -!- Pommers [[email protected]] has left #ipdf []
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 -!- matches [[email protected]] has joined #ipdf
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 -!- matches [[email protected]] has joined #ipdf
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 -!- matches [[email protected]] has joined #ipdf
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