Some stuff I learnt in maths that isn't relevant
[ipdf/documents.git] / irc / #ipdf.log
1 --- Log opened Mon Mar 17 12:20:15 2014
2 12:20 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
3 12:20 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
4 12:20 -!- Irssi: Join to #ipdf was synced in 0 secs
5 12:20 -!- sulix changed the topic of #ipdf to: Angry Strawberry Summer
6 12:20 -!- mode/#ipdf [+o matches] by sulix
7 12:39 <@sulix> This is sensible discussion about the project.
8 12:39 <@matches> The suspense
9 12:39 <@sulix> Anyone up for lunch?
10 12:39 <@matches> Yes
11 12:40 <@sulix> drumroll...
12 12:41 <@matches> I don't think it worked
13 12:42 <@matches> Yes I did it manually
14 12:42 <@matches> Maybe cron is broken on motsugo
15 12:43 <@sulix> We shall find out next time at 12:40, I guess.
16 12:43 <@sulix> (Or the next time cron emails errors out, maybe)
17 12:52 <@matches> Let the record show that it didn't work because I didn't install the crontab
18 --- Day changed Wed Mar 19 2014
19 10:59 <@matches> Some guy asked me if he could use the whiteboard, so I let him rub out our timeline
20 10:59 <@matches> And all he did was write "hello world"
21 10:59 <@matches> >:(
22 19:10 <@matches> Testing
23 19:25 <@matches> So the IRC commits should have a different author
24 19:25 <@matches> So that I don't get a ridiculous number of daily IRC commits
25 19:26 <@matches> I could rebase the first three of them but I think that might break things
26 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
27 19:54 <@matches> Alright, and in theory
28 19:54 <@matches> If I spam this some more
29 19:54 <@matches> There will be a commit soonish
30 19:56 <@matches> Any second...
31 19:56 <@matches> Yes
32 19:56 <@matches> Now that is sorted out I can attain maximum productivity
33 19:56 <@matches> (Sorry)
34 --- Log closed Mon Mar 24 01:12:25 2014
35 --- Log opened Mon Mar 24 08:40:12 2014
36 08:40 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
37 08:40 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
38 08:40 -!- Irssi: Join to #ipdf was synced in 3 secs
39 13:26 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
40 13:27 < matches> Uh oh
41 13:29 -!- Netsplit over, joins: @sulix
42 13:31 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
43 13:32 -!- Netsplit over, joins: @sulix
44 13:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
45 13:40 -!- Netsplit over, joins: @sulix
46 16:19 < matches> Well that will make a nice automatic commit
47 --- Day changed Tue Mar 25 2014
48 21:33 < matches> So, I am pretty much free all day tomorrow
49 21:33 < matches> Also Thursday
50 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.
51 21:34 -!- mode/#ipdf [+o matches] by sulix
52 21:35 <@matches> I'm supervising a test from 2-3pm but that's it
53 21:35 <@matches> So, I will try and get to UWA as early as I can
54 21:35 <@matches> It might be a good idea to have some kind of start on a code base
55 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
56 21:36 <@sulix> Yeah. I agree.
57 21:36 <@sulix> Code + fixing git stuff + preparing for this "talk" on Friday.
58 --- Day changed Wed Mar 26 2014
59 11:32 <@matches> I am in the super secret room
60 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.
61 11:37 <@matches> Oh dear
62 11:42 <@matches> The phone is ringing :O
63 11:43 <@matches> Phew, it stopped
64 22:42 <@matches> I think I have a way to do tests in the Makefile without using cmake
65 22:42 <@matches> You can alter a variable for a target
66 23:20 <@matches> Well, that ended badly
67 23:21 <@matches> With me erasing my own Makefile using make
68 23:21 <@matches> :P
69 23:24 <@sulix> Better than erasing the source code, I guess.
70 23:34 <@matches> This is why we have git
71 --- Day changed Thu Mar 27 2014
72 00:15 <@sulix> Crazy templated loading and saving!
73 00:15 <@sulix> And now for bed!
74 00:30 <@matches> Well
75 00:30 <@matches> It doesn't break the test
76 01:22 <@matches> We now have an arbitrary precision float
77 01:22 <@matches> Where in this case arbitrary precision means I have no idea what the precision is but it is very bad
78 01:35 <@matches> Ok I think I made a half precision float
79 01:35 <@matches> They are quite bad
80 01:36 <@matches> Um, I can probably make a graph of it being terrible as my contribution for Friday
81 01:36 <@matches> Assuming I've done it right
82 --- Day changed Wed Apr 02 2014
83 09:41 <@matches> Dammit codejam is coming up again
84 09:41 <@matches> There goes productivity
85 09:42 <@matches> If you are not busy this afternoon we should do work
86 09:42 <@matches> On the project I mean
87 09:45 <@matches> Although it is tempting to just practice codejam problems for the next week
88 12:44 <@matches> If I work on the project it will help when the inevitable "64 bits is not enough" problem comes up!
89 12:45 <@matches> Maybe
90 --- Day changed Sun Apr 06 2014
91 13:40 <@matches> I get the feeling my part of the project could just be "typedef Real to something from boost"
92 14:15 <@matches> I suppose I could talk about FPU and hardware
93 --- Day changed Mon Apr 07 2014
94 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
95 21:42 <@matches> (This is not a good idea at all but it might be fun)
96 21:42 <@matches> You know, for some definition of fun
97 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
98 21:45 <@matches> Oh, and 4) Document formats and rendering them (PDF/PostScript etc)
99 21:46 <@matches> That is starting to sound suitably ridiculously broad?
100 21:46 <@matches> Can always cut things out I guess
101 21:47 <@matches> To reflect what we actually end up doing
102 22:05 <@sulix> From what Tim was saying, I don't think "too broad" is a possibility.
103 22:05 <@sulix> We could be talking about Aztec history and it'd probably not be "too broad."
104 22:05 <@sulix> I do need to remember to read "Pixels of Perish," though.
105 22:19 <@matches> I'll have a look into VHDL stuff, there seem to be compilers and simulators for linux
106 22:20 <@matches> For a minute I was afraid I'd have to use the UWA EE VHDL environment
107 22:20 <@matches> Which is like, running a Java program in a Windows XP VM
108 22:20 <@matches> I heard you liked simulations of hardware so I simulated some hardware in your simulated hardware
109 --- Day changed Tue Apr 08 2014
110 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
111 10:46 -!- Netsplit over, joins: @sulix
112 11:31 <@matches> The "Experiment Running" sign seems to have worked
113 11:31 <@matches> Also open source VHDL stuff is less "actually compiles" than I had hoped
114 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
115 --- Day changed Wed Apr 09 2014
116 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.
117 15:27 <@sulix> Turns out to have mostly been precision issues due to the lack of precision in your Real data type.
118 15:28 <@sulix> Switching it to double fixes them all.
119 15:32 <@matches> Oh
120 15:32 <@matches> Sorry
121 15:37 <@sulix> Nah: it's good. It means that precision actually is important!
122 15:37 <@sulix> (I was getting a little bit concerned for a while :P)
123 15:40 <@matches> Well
124 15:40 <@matches> I have rediscovered just how awful VHDL is
125 15:41 <@matches> It seems like you can't define anything without typing it three times
126 15:42 <@matches> You define an entity
127 15:42 <@matches> Then you define a component with identical ports
128 15:42 <@matches> Then you tell it to use the entity for that component
129 15:42 <@matches> Then you tell it to map the identical ports to the entity ports
130 15:42 <@matches> adder_0 : adder port map (a=>a, b=>b, cin=>cin, s=>s, cout=>cout);
131 15:44 <@matches> Pretty much all the hardware papers I found talk about using VHDL for things
132 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
133 15:47 <@matches> Uh oh, .bat files
134 15:48 <@matches> This looks ominous
135 15:51 <@sulix> The whole swapping out main thing breaks the makefile in a few ways btw.
136 15:51 <@sulix> Because none of main.cpp's dependencies are listed.
137 15:51 <@matches> Ah
138 15:51 <@sulix> So if you change main.h, nothing gets recompiled.
139 16:02 <@sulix> Okay, just pushed support for click+drag and zoom in and out in the viewer.
140 16:03 <@sulix> (I did change the default precision to single, rather than half, as zoom out was totally broken with half-precision)
141 16:05 <@matches> The half precision implementation is broken itself anyway
142 16:07 <@matches> Hmm
143 16:07 <@matches> I can't seem to compile anymore
144 16:07 <@matches> Hang on
145 16:07 <@matches> That would be because `uname -i` reports "unknown"
146 16:12 <@matches> I have made unknown default to x86_64 :S
147 16:13 <@matches> I can see the precision issues! Good work
148 16:14 <@matches> These lecture notes seem useful: http://www.cs.berkeley.edu/~demmel/cs267/lecture21/lecture21.html
149 16:14 <@matches> Lecture notes > Blog post in terms of suitable reference?
150 16:16 <@sulix> It's got fortran in it, it must be suitably acedemic.
151 16:18 <@matches> Haha
152 16:18 <@matches> The VHDL compiler I am experimenting with uses Ada
153 16:18 <@sulix> I'm getting my fill of new languages by trying out some c++11 features.
154 16:20 <@sulix> I think I broak realtofloat by changing things to be single precision by default.
155 16:22 <@sulix> (Hopefully fixed)
156 16:49 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
157 16:49 -!- Netsplit over, joins: @sulix
158 16:54 <@matches> What's with the netsplits
159 16:55 <@matches> You're on mussel? I'm on mantis? They are VMs on the same host?
160 16:55 <@matches> I don't know what this uniirc nonsense is
161 16:56 <@matches> What is "arctic"
162 16:56 -!- matches changed the topic of #ipdf to: Happy Bannana Netsplit
163 17:33 <@matches> Well I compiled the VHDL FPU
164 17:33 <@matches> It seems to work quite well
165 17:33 <@matches> Except for the part where it never actually finishes an operation
166 17:34 <@matches> One of the virtual transistors must have overheated
167 17:43 <@matches> Oops it might help to actually give it a valid operation
168 18:27 <@matches> Alright, so I'm going to experiment with getting our Real operations to run on the virtual FPU
169 18:28 <@matches> Then I can look into both hardware and software ways of getting arbitrary precision.
170 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
171 18:30 <@matches> On the other hand the compiler is using Ada
172 19:21 <@matches> Oh wow
173 19:21 <@matches> To open stdout
174 19:22 <@matches> You pass it a string "STD_OUTPUT" for the filename
175 21:40 <@matches> Ok, I give up trying to link this thing
176 21:40 <@matches> fork() and exec() is seeming more and more elegant
177 22:11 <@matches> Nooo, buffering
178 22:11 <@matches> Ok, screw this
179 --- Day changed Thu Apr 10 2014
180 00:00 <@matches> Note: Actually exec'ing the program instead of just going straight to "exit(EXIT_FAILURE)" is generally important
181 00:00 <@matches> Wall of text commit message incoming
182 00:01 <@matches> Horribly inefficient interface to virtual FPU sort of implemented
183 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
184 00:08 <@matches> I still can't believe what I have just done, it seems ludicrous
185 00:08 <@matches> Using an entire executable and stdio operations
186 00:08 <@matches> To do a floating point addition
187 00:10 <@matches> You should see how much is involved in compiling the VHDL FPU...
188 00:11 <@matches> I'm very pleased that it actually compiled from the version in jop's github without much effort, but still
189 00:11 <@matches> It's like 30 object files
190 00:11 <@matches> This is why it isn't in the code repo
191 00:19 <@matches> Whoops, there are some blatantly wrong comments in vfpu.cpp
192 00:19 <@matches> Oh well
193 --- Day changed Fri Apr 11 2014
194 13:38 <@matches> Warning! I am about to make a ipdf/vfpu repo
195 13:43 <@matches> You know what's really cool
196 13:43 <@matches> You can run it as `vfpu --vcd=output.vcd`
197 13:43 <@matches> And it will create a gtkwave file as it runs showing all the operations
198 13:44 <@matches> You only get the simulated time from the point of view of the device
199 13:44 <@matches> Which is probably useful
200 13:46 <@matches> Or it would be if I wanted to compare different devices
201 13:47 <@matches> To do that I need to actually make different devices...
202 17:12 <@matches> Would you prefer seperate repos for the individual reports or just sub directories in the documents repo?
203 17:12 <@matches> I can't decide
204 17:12 <@matches> On the one hand 5+ repos is getting a bit out of hand
205 17:12 <@matches> On the other hand they are individual work
206 17:24 <@matches> Individual seems best
207 20:31 <@matches> Hmm
208 20:31 <@matches> The sqrt op in the fpu appears to have been commented out
209 20:31 <@matches> Also despite having constants for the sizes of things they have just used magic numbers everywhere
210 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
211 --- Day changed Mon Apr 14 2014
212 13:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
213 13:43 -!- Netsplit over, joins: @sulix
214 14:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
215 14:43 -!- Netsplit over, joins: @sulix
216 18:32 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
217 18:32 -!- Netsplit over, joins: @sulix
218 18:34 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
219 18:35 -!- Netsplit over, joins: @sulix
220 18:36 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
221 18:38 -!- Netsplit over, joins: @sulix
222 18:40 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
223 18:41 -!- Netsplit over, joins: @sulix
224 18:41 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
225 18:43 -!- Netsplit over, joins: @sulix
226 18:45 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
227 18:45 -!- Netsplit over, joins: @sulix
228 18:46 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
229 18:47 -!- Netsplit over, joins: @sulix
230 18:54 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
231 18:56 -!- Netsplit over, joins: @sulix
232 18:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
233 19:00 -!- Netsplit over, joins: @sulix
234 19:03 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
235 19:04 -!- Netsplit over, joins: @sulix
236 19:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
237 19:08 -!- Netsplit over, joins: @sulix
238 19:10 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
239 19:10 -!- Netsplit over, joins: @sulix
240 19:13 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
241 19:13 -!- Netsplit over, joins: @sulix
242 19:15 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
243 19:15 -!- Netsplit over, joins: @sulix
244 19:17 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
245 19:18 -!- Netsplit over, joins: @sulix
246 19:21 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
247 19:22 -!- Netsplit over, joins: @sulix
248 19:23 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
249 19:23 -!- Netsplit over, joins: @sulix
250 19:26 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
251 19:26 -!- Netsplit over, joins: @sulix
252 19:27 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
253 19:29 -!- Netsplit over, joins: @sulix
254 19:30 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
255 19:31 -!- Netsplit over, joins: @sulix
256 19:32 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
257 19:35 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
258 19:35 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
259 19:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
260 19:42 -!- Netsplit over, joins: @sulix
261 19:44 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
262 19:48 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
263 19:48 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
264 19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
265 19:54 -!- Netsplit over, joins: @sulix
266 19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
267 19:54 -!- Netsplit over, joins: @sulix
268 19:55 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
269 19:56 -!- You're now known as 13VAAAAGJ
270 19:56 -!- Netsplit over, joins: @sulix
271 19:57 <@13VAAAAGJ> Why am I now known as 13VAAAAGJ
272 19:57 <@13VAAAAGJ> WHAT THE FUCK IS GOING ON
273 19:57 <@13VAAAAGJ> ARE WE UNDER ATTACK
274 19:57 <@13VAAAAGJ> Oh crap this is #ipdf
275 19:57 <@13VAAAAGJ> Um, disregard this bit of the totally project related conversation
276 19:57 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
277 19:57 <@13VAAAAGJ> I'd edit the commit script to censor the swear words, but effort
278 19:57 <@13VAAAAGJ> Oh dear
279 19:57 -!- Netsplit over, joins: @sulix
280 19:57 <@13VAAAAGJ> Hello
281 19:58 <@13VAAAAGJ> I think mantis might be dying?
282 19:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
283 20:00 -!- Netsplit over, joins: @sulix
284 20:01 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
285 20:01 -!- Netsplit over, joins: @sulix
286 20:04 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
287 20:04 -!- Netsplit over, joins: @sulix
288 20:05 <@13VAAAAGJ> Sigh
289 20:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
290 20:07 -!- Netsplit over, joins: @sulix
291 20:08 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
292 20:08 -!- Netsplit over, joins: @sulix
293 20:08 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
294 20:09 -!- Netsplit over, joins: @sulix
295 20:09 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
296 20:10 -!- Netsplit over, joins: @sulix
297 --- Log closed Mon Apr 14 20:11:29 2014
298 --- Log opened Mon Apr 14 20:18:05 2014
299 20:18 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
300 20:18 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
301 20:18 -!- Irssi: Join to #ipdf was synced in 0 secs
302 22:04 < matches> Ergh
303 22:06 < matches> http://szmoore.net/ghdl.bug
304 22:06 < matches> Pretty
305 22:10 < matches> Looks like we'll be sticking with ASCII input files for the FPU
306 --- Log closed Mon Apr 14 22:29:33 2014
307 --- Log opened Mon Apr 14 22:44:34 2014
308 22:44 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
309 22:44 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
310 22:44 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
311 22:44 -!- Irssi: Join to #ipdf was synced in 12 secs
312 22:53 <@matches> Someone's VPS was compromised and killing our network
313 22:53 <@matches> For reference
314 22:53 <@matches> It affects this project because
315 23:07 <@matches> Argh
316 23:07 <@matches> So I thought I was being really clever
317 23:07 <@matches> I had files of type "bit" and everything
318 23:07 <@matches> Guess how a "bit" is represented...
319 23:08 <@matches> It's an ASCII "0" or "1"
320 23:09 <@matches> I guess I will just conclude that ASCII strings treated as hex is the only way
321 --- Day changed Wed Apr 16 2014
322 00:10 <@matches> I'm either about to perpetrate horrible things on your nice View class or give up and go to sleep
323 00:28 <@matches> Yeah... the problem is if we want to overlay objects rendered using different precision's over each other
324 00:28 <@matches> It leads towards templates
325 00:29 <@matches> And templates lead towards fear
326 00:29 <@matches> And fear leads towards anger
327 00:29 <@matches> And anger leads to hate
328 00:29 <@matches> I think
329 00:29 <@matches> Saving an image
330 00:29 <@matches> Recompiling the program
331 00:29 <@matches> Overlaying the image
332 00:29 <@matches> Is going to lead to less hate
333 00:30 <@matches> Otherwise pretty much every occurance of "Real" needs to be come a template
334 00:50 < sulix> So there are a couple of problems with doing that.
335 00:51 < sulix> - You'd need some way of storing objects of different precision. Possibly an extra "high-precision bounds" struct.
336 00:51 < sulix> - View also uses real for its internal bounds, which is where many of the problems appear.
337 00:52 < sulix> (I guess you could have a "high-precision viewport" as well.)
338 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.
339 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)
340 01:02 <@matches> Yeah I don't want to replace Real with templates
341 01:02 <@matches> That'd be horrible
342 01:03 <@matches> By the way, the introduction of SDL_Renderer in SDL2 is confusing
343 01:05 <@matches> I thought it was replacing Surface with Renderer and Texture
344 01:05 <@matches> But Surface seems to still be a thing
345 01:13 < sulix> Yeah: basically Surfaces are in CPU memory, textures in GPU memory.
346 01:13 <@matches> Right
347 01:14 <@matches> And renderers magically put stuff on surfaces/textures
348 01:14 < sulix> Yeah.
349 01:14 < sulix> So it basically represents the graphics card.
350 01:15 < sulix> But if you want to just use OpenGL yourself, you don't need to create a renderer at all.
351 01:15 <@matches> Ah, but the plot thickens
352 01:15 <@matches> I'm saving the window to a bmp
353 01:16 <@matches> Which requires a renderer
354 01:16 < sulix> Hmm... I'm not sure if that will work.
355 01:16 <@matches> It does
356 01:16 <@matches> It seems rather convoluted though to be honest
357 01:16 < sulix> (In theory, it shouldn't, but it probably actually does)
358 01:16 <@matches> I seem to remember it not being this convoluted in SDL1.2
359 01:16 <@matches> -_-
360 01:16 <@matches> So the procedure is
361 01:17 <@matches> 1. Get a surface associated with the window
362 01:17 <@matches> 2. Allocate buffer of unsigned char for the pixels
363 01:17 < sulix> Yeah, TBH I prefer SDL1.2's rendering API, but I generally just use OpenGL anyway.
364 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)...
365 01:18 < sulix> In theory we should probably use glReadPixels.
366 01:18 <@matches> 4. Use the magical renderer power to put pixels into the pixel array
367 01:18 <@matches> 5. Create an RGB surface from the pixel array
368 01:18 <@matches> 6. Now you can call SDL_SaveBMP, congratulations
369 01:18 <@matches> What's this about a glReadPixels
370 01:18 <@matches> I was just about to commit this
371 01:19 < sulix> Well, you can use glReadPixels instead of steps 1,3 and 4.
372 01:19 < sulix> (This is what SDL is doing behind the scenes)
373 01:20 < sulix> Unfortunately, the SDL wiki is still down thanks to heartbleed. :/
374 01:20 <@matches> :O
375 01:20 <@matches> It was up when I looked at it before
376 01:20 <@matches> Throwing python exceptions when I tried the search function though
377 01:21 < sulix> Ryan said that it was up, but I'm still getting revoked certificate errors.
378 01:22 <@matches> Hmm, I needed to do step 1 in order to know the size of the pixel array in step 2...
379 01:23 < sulix> Screen::ViewportWidth(), Screen::ViewportHeight()
380 01:26 <@matches> Yeah this is looking a lot shorter than what I had
381 01:33 <@matches> It doesn't seem to work though
382 01:35 <@matches> I'm getting a segfault
383 01:35 <@matches> And of course valgrind automatically exits when it gets more than 1000000 errors from the flgrx driver
384 01:38 <@matches> First call to glReadPixels is OK but the bmp is just white, second call segfaults
385 01:39 < sulix> Hmm... what's the call?
386 01:44 <@matches> Segfault was due to me forgetting about the pixels needing 4 bytes for RGBA
387 01:44 <@matches> Still white though
388 01:45 < sulix> (That was going to be my guess)
389 01:45 <@matches> The advantage of getting the SDL_Surface
390 01:45 <@matches> Was that you just pass all the surf->format->format->stuff
391 01:45 <@matches> Everywhere
392 01:45 <@matches> Also makes it rather verbose
393 01:46 < sulix> The white screen might just be an fglrx bug.
394 01:46 <@matches> There we go
395 01:47 <@matches> No, it helps to remember that the pixels need 4 bytes for RGBA
396 01:47 <@matches> I have very selective memory
397 01:47 <@matches> I had to remember it for each line individually
398 01:47 <@matches> Right I guess it is slightly nicer now
399 01:47 <@matches> Although it has a bunch of magical "*4" everywhere
400 01:48 <@matches> I'm going to put this on Stack overflow as an alternative to the answer I was originally following
401 01:48 < sulix> Well, I'm going to attempt to sleep...
402 01:48 <@matches> Thank you for fixing my bug without seeing it :S
403 01:49 < sulix> I have far too much experience breaking glReadPixels...
404 01:53 <@matches> We need an easy way to compare our document rendering the same thing using a different Real and/or view representation
405 01:53 <@matches> Templates would only solve changing the Real and really they probably wouldn't actually solve it
406 01:53 <@matches> They'd just create nightmares
407 01:53 <@matches> Hmm
408 01:55 <@matches> Um
409 01:55 <@matches> Just looking at View::Render
410 01:55 <@matches> Why is there a seperate loop for each type of object...
411 01:56 <@matches> With "continue" statements for the other types in each loop
412 01:56 <@matches> Is this so you can just make one call to glBegin and glEnd...
413 01:56 <@matches> I am suitable scared
414 01:57 <@matches> suitably scared and also suitable scared
415 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
416 22:07 <@matches> blergh
417 22:07 <@matches> trying again
418 22:07 <@matches> After getting coffee
419 22:07 <@matches> I think
420 22:30 <@matches> Ok, templates is way too complicated
421 22:30 <@matches> I am going to do the following instead:
422 22:31 <@matches> 1. Allow a "save this region to bmp" argument
423 22:31 <@matches> 2. It reads the specified bmp, saves a new bmp with the current view overlayed in a different colour or something
424 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
425 22:32 <@matches> 4. Realise I probably should have used templates
426 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...
427 23:02 <@matches> Hah
428 --- Day changed Thu Apr 17 2014
429 00:26 <@matches> I am not good at OpenGL/SDL
430 00:26 <@matches> I am the master of producing a black screen
431 00:26 <@matches> Also we have FILLED and OUTLINE the wrong way round still
432 14:01 < sulix> Bunch of bugfixes incoming.
433 14:01 < sulix> I'm not proud of what I did to glReadPixels, but it works.
434 14:02 <@matches> Uh oh
435 14:02 <@matches> I just worked it out!
436 14:03 <@matches> The dreaded merge begins
437 14:03 <@matches> I'm tempted to just delete my changes and merge yours but I should probably do a real merge
438 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)
439 14:04 <@matches> And calling glReadBuffers and glPixelStorei before glReadPixels
440 14:05 < sulix> glPixelStorei is probably nicer than what I'm doing.
441 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.
442 14:07 <@matches> You do actually check the byte order which is good
443 14:08 <@matches> I worked that out but basically just changed it to match my machine :S
444 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.
445 14:09 < sulix> (Well, big-endian documents don't load with little-endian code and vice-versa)
446 14:10 <@matches> http://szmoore.net/ipdf/code/src/screen.cpp
447 14:10 <@matches> Is the merge
448 14:10 <@matches> Which one is better?
449 14:11 < sulix> I think yours will still get the bitmaps upside down?
450 14:11 <@matches> Ah yes they do tend to be upside down
451 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.
452 14:12 <@matches> Woah you fixed the FILLED vs OUTLINE
453 14:12 < sulix> I did test overlaying bitmaps and it was fine.
454 14:12 <@matches> Good
455 14:12 <@matches> Does this seem like a better way to compare approaches than using a template and having View<float> View<double> etc?
456 14:13 <@matches> It means recompiling
457 14:13 <@matches> But it means a lot less templates
458 14:13 <@matches> Pretty much the entire thing has to be templatified that way
459 14:13 <@matches> And then there's the issue of what type the document is saving with
460 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.
461 14:14 < sulix> But that is kind-of ugly.
462 14:14 <@matches> I think it's probably nicer to just have real.h contain nothing but a typedef
463 14:14 <@matches> And just recompile with a different typedef and overlay the images
464 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.
465 14:15 <@matches> True
466 14:15 <@matches> But including a video in the pdf will be difficult anyway
467 14:16 < sulix> (Clearly, we should add embedded videos to ipdf)
468 14:16 <@matches> You could also make a movie using ffmpeg
469 14:16 <@matches> Haha
470 14:16 < sulix> (I've got some OpenGL video playback code somewhere...)
471 14:17 <@matches> In fact, if you can output a video you can just overlay two videos
472 14:17 < sulix> Oh... my... god!
473 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
474 14:17 < sulix> Nope, that's probably a good way.
475 14:18 < sulix> With some MAGIC it wouldn't even be slow.
476 14:20 <@matches> Whoops your code isn't giving me a second bmp anymore
477 14:20 <@matches> At least, not one that has pixels that aren't white
478 14:20 <@matches> Does my glReadBuffer thing work for you?
479 14:21 < sulix> Hmm...
480 14:21 <@matches> Can fix the upside-downness some other way
481 14:21 < sulix> Did you make clean
482 14:21 < sulix> Because main.cpp/main.h won't recompile otherwise.
483 14:21 < sulix> And I moved the glClear() calls.
484 14:22 <@matches> I did make clean
485 14:22 < sulix> Which is a less hacky way of solving the problem than reading the front buffer.
486 14:23 <@matches> So the problem is that the texture rendered by Screen::RenderBMP isn't in the buffer that glReadPixels reads from?
487 14:23 <@matches> (Even though it gets shown on the screen fine)
488 14:25 < sulix> Hmm... it works fine here with or without glReadBuffers.
489 14:27 < sulix> Try changing it to save the screenshot before calling scr.Present() in main.h
490 14:29 <@matches> That works
491 14:29 <@matches> But why?
492 14:29 < sulix> Because when you call Present(), it allocates a new buffer to render into.
493 14:30 <@matches> Right
494 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.
495 14:31 <@matches> I have merged it
496 14:33 < sulix> Excellent.
497 14:33 < sulix> This is much more fun than literature!
498 14:33 <@matches> :S
499 14:35 <@matches> It's important
500 14:35 <@matches> It's part of the timeline
501 14:35 <@matches> Just you know
502 14:35 <@matches> It comes after the Literature Review
503 14:37 < sulix> Strictly speaking the Lit Review deadline is past, now, isn't it... :/
504 14:38 <@matches> Well technically it was never a deadline for me... :P
505 14:38  * sulix sighs
506 14:38 < sulix> I'm special.
507 14:39 <@matches> I need to read that last paper on FPUs more
508 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
509 14:40 <@matches> I'll probably just work on getting our / jop's FPU working for different sized floats instead
510 14:40 <@matches> In theory that will teach me how they actually work
511 14:40 <@matches> Then I can actually understand the papers
512 14:40 < sulix> But can you write about it in a Lit Review?
513 14:42 <@matches> Maybe not so much the Lit Review, but it means I can write the Background section that explains how they work
514 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
515 14:44 <@matches> The modern papers all have a lot of assumed knowledge
516 15:59 <@matches> Instead of reading papers I have progressed towards compiling different types and then overlaying them
517 16:02 <@matches> I didn't know you could do such cool things with Makefiles and flags to the compiler
518 16:02 <@matches> If people knew more about this maybe we wouldn't have to have python
519 16:03 <@matches> I will learn to do all my highlevel programming using Make
520 19:48 <@matches> Our Render/Screenshot combo for overlaying bitmaps and $$$ only works the first time it is done
521 19:49 <@matches> Or maybe it's RenderBMP that only works once
522 19:49 <@matches> Hmm
523 19:52 <@matches> I swear the format was BGRA earlier and now it's RGBA
524 19:53 <@matches> This can probably get fixed after some Literature Review
525 20:09 <@matches> Anyway you can now set the type of Real with `make DEF=-DREAL=X`
526 20:09 <@matches> Or `make single` and `make double`
527 20:09 <@matches> 0 and 1 respectively
528 20:09 <@matches> I tried a little bit too hard to get it working with actual C strings
529 21:32 <@matches> Minutes now have less "~*" in them
530 21:32 <@matches> Wrong channel
531 21:32 <@matches> Very wrong channel
532 --- Day changed Mon Apr 21 2014
533 12:32 <@matches> Literature Review O'Clock
534 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
535 12:43 <@matches> Uh oh
536 12:44 <@matches> stb_truetype ?
537 12:44 <@matches> DejaVuSansMono.ttf ?!
538 12:44 <@matches> Is this going to render a font...
539 12:45 <@matches> Woah
540 12:47 <@matches> Looks good
541 12:48 <@matches> I think I will avoid looking at stb_truetype too closely...
542 12:48 <@matches> Too late
543 12:48 <@matches> Why are all the implementations in the .h file
544 12:48 <@matches> And the .cpp file just has some defines...
545 12:48 <@matches> shudder
546 12:53 <@matches> I particularly like #define STBTT_assert(...) do {} while(0)
547 12:53 < sulix> That's a standard way of doing that. SDL_assert does the same thing.
548 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.
549 12:56 <@matches> But... your assert doesn't actually assert anything?
550 12:56 < sulix> That's because you generally only want it enabled in debug builds.
551 12:56 <@matches> I guess
552 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.
553 12:57 <@matches> So what is this "more code" going to do :P
554 12:57 < sulix> Slightly more modern opengl.
555 12:58 <@matches> Yeah, that would be a good idea
556 12:58 < sulix> In particular, uploading the content of a document to a VBO, and just re-rendering from that when needed.
557 12:58 <@matches> Cool
558 12:58 < sulix> Jumps from 9 fps -> 37 fps with 1024^2 objects.
559 12:59 < sulix> I've been without internet, though, so it's pretty broken in many ways, still.
560 12:59 < sulix> Like outline rects don't work.
561 12:59 < sulix> And it still uses a bunch of OpenGL 1.0 stuff.
562 12:59 < sulix> And for some reason the glPrimitiveRestartIndex() function isn't working.
563 13:00 < sulix> Also I need to write shaders at some point, which will be work.
564 13:00 <@matches> I just found the best comment in an IEEE email list
565 13:00 <@matches> We should totally use it
566 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"
567 13:01 < sulix> Oh man, that's basically the thesis in one sentance.
568 13:02 <@matches> Dibs!
569 13:02 <@matches> Although I doubt anyone will care if we both quote it
570 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.
571 13:03 <@matches> :O
572 13:03 < sulix> Then again, the book was (partly) written by (one of) the authors of fglrx, so take it with the requisite salt.
573 13:04 <@matches> Ah, so how many goats were required?
574 13:05 < sulix> Just the two, I think.
575 13:06 <@matches> This email message seems sort of vaguely relevant? It's the "infamous double rounding problem"
576 13:06 < sulix> I take it that you worked out how to swap between CPU and GPU transforms with right-click.
577 13:07 <@matches> I read it in the commit message
578 13:08 < sulix> I was quite happy with how much nicer things ran with CPU transforms and doubles.
579 13:08 <@matches> I think I can see a difference zooming in far enough
580 13:08 <@matches> Yeah that's a huge difference
581 13:08 <@matches> I had a tester that was going to automatically make images of the difference when you zoomed in really far
582 13:09 <@matches> But there were issues with the screen shot / bmp rendering
583 13:09 <@matches> Probably the bmp rendering
584 13:09 < sulix> .bmp files suck.
585 13:10 <@matches> They are nice and simple though?
586 13:10 <@matches> At least, the SDL API is nice and simple
587 13:10 < sulix> That's more a triumph of SDL than of the .bmp file format.
588 13:10 <@matches> After looking through gm6 files with a hex editor to try and extract sprites...
589 13:11 <@matches> Well we could always just fwrite the pixel buffer and fread it back
590 13:11 <@matches> If you want no one to be able to use our files without compiling our program :P
591 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/
592 13:13 < sulix> I'm probably going to get around to fixing all of the warnings in stb_truetype one day.
593 13:13 <@matches> Haha
594 13:13 <@matches> What about implementing an Oct-tree?
595 13:14 <@matches> So .bmp is just a header and then the raw pixel data? What's disgusting about that? No compression?
596 13:16 <@matches> Wait png is also just a header and then an IDAT section
597 13:17 <@matches> Oh well you can put lodepng in if you want I guess
598 13:17 <@matches> As long as I can open the images in eom
599 13:18 <@matches> Ah so PNG is compressed. I missed that
600 13:19 <@matches> Meh
601 13:19 <@matches> Oh and alpha channel
602 13:19 <@matches> Yeah
603 13:19 <@matches> I remember that now
604 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
605 13:21 <@matches> If you open things with alpha it gets really confused
606 13:23 < sulix> You can put alpha in .bmp files, but then they sometimes crash KDE.
607 13:26 <@matches> We can just run all our bmp files through image magick
608 13:26 <@matches> convert a.bmp a.png
609 13:26 <@matches> Done
610 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 -_-
611 13:27 <@matches> Actually gif
612 13:27 <@matches> Probably
613 13:28 <@matches> Since it has "Save as gif"
614 13:28 <@matches> But that is not relevant to this project
615 13:33 < sulix> Damn, just discovered that the opengl feature I was using for rectangle outlines is not supported by my laptop's hardware.
616 13:34 < sulix> (This explains one of the bugs I've been seeing, but sadly only one)
617 13:47 < sulix> Okay, remaining code pushed.
618 13:47 < sulix> I am sorry.
619 13:53 <@matches> I'm messing around trying to do something evil so I'll merge later
620 13:53 <@matches> But you don't seem to call ToggleGPUTransform when there is a right click
621 13:54 <@matches> Oh wait, I need to make clean
622 13:54 <@matches> Cool
623 13:54 <@matches> (So much for our Makefile magically tracking the header files :S)
624 13:58 < sulix> It does it for every header file except ones included by main.cpp because of the weird main.cpp swapping stuff.
625 13:59 <@matches> That main swapping stuff is amazing
626 13:59 <@matches> It is worth it
627 13:59 <@matches> Except main.cpp ends up eventually including all the header files
628 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
629 14:01 <@matches> But I'm normally used to running make clean anyway
630 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
631 14:23 <@matches> Whatever you have done does not look happy
632 14:24 < sulix> It takes like 5 minutes to DebugDumpObjects with a million objects, but it works okay* after that.
633 14:24 <@matches> Yeah ok
634 14:24 < sulix> *well, sort-of.
635 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.
636 14:25 <@matches> Interesting things happen when you zoom out really far
637 14:25 <@matches> Do we care about that
638 14:25 < sulix> I'm going to go with "no".
639 14:26 <@matches> Ah, but the rectangles are not all the same size
640 14:26 < sulix> This is a product of rounding to the nearest pixel. They'd be fine with antialiasing.
641 14:29 <@matches> I have pushed a single line contribution
642 14:29 <@matches> I decided not to bother with all the changes I made to make the video prettier
643 14:29 <@matches> Since I can't actually capture my desktop properly anyway
644 14:30 <@matches> I suppose I could make it render bmps and ffmpeg them all but that is way too much effort
645 14:31 <@matches> So
646 14:31 <@matches> Literature Reviews
647 14:31 <@matches> They are a thing
648 14:38 <@matches> I probably should not reference an email thread
649 14:53 <@matches> In other news, I think this jvm FPU doesn't actually implement sqrt
650 14:57 <@matches> It always gives 0x0 on sqrt ops
651 14:57 <@matches> I certainly hope there isn't a jvm somewhere that just doesn't do square roots
652 14:58 <@matches> They probably hacked it into some other part of their project instead of putting it in the FPU
653 16:08 <@matches> So fprintf style formatting isn't very clever when it comes to floats vs doubles vs long doubles
654 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
655 16:12 <@matches> s/truncating/casting whatever
656 16:52 <@matches> We can compile with long double
657 16:52 <@matches> I suspect this may break things but whatever
658 16:52 <@matches> Running calculatepi on motsugo to see how much difference it actually makes...
659 17:08 <@matches> Charles Babbage seems like an interesting fellow
660 17:09 <@matches> "e sought to prove the
661 17:09 <@matches> reality of the devil by drawing with his blood a
662 17:09 <@matches> circle on the floor and repeating the Lord’s prayer
663 17:09 <@matches> backward"
664 17:09 <@matches> The things one does for science
665 17:44 <@matches> Reading about Charles Babbage counts as Literature Review...
666 17:44 <@matches> Actually I'm trying to find a paper written *by* him
667 17:44 <@matches> Since apparently he came up with Floating Point representations
668 22:11 <@matches> Found an actual paper talking about floating points on GPUs
669 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
670 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
671 22:13 <@matches> This is probably of interest
672 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
673 22:15 <@matches> I also have a random obituary to Charles Babbage just because
674 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
675 22:17 <@matches> He has some books but they are mostly about economics
676 22:18 <@matches> Would have been nice if he'd written something that says "I have invented floating point" but I guess not
677 22:18 <@matches> That's only really of historical interest but it'd be nice
678 --- Day changed Tue Apr 22 2014
679 01:17 <@matches> Urgh looking at the git diff
680 01:17 <@matches> I really have not accomplished much
681 01:30 <@matches> Oooh, motsugo finally got to a number of intervals where long double is better than double
682 11:56 < sulix> So it turns out that I've broken the open-source GL drivers.
683 11:56 < sulix> They don't support one of the features ("primitive restart") we need when in compatibility mode.
684 11:56 < sulix> So I guess now I've got to rewrite everything to use OpenGL 3.
685 14:47 <@matches> ?
686 14:48 <@matches> I should probably look more carefully at what the OpenGL stuff is doing nowdays
687 14:49 <@matches> Downgrading to OpenGL 3 sounds drastic
688 14:50 <@matches> Wait 3 is the OK one, 4 is the new one
689 14:50 <@matches> 1 is the ancient one
690 14:52 <@matches> I see pointer arithmetic...
691 14:53 <@matches> banana would be furious
692 14:53 <@matches> should be using std::super_ptr_unsegfaultable_arith
693 14:53 <@matches> (I am not a fan of the smart pointers)
694 14:55 <@matches> *indexData = 0xFFFFFFFF; // Primitive restart.
695 14:55 <@matches> I do not know what is going on here :S
696 14:58 <@matches> Ahh I get it now
697 14:58 <@matches> Reading commit messages turns out to be useful
698 15:04 <@matches> git blame for view.cpp reveals that I still own the opening braces on some things
699 15:05 <@matches> That's about it :P
700 15:06 <@matches> I'm going to keep looking at rounding errors and maybe have a better thing than calculating pi
701 15:06 <@matches> As a bench mark
702 15:07 <@matches> I might look at Paranoia
703 15:07 <@matches> Although it was originally in BASIC
704 15:07 <@matches> And ~7000 lines
705 15:07 <@matches> With almost no whitespace characters
706 15:07 <@matches> And totally no indents
707 15:08 <@matches> I sometimes get the feeling people used to be smarter than we are now...
708 15:08 <@matches> Then I remember that those people are ultimately responsible for the tools we use now
709 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.
710 15:18 < sulix> Okay, we need to fix that makefile at some point.
711 15:38 <@matches> make clean?
712 15:41 <@matches> It's not actually swapping out main.cpp
713 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
714 15:42 <@matches> I guess that is swapping out main but MAIN is not being changed
715 15:42 <@matches> derp
716 15:45 <@matches> I think I fixed it?
717 15:45 < sulix> Ah. Well, you've got a merge conflict to look forward to.
718 15:45 <@matches> Not if I just NEVER COMMIT IT
719 15:46 <@matches> I'm going to call your fix being right and mine being a horrible hack
720 15:46 <@matches> Ok I pullsd some changes to graphics stuff, is that it or is there more?
721 15:46 < sulix> I haven't fixed it, I've just gone and bu(gg|ff)ered up the font stuff.
722 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?
723 15:48 <@matches> I see a lot of "Flushing Debug Font arrays"
724 15:48 < sulix> The debug font stuff is separate from the whole view system.
725 15:48 <@matches> That makes sense
726 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.
727 15:49 < sulix> One more step on the path of getting rid of all of the OpenGL 1.1 stuff.
728 15:50 <@matches> Haha
729 15:50 <@matches> git stash seems to think I modified graphicsbuffer.h and screen.h
730 15:51 <@matches> git diff seems to think everything is identical
731 15:51 <@matches> I'm just going to git reset the things I didn't actually change...
732 15:52 < sulix> I do that far too often.
733 15:52 <@matches> Oh there is a comment "//test" for testing the Makefile
734 15:53 <@matches> And a comment "This isn't the Screen class?" where you copy/pasted the screen class description for the GraphicsBuffer class
735 15:53 <@matches> I don't think they need to be preserved
736 15:54 < sulix> Yeah, I should have got rid of that screen class bit by now.
737 15:55 <@matches> Have a 2 line commit
738 15:55 < sulix> The best kind.
739 15:55 <@matches> I really need to cut back on the new line creep
740 15:56 <@matches> It's like I can't add a line by itself without putting in extra whitespace 
741 15:57 <@matches> Uh oh we've ran out of coffee here
742 15:58 <@matches> I'm slightly scared by how much the graphics code has increased since I last actually understood how it worked...
743 15:59 <@matches> Can you change those *vertexData to *(vertexData++) or is that considered even uglier
744 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.
745 16:03 < sulix> The plan is to have a nice AppendFloat() function or similar that will do this eventually.
746 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.
747 16:06 < sulix> Thanks nVidia.
748 16:06 < sulix> Now if only we were using OpenGL 4.4 which got rid of buffer usage hints entirely.
749 16:29 <@matches> Also I think you forgot the naming scheme :P
750 16:30 <@matches> vertex_data
751 16:31 <@matches> I will go back to pretending to be doing a literature review
752 16:32 <@matches> Instead I will probably plot some graphs
753 16:48 <@matches> So
754 16:48 <@matches> If you look up "Handbook of Floating Point Arithmetic" on google (which lots of things like to reference these days)
755 16:48 <@matches> You can download the entire thing
756 16:48 <@matches> I was prepared to pay like $20 for it on amazon
757 16:49 <@matches> Oh amazon doesn't sell actual books anymore though does it?
758 16:49 <@matches> No they do have it
759 16:50 <@matches> For $100...
760 16:50 <@matches> I think I'll just stick with my free pdf thanks
761 16:55 <@matches> "Handbook" being 579 pages...
762 17:04 <@matches> I think if a textbook is citing blog posts we can probably get away with it
763 17:05 <@matches> Oh my god I love this textbook
764 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."
765 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"
766 17:06 <@matches> [Complete C code for Program 1.1 follows]
767 17:06 <@matches> None of this "Pseudo code" crap
768 17:07 < sulix> Clearly we should get an extra 10% for every line of pointer arithmetic in our theses.
769 17:07 <@matches> There'
770 17:07 <@matches> s a problem here
771 17:07 <@matches> How do I not make the entire literature review just paraphrased from this one text book
772 17:08 <@matches> Mr Gullible and the Chaotic Bank Society!
773 17:08 <@matches> It has stories!
774 17:08 <@matches> Parents should read this textbook to their children
775 17:09 < sulix> I'm pretty certain I know someone with a data structures and algorithms picture book...
776 17:09 <@matches> That reminds me of a children's book I wrote about multithreading
777 17:10 <@matches> I should probably scan it one day
778 17:10 < sulix> Did it begin "Once upa timeon...
779 17:10 <@matches> I think it did actually
780 17:10 <@matches> Once upon a time there was a process who had a lot of work to do...
781 17:11 <@matches> "I should probably scan it one day" - Why not TODAY!
782 17:11  * matches goes searching
783 17:16 <@matches> It is no where to be found
784 17:16 <@matches> I distinctly remember going to throw it out and deciding not to, but not where it actually went
785 17:27 <@matches> So maybe compiling a bunch of HFPA's examples using our Real type is a good way to make benchmarks
786 17:27 <@matches> I don't know
787 17:27 <@matches> My part of the project seems to move further and further away from the document formats thing
788 17:27 <@matches> Maybe I'll try and compile the GPU Paranoia
789 17:28 <@matches> Hah
790 17:34 <@matches> It seems like whatever Mathematica does is what we should do
791 17:35 <@matches> I wonder if wolfram is open about how Mathematica actually works
792 17:35 <@matches> I don't think they are
793 17:35 <@matches> The CQM lecturer for physics found a bug in Mathematica's number representation once that she showed us
794 17:35 <@matches> Apparently she reported it years ago and it's still there
795 17:36 <@matches> This segued nicely into why we should learn fortran
796 --- Day changed Wed Apr 23 2014
797 14:00 <@matches> IEEE's float encoding is inconvenient
798 14:01 <@matches> The mantissa is like, reversed
799 14:01 <@matches> b_{23-i} * 2^{-i}
800 14:19 <@matches> And the implicit extra 1 except when it isn't is a pain in the ass as well
801 14:19 <@matches> It's like
802 14:19 <@matches> I can't just copy the right bits I have to think
803 14:19 <@matches> What is this
804 14:19 <@matches> Mental effort
805 14:19 <@matches> Blargh
806 14:20 <@matches> I should have just stuck with the 8 bit floats with their 2 sign bits
807 14:20 <@matches> The hydra float
808 15:17 <@matches> Wow you get really different representations with an IEEE encoding of the bits
809 15:17 <@matches> ...
810 15:17 <@matches> I think I liked just treating the two parts as integers in the order they were stored better
811 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
812 15:19 <@matches> Unless I'm missing some obvious trick
813 15:20 <@matches> But in IEEE the mantissa is not an integer
814 15:37 <@matches> Ooookkk
815 15:38 <@matches> You're precision doesn't disappear as fast when you do it that way
816 15:38 <@matches> Your
817 15:38 <@matches> Whatever
818 --- Day changed Thu Apr 24 2014
819 14:40 -!- You're now known as notmatches
820 14:40 -!- You're now known as matches
821 14:41 <@matches> Ok, less spammy channel time
822 14:41 -!- mode/#ipdf [+b m:matches!*@*] by matches
823 14:41 <@matches> Spam
824 14:41 <@matches> Dammit
825 14:42 -!- mode/#ipdf [-o matches] by matches
826 14:42 < matches> Spam
827 14:43 < matches> Yay
828 14:43 < matches> ... this will all appear in the next git commit won't it -_-
829 14:52 -!- You're now known as notmatches
830 14:52 -!- You're now known as matches
831 --- Day changed Sat Apr 26 2014
832 00:45 -!- mode/#ipdf [+o matches] by OperServ
833 00:46 <@matches> Incoming "at least it is self consistent in its wrongness" floating point conversion
834 00:48 -!- mode/#ipdf [-o matches] by matches
835 00:48 < matches> Still can't talk
836 00:48 < matches> Excellent
837 --- Day changed Sun Apr 27 2014
838 17:10 < sulix> I finally got ipdf working on my laptop again by porting everything to OpenGL 3.1.
839 17:10 < sulix> I'm so sorry about how ugly the code now is, by the way.
840 18:04 -!- mode/#ipdf [+o matches] by OperServ
841 18:04 -!- Pommers [bobgeorge33@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
842 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!
843 18:05 -!- Pommers [bobgeorge33@motsugo.ucc.gu.uwa.edu.au] has left #ipdf []
844 18:06 <@matches> Wat
845 18:06 <@matches> Well we've got that
846 18:06 <@matches> We just can't read pdfs
847 18:07 <@matches> Did you get much done not going to the cleanup?
848 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
849 18:08 <@matches> Then I looked at Frames' proposal and despaired at how much it is actually complete and has words in it
850 18:08 <@matches> I think he's onto something with his plan of actually writing things
851 18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf
852 18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf but the df stands for df
853 18:14 -!- matches changed the topic of #ipdf to: Sort of
854 18:15 <@matches> I need a script to auto mute me...
855 18:15 < sulix> I spent basically all of today on that one commit.
856 18:15 -!- mode/#ipdf [-o matches] by matches
857 18:15 -!- mode/#ipdf [+o matches] by OperServ
858 18:15 < sulix> Whether or not that was more useful than the cleanup remains to be seen.
859 18:16 <@matches> I should look at it I guess :P
860 18:16 < sulix> It compiles*
861 18:16 < sulix> *but has lots of warnings.
862 18:16 <@matches> It can't be worse than my tester that converts floats to floats
863 18:17 < sulix> I'm pretty certain it can be and is worse.
864 18:17 <@matches> However I've realised I kind of actually do need to be able to do that
865 18:17 <@matches> Woah 3k+ lines
866 18:17 <@matches> * 4k+ lines
867 18:18 < sulix> Most of it was autogenerated, but still...
868 18:18  * matches weeps for OpenGL 1
869 18:18 < sulix> You don't realise how much you miss it until it's gone...
870 18:19 <@matches> So what does all this stuff actually do
871 18:19 <@matches> Because I could see rectangles and things just fine without it
872 18:19 < sulix> Exactly the same thing as before but it works on my laptop now.
873 18:19 <@matches> I see a shader program, that's obviously good
874 18:20 <@matches> Actually I see code for a shader but no shader yet
875 18:20 < sulix> The shaders are all #defines, I'm afraid.
876 18:22 <@matches> What was wrong with your laptop?
877 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
878 18:23 < sulix> On the bright side, this paves the way for doing things like getting the GPU to use doubles.
879 18:26 <@matches> Ooh
880 18:27 < sulix> (also halves)
881 18:27 < sulix> (halfs?)
882 18:27 <@matches> Do GPUs use IEEE floats? I had a reference that seemed to be complaining they didn't
883 18:27 <@matches> Although it was circa 2007
884 18:28 < sulix> I don't think that there's a requirement that they internally use them, but they do read and write them.
885 18:28 < sulix> A bit like how x86 processors use(d) 80 bit reals internally and rounded when reading/writing to memory.
886 18:28 <@matches> Do halves have a different mantissa encoding
887 18:29 <@matches> The examples given on wikipedia seem wrong
888 18:30 < sulix> I think this is the canonical description: http://www.opengl.org/registry/specs/NV/half_float.txt
889 18:33 <@matches> That would be before IEEE specified half (binary16) but its the same summation for the mantissa anyway
890 18:33 <@matches> binary16 is (briefly) in the 2008 revised 754
891 18:34 <@matches> So I think wikipedia is giving a wrong example, but I'm not confident enough to go and change wikipedia
892 18:35 <@matches> Also I just realised my conversion of the mantissa to a Real is horrible
893 18:35 <@matches> Oh well, it can get fixed later
894 18:36 <@matches> Hopefully I can finish my fluid mechanics assignment quick enough to actually work on my progress report / proposal / thing
895 18:36 <@matches> (Hah)
896 18:36 -!- mode/#ipdf [-o matches] by matches
897 18:37 < sulix> Yeah, I'm going to see how much Lit review I can write for tomorrow. :/
898 --- Day changed Mon Apr 28 2014
899 22:06 -!- mode/#ipdf [+o matches] by OperServ
900 22:10 <@matches> Must find motivation to work on Lit Review at 10pm...
901 --- Day changed Tue Apr 29 2014
902 10:06 <@matches> Must find motivation to work on Lit Review at 10am...
903 --- Day changed Wed Apr 30 2014
904 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!)
905 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
906 13:04 <@matches> Before scaling
907 13:05 <@matches> I guess a screenshot tool might be the best way
908 13:06 <@matches> I don't know if I need to do this really
909 13:07 <@matches> I guess Mechanical and Chemical engineers marking this will probably benefit from having an example
910 13:07 <@matches> Doesn't everyone know the difference between vector and raster graphics
911 13:07 <@matches> Where was that paper that had tux vector and rasterised
912 13:10 <@matches> Ah, worth2003xr.pdf
913 13:11 <@matches> If it's in a paper I guess it can go in a Lit Review
914 13:11 <@matches> At least until I have something better
915 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
916 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
917 13:57 <@matches> Oh well
918 13:58 <@matches> I suppose "It looks shittier" will have to suffice without trying to make them look exactly the same before scaling
919 13:59 <@matches> I have spent WAY too long making this example
920 13:59 <@matches> I could have just gone "See \cite{worth2003xr.pdf}"
921 16:00 <@matches> So it might be worth talking about dpi in pdf viewers and how it SUCKS
922 20:17 -!- mode/#ipdf [-o matches] by matches
923 21:14 -!- mode/#ipdf [+o matches] by OperServ
924 21:46 <@matches> I have perpetrated XML on the codebase
925 21:47 <@matches> I have grand visions of our code supporting SVGs
926 21:47 <@matches> I also have grand visions of actually doing a Literature Review
927 21:50  * sulix git pull's with some trepidation.
928 21:52 < sulix> Never heard of pugixml before but it looks okay.
929 21:55 <@matches> The W3C XML specification is pretty terrifying
930 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
931 21:57 <@matches> Well SVG in particular
932 21:57 <@matches> SVG defines a "minimum" precision of IEEE binary32 
933 21:58 <@matches> But there's a specification for "High Quality" viewers that have to use binary64
934 21:58 <@matches> That's probably the only real thing relevant directly to our problem
935 --- Day changed Thu May 01 2014
936 01:23 <@matches> It's May 1st
937 01:23 <@matches> This means we can no longer say "The Literature Review is due Next Month"
938 01:23 <@matches> IT'S DUE THIS MONTH
939 01:23  * matches freaks out
940 01:23 <@matches> ... but after sleep
941 01:25 <@matches> Page 12 of my Literature Review by the way
942 01:25 <@matches> Is the only page I like
943 16:34 <@matches> The C version of paranoia compiled for me
944 16:34 <@matches> Not terribly exciting (I have an IEEE 754 compatible processor! Amazing)
945 22:17 <@matches> W Kahan's website is a very interesting if slightly difficult read
946 22:24 <@matches> He appears to have written this 80 page pdf in a day
947 22:27 <@matches> It kind of reads like one of those religious propaganda pamphlets
948 22:27 <@matches> "Java is the Work of Satan"
949 22:27 <@matches> "Kernighan-Ritcie C floating-point semantics are the light"
950 22:28 <@matches> But every so often he has a graph or example that makes him seem less crazy
951 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."
952 22:34 <@matches> Java has long double now right?
953 22:34 <@matches> Although that JOP I was looking at was just 32 bit
954 22:36 <@matches> Ah, java.lang.math.BigDecimal
955 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."
956 22:37 <@matches> That sounds horrifying
957 22:40 -!- mode/#ipdf [-o matches] by matches
958 --- Day changed Sat May 03 2014
959 22:01 < sulix> My crazy idea to you would be to research p-adic number representations.
960 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.
961 22:28 -!- mode/#ipdf [+o matches] by OperServ
962 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
963 22:29 <@matches> Maybe someone actually cares enough to research better ways
964 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)
965 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!"
966 22:31 < sulix> I think we want to truncate to whatever the most accurate you can see at the given zoom level.
967 22:31 <@matches> Yeah
968 22:32 <@matches> It annoys me that XML and HTML specs don't have a PDF version
969 22:32 < sulix> I've been printing to pdf for some of those things.
970 22:33 <@matches> None of the links to different sections would work though
971 22:35 <@matches> Specifications are thrilling
972 22:35 <@matches> "How to read this specification"
973 22:35 <@matches> "This specification should be read like all other specifications"
974 22:35 <@matches> Oh wait
975 22:35 <@matches> It actually gets better
976 22:35 <@matches> Is that...
977 22:35 <@matches> Humour!
978 22:36 <@matches> I thought that wasn't allowed!
979 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"
980 22:37 <@matches> As much as I love the idea of reading 626 pages of specification backwards...
981 --- Day changed Tue May 06 2014
982 00:39 <@matches> http://szmoore.net/ipdf/sam/rate-my-litreview.py
983 00:39 <@matches> Tim will be thrilled!
984 00:40 <@matches> I'm probably going to really regret making that
985 00:41 <@matches> The regret is rising to the surface
986 00:41 <@matches> It's an example of an interactive document format
987 00:41 <@matches> The pixels or perish guy would approve
988 00:43 <@matches> So much regret
989 00:43 -!- mode/#ipdf [-o matches] by matches
990 23:37 -!- mode/#ipdf [+o matches] by OperServ
991 23:38 <@matches> So, I have this book called "Computer Graphics" that is pretty amazing
992 23:38 <@matches> Funnily enough it has all the algorithms in it
993 23:38 <@matches> For computer graphics
994 23:38 <@matches> Probably should have been reading it ages ago but I thought we were worrying more about precision
995 23:38 <@matches> I don't even know anymore
996 23:39 <@matches> Have to read 500pg textbook on graphics, 500pg textbook on floating point numbers, 500pg PDF/PostScript standards...
997 23:39 <@matches> Too many pages
998 23:39 <@matches> Anyway it has a section on Octrees
999 23:39 <@matches> But don't worry
1000 23:39 <@matches> It mentions Quad trees
1001 23:39 <@matches> It also actually mentions fractals
1002 23:39 <@matches> As a thing
1003 23:40 <@matches> In other news, extending the document we have at the moment to allow anything other than rectangles will be interesting
1004 23:41 <@matches> Did you do this on purpose? :P
1005 --- Day changed Wed May 07 2014
1006 12:32 <@matches> We need to do something about all the warnings generated by the magic OpenGL 3 stuff
1007 12:32 <@matches> It's making it hard to sport warnings that I actually care about
1008 12:33 <@matches> Like: You forgot to return a value in this function :S
1009 13:52 <@matches> Gah I did it again
1010 13:52 <@matches> auto is dangerous
1011 13:53 <@matches> Possibly because it's buggy
1012 13:53 <@matches> I can't actually see any compiler warnings at all
1013 17:39 <@matches> So you can almost maybe see a difference between beziers calculated using floats and doubles
1014 17:40 <@matches> If you squint
1015 17:40 <@matches> And view them on different monitors
1016 17:41 <@matches> Ah there we go
1017 17:41 <@matches> I successfully broke it
1018 17:42 <@matches> When you round to pixel positions it doesn't make a difference
1019 17:43 <@matches> But on the other hand if you calculate beziers using really big numbers they look wierd :P
1020 17:43 <@matches> That's important
1021 17:43 <@matches> Because if you have an arbitrary infinite document you might be at coordinate positions that are really big
1022 17:43 <@matches> Captain Obvious strikes again
1023 17:45 <@matches> I think I will make a video of a circle moving towards infinity
1024 17:45 <@matches> This probably won't help the literature view much but it's too tempting to resist
1025 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
1026 --- Day changed Thu May 08 2014
1027 10:57 <@matches> So circle was a terrible example
1028 10:57 <@matches> It stays as a circle
1029 10:58 <@matches> Hopefully the first curve I tried wasn't just a bug
1030 12:31 <@matches> I think it was a bug
1031 13:35 <@matches> There are bezier things in ipdf/code/src/tests now
1032 13:57 < sulix> I am very confused. 
1033 13:57 < sulix> It generates bitmaps of circles in varying shades of red?
1034 13:58  * sulix decides to actually read the code.
1035 14:03 < sulix> Ah: I see what it's doing now.
1036 14:16 <@matches> Your first comment was pretty accurate :S
1037 14:17 <@matches> I was trying to obtain some amazing animation of a circle that hopelessly collapsed or exploded or something
1038 14:19 < sulix> I'm slightly terrified that it's generating a vector of points.
1039 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.
1040 14:19 <@matches> Yeah that's a bit lazy
1041 14:19 <@matches> Although, is returning a vector optimisable?
1042 14:20 < sulix> In C++11 it is.
1043 14:20 < sulix> (But not C++98)
1044 14:20 <@matches> C++11 is growing on me
1045 14:20 < sulix> Yeah: I've found the same thing.
1046 14:21 < sulix> I'm a bit scared about what that means, though.
1047 14:21 < sulix> Maybe one day I'll think boost was a good thing, and then I'll truly be lost.
1048 14:21 <@matches> Hahaha
1049 14:21 <@matches> The lambdas remind me of Javascript :S
1050 14:22 < sulix> I think lambdas are one of those things that are good for you in moderation, but poisonous in large quantities.
1051 14:22 <@matches> Probably
1052 14:23 < sulix> I won't be around on Monday, btw, so I'll miss the meeting.
1053 14:23 < sulix> (Also I'm missing out on Codejam, sadly)
1054 14:23 <@matches> No!
1055 14:23 <@matches> (To both of those things)
1056 14:24 <@matches> Oh god that means I need to make double the progress
1057 14:25 < sulix> I spoke to Tim, he said that it might be worth cancelling the meeting altogether.
1058 14:26 <@matches> Haha
1059 14:26 <@matches> I'm not sure if I should take that as a good or bad sign
1060 14:27 <@matches> I'm not going great with the literature review
1061 14:28 < sulix> I rated a bit of it.
1062 14:28 < sulix> (Though there wasn't a submit button, and it took me a few goes to get through the Turing test)
1063 14:28 <@matches> Page 20?
1064 14:28 <@matches> Haha
1065 14:28 <@matches> The turing test defaults to the accepted answer though!
1066 14:28 <@matches> You have to actually change it to get it wrong
1067 14:29 < sulix> Yeah, I thought it was a trick question.
1068 14:29 <@matches> Maybe I'll give Tim a slightly less joke-worthy version of Rate My LitReview when the draft is done
1069 14:29 <@matches> ... when hell has frozen over...
1070 14:29 <@matches> Whichever comes first
1071 14:31 < sulix> You should read James Mickens' USENIX articles: mkdir -p vogl/vogl_build/bin/release64 && cd $_                                                                                                                                                                                  
1072 14:31 < sulix> cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_X64=On ../../..                                                                                                                                                                         
1073 14:31 < sulix> make -j 10
1074 14:31 < sulix> (Also I should paste the right thing in)
1075 14:31 < sulix> http://research.microsoft.com/en-us/people/mickens/
1076 14:32 <@matches> Ah yes, I will read those at some point
1077 14:32  * matches downloads the first one, telling himself he will not read it until working on the lit review
1078 14:33  * matches reads it anyway
1079 14:33  * sulix feels guilty about not doing lit review at the moment, too.
1080 14:40 <@matches> Have you heard of /read Computer Graphics by Hearn and Baker?
1081 14:40 <@matches> I have the ancient "In the dawn before OpenGL 1.0" version
1082 14:41 <@matches> There is a section mentioning "GL"
1083 14:41 <@matches> I don't think they use GPU anywhere, they call them "Display Rasterisers" or something
1084 14:42 <@matches> Display Processor
1085 14:43 <@matches> A Display Processing Unit is a Display Processor for a Random Scan (vector) display system
1086 14:43 <@matches> Input devices are interesting too
1087 14:44 <@matches> "Input Dials"
1088 14:44 <@matches> A box of variable resistors basically
1089 14:45 <@matches> Working with computers in the 70s/80s would have been interesting although probably just as horrible as it is today
1090 14:45 <@matches> But at least it would have been less "webby"
1091 14:46 <@matches> Where "How do I centre a div" is a deep philosophical question
1092 14:48 <@matches> I should probably obtain / read a newer edition of this if I want to put it in my lit review?
1093 14:48 <@matches> Although it is referrring to the same papers we had about Bressenheim
1094 15:14 <@matches> Oh my god they mention precision!
1095 --- Log closed Thu May 08 17:04:49 2014
1096 --- Log opened Thu May 08 18:56:39 2014
1097 18:56 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
1098 18:56 -!- Irssi: #ipdf: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
1099 18:56 -!- Irssi: Join to #ipdf was synced in 3 secs
1100 19:55 < matches> Bresenham made a tutorial on rasterisation
1101 19:56 -!- mode/#ipdf [+o matches] by OperServ
1102 19:56 <@matches> Bresenham has a nice tutorial about rasterising
1103 19:56 <@matches> Ties in with the "Since mankind came down from the trees" angle
1104 19:57 <@matches> "Needlepoint or counted cross-stitch, such as that popularised by the image on a box of Whitman Sampler chocolates..."
1105 19:57 <@matches> I'm not sure how to relate the rasterisation stuff to the precision stuff
1106 19:58 <@matches> You have to make a pretty big rounding error to end up in the wrong pixel
1107 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
1108 19:59 <@matches> The (bigger) reason being that floating point operations are expensive
1109 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
1110 20:02 <@matches> I want to actually make a drawing of things that look different due to rounding errors dammit!
1111 20:03 <@matches> None of this "here is a sentence or two of handwaving"
1112 20:04 <@matches> Maybe rounding errors were a problem on computers with 8 bit floats and terrible resolution displays :P
1113 20:04 <@matches> Except the worse your resolution the less you'd notice rounding errors
1114 20:04 <@matches> Well the more you'd notice them, the less they'd happen?
1115 20:04 <@matches> I don't know
1116 20:05 -!- mode/#ipdf [-o matches] by matches
1117 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
1118 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 )
1119 21:21 < matches> I'll look at them at some point
1120 21:22 -!- mode/#ipdf [+o matches] by OperServ
1121 21:22 <@matches> I'll look at them at some point
1122 21:22 <@matches> I sort of got bogged down explaining how lines are drawn :S
1123 21:22 <@matches> Graphics is complicated dammit
1124 21:22 <@matches> I'll probably get more done if I just write about everything no matter how irrelevant
1125 21:23 <@matches> Sooner or later I'll actually write something important and the rest can be appendicised
1126 21:23 <@matches> Hopefully
1127 21:25 <@matches> Oh dear, I have located some primitive form of blog
1128 21:26 <@matches> Well, it talks about things, so I'll reference it...
1129 21:26 <@matches> "The good-looking textured light-sourced bouncy fun smart and stretchy page"
1130 21:26 <@matches> It's generally best to not go up a directory from the page you are looking at
1131 --- Day changed Sun May 18 2014
1132 15:47 <@matches> So things are due soonish
1133 15:47 <@matches> :S
1134 20:09 <@matches> Are you alive, because I don't think I'm alive
1135 20:10 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
1136 20:11 <@matches> I'm feeling pretty guilty about all that work I didn't do last week...
1137 20:47  * sulix agrees entirely.
1138 22:11 <@matches> I give up
1139 22:11 <@matches> I will just have to face disappointment O'clock tomorrow
1140 22:22 < sulix> I still have to put more work in before I feel I even deserve disappointment, I think... :/
1141 22:23 < sulix> I made the mistake of deleting the irrelevant bits from my lit review, and now there's almost nothing left!

UCC git Repository :: git.ucc.asn.au