65452d25a0a38953a439f99c3b90749a6f7a7aa4
[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!
1142 --- Day changed Mon May 19 2014
1143 08:03 < sulix> At the risk of causing terror: is your final Lit review due on Friday too?
1144 08:05  * sulix has discovered that his is, and is currently trying to work out how to type in the foetal position.
1145 09:59 <@matches> Yeah it's due on Friday
1146 09:59 <@matches> Today is not off to a good start
1147 10:00 <@matches> I missed an 8am lab but I can't blame the 2 buses I missed because I actually forgot about it
1148 10:00 <@matches> Then I missed the 2 buses
1149 10:00 < sulix> Ouch.
1150 10:00 <@matches> I think missing my tutorial this afternoon is a bad idea but on the other hand... lit review
1151 10:02 < sulix> I'm frantically writing irrelevant stuff now.
1152 10:03 < sulix> I'm a little concerned about my entire section on "Document Formats" basically only referencing some specs and "Pixels or Perish".
1153 10:03 <@matches> That's what I do
1154 10:03 < sulix> Whereas I have like 20 references for graphics papers that are almost totally irrelevant.
1155 10:04 <@matches> I have a reference for shading on a vector display
1156 10:04 <@matches> That's pretty irrelevant
1157 10:04 < sulix> I've started referencing data structures that are "kinda similar I guess" to the Quadtree, as well. :/
1158 10:05 <@matches> I ham fisted it in with the paper about embedding 3d figures in documents
1159 10:05 <@matches> Like "in the 70s even though people had algorithms for things they still drew the diagrams by hand!"
1160 10:05 < sulix> Peasants!
1161 10:06 <@matches> My section on number representations is pretty shite
1162 10:06 <@matches> I still haven't finished floats
1163 10:06 < sulix> Mine is currently under construction, as it were.
1164 10:06 <@matches> And the whole point is supposed to be that floats are not good enough
1165 10:07 < sulix> I've got a terrible thing about floats, but have started talking about arb. precision floats now.
1166 10:07 <@matches> All I know about the alternatives are that they are basically still floats
1167 10:07 <@matches> But with more bits...
1168 10:07 < sulix> I also have some maths I made up that is maybe wrong.
1169 10:07 <@matches> Will you be here in time for doom O'clock?
1170 10:08 <@matches> *cough* I meant eleven
1171 10:08 < sulix> We can but hope.
1172 10:08 < sulix> I'm sort-of counting on the meeting not happening until 11:20 or so. :/
1173 10:09 <@matches> I'll show him Rate My Lit Review
1174 10:09 <@matches> That'll distract attention from the lack of Lit Review
1175 10:09 <@matches> I'm also assuming no one is ever going to read these IRC logs
1176 10:09 < sulix> We can but hope.
1177 10:10 < sulix> I'm feeling dirty because I've just referenced the java standard library.
1178 10:10 < sulix> Out damnéd 
1179 10:10 < sulix> java.math.BigDecimal.
1180 10:15 <@matches> I was going to reference that at some point
1181 10:16 <@matches> I feel like you've made more progress than I have been
1182 10:17 <@matches> Possibly the decision to sleep last night was a poor one
1183 10:26 < sulix> Having done the opposite: it wasn't.
1184 10:30 <@matches> Argh I just got the icedove reminder for the meeting
1185 10:32 <@matches> So I washed out my Guild (TM) Keep Cup (TM) this morning and now my tea tastes like detergent
1186 16:37 <@matches> We didn't get the random asking about photoshop in here
1187 16:37 <@matches> I feel left out
1188 22:49 <@matches> sjy in #ucc mentioned Knuth's Metafontbook in regards to rendering fonts at infinite precision
1189 22:49 <@matches> Yet another thing to get around to reading :S
1190 22:49 <@matches> Before Friday :S
1191 22:50 <@matches> Wednesday I guess if we meet Tim's deadline for a draft :P
1192 23:08 <@matches> I guess I was meaning to reference the TeX book at *some* point
1193 23:08 <@matches> So many things
1194 23:08 <@matches> Oh dear it's 11pm already
1195 23:08 <@matches> :-(
1196 23:09 <@matches> Ok, so 
1197 23:09 <@matches> Metafont seems to basically be symbolic ways to define fonts
1198 23:10 <@matches> Also Beziers
1199 23:10 <@matches> All the beziers
1200 23:10 <@matches> Good
1201 23:11 <@matches> I was on the right track when I said Beziers were really important
1202 23:11 <@matches> Knuth is so detailed
1203 23:12 <@matches> Now I feel guilty about my cartesian line
1204 23:12 <@matches> That I didn't reference Rene Descartes La Geometrie 1637
1205 23:12 <@matches> I'm a monster
1206 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
1207 23:16 <@matches> Actually scratch that
1208 23:16 <@matches> I don't know anymore
1209 23:16 <@matches> It's too philosophical
1210 23:16  * matches goes back to floating point nubers
1211 23:18 <@matches> So I wonder how much of PostScript is a shameless rip off of METAFONT
1212 23:18 <@matches> It's not like you have to give credit when you are trying to sell something
1213 --- Day changed Tue May 20 2014
1214 09:29 <@matches> So it's quite easy to do a 
1215 09:29 <@matches> "fractal" in SVG/Javascript
1216 09:29 <@matches> Where easy does not necessarily mean it isn't horrifying
1217 09:30 <@matches> Aaand there goes all my RAM
1218 21:43 <@matches> Casually slipping in a footnote directing the reader to rabbitgame.net in my lit review...
1219 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
1220 21:44 <@matches> It is basically
1221 21:44 <@matches> "Here are the w3c standards"
1222 21:44 <@matches> "Here are some pretty pictures made with SVGs, can't you just see the DOM leaching out of them?"
1223 21:44 <@matches> :S
1224 21:45 <@matches> I'm not sure how well I am treading the line between actually reviewing literature and just giving examples of things
1225 --- Day changed Wed May 21 2014
1226 12:09 <@matches> PDF is a mess of a "standard"
1227 12:09 <@matches> As are all useful things I suppose
1228 12:09 <@matches> As far as I can work out
1229 12:09 <@matches> It is not a DOM but a graph
1230 12:10 <@matches> However, it is also PostScript-y
1231 12:10 <@matches> But they deal with "interactivity"
1232 12:10 <@matches> By including XHTML
1233 12:10 <@matches> And having an "action dictionary" which is literally just a string of javascript
1234 12:11 <@matches> I just
1235 12:11 <@matches> Can't even begin to understand how it all works
1236 12:12 <@matches> But yeah, not really "Crippled Postscript" so much as "Everything including the kitchen sink except for a few bits of Postscript"
1237 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
1238 12:13 <@matches> Oh and even though they have XHTML-ish stuff their Javascript API is totally different to W3Cs
1239 12:13 <@matches> Hooray
1240 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
1241 12:15 <@matches> I reckon the ideal standard
1242 12:15 <@matches> Would probably be the DOM but with the "we actually care about efficiency" parts of PDF
1243 12:18 <@matches> The interactivity of web pages combined with the actually professional looking type setting of PDF
1244 12:18 <@matches> Or just plain text files
1245 12:19 <@matches> Plain text files are an underapreciated Document Format
1246 12:23 <@matches> Ah, I think it sort of makes sense now
1247 12:23 <@matches> PDF uses what is essentially PostScript to construct this graph thing
1248 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"
1249 12:25 <@matches> And it can also have elements that are "Execute this Javascript to dynamically change this graph"
1250 12:25 <@matches> But the normal elements are just like PostScript as it would be sent to a printer to show the thing statically
1251 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
1252 12:26 <@matches> I *think*
1253 12:26 <@matches> This is different from the webby standards which don't really specify how things are actually drawn
1254 12:27 <@matches> No wait it's not
1255 12:27 <@matches> Argh I don't know
1256 12:27 <@matches> You can't classify this shit
1257 12:27 <@matches> Document Goes In -> Pixels Come Out
1258 12:28  * matches despairs
1259 12:49 < sulix> You will find (slightly) less despair if you relegate javascript to the footnote where it belongs. :P
1260 13:07 < sulix> Hmm... the HTML 2 spec looks like it almost got properly IETF standardised. Might just reference that.
1261 13:12 < sulix> Oh, they obsoleted it and replaced it with a "Just look at w3c" standard...
1262 13:17 <@matches> But PDF isn't just flattened PostScript
1263 13:17 <@matches> It is like, everything
1264 13:17 <@matches> All merged into one horrifying standard
1265 13:18 <@matches> Oh well
1266 13:18 <@matches> I made my shape example in PostScript by removing the alpha
1267 13:18 <@matches> I'm not sure whether there's any point in including it as a figure
1268 13:18 <@matches> Most of the PostScript file is taken up by the header
1269 13:19 < sulix> Holy balls, I just looked up the CSS spec. There are like 200 of them.
1270 13:19 <@matches> Yeah I just used CSS2
1271 13:19 <@matches> The others are like
1272 13:19 <@matches> Colours
1273 13:19 <@matches> Or something
1274 13:20 < sulix> That's what I'm using, too. 
1275 13:20 < sulix> The tired and tested "what gets top result on google" method of paper selection.
1276 13:20 <@matches> Closer examination reveals that most of the PostScript header is defining commands to be shorter :P
1277 13:20 <@matches> Amazing
1278 13:20 <@matches> Cairo probably needs to get referenced somewhere
1279 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
1280 13:21 <@matches> I desperately need to escape the Javascript
1281 13:25 < sulix> I think the secret is to use the phrase "rendering model" wherever possible.
1282 13:51 <@matches> Dammit
1283 13:51 <@matches> So I have that wierd shape in both SVG and PostScript now
1284 13:51 <@matches> The SVG version fits beautifully and is wonderfully concise and you can see how SVG works
1285 13:51 <@matches> The PostScript version is just like, BLARGH WALL OF TEXT
1286 13:51 <@matches> ALSO WE DON'T HAVE ALPHA
1287 13:52 <@matches> So I'm not sure whether to cut just the PostScript one or both of them now :S
1288 13:53 <@matches> PDF looks distinctly not like it is just PostScript the more I think about it
1289 13:53 <@matches> It's like "We are using the same model as PostScript in that commands go in and pixels come out"
1290 13:54 <@matches> By that logic SVG is also the same
1291 13:54 <@matches> I think what I should do is just make an appendix
1292 13:54 <@matches> "A Shape in 20 Document Formats"
1293 13:56 <@matches> SVG really is the most concise compared to PS and PDF
1294 14:53 <@matches> Right I can simplify the god awful mess of PS a bit
1295 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"
1296 14:54 <@matches> Cairo appeared to draw each element backwards and reverse it after drawing it
1297 14:54 <@matches> It is stupid
1298 14:57 <@matches> Like, why bother doing definitions like m == moveto etc
1299 14:57 <@matches> If you're just going to stick pointless crap in
1300 14:57 <@matches> My document is half the size without using single letter definitions
1301 15:31 < sulix> Welp. The wrath of Tim is upon us...
1302 15:41 <@matches> I'm choosing to latch onto the "quite good" rather than "some way to go"
1303 15:45 <@matches> It sort of sounds like "Well at least you gave me a pdf file" :P
1304 15:48 < sulix> One day, all anyone will use are ipdf files...
1305 15:50 <@matches> Right, TeX is very different from PostScript I think
1306 15:50 <@matches> At least, pure tex
1307 15:50 < sulix> Also, holy mackerel, I might have just found a paper on precision in document formats...
1308 15:50 <@matches> :O
1309 15:50 < sulix> It even quotes Kahan
1310 15:50 <@matches> :OOO
1311 15:50 < sulix> https://www.tug.org/TUGboat/tb28-3/tb90beebe.pdf
1312 15:50 <@matches> What is it
1313 15:50 <@matches> Emergency rewrite of entire lit review
1314 15:51 < sulix> It's a bit TeX specific, but still.
1315 15:51 <@matches> That's alright
1316 15:51 <@matches> It ties in amazingly with my decision to hamfist TeX and Metafont into the lit review
1317 15:52 <@matches> Although I'm not sure it is wise because it means I have to talk about fonts and things
1318 15:53 <@matches> I wonder if "Fonts are just bezier curves" is sufficient
1319 15:53 <@matches> They are always treated seperately to curved paths
1320 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
1321 15:54 <@matches> Anyway I'm glad my assertion that Beziers are the only curves we care about is proving true
1322 16:33 <@matches> Are you in a position to retrieve this "envelope"
1323 16:57 < sulix> Not tonight: I'm going to pick it up tomorrow morning.
1324 16:58 < sulix> And hopefully replace it with a sparkling, glorious review of literature.
1325 17:00 <@matches> :(
1326 17:00 <@matches> I cannot concentrate now
1327 17:00 <@matches> Because I haven't read the comments, I could be doing everything wrong!
1328 17:02 <@matches> Admitedly I'm technically "working" right now
1329 17:27 < sulix> My "Document Format Taxonomy" is almost complete... Just need to add SVG.
1330 17:28 < sulix> (And close my eyes and assert that Microsoft Word documents are not actually documents or something)
1331 17:28 <@matches> I am jealous
1332 17:29 <@matches> I just added PostScript it's not particularly well written
1333 17:29 < sulix> (I don't have any pretty pictures or code, though)
1334 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.
1335 17:32 <@matches> Bahaha
1336 17:32 < sulix> Do you know where the SVG spec mentions precision?
1337 17:33 <@matches> Ah, I regret not noting the page number
1338 17:33 <@matches> But a text search should find it
1339 17:33 <@matches> It specifically says things
1340 17:33 <@matches> I am interested in whether or not Javascript is subject to the same requirements
1341 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".
1342 17:35 <@matches> There's something that is about IEEE floats
1343 17:35 < sulix> Aaah... and a "High-Quality Viewer" must support at least double precision on coordinate system transforms.
1344 17:35 < sulix> But "IEEE" does not show up in a search of the spec.
1345 17:36 <@matches> Ah right
1346 17:36 <@matches> My brain just inserts IEEE whenever I hear "single" or "double" now
1347 17:36 <@matches> "An IEEE Double Episode of MasterChef!"
1348 17:36 <@matches> (Which would probably be infinitely more exciting)
1349 17:37 < sulix> (Or would it be NaNly more exciting...? :P)
1350 17:38 <@matches> Speaking of "where things are" are we meant to reference page numbers in standards?
1351 17:38 <@matches> I guess I'll find out when I read Tim's comments
1352 17:39 <@matches> Excellent my lab finished 20 minutes early
1353 17:39 <@matches> And also 40 minutes later than the other demonstrators :S
1354 17:40 <@matches> Do you want me to pick up your comments and scan them and email them to you? :P
1355 17:40 < sulix> That'd be great.
1356 17:40 < sulix> Also probably depressing.
1357 17:41 < sulix> But great.
1358 17:41 <@matches> Alright, ETA Transperth + Scanner is probably broken O'clock
1359 17:42 < sulix> I'll savour the blissful ignorance.
1360 19:50 <@matches> I don't think scanning is worth it, I'll just spam the feedback into this channel
1361 19:50 <@matches> First up, David's Lit Review
1362 19:50 <@matches> There is either "Gool" or "Cool" or possibly "Good" written and underlined on the first page
1363 19:51 <@matches> The opening paragraph is "A little overdramatic?"
1364 19:51 <@matches> (Since it's a question, I'd like to voice a "No" opinion here)
1365 19:51 <@matches> The DOM in a footnote is not defined
1366 19:52 <@matches> Page 2
1367 19:52 <@matches> There is a tick
1368 19:52 <@matches> A question mark in regards to the hyphenated bit in the rendering paragraph
1369 19:53 <@matches> Say "avoid" instead of lack
1370 19:53 <@matches> Add what the "basic primitives" actually are
1371 19:53 <@matches> There appears to be an issue with hyphenated phrases the hyphens are circled
1372 19:53 <@matches> Another tick!
1373 19:54 <@matches> Oh, you have a $2^64 - 1$\footnote{} which is unfortunate because it looks like $2^64 - 1^2$
1374 19:54 <@matches> That footnote (probably others?) would work in the paragraph without being footnote
1375 19:54 <@matches> Fullstops go after \cite{}
1376 19:55 <@matches> A tick (in regards to the quadtree diagram)
1377 19:55 <@matches> The concluding comment
1378 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"
1379 19:57 <@matches> And (not even our references lists are safe!)
1380 19:57 < sulix> Oh dear.
1381 19:57 <@matches> Where referencing web pages, include the date retrieved
1382 19:57 <@matches> That's it
1383 19:57 <@matches> I shall move on to my own for completeness although you might not need to care
1384 19:58 < sulix> Phew, that's not quite as horrible as it could have been, I guess.
1385 19:58 <@matches> I also have "Good"
1386 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)
1387 19:59 <@matches> Sorry Tim if you read this
1388 19:59 <@matches> But when I mark lab reports for Physics that's usually where I put the ticks :P
1389 19:59 < sulix> (The secret comes out)
1390 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...)
1391 20:01 <@matches> (It's the bits that I scribble all over that are where the marking gets done)
1392 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...)
1393 20:02 <@matches> Attention is called to the many glaring instances of [?] and "Refer to Section ?"
1394 20:02 <@matches> :S
1395 20:02 <@matches> I should probably define a vector image before comparing it to a raster image
1396 20:02 <@matches> Incidentally my Fox looks amazing
1397 20:02 <@matches> On printed paper
1398 20:03 <@matches> (Tim didn't say that, that's just my modest opinion)
1399 20:03 <@matches> Ahem.
1400 20:03 < sulix> Can you see the difference between the vector and bitmap versions easily?
1401 20:04 <@matches> At the original scale there is, alas, a very slight fuzziness
1402 20:04 <@matches> But I reckon the markers will be old and blind
1403 20:04 <@matches> Hmm, I should either be more careful about what I say here or stop logging this channel...
1404 20:04  * sulix hopes they don't read that.
1405 20:04 <@matches> Sorry markers
1406 20:04 <@matches> I worship your power
1407 20:04 <@matches> Please do not smite me
1408 20:05 <@matches> The scaled up version is interesting
1409 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
1410 20:06 < sulix> I guess the scaling would be done by the printer's postscript RIP.
1411 20:06 <@matches> Yeah I guess
1412 20:07 < sulix> (Side note: I find the whole idea of Postscript interpreters being called RIPs somewhat fitting)
1413 20:07 <@matches> The PDF decides not to antialias it and converts it to Postscript and then the postscript interpreter adds its own antialiasing?
1414 20:07 <@matches> I don't know
1415 20:07  * sulix joins the "SVG is the least broken format" club.
1416 20:07 <@matches> It's very tempting to descend into footnote madness with this lit review
1417 20:07 <@matches> "By the way, this very document is an example of this thing!"
1418 20:07 <@matches> Etc
1419 20:08 <@matches> Moving on
1420 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)
1421 20:08 <@matches> Or it could be "Why is there yet another ?? in this paragraph" I guess
1422 20:09 <@matches> But probably the former
1423 20:09 <@matches> I do not have space to include Bresenham's algorithm
1424 20:09 <@matches> Oh boy, he's going to love what I did with the SVG and Postscript images...
1425 20:09 <@matches> But I am glad I do not have to actually explain Bresenham's algorithm because it's actually annoyingly detailed
1426 20:11 < sulix> All sane descriptions of Bresenham's algorithm end up being cascades of "By symmetry" anyway.
1427 20:11 <@matches> I need to actually find a reference that applied Wu/Bresenham directly to a non-straight line
1428 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
1429 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"
1430 20:12 <@matches> But I think things might have advanced since the 1980s
1431 20:12 < sulix> Well, we can compute points that are closer together and draw more lines, I guess.
1432 20:13 <@matches> Next, Tim wants an example of a spline
1433 20:13 <@matches> (Oh boy have I got that covered)
1434 20:13 <@matches> My mathematics terminology on Beziers is not really great
1435 20:14 <@matches> Well it's right but confusing maybe
1436 20:14 <@matches> Or I just need to say "t is a trajectory parameter"
1437 20:14 <@matches> Haha
1438 20:15 <@matches> He found one of my "????" that is actually just me typing question marks and not a broken reference
1439 20:15 <@matches> The *entire* section on shading and compositing has a big question mark
1440 20:15 <@matches> Oh dear
1441 20:15 <@matches> I just finished writing the compositing bit
1442 20:16 <@matches> I hope the question mark means "Why isn't this written" and not "Why is this in here"
1443 20:16 <@matches> Because it is quite useful for an excuse to say PostScript can't do alpha
1444 20:17 <@matches> I need to refer to the IM (I really don't think that's a thing) and DOM when citing Hayes
1445 20:17 <@matches> "I don't think Turing Completeness is essential" (Big cross through the Crippled Interpreted Model)
1446 20:17 <@matches> Fair enough
1447 20:17 <@matches> A tick appears
1448 20:18 <@matches> Predictably in the web based documents part
1449 20:18 <@matches> I need to explain why Ipython is cool if I want to talk about it
1450 20:18 <@matches> My entire section on Precision as defined in the various formats is ?
1451 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"
1452 20:20 <@matches> The progress report gets a single tick
1453 20:20 <@matches> And the references have similar issues
1454 20:20 <@matches> Well
1455 20:21 <@matches> I'll take a few minutes to quiver in terror
1456 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
1457 20:22 <@matches> Interestingly he didn't call me out for just talking about standards
1458 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
1459 20:23 < sulix> It's going to be a long night, but I think we'll manage it.
1460 20:23 <@matches> Mine will be too long but I don't care
1461 20:24 <@matches> I'll ask for an extension to prepare a condensed version if I must :P
1462 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
1463 20:50 <@matches> Argh the idea of making my koch snowflake example for PS just got in my head
1464 20:50 <@matches> Which would be brilliant I guess if the topic was still "Fractal Document Formats"
1465 20:50 <@matches> It probably would be useful if I could demonstrate precision issues..
1466 20:50 <@matches> NO
1467 20:50 <@matches> MUST WRITE 
1468 20:50 <@matches> WORDS
1469 20:50 <@matches> NOT PICTURES
1470 20:51 <@matches> But still it would make the PostScript and SVG sections consistent with each other...
1471 20:51 <@matches> NO
1472 20:51 <@matches> Must control urge to put pointless pictures in
1473 20:51 <@matches> No matter how much it seems like a good idea
1474 20:51 <@matches> And not pointless
1475 20:52 <@matches> Help I'm losing this battle
1476 20:53 <@matches> It is probably actually a better way of making a Koch curve than the hideous Javascript parsing of strings version
1477 22:50 <@matches> By the way, you can totally have "pre layout" stages in PostScript since you can define your own operators
1478 22:50 <@matches> Or do I misunderstand your sentence
1479 22:50 <@matches> Oh well it sounds smart anyway
1480 22:51 <@matches> In fact it's a lot more concise than my DOM-y section
1481 22:52 <@matches> I should sign my Lit Review as Captain Obvious
1482 22:57 < sulix> My current version does have a "PostScript programs typically embody documents which have been type-
1483 22:57 < sulix> set, though as a turing-complete language, some layout can be performed
1484 22:57 < sulix> " sentence.
1485 22:57 < sulix> by the document.
1486 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.
1487 23:03 <@matches> I think I am managing to do it
1488 23:03 <@matches> I will commit something at some point
1489 23:03 < sulix> I'm hoping that rewriting most of the rendering section with painful discussions of algorithms will do it.
1490 23:03 <@matches> An example is Porter and Duff Compositing
1491 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
1492 23:04 <@matches> And not because they thought alpha was dumb :P
1493 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
1494 23:05 <@matches> And then I can sit back in satisfaction
1495 23:05 <@matches> And realise this says fuck all about precision
1496 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
1497 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.
1498 23:06 <@matches> Yeah I have that, but it was dot-pointed
1499 23:06 <@matches> I thought that would be OK actually but it has a question mark here... :S
1500 23:06 < sulix> Basically most of them say "implementation-defined" anyway.
1501 23:06 <@matches> Oh right because I was saying random stuff about how Postscript *used* to not have IEEE
1502 23:07 <@matches> Yeah it is odd that the standards don't actually reference IEEE
1503 23:07 <@matches> You'd think, since it's a standard...
1504 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"
1505 23:08 <@matches> I assume "single" is widely accepted to mean IEEE single
1506 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."
1507 23:08 <@matches> Ah I will check that more carefully
1508 23:08 <@matches> But it sounds about right
1509 23:08 < sulix> They give "typical limits" for their data types, but specifically do not specify what they are to be implemented as.
1510 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
1511 23:09 <@matches> PostScript also does a bunch of silly maths because of units
1512 23:09 < sulix> The idea being that each postscript interpreter could do whatever they liked.
1513 23:09 <@matches> Cool
1514 23:09 <@matches> I should know this already :S
1515 23:09 <@matches> I just included a single character as a figure
1516 23:10 <@matches> But I want to actually work out how to do it in LaTeX by setting the size of the font appropriately
1517 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"
1518 23:10 <@matches> I did see that
1519 23:10 < sulix> TeX using 14.16 fixed point.
1520 23:10 < sulix> DVI uses "up-to 32bit" signed integers.
1521 23:11 <@matches> So basically no one actually uses IEEE for anything :P
1522 23:11 <@matches> Good work
1523 23:11 <@matches> I shall panic a bit and then try and actually do that work myself
1524 23:11 < sulix> SVG uses "implementation defined" or "double-precision floating point" "for coordinate transforms" if you want to be certified "High Quality"
1525 23:12 <@matches> I saw that one
1526 23:12 <@matches> But I'm skeptical about how this plays with Javascript
1527 23:12 <@matches> Not for High Quality even, just in general
1528 23:12 < sulix> Javascript numbers are always IEEE 754 doubles.
1529 23:13 <@matches> Ah thanks
1530 23:13 < sulix> (Even their integers are IEEE 754 doubles, which just happen to be integers)
1531 23:13 <@matches> Yes I have heard this before
1532 23:13 <@matches> From you probably :P
1533 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.
1534 23:16 <@matches> Oh right, Javascript is actually ECMAscript
1535 23:16 <@matches> I forgot that
1536 23:17 <@matches> Dammit I am struggling to stay awake here
1537 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
1538 23:18 <@matches> Or sleep and then be more coherant tomorrow
1539 23:18 <@matches> I guess I'll try and finish a couple more sections
1540 23:19 < sulix> I'm going to try to finish this tonight.
1541 23:20  * sulix has another assignment due Friday that needs significant work.
1542 --- Day changed Thu May 22 2014
1543 00:47 <@matches> So X just managed to totally shit itself
1544 00:47 <@matches> Time to see when I last pressed Ctrl-S
1545 00:48 <@matches> Oh good (I typically press it once per sentence)
1546 00:48 <@matches> I hope it wasn't one of my SVGs that broke everything
1547 00:49 <@matches> Making all my figures in SVG
1548 00:49 <@matches> Lovingly hand written
1549 00:49 <@matches> I'm not sure that was a good idea
1550 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
1551 01:44 <@matches> 1.25*56
1552 01:45 <@matches> Disregard I appear to have mistaken this terminal for a calculator
1553 01:45 <@matches> They do look similar at this hour in the morning
1554 01:49 < sulix> I'm seriously doubting whether starting to write stuff about how all of the rasterizing algorithms work was a good idea.
1555 01:49 <@matches> Haha
1556 01:49 <@matches> I don't really have much rasterising as such
1557 01:49 <@matches> Straight lines
1558 01:50 <@matches> Beziers aren't really "rasterising" so much as defining curves
1559 01:50 <@matches> Then I mention fonts and how they are all bezier-ish
1560 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.
1561 01:50 <@matches> Then I have a bit on shading that I can't do
1562 01:50 <@matches> :S
1563 01:50 <@matches> That's probably not important
1564 01:50 <@matches> To quote Tim in my thesis regards to actually explaining algorithms
1565 01:50 < sulix> It turns out that if you clip the endpoints (even correctly), you adjust the slope of the lines slightly.
1566 01:51 <@matches> "No you don't have space. [...] details should be left to where they are useful"
1567 01:51 <@matches> Having said that absolutely none of this is "useful"
1568 01:51 < sulix> To fix it you have to initialize bresenham's "accumulated error" properly.
1569 01:51 <@matches> That sounds sort of relevant
1570 01:52 <@matches> Well I just copied some SVG into PostScript and discovered that the coordinates are all reflected :S
1571 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.
1572 01:52 <@matches> Bahaha
1573 01:53 <@matches> That sounds like work for the final lit review rather than this one
1574 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.
1575 02:05 <@matches> minipage for latex is great by the way
1576 02:06 <@matches> Like <div> but not awful
1577 02:40 <@matches> Oh year
1578 02:40 <@matches> The best spline curve example ever
1579 02:41 <@matches> Fuck it took about 3 hours to do that
1580 02:41 <@matches> Dear god
1581 02:41 <@matches> Ergh remind me to go censor the log before Friday 1am
1582 02:50 <@matches> I pushed my references changes by the way
1583 02:51 < sulix> Yay merging!
1584 02:51 <@matches> Oh I forgot the actual pdfs but whatever
1585 02:51 <@matches> I am jealous of your actual concise and to the point lit review
1586 02:51 <@matches> Mine suddenly exploded into figures
1587 02:51 <@matches> I should stop
1588 02:51 <@matches> I think I will delete the Shading section
1589 02:52 <@matches> No wait it would be a gap to take it out now
1590 02:52 <@matches> Argh
1591 02:53 <@matches> I will just have to resist the urge to put a diagram in showing how shading works
1592 02:53 <@matches> All these diagrams will probably kill me
1593 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.
1594 02:54 <@matches> Tim did seem strongly in favour of covering the rendering stuff
1595 02:54 <@matches> At least referencing the papers and giving the definitions of things if not actually how to render them
1596 02:55 <@matches> Anyway I think Beziers at least are important
1597 02:55 <@matches> I'm discovering a few interesting things about SVG
1598 02:56 <@matches> The path definitions are basically exactly the same as postscript's commands except less stack-y
1599 02:56 <@matches> But it has relative commands as well
1600 02:56 <@matches> Which is interesting because if you have a really really long curve defined with relative commands
1601 02:56 <@matches> Maybe, just maybe, it will actually cause a precision issue
1602 02:57 <@matches> I doubt it though
1603 03:00 <@matches> Well good luck, I am going to sleep
1604 03:01 < sulix> Thanks. I will see what I can say about Béziers.
1605 03:38  * sulix collapses.
1606 08:07 <@matches> Nice work
1607 08:07 <@matches> Mine is too detailed I think
1608 08:07 <@matches> It's horrible because now I'm committed to following through on that level of detail everywhere
1609 08:09 <@matches> Removing detail feels like murder
1610 08:12 <@matches> Would you be offended if I cited your lit review as a "more concise" overview for the bored reader? :P
1611 14:28 < sulix> So apparently the entire internet is talking about Bézier curves today.
1612 14:28 < sulix> This would have been really useful, say, yesterday.
1613 14:30 < sulix> Also this page looks amazing... http://pomax.github.io/bezierinfo/
1614 14:39 <@matches> Haha
1615 14:39 <@matches> I think I've got the Beziers covered
1616 14:39 <@matches> If you could just hop over to ratemylitreview and check me on that...
1617 14:39 <@matches> :P
1618 14:42 < sulix> Ratemylitreview has broken some of the equations...
1619 14:46 <@matches> If I had time I would include a "rate ratemylitreview" field
1620 14:46 <@matches> I sent an email
1621 14:46 <@matches> Now to fear the wrath
1622 14:47 <@matches> Half time
1623 14:48 <@matches> Haha I'm somewhat regretting choosing such condescending ratings
1624 14:49 < sulix> I got terrified seeing that email before I realised it was from you.
1625 14:49 <@matches> Bahaha
1626 14:49 <@matches> Well I have to give him something
1627 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\""
1628 14:51 <@matches> You can POST your own ratings but expecting that might be a bit much
1629 14:51 <@matches> They are emailed to me as text and they are also stored in the database as text
1630 14:51 <@matches> Not the most objective of systems :S
1631 14:51 <@matches> I thought the ratings covered all the bases though
1632 14:52 < sulix> You could always do what the Shakespeare proramming lanugage does. Positive adjectives +1, negative adjectives -1.
1633 20:18 <@matches> I haven't said half of what I thought I should about floats
1634 20:18 <@matches> Tim has been scarily silent :P
1635 20:19 <@matches> I guess I will assume that means everything is FINE
1636 20:19 <@matches> I finally got my Table of Contents and things to not take up 6 pages
1637 20:20 <@matches> I have to resist the urge to add some snarky comments to my section on LaTeX
1638 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
1639 20:22 <@matches> Blargh
1640 20:22 < sulix> Just stumbled upon a mention of numerical precision causing issues with Wu's algorithm in a book.
1641 20:22 <@matches> Cite it
1642 20:23 <@matches> Also give it to me to cite if I can stay awake long enough to read it
1643 20:23 <@matches> You have contributed some good last minute references
1644 20:23 <@matches> I seem to have contributed Javascript
1645 20:23 <@matches> I should be ashamed
1646 20:24 < sulix> It's in Abrash's Black Book, end of Chapter 42 ("Wu'ed in Haste; Fried, Stewed at leasure"(
1647 20:24 <@matches> Haha
1648 20:24 <@matches> My venerable graphics book doesn't even have Wu in it :S
1649 20:25 <@matches> It also doesn't really properly reference people's papers, or I guess you don't need to in a textbook?
1650 20:26 <@matches> It gives De Casteljau's method without crediting him for example. It does credit Bezier with things though.
1651 20:26 <@matches> But they clearly didn't have to worry about putting \cite{} after every single statement
1652 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
1653 20:27 < sulix> Casey from the Jeff & Casey show did a video blog on Bézier curves and interpolation this morning.
1654 20:28 <@matches> I really should start reading blogs more, but I was in no position to be watching blogs this morning
1655 20:28 < sulix> He claims that Bézier did not invent the Bézier curve, so why the hell are they named after him.
1656 20:28 <@matches> Had I known
1657 20:28 <@matches> Oh he didn't
1658 20:28 <@matches> I know that
1659 20:28 <@matches> That's in Metafont
1660 20:28 < sulix> I should read Metafont.
1661 20:28 <@matches> They were named after him because he was the first guy that said "These look useful for things"
1662 20:28 <@matches> However
1663 20:28 <@matches> I can't find the paper in a peer reviewed journal
1664 20:29 <@matches> I think it was for Industry (TM)
1665 20:29 <@matches> And also in French
1666 20:29 <@matches> I just cited a paper he did write in English about his experiences with Computer Aided Design
1667 20:29 <@matches> He doesn't define anything, just shows pictures of nice bezier curvey car bodies
1668 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.
1669 20:30 <@matches> De Casteljau's paper is also hard to find
1670 20:30 <@matches> The order of events was
1671 20:30 <@matches> 1912 - Bernshtein comes up with the basis polynomials for some sort of mathematical fitting
1672 20:31 <@matches> 1959 - De Casteljau decides to approximate the curves using his algorithm
1673 20:31 <@matches> (De Casteljau is only an approximation by the way, but it would converge to the true bezier curve)
1674 20:31 <@matches> 196? - Bezier does stuff
1675 20:31 <@matches> 1983/4 - Knuth decides to use them for fonts
1676 20:32 <@matches> Somehow they ended up in PostScript around that time as well
1677 20:32 <@matches> Now we're stuck with them
1678 20:34 <@matches> Hmm I hope my Tensor Equation is right there
1679 20:34 < sulix> Here's that Wu thing, btw: http://www.jagregory.com/abrash-black-book/#notes-on-wu-antialiasing
1680 20:36 <@matches> I'm struggling to make my floating point section sound sane
1681 20:36 <@matches> Too many little details
1682 20:37 <@matches> Like that you can choose different bases
1683 20:37 <@matches> What even is a number anyway
1684 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
1685 20:39 <@matches> Then computers can only fit X binary digits in their registers
1686 20:39 <@matches> A floating point is basically where you have a fixed point mantissa and then shift the location of the fixed point
1687 20:39 <@matches> Let's try and ignore the implicit leading one...
1688 20:40 <@matches> It sort of all falls apart when trying to fit IEEE in there
1689 20:40 <@matches> This thing is too big as well :(
1690 20:41 <@matches> Page limits are stupid
1691 20:42 <@matches> I can't remember what it even is but it's definitely less than what I have
1692 21:06 <@matches> Ah I see, the aliasing of Wu's line isn't perfect
1693 21:06 <@matches> I think Wu admits that
1694 21:06 <@matches> Hmm, that is interesting
1695 21:11 <@matches> Argh that blog is all like "We should use web based documents instead of PDF"
1696 21:11 <@matches> Pixels or Perish detected
1697 21:11 <@matches> To be fair it does actually look nice
1698 21:14 <@matches> The table of contents in the black book are quite amusing
1699 21:14 <@matches> No! I finished writing about graphics stuff I need to do floating stuff
1700 21:15 < sulix> It's a brilliant book, but possibly for another day.
1701 21:16 <@matches> Dammit I guess I do need to produce more figures
1702 21:16 <@matches> Sigh
1703 21:17 <@matches> A picture is worth a thousand words and all that
1704 21:17 <@matches> And therefore takes at least as long as writing a thousand words to make
1705 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
1706 21:27 <@matches> right
1707 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
1708 21:28 <@matches> I guess PDF would be more efficient though
1709 21:29 < sulix> That's pretty much the conclusion I've come to.
1710 21:31 <@matches> Unfortunately now I know more about SVG I keep hand editing my figures
1711 21:32 <@matches> I don't need to use gnuplot's terrible data point markers anymore!
1712 21:32 <@matches> I am free!
1713 21:40 <@matches> I particularly like
1714 21:40 <@matches> That I can make the points have alpha now
1715 21:40 <@matches> So if you plot overlapping points it is no longer impossible to see them
1716 21:40 <@matches> Of course we are restricted by the zoom in the pdf viewer...
1717 21:41 <@matches> This project is too meta
1718 21:41 <@matches> It is doing my head in
1719 --- Day changed Fri May 23 2014
1720 11:22 < sulix> Welp. Submitting this version: http://davidgow.net/stuff/LitReviewDavid.pdf
1721 11:23 < sulix> (The introduction has only got more over the top, I'm afraid)
1722 11:48 < sulix> Do you know what is happening/isn't happening RE: Revised project proposals?
1723 12:03 < sulix> Well: Literature review is submitted.
1724 12:03 < sulix> (In person to the coordinator, which is a little bit scary)
1725 --- Day changed Sun May 25 2014
1726 15:42 <@matches> No meeting tomorrow by the way
1727 15:43 < sulix> Ah. Cool. I have like 300 things to do.
1728 15:43 < sulix> Just pushed fixes for all of the compile warnings, btw.
1729 15:43 <@matches> Cool
1730 15:44 <@matches> I want to keep editing my Lit Review :S
1731 15:44 < sulix> I had thought that Float() always returns a "float", but it sometimes returns a double.
1732 15:44 <@matches> Oh
1733 15:44 <@matches> Whoops
1734 15:44 <@matches> Well a double is technically still a float...
1735 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)
1736 15:45 <@matches> Sigh
1737 15:45 < sulix> It was warning that I was losing precision from float x = Float(blah);
1738 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
1739 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.
1740 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
1741 15:46 <@matches> Ah
1742 15:46 < sulix> So casting any data pointer to a function pointer is apparently illegal.
1743 15:47 <@matches> That's annoying
1744 15:47 < sulix> Fortunately, gcc doesn't complain if you start the line that does it with "__extension__", so that's what we do.
1745 15:47 <@matches> Haha
1746 15:54 <@matches> Ok I am still about 3 days behind on sleep but I guess I should do work
1747 15:54 <@matches> Bye
1748 --- Day changed Tue May 27 2014
1749 12:49 <@matches> We missed the Computable Document Format (CDF) by Mathematica by the way
1750 12:49 <@matches> Wolfram would be offended
1751 12:50  * matches hopes none of the Mathematica fanatics read the lit review
1752 12:50 <@matches> Or this channel
1753 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
1754 12:54 <@matches> Maybe I'll add them in later
1755 12:55 <@matches> Frames does not seem to agree with my assertion that practically anything can be considered a document format :P
1756 12:55 <@matches> Plain text!
1757 12:57 <@matches> So I was looking through last year's Mech/Chem final year conference
1758 12:57 <@matches> Naturally there is nothing remotely like this project in there
1759 12:57 <@matches> :(
1760 --- Log opened Tue Jun 10 13:59:54 2014
1761 13:59 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
1762 13:59 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
1763 13:59 -!- Irssi: Join to #ipdf was synced in 3 secs
1764 16:29 -!- mode/#ipdf [+o matches] by OperServ
1765 --- Day changed Wed Jun 11 2014
1766 13:13 <@matches> JVB just asked me if it was possible to have a self updating pdf
1767 13:13 <@matches> I suppose he didn't ask whether it would be easy
1768 13:15 <@matches> As in, one that would download itself if there was a newer version
1769 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...
1770 13:18 <@matches> Hmm, a webserver running git and a cronjob and requiring authentication may solve his problem
1771 13:18 <@matches> With pdf.js or just relying on browsers to have pdf plugins
1772 13:18 <@matches> Wait why am I solving JVB's problem
1773 --- Day changed Fri Jun 13 2014
1774 16:31 <@matches> So exams have finished
1775 16:31 <@matches> Well my exams have finished
1776 16:32 <@matches> Now I can go back to panicking about the project again
1777 16:37 <@sulix> Excellent: it's your turn to do something impressive for the meeting on Monday, then. :P
1778 --- Day changed Mon Jun 16 2014
1779 14:49 <@matches> Some of this OpenGL stuff doesn't quite add up
1780 14:49 <@matches> Like m_cahed_display.UnBind(); m_cached_display.Blit();
1781 14:50 <@matches> Oh
1782 14:50 <@matches> I see
1783 14:50 <@matches> There is a difference
1784 14:51  * matches -> OpenGL documentation
1785 14:53 <@matches> Right I see
1786 15:03 <@matches> Well, this makes a lot more sense than tpg's "Adventures in VEMS" in #ucc at least
1787 15:18 <@sulix> Well that's an achievement, I guess.
1788 15:18 <@sulix> Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
1789 15:18 <@sulix> It's the spec for "nullptr"...
1790 15:20 <@matches> "Pointers are pretty cool. Pointers that are NULL are pretty cool. We address these issues by proposing nullptr" ?
1791 15:21 <@sulix> Haha: Pretty much.
1792 15:22 <@matches> Why not just reserve the word "null"
1793 15:22 <@matches> I could get behind it then
1794 15:23 <@matches> It is not a null reference
1795 15:23 <@matches> But if you ever have a null reference something is horrifyingly wrong
1796 15:23 <@matches> Bah humbug
1797 15:24 <@sulix> They have a page about that where they said "everyone was naming their variables \"null\"".
1798 15:24  * sulix realises he just escaped those quote. Oh dear.
1799 15:24 <@matches> A valid point, which should have lead to "Everyone are morons"
1800 15:24 <@matches> Fun fact
1801 15:25 <@matches> Matlab (like fortran actually) will let you use key words as variable names.
1802 15:25 <@sulix> "It's a feature!"
1803 15:25 <@matches> Question on CITS2401 exam: "Why is 'ii' preferred over 'i' and 'jj' over 'j' for loop iteration?"
1804 15:26 <@matches> Both i and j are the complex number sqrt(-1)
1805 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
1806 15:30 <@matches> Well I am infinitely wiser about nullptr now but I don't think it will stop me just using NULL
1807 16:15 <@matches> This is slowly starting to make sense
1808 16:35 <@matches> I'm having a bit of difficulty because it's all so optimised for the GPU
1809 16:35 <@matches> I think what we need is an ObjectRenderer class or similar
1810 16:36 <@matches> Have one for each type of object and implement RenderUsingGPU and RenderUsingCPU
1811 16:36 <@matches> I will see what monstrosity I can come up with
1812 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
1813 16:37 <@matches> I think there is an official software engineering term for that sort of thing...
1814 16:46 <@matches> Alright, breaking everything
1815 16:46 <@matches> This will probably take a while
1816 16:47  * matches dreads merges
1817 17:02 <@sulix> Yeah, I was going to basically end up with an ObjectRenderer class, too.
1818 17:02 <@sulix> So I'll leave it to you for now and procrasinate from doing my maths in some other way.
1819 17:07 <@matches> Cool :)
1820 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?
1821 17:52 <@matches> I guess we can fight about those later
1822 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
1823 17:54 <@matches> I have gone mad with power
1824 17:54 <@matches> Maaad
1825 20:30 <@matches> This ObjectRenderer is like a two headed hydra
1826 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
1827 20:31 <@matches> So it will have an ibo for the GPU and an array for the CPU
1828 20:35  * sulix thinks this makes sense.
1829 21:47 <@matches> Good news! I have things on the screen. Bad news. They are still on the GPU and they are wrong.
1830 21:49 <@matches> More coffee required...
1831 21:58 <@matches> Not sure if code wrong or fglrx having an existential crisis
1832 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
1833 22:05 <@matches> I imagine the OpenCL libraries etc actually use the IEEE floating point capabilities? I hope?
1834 22:05  * matches files under "beyond the scope of project"
1835 22:06 <@sulix> If you commit code I can test it on non-fglrx if that'll help.
1836 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
1837 22:06 <@matches> It'd be like vomiting all over the codebase
1838 22:07  * sulix is pretty sure half of his commits broke something.
1839 22:29 <@matches> Ok I committed stuff that should in theory work with the test pattern again
1840 22:30 <@matches> Using new and improved ObjectRenderer classes
1841 22:30 <@matches> For some definition of improved
1842 22:30 <@matches> It doesn't actually use the CPU yet
1843 22:30 <@matches> It'll get there
1844 22:33 <@matches> You can go and add your MandleBrotSetRenderer now though :P
1845 22:36 <@sulix> Cool.
1846 22:37 <@sulix> The circles do trigger that intel driver bug again, though...
1847 22:38 <@matches> Ah damn
1848 22:38 <@matches> Would making CIRCLE_FILLED the first ObjectType fix that?
1849 22:38 <@sulix> It does.
1850 22:38 <@sulix> (I just checked)
1851 22:38 <@sulix> Yay intel!
1852 22:39 <@matches> Haha
1853 22:49 <@matches> Hey, does our rendering approach completely break compositing?
1854 22:49 <@matches> Render all circles
1855 22:49 <@matches> Then render all rectangles...
1856 22:49 <@matches> There's no depth...
1857 22:49 <@sulix> Um, maybe.
1858 22:49 <@matches> :P
1859 22:49 <@matches> I was just worrying about how to make compositing work using the CPU
1860 22:49 <@matches> and then I realised it won't work using the GPU as it is either
1861 22:50 <@sulix> If we're not doing alpha-blending, we could just add a z-coordinate and use the z-buffer.
1862 22:50 <@sulix> Otherwise, they need to be sorted if they intersect.
1863 22:50 <@matches> Let's not worry about this for now...
1864 22:50 <@matches> Even though I spent a rather significant part of my lit review explaining how awesome compositing is
1865 22:51 <@matches> I guess it doesn't matter, clearly the lit review was not intended for anyone to actually read
1866 23:42 <@matches> I suspect RenderPixels doesn't work
1867 23:45 <@sulix> This may be the case.
1868 --- Day changed Tue Jun 17 2014
1869 01:05 <@matches> Behold the magnificence of CPU based rendering
1870 01:06 <@matches> In which we pass a massive pixel array to the ObjectRenderer's and just save it to a BMP
1871 01:06 <@matches> Because OpenGL
1872 01:06 <@matches> I'll probably fix it later
1873 01:11 <@matches> Whoops seg faults ahoy
1874 01:12 <@matches> Wait I swear it wasn't segfaulting before I commited that
1875 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.
1876 01:19 <@matches> That, is a certified result
1877 10:13 <@sulix> I got the CPU rendered version to show up on the screen.
1878 10:14 <@sulix> RenderPixels was pretty broken.
1879 10:38 <@matches> Nice
1880 10:39 <@sulix> I think the segfaults are it trying to draw outside of the display.
1881 10:39 <@matches> Yeah
1882 10:39 <@sulix> I haven't managed to zoom in too much yet.
1883 10:39 <@matches> My clipping is probably wrongish
1884 10:40 <@matches> fonttex_frag.glsl? Fear
1885 10:40 <@sulix> Yeah, the "basictex_frag" file did a bunch of pretty font-specific things.
1886 10:40 <@matches> Ah
1887 10:43 <@sulix> The CPU renderer also shows some random lines when there are no outlines on the screen.
1888 10:43 <@matches> Is it just me or does it look slightly nicer on the CPU when zoomed out a bit
1889 10:44 <@matches> Well it looks different
1890 10:44 <@matches> I can't quite work out whether it looks nicer or worse :P
1891 10:44 <@sulix> Okay, it doesn't segfault if the rectangle outlines are disabled.
1892 10:45 <@matches> Ah
1893 10:45 <@matches> Yeah it is setting top/bottom/left/right outside the pixels
1894 10:45 <@sulix> I think there are just some slightly different edge-case rules when zoomed out.
1895 10:47 <@matches> With my skills at writing renderers I should be working on the fglrx drivers
1896 10:47 <@matches> :P
1897 10:47 <@sulix> Things vanish if you zoom in too much, too.
1898 10:48 <@matches> Blame it on floats
1899 10:49 <@matches> The CPU renderer is using a width of 1 pixel less than it should be
1900 10:49 <@sulix> Why are the floats sinking? :P
1901 10:49 <@matches> That's unrelated
1902 10:49 <@matches> It's probably an integer rounding issue somewhere
1903 10:49 <@matches> When the view gets big something goes to zero
1904 10:50 <@matches> The CPU renderer transforms everything to pixel positions and then renders using those
1905 11:02 <@matches> The GPU renderer occassionally leaves off the corners of things
1906 11:02 <@matches> I never noticed before
1907 11:02 <@matches> Anyway I think the segfaults are fixed
1908 11:03 <@matches> Looking at the mysterious disappearances next
1909 11:04 <@matches> It's integer overflow!
1910 11:04 <@matches> Facepalm
1911 11:05 <@sulix> Is it int64_t time?
1912 11:05 <@sulix> Or magic huge bigint time?
1913 11:05 <@matches> No I don't think that's necessary
1914 11:06 <@matches> If the transformed width is smaller or larger than the width of the screen you can surely just ignore it
1915 11:06 <@matches> Well, depending on what you are drawing
1916 11:08 <@matches> Well it does matter unless you do some clever maths
1917 11:08 <@matches> The clever maths was your part of the project...
1918 11:09 <@matches> So I will just make them int64_t for now
1919 11:50 <@matches> Pushe
1920 11:50 <@matches> *d
1921 11:50 <@matches> I should probably just make all the coorinates into Real instead of int64_t actually
1922 12:03 <@sulix> Wow: this is pretty awesome.
1923 12:03 <@sulix> I still get the artefacts, but I have to zoom in a lot more.
1924 12:03 <@matches> Haha
1925 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.
1926 12:04 <@matches> That is nice
1927 15:20 <@matches> I'm trying to do a performance graph. Gnuplot doesn't like it much
1928 15:20 <@matches> Well actually it's python's crappy interface to gnuplot that doesn't like it
1929 15:23 <@matches> ... tempted to implement the performance graph in ipdf...
1930 15:23 <@matches> Just keep adding circles to the document
1931 15:24 <@matches> So meta
1932 15:25 <@matches> We need a cool performance graph-y thing
1933 15:26 <@matches> I think doing it in OpenGL is going to be the least shitty way actually
1934 15:26 <@matches> This is a wheel that's probably been invented but it was invented wrong
1935 17:11 <@matches> I've got a performance graph sort of working
1936 17:11 <@matches> It almost looks like we are doing real science!
1937 17:13 <@matches> I think we'll need to put some effort into our data analysis though because it's extremely noisy
1938 17:13 <@matches> Smoothing averages or something
1939 17:13 <@matches> Smoothing averages are the best
1940 17:14 <@matches> They make any data look amazing
1941 17:15 <@matches> Anyway, CPU rendering is only worse than GPU rendering when you force re-rendering
1942 17:16 <@matches> So well done with the amazingly efficient cached frame buffer
1943 17:18 <@matches> We can probably make it draw every frame both on the CPU and GPU to compare them in real time
1944 17:18 <@matches> The possibilities are limitless!
1945 17:19 <@matches> Graphs graphs graphs!
1946 17:20 <@matches> Also I did end up using Gnuplot and python (sorry) but I made it slightly less shitty
1947 17:27 <@matches> I have pushed things
1948 17:27 <@matches> Also we probably don't need all three of those ways to measure performance
1949 21:00 <@sulix> I got the graphs working on my laptop: very nice.
1950 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.
1951 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
1952 21:59 <@matches> Also the size of Real has to be constant
1953 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
1954 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
1955 22:04 <@matches> :S
1956 22:05 <@matches> You'll still want the struct of arrays because that will make view reparenting much easier
1957 22:05 <@matches> Gah
1958 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.
1959 22:06 <@matches> Yeah but you need to store an "indexes" array as well
1960 22:06 <@matches> But that might be the least terrible
1961 22:07 <@matches> Yes that should work
1962 22:07 <@matches> Our fwrite/fread is still doomed though
1963 22:07 <@matches> When shit gets Real
1964 22:07 <@sulix> Yeah, you'd need some indices one way or another.
1965 22:08 <@sulix> And yeah, we'll need a massive "ConvertWhateverRealIsStoredInTheFileToWhateverRealIsDefined" function or something.
1966 22:08 <@matches> That will totally be its name
1967 22:08 <@sulix> (Some old compilers had function name limits... I wonder if modern gcc has)
1968 22:09 <@sulix> (There is but one way to find out!)
1969 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
1970 22:10 <@matches> Which you probably will? So you can approximate beziers
1971 22:10 <@matches> Anyway I'll worry about adding Beziers first and once we've worked that out others should hopefully be easier
1972 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
1973 22:11 <@matches> Then you can make paths out of your beziers
1974 22:11 <@matches> But they won't be fixed size
1975 22:12 <@matches> Anyway I will see if you have magically solved the problem for me in the morning :P
1976 22:14 <@sulix> I wouldn't count on it...
1977 --- Day changed Wed Jun 18 2014
1978 16:50 <@matches> Behold, the glory of Beziers and Bresenham!
1979 16:50 <@matches> Breseniers I shall call them
1980 16:54 <@matches> I'm getting a very strong vibe of "Reinventing graphics technologies from the 1990s" at the moment
1981 16:55 <@matches> I should probably look at floating point some more
1982 16:55 <@matches> And reinvent numerical computation technologies from the 1980s
1983 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 ...
1984 16:56 <@matches> Argh
1985 16:56 <@matches> All the things
1986 17:00 <@matches> Maybe I'll multithread the CPU rendering too, just to make things more difficult :P
1987 22:48 <@sulix> So I got some béziers rendering on the GPU.
1988 22:48 <@sulix> They're not the ones in the document, and they're not in the right spots, though.
1989 23:12 <@sulix> First 3 béziers are rendering properly on the GPU, then we get corrupted memory or something.
1990 23:14 <@sulix> Ah: I see, I need some way of uploading which bézier IDs are being used.
1991 23:41 <@sulix> Okay, Béziers now render on the GPU as well.
1992 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.
1993 23:43 <@sulix> So we're basically uploading all of the raw document data into a huge texture.
1994 23:47 <@sulix> (If you ask me, the GPU ones also look slightly nicer, though that's probably a bug)
1995 --- Day changed Thu Jun 19 2014
1996 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
1997 13:57 <@sulix> (It's basically just a direct port of your CPU implementation, tbh)
1998 13:59 <@matches> When I zoom out the GPU ones look nicer, there's probably something wrong with my Bresenham implementation
1999 13:59 <@matches> Although it was mostly shamelessly copied from "Computer Graphics"
2000 13:59 <@matches> Except they were like "Here it is for 0 < m < 1, the rest can be done by symmetry"
2001 14:02 <@matches> The lines definitely have gaps on the CPU, and they also seem too thick as you zoom out
2002 14:02 <@matches> Having said that, I don't think the GPU starts at x0,y0
2003 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?)
2004 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)
2005 14:20 <@sulix> Fixed the missing bit off the end.
2006 16:43 <@matches> I suspect Rationals are either not a very good idea, or there is a bug in one of my fundamental operations
2007 16:43 <@matches> +, -, *, / are hard
2008 16:56 <@sulix> Is it at least a pretty bug?
2009 16:59 <@matches> Um...
2010 16:59 <@matches> No
2011 17:00 <@matches> It seems buggy for anything other than the {0,0,1,1} starting view
2012 17:14 <@matches> I suspect it's the expf in the mouse wheel scrolling
2013 17:14 <@matches> Since you know, exp is definitely not a rational number...
2014 17:15 <@matches> Hmm, but it shouldn't matter because it will just convert to the nearest rational number
2015 17:16 <@matches> ie: p = (int64_t)(whatever*1e10) q = (int64_t)1e10
2016 17:28 <@matches> Oh
2017 17:28 <@matches> Oh
2018 17:28 <@matches> Head -> Desk
2019 17:28 <@matches> Rational & operator*=(const Rational & r) {this->operator=(*this*r); return *this;}
2020 17:28 <@matches> Rational & operator/=(const Rational & r) {this->operator=(*this*r); return *this;}
2021 17:29 <@matches> Rational & operator-=(const Rational & r) {this->operator=(*this+r); return *this;}
2022 17:29 <@matches> I think the worst part is that I actually said "It is probably a bug in my +,-,*,/
2023 17:29 <@matches> And it still took me this long to notice
2024 17:30 <@matches> The second worst thing is I've made that sort of mistake like 1000 times before
2025 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"
2026 17:30 <@sulix> Feel the power of copy and paste flowing through you.
2027 17:32 <@matches> Well let's not celebrate just yet, the view still goes to shit. Just slightly slower :P
2028 17:33 -!- matches changed the topic of #ipdf to: NaNpdf
2029 17:33 <@matches> Our document supports a view of {-inf,-inf,nan,nan} thus making it truly infinite precision
2030 17:34 <@sulix> I had that happen a lot when I was writing the original zoom code.
2031 18:19 <@matches> So I suspect that Rationals are just a really shitty number representation :P
2032 18:20 <@matches> Specifically, you get integer overflows really really fast
2033 18:20 <@matches> And if you are going to have a Rational that's BigInt / BigInt you may as well just have a BigFloat
2034 18:21 <@matches> The ancients were probably right.
2035 18:21 <@matches> When they decided not to use rationals.
2036 18:23 <@matches> I guess floats are rationals technically, I mean the representation using P/Q
2037 18:23 <@matches> I kind of wish I'd done some pure maths here...
2038 18:23 <@matches> Or paid more attention in second year
2039 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"
2040 19:00 <@sulix> Floats are not rationals.
2041 19:00 <@sulix> Not exactly.
2042 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.
2043 19:01 <@sulix> e.g.: 1/3
2044 19:04 <@sulix> Basically floats = rationals where the denominator must be a power of two.
2045 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)
2046 19:18 <@matches> Yeah floats are a subset of the rationals I think I meant
2047 --- Day changed Sat Jun 21 2014
2048 16:22 <@matches> So I got a new smartphone today... I'm having fun trying to zoom in on things
2049 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
2050 16:25 <@matches> This is what I get for buying the cheapest phone with the lowest resolution they had :P
2051 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
2052 16:26 <@matches> Or months. Or years. But eventually.
2053 --- Day changed Mon Jun 23 2014
2054 11:51 <@matches> The meeting happened at ~11:30
2055 12:49 <@sulix> Oh damn. I thought there wasn't going to be one today.
2056 12:49 <@sulix> What did I miss?
2057 13:04 <@matches> Basically I told him what we'd done
2058 13:05 <@matches> Which was rendering on CPU or GPU, and Beziers (but only degree 2)
2059 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
2060 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.
2061 13:13 <@sulix> A lot of people have started quoting Kahan at him.
2062 13:20 <@matches> Haha
2063 --- Log closed Tue Jun 24 16:07:29 2014
2064 --- Log opened Tue Jun 24 16:17:39 2014
2065 16:17 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
2066 16:17 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
2067 16:17 -!- Irssi: Join to #ipdf was synced in 15 secs
2068 --- Day changed Wed Jun 25 2014
2069 21:41 < matches> So... if we need to put a HTTP server in IPDF I've got us covered...
2070 21:44 <@sulix> You terrify me.
2071 21:45 < matches> I still have to work out Websockets
2072 21:45 < matches> They are silly
2073 21:46 <@sulix> I take it they aren't compatible with regular sockets.
2074 21:46 < matches> Well you use a TCP socket, but they aren't just plain text
2075 21:46 < matches> There's a protocol on top of it
2076 21:46 < matches> It's wired
2077 21:47 < matches> *wierd
2078 21:47 < matches> There are frames and things
2079 21:47 < matches> And copious amounts of base64 encoding the SHA1 hash of a string prepended to a magic string
2080 21:48 < matches> Apparently this makes it more secure
2081 21:48  * sulix looks doubtful.
2082 21:48 <@sulix> I could understand it being more secure if they actually encrypted things.
2083 21:48 < matches> They have wss:// as well which is just the same thing through ssl
2084 21:48 < matches> Yes it doesn't make sense
2085 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.
2086 21:49 < matches> Haha
2087 21:49 < matches> I'd like websockets so I can control my robot via my phone through its web browser...
2088 21:50 < matches> I can probably do that without websockets but it will also be useful for humphrey the rabbit
2089 21:50 <@sulix> Surely with plain old TCP you could control your robot via telnet, which is more awesome and just as user friendly.
2090 21:51 < matches> :P
2091 21:51 < matches> It will have a webcam image though
2092 21:51  * sulix mutters "ASCII art" under his breath.
2093 21:52 < matches> I figure if I implement everything in C++ it will be less "Webby"
2094 21:52 < matches> And more segfaultastic
2095 21:52  * sulix has a new favourite word.
2096 --- Day changed Thu Jun 26 2014
2097 14:58 < matches> I think the WebSocket RFC put this "Framing" business in just to confuse people
2098 14:58 < matches> My RFC Compliant* WebSocket server just sends the entire message in a single frame
2099 14:59 < matches> Doesn't TCP already do framing or something
2100 15:00 < matches> I mean, they specifically allow for frames with up to 2^63 bytes
2101 15:00 < matches> Sorry, bits not bytes
2102 15:02 < matches> So server -> client is pretty much TCP but you stick some stupid frame guff on the message
2103 15:02 < matches> client -> server involves... "masking"
2104 15:02 < matches> There are several long paragraphs on it
2105 15:10 < matches> I'm going to pretend this is related to precision
2106 --- Day changed Wed Jul 02 2014
2107 17:30 < matches> I put the code repository on github
2108 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...
2109 17:32 < matches> "How many lines of code does it take to draw a rectangle?" 91000
2110 --- Day changed Fri Jul 04 2014
2111 12:59 < matches> Found my rational bug
2112 13:00 < matches> ...
2113 13:00 < matches> Copy paste strikes again
2114 13:00 < matches> My operator/ looked suspiciously similar to operator+ -_-
2115 13:00 < matches> -____-
2116 13:02 < matches> Not sure how it got like that, it was definitely working at one point
2117 13:02  * matches should probably use git properly
2118 13:12 < matches> Pushed it
2119 13:21 < matches> So yeah, it should work fine until you zoom
2120 13:21 < matches> Then crazy things happen
2121 16:44 < matches> I think all the references you added at the last minute break my litreview
2122 16:45 < matches> (he says several months later :P_
2123 21:00 <@sulix> Question: in Rational::Simplify(), why is (-P)/(-Q) becoming (-P)/(Q) rather than P/Q?
2124 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
2125 21:02 <@sulix> Also zoom can be improved (but not totally fixed) by reducing precision when overflow would be possible.
2126 21:19 < matches> Yeah, that's the idea of using the Stern Barcot tree Tim was talking about
2127 21:20 < matches> Which I still need to read about
2128 21:20 < matches> Also yes P should be -P because I am just that amazing at maths
2129 21:22 < matches> In other news assembly happened
2130 21:22 < matches> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s
2131 21:22 < matches> Which no doubt has terrible bugs in it :P
2132 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
2133 21:24 < matches> x64 is actually much easier though
2134 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
2135 21:25 < matches> Just got all the arguments in a bunch of registers
2136 21:31 <@sulix> I think I just worked out why you have 16 "inc" instructions, and am loving it!
2137 21:32 <@sulix> inc doesn't change flags!
2138 21:32 < matches> I wonder if it would be faster to just store the carry flag in a register though
2139 21:33 < matches> Actually probably not because there'd be branches involved
2140 21:33 < matches> Hmm
2141 21:33 <@sulix> Traditionally, mucking about with flags is slow.
2142 21:33 < matches> Yep cool
2143 21:34 < matches> I've got the AMD64 ABI
2144 21:34 < matches> Chapter 2 is a good one
2145 21:34 < matches> "Software Installation"
2146 21:35 < matches> "This document does not specify how software must be installed on an AMD64 architecture machine"
2147 21:35 < matches> End chapter
2148 21:35 <@sulix> Just a thought, can use use the lea instruction instead of all of those incs.
2149 21:37 <@sulix> Like lea rsi, [rsi+8h]?
2150 21:37  * sulix ponders.
2151 21:38 < matches> Maybe, my assembly is very rusty and was based on those ELEC1301 labs in the first place...
2152 21:38 < matches> I don't even remember if they had lea
2153 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")
2154 21:39 < matches> :S
2155 21:40 < matches> When did you last reboot?
2156 21:40 <@sulix> This morning, actually.
2157 21:40 < matches> Integer overflow in PID?
2158 21:40 <@sulix> It looks like it was an out-of-memory problem.
2159 21:40 <@sulix> On a related note, the intel instruction set documentation is a 3 and a half thousand page pdf.
2160 21:41 <@sulix> and firefox has a PDF viewer written in javascript.
2161 21:41 <@sulix> ...that runs by default.
2162 21:44 < matches> Hahaha
2163 21:44 < matches> Yes, pdf.js is apparently the best thing since sliced bread...
2164 21:45 < matches> I'm having some difficulty with lea, possibly the syntax
2165 21:47 < matches> "lea (%rsi+8), %rsi" is wrong
2166 21:48 <@sulix> Yeah, gcc's assembler uses whacked syntax.
2167 21:48 < matches> I thought it was just () instead of [], add % to all the registers, and swap destination and source
2168 21:48 <@sulix> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s;hb=HEAD
2169 21:49 <@sulix> They replaced the arithmetic operators with strange things, too.
2170 21:49 < matches> Riight
2171 21:49 < matches> Thanks
2172 21:49 < matches> So 8(,%rdi,1) means [rdi+8]
2173 21:49 < matches> That is dumb
2174 21:49 <@sulix> I'm not sure if it's worth using nasm or the ".syntax intel" directive.
2175 21:51 < matches> Hopefully there won't be too much more assembly to write...
2176 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))"
2177 21:51 <@sulix> in gcc
2178 21:51 < matches> ok
2179 21:51 < matches> Well once I know the syntax I can cope with it
2180 21:51 < matches> But all the documentation being written in a different syntax doesn't help :P
2181 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)
2182 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
2183 21:53 <@sulix> Hah: they were in "ckpatch" syntax.
2184 21:53 <@sulix> And were just the final output bytes.
2185 21:53 < matches> The memory can play strange tricks...
2186 21:54 <@sulix> I used the "debug.com" utility that came with dos to assemble them, which let you write assembly to arbitrary memory.
2187 21:54 <@sulix> and then read the contents of that memory to see what it assembled down to.
2188 21:55 < matches> So, I need subtraction and multiplication but not division to implement arbitrary rationals
2189 21:55 < matches> I'll try sort those out tomorrow
2190 21:56 < matches> I'm pretty sure I'm doing better than at least one arbitrary integer representation
2191 21:56 < matches> Which had a int32_t word and int64_t "double" word
2192 21:56 < matches> So they could tell if they had a carry by doing the additions using double words
2193 21:57 < matches> The code in C was longer than add_digits is in assembly
2194 21:57 < matches> Although to be fair it might actually work on things that aren't amd64
2195 21:57 <@sulix> Well, the good news is that there's an "sbb" instruction like "adc"
2196 21:57 < matches> Excellent
2197 21:58 <@sulix> The bad news is that multiplication is harder.
2198 21:58 < matches> Yeah, at least I don't need division though
2199 21:59 < matches> Although converting it to a string will be annoying
2200 21:59 <@sulix> IIRC, the IMUL instruction gives an output twice as long as the inputs, to prevent overflow.
2201 22:00 <@sulix> Converting to a string won't be so bad if you get division done.
2202 22:00 <@sulix> And you can always just implement multiplication and division by slow recursive addition/subtraction.
2203 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
2204 22:04 < matches> I guess I just need to implement as many things as possible and compare them all
2205 22:04 < matches> Seems easy enough...
2206 22:04 < matches> (Famous last words)
2207 --- Day changed Sat Jul 05 2014
2208 11:09 < matches> Well... subtraction took me two seconds
2209 11:09 < matches> Should probably have just done it last night
2210 11:09 < matches> I got distracted
2211 11:09 < matches> By someone actually using my websocket library
2212 11:09 < matches> Does this mean I'm officially an open source developer now
2213 11:09 < matches> I didn't even give it a license :S
2214 11:11 < matches> Hmm
2215 11:12 < matches> Multiplication...
2216 11:12 < matches> It is tempting to just use a for loop and call the += operator...
2217 11:40 < matches> I'll do that for now I think
2218 11:41 < matches> Once += actually works
2219 11:41 < matches> Turns out I will definitely need division also
2220 11:42 < matches> I was looking at the rationals going "There are no divisions here!"
2221 11:42 < matches> But there are
2222 11:42 < matches> In the gcd
2223 11:42 < matches> Mind you maybe I don't need to call gcd if I have arbitrary integers :P
2224 11:42 < matches> Just use all the memory
2225 12:39 < matches> Ok for loop for multiplication is not easy
2226 12:39 < matches> Bah
2227 12:39 < matches> Having to actually learn assembly properly
2228 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...
2229 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.
2230 12:47 < matches> True
2231 12:54 < matches> Putting "_asm" in filenames so that our Makefile can do the .s files is kind of irritating
2232 12:54 < matches> Would naming them .cpp work? That would be even more irritating though!
2233 12:54 < matches> Oh well it compiles
2234 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
2235 13:15 <@sulix> I'm told 256-bit integers can represent the visible universe to the width of a proton or something.
2236 13:45 < matches> I might put a maximum length in once this works
2237 13:45 < matches> So I'm not doing a Java
2238 13:46 < matches> Where 1/3 becomes "Runtime Exception!"
2239 13:46 < matches> That's with BigDouble not BigInt but whatever
2240 14:00 < matches> I must admit, assembly is pretty nice for this sort of thing
2241 14:00 < matches> At least, the inner operations
2242 14:00 < matches> Not for managing the memory
2243 15:29 < matches> Alright. We have an Arbint class that is equivelant to an int64_t when it only has one digit.
2244 15:30 < matches> I'm not sure how to test that extra digits function correctly
2245 15:30 < matches> Other than just looking at a few cases and going "Yep that looks right" :S
2246 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
2247 16:41 < matches> Currently 10% of the way through upgrading tex-live...
2248 16:41 < matches> The mystery of just how shitty the Arbints are will have to wait
2249 16:42 < matches> Well it's clear they are shitty but I suspect there is a bug in division
2250 16:42 < matches> Maybe I should actually read my code
2251 16:42 < matches> Blargh
2252 16:47 < matches> Ok constructing a rational takes infinite time
2253 16:51 < matches> Ah, 1 % 1 == 1
2254 16:51 < matches> That is definitely not correct :P
2255 17:56 < matches> Oh my goodness I just rendered a frame
2256 17:56 < matches> On the GPU...
2257 18:00 <@sulix> Hmm...  {add,sub}_digits_asm.s are missing from git.
2258 18:05 < matches> Really
2259 18:05 < matches> Whoops
2260 18:07 < matches> There you go
2261 18:07 < matches> Addition, subtraction, multiplication should be fine, I need to actually do division properly
2262 18:08 < matches> Also probably pow at some point
2263 18:08 < matches> Since pow still just casts things to doubles
2264 18:22 <@sulix> It works!
2265 18:22 <@sulix> (Eventually)
2266 18:24 < matches> Haha
2267 18:24 < matches> Of course it's still in the single digit range
2268 18:24 < matches> Or did you manage to wait long enough to zoom a bit
2269 18:25 < matches> I'm sure I can make this division better if I use some kind of binary searchish type algorithgm
2270 18:25 < matches> I could look up the proper algorithm too I guess
2271 18:25 <@sulix> Yeah, I was thinking binary search.
2272 18:26 <@sulix> You'd want a decent bitshift implementation.
2273 20:32 < matches> Yeah it is more difficult than I thought
2274 20:33 < matches> I'm going to need "shift_digits" assembly functions
2275 20:33 < matches> C style bit shifting has too many wierd edge cases
2276 20:36 < matches> 0x7000000000000000 >> 3 == 0x0e00000000000000 ?
2277 20:36 < matches> There are more bits set in the second number than the first!
2278 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
2279 20:39 < matches> Except for a carry
2280 20:39 < matches> So I'd have to do a loop one bit shift at a time
2281 20:39 < matches> Blergh
2282 20:40 < matches> I shall resume my epic battle with primary school level mathematics tomorrow
2283 --- Day changed Sun Jul 06 2014
2284 00:32 <@sulix> long division of an arbint by a uint64 worksish.
2285 09:47 <@sulix> long division of an arbint by a uint64 now actually works and is less obviously badly designed
2286 10:32 < matches> Thanks...
2287 10:33 < matches> In other news I seem to have broken X again
2288 10:34 <@sulix> Oh no!
2289 10:35 < matches> We need an ASCI renderer...
2290 10:36 <@sulix> That can not possibly end badly.
2291 10:40 < matches> shouldn't be too hard...
2292 10:40 < matches> Lets see if reinstalling fglrx works
2293 10:41 < matches> I need to add that to a boot script :S
2294 10:42 < matches> uhoh installation failed
2295 10:48 <@sulix> Hmm... enabling optimization makes Arbint segfault.
2296 10:49 < matches> You should probably make quadtrees
2297 10:50 < matches> Although I admit you're better at Arbints than me :P
2298 10:50 <@sulix> Yeah... I should.
2299 10:50 <@sulix> But segfaults...
2300 10:51 < matches> Yeah somewhere in std vector I had some as well
2301 10:51 < matches> I think I might change to a custom dynamic array
2302 10:52 < matches> Then fast copying is easier
2303 10:52 <@sulix> Yeah, it's segfaulting in std::swap somewhere, I think.
2304 10:52 < matches> I'll fix it when I have X
2305 10:53 < matches> Or an ascii renderer...
2306 10:54 < matches> Probably more realistic at this stage
2307 10:55 <@sulix> I'm pretty certain there's a unicode character for "face of disapproval due to fglrx bugginess".
2308 10:56 < matches> Yeah but when you try and render it you get a seg fault
2309 11:24 < matches> Woo, xvesa
2310 11:26 < matches> I see what you mean about fglrx being hard to remove
2311 11:58 <@sulix> So: quick profile. 98% of frame rendering time is spent in Arbint::Division.
2312 11:59 < matches> Yeah
2313 12:00 < matches> I *was* trying to install kcachegrind you know
2314 12:00 <@sulix> The vast majority of that time is spent in malloc and free.
2315 12:01 < matches> Well copy constructing an Arbint requires copy constructing the vector
2316 12:01 < matches> I'll investigate
2317 12:01 < matches> Now I have X again
2318 12:01 < matches> Go make a quad tree
2319 12:02 <@sulix> Also, should add_digits clear the carry flag at the beginning?
2320 12:02 < matches> Hmm
2321 12:02 < matches> Probably
2322 12:02 < matches> Yeah
2323 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
2324 12:09 < matches> But copy-on-write Arbint shouldn't be too hard
2325 12:09 < matches> Oh unless the original changes
2326 12:10 < matches> Yeah it would be hard
2327 12:10 < matches> I'm sure I did something like it before
2328 12:10 < matches> Back when I actually made my own data structures instead of just using std::vector
2329 12:15 <@sulix> My custom vector class: http://davidgow.net/stuff/DynamicArray.h
2330 12:15 <@sulix> Probably won't compile without a bunch of other files, though.
2331 12:16 < matches> I think I have several, in different versions of neurosis
2332 12:16 < matches> Which was never under git
2333 12:16 < matches> Some of them were prone to segfaults though
2334 12:17 < matches> So, will you have some kind of quad-tree-y thing by monday? :P
2335 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.
2336 12:18 <@sulix> I have a "struct QuadTree".
2337 12:18 <@sulix> (You can't do anything with it, but the basic idea is there)
2338 12:20 < matches> My shifting operators might not have been as fith as I thought last night
2339 12:20 < matches> Since 7 and e do actually have the same number of bits
2340 12:21 < matches> I'm not sure where that came from
2341 12:21 < matches> Ah dammit
2342 12:21 < matches> Cannot find -lGL
2343 12:22 <@sulix> Try just removing that from the Makefile
2344 12:22 <@sulix> I think when I GL-3'd everything I made it load libGL at runtime.
2345 12:23 < matches> Well it will compile but I get glx errors
2346 12:23 < matches> I get similar errors running glxinfo though...
2347 12:24 < matches> Odd
2348 12:26 <@sulix> I think you still have some of fglrx breaking things.
2349 12:26 <@sulix> It replaces the system libGL.so
2350 12:26 < matches> I installed mesa's stuff
2351 12:27 <@sulix> You need to also get the version of libGL that runs as part of the X server, IIRC.
2352 12:28 < matches> I'll try some apt-get --reinstalls
2353 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
2354 12:30 < matches> Well ok
2355 12:30 < matches> most of my problems were fglrx
2356 12:30 <@sulix> I remain sceptical that installing fglrx by hand will ever cause anything that is not pain.
2357 12:30 < matches> Well it worked better than the open source drivers for a very long time
2358 12:30 < matches> It all ended in tears and segfaults though
2359 12:32 < matches> Also it worked better than the non-free fglrx package in the debian repos which always ended in tears and segfaults
2360 12:33 <@sulix> I use the non-free nvidia package, which works fine, even if it is horribly outdated.
2361 12:34 <@sulix> I'm scared of the sheer amount of ripping up the rendering code getting quadtrees working will take.
2362 12:39 < matches> Haha
2363 12:40 < matches> It might be easier to do the CPU rendering in quad trees first?
2364 12:40 < matches> I'm not quite sure how you'll do it
2365 12:41 < matches> CPU rendering at least gives you direct control over the rendering target as a pixel buffer
2366 12:41 < matches> GPU rendering is a bit shady (ho ho)
2367 12:41 <@sulix> ...
2368 12:42 <@sulix> That was terrible, yet accurate!
2369 12:42 < matches> With the CPU rendering we're already passing the objects list, view, and target bounds
2370 12:42 < matches> So maybe you can adapt View or something to be quad-tree-ish
2371 12:43 < matches> Good luck
2372 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.
2373 12:47 < matches> Hmm, you could call RenderUsingCPU with a different target pixel buffer for each part of your quad tree or something
2374 12:48 < matches> Oh well, hopefully I can adapt whatever you do into RenderUsingASCII :P
2375 12:49 < matches> I don't need GLX working to try and fix division but I'd really like to have GLX working
2376 12:49 < matches> Sigh
2377 13:12 < matches> I'm making progress, instead of reporting an invalid operation glxinfo segfaults now
2378 13:13 < matches> So I have the wrong libraries or something... how to get the right ones...
2379 13:32 <@sulix> Woo. I got it compiling again!
2380 13:32 <@sulix> And the rendering is only half-wrong.
2381 13:33 < matches> Nice
2382 13:33 < matches> Manually deleting anything on my system with fglrx in it...
2383 13:34 <@sulix> Someone really needs to write an "fglrx removal guide".
2384 13:34 < matches> I'm not sure why reinstalling the radeon driver and mesa isn't actually giving me a libGL
2385 13:34 < matches> At least
2386 13:34 < matches> I suspect it is just leaving the existing broken one
2387 13:36 <@sulix> So it turns out that *2 I don't understand is important.
2388 14:01 < matches> Ok
2389 14:01 < matches> I have glxgears
2390 14:01 < matches> An epic achievement
2391 14:01 < matches> I had to go back to fglrx but at least this time its the debian packaged version
2392 14:02 < matches> The radeon driver seems to work better for stuff that isn't glx
2393 14:03 < matches> Which is pretty cool but I kind of like glx actually working
2394 14:11 < matches> Ok... time to fix division
2395 14:11 < matches> Finally
2396 14:11 < matches> No wait time for coffee
2397 14:11 < matches> Then time to fix division
2398 14:24 < matches> Did you test the div_digits function at all?
2399 14:25 < matches> # We want to point to the end of the buffer (LSB)
2400 14:25 < matches> Aren't I doing it the other way around...
2401 14:25 < matches> I'll test it
2402 14:28 <@sulix> With long division you do things in the opposite direction to addition.
2403 14:29 <@sulix> I tested it with some simple things and it worked.
2404 14:34 < matches> Hmm
2405 16:35 < matches> Well the good news is that division is faster now
2406 16:35 <@sulix> Cool!
2407 16:36 < matches> The bad news is that I can't see anything
2408 16:36 < matches> Even when GPU rendering
2409 16:36 < matches> Also segfaults
2410 16:36 <@sulix> I've just pushed some initial quadtree-enabling breakage.
2411 16:36 < matches> I didn't work out how to apply the div_digits to a multi digit number either
2412 16:36 <@sulix> Yeah, I thought about that, then went to bed.
2413 16:36 < matches> I might convert the current algorithm which is all based on bit shifting
2414 16:36 < matches> To assembly
2415 16:37 < matches> But maybe not
2416 16:37 < matches> Actually being able to see something render would be good even if it were slow
2417 16:37 < matches> Then I can think about making it faster
2418 16:38 <@sulix> The old one had all of the beziers connected for no readily apparent reason.
2419 16:38 < matches> I have a tester called "Arbitrary Rationals" (arbrationals.cpp) which sounds like some kind of political party
2420 16:39 < matches> A rather indecisive political party
2421 16:39 <@sulix> That's amazing.
2422 16:48 < matches> Ah, I might be having trouble with the sign of things, hm
2423 16:49 < matches> Rational 15625/288230376151727369 (0.000000) is not close enough at representing 1.000000 (1.000000 vs 0.001000)
2424 16:49 < matches> That doesn't look like a sign problem...
2425 16:52 <@sulix> I admit, 15625/288230376151727369 is not really similar to 1.
2426 16:54 < matches> So, somewhere along the way Arbint(1e6) became 15625 and Arbint(1e6) also became 288230376151727369 ?
2427 16:54 < matches> Uninitialised things?
2428 16:54 < matches> Constructing from int64_t seems fine
2429 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
2430 17:00 <@sulix> Ha: I've done that a few times.
2431 17:19 < matches> Maybe I shouldn't have pulled your latest commit
2432 17:19 < matches> Now I have two problems :(
2433 17:22 < matches> Meeting tomorrow
2434 17:22 < matches> "So how much progress have you made?"
2435 17:22 < matches> "Segfaults are up 100% to a record high!"
2436 17:26 < matches> Oh ok
2437 17:26 < matches> I'm not sure if this is new
2438 17:26 < matches> But if there is nothing in the document the GPU rendering doesn't like it
2439 17:27 <@sulix> Hmmm... there might be some issues with that.
2440 17:28 < matches> Ok
2441 17:28 < matches> Rectangle renders
2442 17:28 < matches> With arbitrary rationals
2443 17:28 < matches> In the default view
2444 17:29 <@sulix> Ooh!
2445 17:31 < matches> I'm going to commit this even though it's totally broken
2446 17:32 <@sulix> Things being broken hasn't stopped me from committing them.
2447 17:35 < matches> I love this though
2448 17:35 < matches> When you activate CPU rendering
2449 17:36 < matches> You get like a billion errors from Rational<Arbint>::CheckAccuracy
2450 17:36 < matches> And then the Bezier appears!
2451 17:36 < matches> Magically!
2452 17:36 < matches> I guess I shouldn't rule out a bug in CheckAccuracy :P
2453 17:36 < matches> Although zooming will definitely cause a segfault
2454 17:38 <@sulix> I tried running the really slow version under valgrind, but that turned out to be a bad idea.
2455 17:39 < matches> I've pushed the slightly less really slow version
2456 17:39 < matches> That is still really slow
2457 17:39 < matches> I can't install kcachegrind
2458 17:39 < matches> It is really annoying
2459 17:40 < matches> There aren't any valgrind analysis things that don't require the entirity of KDE are there?
2460 17:40 < matches> Or should I just learn how to read the raw output files
2461 17:40 <@sulix> Cool: it works.
2462 17:41 <@sulix> (I dunno, I just use KDE :P)
2463 17:41 <@sulix> You can try "perf" or "oprofile".
2464 17:41 < matches> Well I can't even install KDE :S
2465 17:41 <@sulix> They're terminal-based.
2466 17:41 <@sulix> Well, perf is, at least. There's a gtk+ oprofile gui.
2467 17:41 <@sulix> They both measure the entire system by default though.
2468 17:43 <@sulix> Rational::Simplify is ~54% of time (w/ GPU rendering) with the new build, according to callgrind.
2469 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
2470 17:50 < matches> I think the segfault might be related to my (ab)use of things like memcpy on std::vector::data()
2471 17:52 < matches> Also I think I've fixed my dependency hell
2472 17:52 < matches> Well
2473 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
2474 17:53 < matches> And much swearing will ensue
2475 17:54 <@sulix> Yeah, it segfaults immediately if you enable optimization level 2 or higher.
2476 17:55 < matches> Hm
2477 17:56 < matches> I'll probably get rid of std::vector then
2478 17:57 <@sulix> The problem I'm seeing is in the vector<Bezier>::push_back() bit, so who knows what is going on.
2479 17:58 < matches> Oh that's odd
2480 17:58 <@sulix> Okay, don't run it in valgrind.
2481 17:58 <@sulix> I'm getting about 200 "uninitialized values" a second in the nVidia driver.
2482 17:58 < matches> But I just installed kcachegrind!
2483 17:59 <@sulix> (Oh wait, that was with REAL=double)
2484 17:59 < matches> Haha
2485 18:00 < matches> Wait, vector<Bezier>::push_back causes problems even with REAL=double :S
2486 18:00 <@sulix> Nah, the nVidia driver seems to.
2487 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()
2488 18:02 < matches> Division
2489 18:02 < matches> Oh
2490 18:02 < matches> oooh
2491 18:02 < matches> > -> >=
2492 18:02 < matches> ...
2493 18:03 <@sulix> Well, my first attempt to fix it just broke rendering.
2494 18:04 <@sulix> Ah, yep, I see it.
2495 18:05 < matches> I think I need to do less memcpy/memseting and more std::vector::operator= -_-
2496 18:05 < matches> I mean, they implemented it for a reason
2497 18:05 <@sulix> So, with that change it no longer segfaults!
2498 18:05 <@sulix> (It corrupts memory and throws an exception instead)
2499 18:05 < matches> Woah
2500 18:06 < matches> I changed Arbint operator= to use std::vector operator=
2501 18:06 < matches> And now I get a filled circle on top of my bezier...
2502 18:07 < matches> Ok, I will rewrite Arbint to just rely solely on std::vector operations
2503 18:08 < matches> That might slow it down but it's impossible to test that the maths works properly with all these memory errors
2504 18:09 <@sulix> Should you be using m_sign more often?
2505 18:09 <@sulix> It seems to be "forgotten" in a number of places...
2506 18:10 <@sulix> Hmm... everything looks like it's working at the moment, actually.
2507 18:10 < matches> What else did you change?
2508 18:10 < matches> Try zooming
2509 18:11 < matches> That will break it
2510 18:11 <@sulix> Zooming seemed to work, actually.
2511 18:11 < matches> Are you sure you compiled with REAL=5
2512 18:11 < matches> The sign is a bit wierd
2513 18:12 <@sulix> It works for a little bit, then the view bounds suddenly become huge.
2514 18:12 < matches> Haha
2515 18:12 <@sulix> For no reason, the y coordinate jumps to 10^8.
2516 18:13 <@sulix> Also after you've zoomed, sometimes translating goes in the wrong direction or is otherwise broken.
2517 18:15 < matches> That might be related to m_sign...
2518 18:15 < matches> The joys of implementing your own number representation
2519 18:16 <@sulix> Trying to "fix" the sign fixed zoom, but broke translation even more.
2520 18:18 <@sulix> Also: best representation of 1 ever: 9223372036854775807/9223372036854775807
2521 18:18 < matches> Hahaha
2522 18:18 < matches> Oh
2523 18:18 < matches> I think I commented out a Simplify() somewhere :P
2524 18:18 < matches> No
2525 18:18 < matches> I didn't
2526 18:18 < matches> Hmm
2527 18:19 < matches> Well I am going to push some minor changes
2528 18:20 <@sulix> Also: T g = gcd(T(llabs(P)),T(llabs(Q)));
2529 18:20 <@sulix> Is that "llabs" truncating everything?
2530 18:20 < matches> ...
2531 18:20 < matches> Probably
2532 18:20 < matches> !
2533 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.
2534 19:05 <@sulix> I do not want to know how that is possible.
2535 19:05 < matches> Heh, I was trying to do that before dinner
2536 19:06 < matches> I just got segfaults
2537 19:08 < matches> Oh 
2538 19:08 < matches> I see
2539 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.
2540 19:08 < matches> Yeah
2541 19:08 <@sulix> But first I'll have to get X working again.
2542 19:08 < matches> The problem with overriding llabs is that the constructor for Arbint calls llabs...
2543 19:08 < matches> And Arbint has a constructor from int64_t...
2544 19:09 < matches> So as soon as you implement llabs using Arbint it will call itself for eternity
2545 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.
2546 19:09 < matches> Bahaha
2547 19:10 <@sulix> Then X started using 100% of my CPU and nothing responds to anything.
2548 19:10 < matches> :S
2549 19:10 <@sulix> The mouse cursor still moves, but everything else is a black screen.
2550 19:11 <@sulix> Excellent, "sudo pkill -9 Xorg" has made everything work again.
2551 19:12 <@sulix> (And even fixed an unrelated problem, which is good but worrying)
2552 19:17 <@sulix> Note to self: if something crashes X when you run it once, don't run it again after fixing X.
2553 19:18 < matches> Haha
2554 19:18 <@sulix> Now to try it for a third time.
2555 19:18 < matches> I've got an abs working
2556 19:18 <@sulix> Ah, excellent.
2557 19:19 <@sulix> Does it make things better? Worse? The same but slower?
2558 19:19 <@sulix> Crash X?
2559 19:20 < matches> It doesn't crash X but I think I have an infinite loop in gcd now
2560 19:21 < matches> I should probably work out why X/X for really big X is not simplifying to 1/1
2561 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
2562 19:43 < matches> As opposed to
2563 19:43 < matches> "1/2 == 0.5" yep looks good she'll be right
2564 19:43 < matches> One could say
2565 19:43 < matches> There are *signs* of serious problems
2566 19:44  * matches puts on sunglasses
2567 19:44 < matches> No wait I got the order wrong
2568 19:44 < matches> Oh well I wasn't cool enough to watch that show anyway
2569 20:18 < matches> So now I have a tester that actually tests things
2570 20:18 < matches> I just need to blindly fumble around with m_sign until all the tests are passed!
2571 20:18 < matches> Right?!
2572 20:26 < matches> Heh, it's amazing how many errors fixing the sign in Division prevents
2573 20:27 < matches> Well amazing until you realise that every single Rational calls a division at least once
2574 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.
2575 20:46 < matches> Yeah
2576 20:46 < matches> It should work nicer nowish
2577 20:46 < matches> At least, the tester works most of the time...
2578 20:46 < matches> It still randomly fails sometimes
2579 20:46 <@sulix> Yeah, it's working much better.
2580 20:46 < matches> Now 12% of the time is in std::vector::size()
2581 20:46 <@sulix> All of the things I've seen have been to do with subtraction in ScaleAroundPoint()
2582 20:47 < matches> Ah
2583 20:47 < matches> Wait I haven't pushed the 12% in std::vector::size yet
2584 20:47 < matches> tl;dr I was allocating one extra digit every single addition operation and then deleting it if it wasn't used
2585 20:48 < matches> Because I am just that good :P
2586 20:48 < matches> I suspect the Arbint is going to break when it actually does need to resize itself
2587 20:49 < matches> But for now I will settle for "At least as good as an int64_t"
2588 20:49 < matches> * But slower
2589 20:49 <@sulix> I'm curious as to why digit_t is int64_t and not uint64_t.
2590 20:49 < matches> Oh it is uint64_t now
2591 20:49 < matches> It was int64_t mainly because geany doesn't syntax highlight uint64_t
2592 20:50 <@sulix> Ah.
2593 20:50 < matches> Then I realised being int64_t instead of uint64_t broke the shift operators
2594 20:50 < matches> Because they try to preserve the sign
2595 20:50 <@sulix> Shift on signed ints is undefined behaviour, IIRC.
2596 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
2597 20:52 < matches> Zooming is still incredibly slow
2598 20:54 < matches> In fact it is infinitely slow
2599 20:54 <@sulix> I once waited about 10 minutes and did get another frame.
2600 20:54 < matches> In fact the Arbint appears to want to grow an infinite number of 0L digits
2601 20:55 <@sulix> Ah ha! I have realised why CheckAccuracy is only throwing errors on "-".
2602 20:55 <@sulix> The CheckAccuracy calls for everything else have been commented out,
2603 20:55 < matches> They should all be commented out so I can use tests/realops.test instead
2604 20:57 < matches> 23 / 12000 operations failed... doesn't seem too bad...
2605 20:58 <@sulix> Keep in mind that == isn't precise as it casts to doubles.
2606 20:58 < matches> You get more like 40 out of Rational<int64_t>
2607 20:58 < matches> Yeah they are "equal" if it is within 1e-1 :S
2608 20:58 < matches> I'm searching for the more totally catastrophic failures like the wrong sign first :P
2609 21:20 < matches> Ok tomorrow I might just try using boost arbitrary integers or something
2610 21:28 <@sulix> All of the failures I'm getting are with "/="
2611 21:28 <@sulix> Except one, which was only just outside the error bounds, so probably the doubles' fault.
2612 21:30 < matches> I was restricting the test values somewhat though
2613 21:30 < matches> (With rand()%100 + 1)
2614 21:33 <@sulix> You do know that the Rational<Arbint> -> double conversion is totally broken if either P or Q have > 1 digit.
2615 21:33 < matches> Yeah I noticed that
2616 21:37 <@sulix> Oh man, re-enabling the operator double on Arbint totally breaks things.
2617 21:40 < matches> Yeah don't touch it
2618 21:40 < matches> Basically touching anything will totally break something else
2619 21:40 < matches> :S
2620 21:40 < matches> I should probably sleep some more before attempting to fix things
2621 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.
2622 21:41 < matches> Ah ok
2623 21:41 < matches> I thought unary - was equivelant to "0 - x" but I suppose that doesn't make sense
2624 21:41 <@sulix> Nah, it has to be written explicitly.
2625 21:44 <@sulix> Okay, I think I've got realops.test down to 0 errors with Arbint.
2626 21:45 < matches> Well you're doing better than me
2627 21:46 <@sulix> I'm running it with a huge number of tests now.
2628 21:47 <@sulix> 85.95% of my entire computer's processing time is in IPDF::Rational<IPDF::Arbint>::operator/=
2629 21:48 < matches> Can you push what you have?
2630 21:48 <@sulix> Yeah, I will in a second.
2631 21:48 <@sulix> It's basically a lot of hacks.
2632 21:49 <@sulix> CPU rendering is broken, though.
2633 21:49 < matches> There were cases where it would grow an infinite number of digits; did you fix those?
2634 21:49 <@sulix> Probably not: it still gets very, very slow zooming.
2635 21:51 < matches> Yeah there's something wrongish it shouldn't need extra digits so fast
2636 21:51 <@sulix> Pushed now.
2637 21:52 <@sulix> Now to look at the diff and see what I actually changed.
2638 21:53 < matches> Oh
2639 21:54 < matches> Simplify call in Rational operator= is good
2640 21:56 < matches> I think I fixed some more bugs but I also introduced an infinite loop so...
2641 21:57 < matches> How is the quad tree bit going :P
2642 21:57 <@sulix> Yeah, about that...
2643 21:58 < matches> Remember Arbints don't have to work for quad trees to work :P
2644 21:58 < matches> Or do they
2645 21:58 <@sulix> In theory, no.
2646 21:58 <@sulix> In practise, it probably depends on how one defines "success".
2647 21:59 < matches> I think we need to design a test pattern where you actually want to zoom forever
2648 21:59 <@sulix> Highly theoretically, I'm pretty certain the QuadTree basically ends up isomorphic to the Arbint.
2649 21:59 < matches> Seems legit
2650 21:59 < matches> Can you prove it?
2651 21:59 < matches> That would be a useful result
2652 21:59 <@sulix> Yes*
2653 22:00 <@sulix> *hopefully
2654 22:00 < matches> I'm afraid most of my "theory" is based solely on intuition at this point :S
2655 22:00 < matches> Well the division algorithm came from wikipedia but division isn't as intuitive as the other operations
2656 22:01 < matches> Actually if I can fix all these other stupid bugs I'll try my binary searchish division idea
2657 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.
2658 22:02 <@sulix> That's really, really easy in asm, as well, which is nice, but not quite as useful as I'd hoped.
2659 22:02 < matches> It's pretty useful; we can still have a "if div.m_digits.size() use the assembly function"
2660 22:02 < matches> * size() == 1 that is
2661 22:02 <@sulix> Wikipedia mentioned doing newton-raphson for division, which is a terrifying thought.
2662 22:02 < matches> Haha
2663 22:03 < matches> So I've got Arbint::Shrink() calls pretty much after every operation now for no apparent reason
2664 22:04 <@sulix> Does it help?
2665 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
2666 22:05 < matches> I can't work out what it is
2667 22:05 < matches> I have a GrowDigit that spams Debug messages now
2668 22:05 < matches> So its not that
2669 22:05 < matches> It's silent
2670 22:05 < matches> Let's see what callgrind has to say
2671 22:06 < matches> A few minutes should be enough for it to be obvious right
2672 22:07 < matches> I think the division loop runs forever
2673 22:07 < matches> Bugger
2674 22:08 < matches> Wait that doesn't make sense there's only 1 digit
2675 22:08 < matches> Blargh
2676 22:17 <@sulix> So using the asm version when possible makes realops.test 20x faster, but there were a couple of failed tests.
2677 22:18 <@sulix> I'm not sure if they're new or not, because I was able to run many more tests.
2678 22:20 <@sulix> Also, I think I've found your infinite loop.
2679 22:23 <@sulix> Okay, maybe I've just obfuscated the code some more.
2680 22:24 < matches> Infinite loop is due to subtraction bug
2681 22:24 < matches> I'm pretty sure
2682 22:24 <@sulix> Yeah, pushing a "fix"
2683 22:26 <@sulix> Pushed, but think I might have found a bug in the fix.
2684 22:26 < matches> Ok
2685 22:27 < matches> (0,0) - +(16292953875657448384,1) = -(16292953875657448384,2) seems wrong
2686 22:28 <@sulix> Pish! Nothing could be more beautiful.
2687 22:28 < matches> It's pretty hard to debug with such huge numbers :P
2688 22:31 <@sulix> Try this...
2689 22:31  * sulix pushes.
2690 22:32 < matches> What does that do...
2691 22:33 < matches> oh
2692 22:33 < matches> You negate the entire thing and add one
2693 22:33 < matches> Seems legit
2694 22:33 <@sulix> So "two's complement" negatives mean that -A == flip all bits of A and add 1.
2695 22:33 < matches> Yeah
2696 22:34 <@sulix> There seems to be a bug in the asm div_digits though.
2697 22:35 < matches> I'm taking that out until I know the main algorithm works :P
2698 22:35 < matches> Silly I spent so much time wondering why division was broken without checking subtraction
2699 22:36 < matches> After I spent all that time thinking I was so clever for doing division using bit shifts and subtractions
2700 22:37 <@sulix> It still takes forever.
2701 22:37 <@sulix> (Zooming in, that is)
2702 22:37 < matches> Nah there's still a bug
2703 22:37 < matches> You're running with an older version of realops test
2704 22:37 < matches> Hang on
2705 22:37 < matches> I will push things
2706 22:38 < matches> Trying to avoid a merge...
2707 22:38 <@sulix> And I will get a drink.
2708 22:44 < matches> So if you run enough tests you eventually get a bunch of SubBasic spam
2709 22:45 < matches> Which is actually occuring due to "<" operators
2710 22:45 <@sulix> Yeah: I'm going to add a bunch of hacks to "<" at some point.
2711 22:45 < matches> Which are in the Division loop ( >= is implemented in terms of <)
2712 22:45 < matches> Don't add the hacks until subtraction works!
2713 22:46 < matches> I don't want to optimise it yet
2714 22:46 < matches> Otherwise all the optimisations hide the bugs
2715 22:47 < matches> Time for a tester that just does subtractions I think
2716 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.
2717 22:49 < matches> Most of the tested numbers can be represented in a single digit which is causing problems
2718 22:50 < matches> With finding the bugs in the multi-digit algorithm
2719 22:52 < matches> For small enough multi digit Arbints testing against doubles might work?
2720 22:52 <@sulix> Maybe.
2721 22:53 <@sulix> You'd lose enough precision that it's not worth it for anything > 2 digits, I'd say.
2722 22:53 < matches> Yeah, 2 digits should be enough to make sure the algorithms actually work though
2723 22:54 < matches> 2 digits in one operand and 1 in the other (which will resize itself to have a leading zero if necessary)
2724 22:55 < matches> At some point I am going to have to use a library for Arbints and compare ours to it
2725 22:55 < matches> But I kind of want ours to work properly before bringing in an external one
2726 22:56 < matches> When I try floats I might just bring in the external library :P
2727 22:56 <@sulix> Two questions:
2728 22:57 <@sulix> 1. What is "borrow" supposed to be? Is it the "carry" or the "result has changed sign" or something else?
2729 22:57 <@sulix> 2. What do you think of replacing Sub() with Add() + Negate()?
2730 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
2731 22:59 < matches> and 2 sounds like an excellent idea
2732 23:00 <@sulix> Okay.
2733 23:00 <@sulix> 'cause there's a separate "carry" flag and "sign" flag, so I wasn't sure.
2734 23:01 < matches> subtract actually working would be slightly faster than add and then negate I think
2735 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.
2736 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
2737 23:04 < matches> I should check whether sbb does unsigned or signed subtraction
2738 23:04 <@sulix> Both, I think.
2739 23:04 <@sulix> 2's complement makes them the same, which is why it's so nice.
2740 23:04 <@sulix> But it requires a fixed number of bits to work.
2741 23:09 < matches> Whoops now the bit shift tester runs forever as well
2742 23:13 < matches> Oh no it doesn't
2743 23:13 < matches> It just exceeds the limit on GrowDigits
2744 23:14 < matches> Phew
2745 23:14 < matches> Bit shifting works at least
2746 23:14 < matches> Or at least it is consistently broken
2747 23:14 < matches> (a >> X) << X == a
2748 23:14 < matches> But == could be broken
2749 23:14 < matches> NOTHING IS SAFE
2750 23:14 < matches> When you are writing your own number represntation :(
2751 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.
2752 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
2753 23:15 <@sulix> I think the answer is "no: we're always trapping it and converting it" but am not sure.
2754 23:16 < matches> Our subtraction doesn't take forever
2755 23:16 < matches> The issue is when the result would be less than zero
2756 23:16 < matches> Hang on let me make another tester
2757 23:17 < matches> Well, I'll put it in the arbint tester instead of the real tester
2758 23:18 < matches> Since it's pretty clear the bugs are in arbint not rational<arbint> itself
2759 23:18 < matches> Although there might be bugs in rational<T> as well
2760 23:18 < matches> But we'll squish those when we get to them
2761 23:18 < matches> Also quad trees are they a thing yet?
2762 23:20 <@sulix> "The quadtrees aren't in the code, they were in your heart all along."
2763 23:21 < matches> Haha
2764 23:21 < matches> Tell that to Tim :P
2765 23:21 < matches> Ok (45,10) - (128,0) = -(83,18446744073709551605)
2766 23:21 < matches> But I'm pretty sure it should be -(83,9)
2767 23:21 < matches> + even
2768 23:22 < matches> (The least significant digit is first)
2769 23:23 < matches> Actually the plot thickens
2770 23:23 < matches> +45,10 - +128,0 = +18446744073709551533,9
2771 23:23 < matches> +45,10 - +128 = -83,18446744073709551605
2772 23:23 <@sulix> What is 0 + -1?
2773 23:24 < matches> +0 + -1 = -1
2774 23:24 <@sulix> I am pleased to hear that.
2775 23:25 < matches> +0 - +1 = -1
2776 23:25 <@sulix> -1 + 2?
2777 23:25 < matches> Now you're getting tricky...
2778 23:25 <@sulix> (As a maths major, I should know this)
2779 23:25 < matches> -1 - +2 = +1
2780 23:25 < matches> They're all single digit though
2781 23:26 <@sulix> Do you mean -1 + +2 = +1?
2782 23:26 <@sulix> Otherwise I'm slightly concerned.
2783 23:26 < matches> Uh yeah
2784 23:26 < matches> Sorry I have to change both the Arbint c(a + b) and the Debug
2785 23:26 < matches> Before copy pasting
2786 23:27 < matches> So I guess I should calculate if 45 + 10*2^64 - 128 == 18446744073709551533 + 9*2^64
2787 23:31 < matches> Expletive grenade
2788 23:31 < matches> I started Mathematica 
2789 23:31 < matches> fglrx segfaulted
2790 23:31 < matches> startx
2791 23:32 < matches> -bash: /usr/bin/startx: No such file or directory
2792 23:32 < matches> Also now I am getting zenity int3 error messages all over the bottom line of my terminal
2793 23:33 < matches> Whyyy
2794 23:33 <@sulix> That's terrible.
2795 23:33 < matches> Why does this computer persecute me so
2796 23:34 < matches> I gave it a good life
2797 23:34 <@sulix> You should ask frames how he runs mathematica on the command line.
2798 23:34 < matches> I fed it lots of AC power
2799 23:34 < matches> I replaced that keyboard that I broke
2800 23:34 < matches> I only spilled coffee on it once
2801 23:34 < matches> I *tried* to use the drivers that weren't fglrx
2802 23:35 < matches> I give up, see you tomorrow. Try not to totally rewrite all the Arbint code :P
2803 23:35 < matches> I think the subtraction might actually work except for the resizing bit
2804 23:35 <@sulix> Nah, I'm calling it a night here too.
2805 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.
2806 23:37 < matches> Well using my calculator I get something with a 184 ish at the start and too many digits to display
2807 23:37 < matches> Hence the mathematica disaster
2808 23:40 < matches> Oh well, I got startx back by installing "xinit" so that's something
2809 23:41 < matches> I guess apt decided to remove it as part of apt-get autoremove in its infinite wisdom
2810 23:41 <@sulix> I have decided to never call apt-get autoremove.
2811 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.
2812 --- Day changed Mon Jul 07 2014
2813 08:40 < matches> I try to avoid it, but sometimes apt won't let me do anything because it would break some dependency
2814 08:40 < matches> Although usually even after I run autoremove it complains
2815 08:41 < matches> Had to use aptitude to fix my "You can'd have kde-runtime!" issues
2816 08:45 < matches> Anyway wolfram alpha says that example +45,10 - +128 == +18446744073709551533,9
2817 08:45 < matches> is correct
2818 08:45 < matches> Checking the algorithm using 8 bits it should work too
2819 08:46 < matches> So it works as long as you supply the leading zeros...
2820 08:46 < matches> (On that particular case...)
2821 08:48 < matches> I hope it's not interpreting Arbint(128L) as Arbint(128u, ...)
2822 08:48 < matches> Nope sanity seems to prevail there
2823 08:50 < matches> Ah
2824 08:50 < matches> Ok
2825 08:50 < matches> First bug of the day: The subtracted argument needs to be resized
2826 08:50 < matches> As I am doing (45,10) - (128)
2827 08:59 < matches> :O
2828 08:59 < matches> I passed the realops test
2829 09:00 < matches> And it's also a lot faster now!
2830 09:00 < matches> Probably because the subtraction bug meant it was spending a long time in division to get the wrong result
2831 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
2832 09:01 < matches> Oh well
2833 09:02 < matches> Should probably not celebrate just yet, now the bezier looks really wierd again
2834 09:04 < matches> Ok
2835 09:04 < matches> Actually compiling with Real == Rational<Arbint> might be a better test
2836 09:04 < matches> But it still passes
2837 09:05 < matches> In particular it passes with Arbints where int64_t fails horribly
2838 09:05 < matches> So something is right
2839 09:05 < matches> Just not all of it...
2840 09:08 < matches> The GPU rendering seems to workish
2841 09:09 < matches> We really quickly end up with Arbints of size 30 digits or so :S
2842 09:09 < matches> Which is big enough to give an overflow in doubles I think
2843 09:10 < matches> Rational::ToDouble can probably be written as double(integer division) + Rational(remainder, quotient).ToDouble()
2844 09:10 < matches> (With some things to stop it recursing infinitely)
2845 09:20 < matches> Or even double(integer division) + double(remainder)/double(quotient)
2846 09:20 < matches> I don't think any recursion is needed
2847 09:22 < matches> Oh, there's a "pow" call that is probably broken
2848 09:24 <@sulix> Yeah, I feel the growing quickly is just a fact of life.
2849 09:25 <@sulix> Perhaps changing the zooming to avoid coprimes or something.
2850 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.
2851 09:28 <@sulix> "New biggest Arbint of size 173"
2852 09:28 <@sulix> and counting...
2853 09:34 < matches> haha
2854 09:34 < matches> There are more issues I spotted with add and subtract
2855 09:34 < matches> Basically you have to add the leading zeros - all of them
2856 09:35 < matches> My patch only simulates adding one leading zero
2857 09:35 < matches> Actually maybe I don't need to add them all, just enough until the borrow becomes zero
2858 09:36 < matches> But whatever
2859 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
2860 09:37 < matches> Realops is not a good enough tester
2861 09:42 <@sulix> Surely if there's borrow bit, subracting it from zero will always give another...?
2862 09:42 < matches> You only need as many as there are digits in your number
2863 09:42 < matches> At most
2864 09:42 < matches> If you still have a borrow at the end
2865 09:42 < matches> That means the result is negative
2866 09:43 <@sulix> Yeah, that's what I thought: you need to cap the number of digits you add.
2867 09:44 < matches> The problem was the algorithm before didn't finish all the borrows
2868 09:44 < matches> eg: 100 - 2 would have become "-8"
2869 09:44 < matches> Because 2 only has one digit
2870 09:44 <@sulix> My powers of mathematics tell me that that is not quite correct.
2871 09:45 < matches> What, that our algorithm was wrong?
2872 09:45 <@sulix> No, that 100-2 is not -8
2873 09:45 < matches> Yes
2874 09:45 < matches> Yes that's the problem :P
2875 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
2876 09:46 < matches> Addition also needs it for carry
2877 09:46 < matches> Damn
2878 09:47 < matches> I'd hoped that might fix the beziers not looking like beziers on the CPU bug
2879 09:50 <@sulix> I've pushed code to clear the carry/borrow flag before adding/subtracting.
2880 09:50 <@sulix> I don't think any bug is triggered, but there was the potential for off-by-one errors.
2881 09:52 < matches> Argh no
2882 09:52 < matches> Merge
2883 09:53 < matches> Yeah I'm pushing a fix for bugs that I don't think we've seen (yet)
2884 09:54 <@sulix> Out of curiosity, I tried removing the Simplify() calls from Rational.
2885 09:54 <@sulix> Relatedly, I've coined the term "NaN soup"
2886 09:54 < matches> Oh, clearing the carry/borrow flag might actually fix a bug with the code I just committed
2887 09:54 < matches> No wait it won't
2888 09:55 < matches> Eh it's still kind of dangerous to assume it isn't set to start with
2889 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.
2890 09:55 < matches> One of my early attempts had inline adc instructions in a for loop
2891 09:56 < matches> Which failed miserably because the for loop was clearing the carry flag :P
2892 09:57 <@sulix> For some reason "*=" segfaults if optimization is enabled, but I don't know why.
2893 09:57 < matches> Yuk
2894 09:58 <@sulix> Somehow we end up with "mul" as a null reference.
2895 09:58 < matches> Rataional::*= or Arbint?
2896 09:58 <@sulix> Arbint
2897 09:58 <@sulix> (So, also rational)
2898 09:58 <@sulix> Valgrind isn't picking anything up.
2899 09:58 < matches> null references are the worst
2900 09:59 < matches> Since I'm pretty sure the point of a reference is that it is never null...
2901 09:59 < matches> I'm sure this doesn'
2902 09:59 < matches> t stop people from deliberately creating null references
2903 09:59 < matches> And also checking that they are not null
2904 10:02 <@sulix> Tried compiling with clang. Nope.
2905 10:02 <@sulix> Apparently not even #include <iostream> compiles with clang.
2906 10:02 < matches> It might be worth implementing a non assembly version of those functions
2907 10:03 <@sulix> Yeah, that's always a good idea.