23:07 < matches> 8 hours in the future
23:07 < matches> I really should fix my system clock
23:07 < matches> One of these days...
+--- Day changed Mon Sep 01 2014
+17:05 < matches> The wobbly lines on things are irritating me
+17:10 < matches> There doesn't seem to be anything wrong with Bresenham, which means the actual line endpoints are wrong
+17:11 < matches> The GPU does everything from floats and magically they go to the right spot in the buffer
+17:11 < matches> The CPU has to calculate integer pixel coordinates
+17:16 < matches> I need a magnifier I can't see the pixels that are in the wrong spot
+17:16 < matches> I know they are there
+17:21 < matches> ... ok maybe the Bresen Ham was a little past its use by date
+19:48 < matches> The more I try and get these lines to not look dumb, the more convinced I become that glDrawLines is doing something fancy
+19:56 < matches> You end up with wiggles in the line because the end points round to a different pixel to what you end up at by drawing the line
+19:57 < matches> If you make sure you start from where the last line ended, you still get a bend because of the left over error from the last line
+19:58 < matches> ...
+19:58 < matches> Drawing a single line when you know the Bezier is actually a single line is probably going to be less rage inducing than trying to fix this
+21:01 < matches> The Beziers are now classified according to Loop and Blinn
+21:01 < matches> Well
+21:01 < matches> Maybe
+21:01 < matches> It at least knows what lines are
+21:01 < matches> ...
+21:02 < matches> Ok all the ttf beziers are SERPENTINE and LOOP so that's probably wrong
+21:43 < matches> Ah, floating point precision strikes again
+21:43 < matches> That's kind of annoying
+21:47 < matches> But I suppose it's relevant
+21:47 < matches> Unless I'm totally screwing something up
+21:48 * matches adds in arbitrary fabs(x) < 1e-6 checks
+21:58 < matches> On the other hand, if you use DeCasteljau and stop the sub dividing whenever you get to something that classifies as a line, it's actually pretty cool
+21:59 < matches> But if you zoom in too far it starts to get classifications totally wrong
+22:02 < matches> Yeah I have an abstract due in 2 weeks
+22:02 < matches> so screwed
+--- Day changed Tue Sep 02 2014
+13:42 < matches> Ok, let's not use floating point values for colours
+13:42 < matches> Baad
+13:43 < matches> Bad bad
+13:43 < matches> Bad sheep
+13:43 < matches> The project isn't about precision of representable colours
+13:44 < matches> So I'm perfectly OK with using uint8 for colour components
+18:53 < matches> Is it too late to change the aim of the project to "render svg-tests/fox.svg but without antialiasing"
+18:54 < matches> "Or using the GPU"
+18:55 < matches> Well, I understand why shading doesn't usually use flood fill now anyway
+18:55 < matches> But I still kind of think flood fill is better at high resolutions
+18:56 < matches> Not parallelisable I guess
+18:56 < matches> ... Or is it
+18:57 < matches> I was going to try and do arbitrary precision stuff but it seems we can no longer compile unless Real == double or float
+--- Day changed Wed Sep 03 2014
+17:26 < matches> It would seem Mr Munroe has beaten us...
+17:28 < matches> In Javascript
+17:28 < matches> We should die of shame
+17:29 < matches> Hahaha
+17:29 < matches> "// there is no elegance here. only sleep deprivation and regret"
+17:31 < matches> On the bright side, we now have a reason to reference xkcd
+17:31 < matches> I guess?
+17:59 < sulix> I just saw that, and had planned to use that comment as my next commit message.
+--- Day changed Thu Sep 04 2014
+10:59 * sulix sulix also engages panic mode.
+11:00 * sulix apparently also needs to engage sleep mode.
+11:00 * sulix almost engaged sheep mode by mistake.
+11:49 < sulix> How sure are you that SolveCubic works?
+18:37 < matches> Well, sure within 1e-4
+19:40 < matches> Rational<Gmpint> compiles again
+19:41 < matches> It just takes... several minutes... to load "The quick brown fox jumps over the lazy dog"
+21:04 < matches> I have a new ingenius plan
+21:06 < matches> This will probably not work but hopefully it won't take me too long...
+21:06 < matches> Oh dear what am I saying
+21:06 < matches> It's going to take a month now
+22:24 < matches> I really should be integrating one of those two libraries Rowan suggested into the project
+22:24 < matches> As opposed to implementing what I like to call the "Paranoid Number"
+22:25 < matches> It starts as a float
+22:25 < matches> It checks each operation for an exception, and if it does it adds the operation to a linked list instead
+22:25 < matches> After trying to simplify the next elements in the list
+22:26 < matches> This is going to be awful
+22:26 < matches> But it's been a while since I wrote a good linked list
+22:32 < matches> ... I think the last linked list I wrote had a nasty tendency to randomly segfault...
+22:32 < matches> Nevertheless we shall forge ahead
+23:14 < matches> You know you haven't had enough sleep when you start to terminate lines with ':' instead of ';'
+23:14 < matches> I blame python
+23:14 < matches> Not that it was valid python syntax either
+23:15 < matches> But it's a good scapesnake
+23:42 < matches> Oh recursive list based functions
+23:42 < matches> How I have missed you
+23:42 < matches> void Foo() {if (m_next != NULL) m_next->Foo();}
+23:42 < matches> <3
+--- Day changed Fri Sep 05 2014
+09:26 < matches> It sort of kind of works
+09:26 < matches> Except when it breaks
+09:26 < matches> ParanoidNumber::Simplify needs improvement
+09:26 < matches> Also operator+=
+09:26 < matches> operator-=
+09:26 < matches> operator*=
+09:26 < matches> and operator/=
+09:26 < matches> But it's definitely a number
+09:27 < matches> It just occasionally does things in totally the wrong order'
+09:28 < matches> So basically the idea is if you have an inexact (or overflow/underflow) operation, you delay it, and then in theory you can rearrange the operations so you have a smaller error...
+09:28 < matches> It seems to give better results than floats for tests/paranoidcalculator
+09:29 < matches> But that might be because it is initialised off 3/10 and the float starts at 0.3
+09:30 < matches> It could all be totally useless
+09:30 < matches> It probably is totally useless
+09:31 < matches> I have a hunch that even if it's terrible it might beat true arbitrary precision arithmetic
+09:31 < matches> In terms of actually being able to use it
+09:31 < matches> Who needs mathematics when you have blind intuition...
+--- Day changed Sun Sep 07 2014
+11:37 < sulix> Explicit mentions of hitting floating point precision issues in the xkcd comic: http://chromakode.com/post/notes-on-xkcd-pixels
+17:33 < unmercifulfish> mwahahaha
+17:34 < unmercifulfish> you can't escape my stalkerish tendencies now
+--- Day changed Mon Sep 08 2014
+11:10 < matches> This channel seemed like such a good idea at the time...
+11:19 < sulix> (So did the quadtree...)
+12:08 < Pommers> http://chromakode.com/post/notes-on-xkcd-pixels
+12:10 < sulix> It's gettign crowded in here.
+12:10 < sulix> Pommers: We were looking at that yesterday. The XKCD guys had it easy.
+12:11 < Pommers> Lets get all the people in here
+12:42 < unmercifulfish> IPDF PARTY
+13:49 < matches> Hmm, maths is harder than I thought
+15:41 < Pommers> Speaking of math, I know a guy who is looking for people versed in maths and willing to work on psuedo random number sets
+--- Day changed Wed Sep 10 2014
+11:50 < matches> So, compiling with mpfr reals is not as simple as including the mpfr real header and doing a typedef
+11:50 < matches> As there appear to be compiler errors in mpfr
+11:51 < matches> Does anyone actually check that things compile before including them in debian..
+11:53 < matches> I'd expect this sort of thing from Fedora
+11:58 < matches> Never mind it's namespace issues
+11:58 < matches> I'm sorry debian
+12:15 < matches> Something is horrendously broken about mpfrc++
+12:16 < matches> Oh
+12:17 < matches> #if REAL >= REAL_RATIONAL was not a wise choice
+12:21 < sulix> Ah...
+12:24 < matches> mpfrc++ is at least as precise as doubles but slower
+12:24 < matches> I never actually found the limit for doubles
+12:24 < matches> I should do that first
+12:26 < matches> Hmm, things start to disappear at around 4e-11 but you can still add stuff and it looks fine
+12:27 < matches> Ok doubles go crazy at 1e-17
+12:27 < matches> 1e-15 even
+12:30 < sulix> Is that zooming in on the origin, or somewhere further away?
+12:31 < matches> Somewhere further away
+12:31 < matches> If you translate towards the origin you can actually see the shapes start to get better
+12:31 < matches> It's actually pretty cool
+12:35 < matches> There's something dodgy with starting the View with low width/height as opposed to zooming in to the same width/height
+12:37 < matches> mpreal doesn't seem to want to show anything
+12:39 < matches> I think it's well past time we automated the zooming/translating process
+12:39 < matches> Sitting here zooming for 20 minutes is not really an effective use of time...
+12:47 < matches> Speaking of which, the CPU shading evaluates the fill points lazilly now, so you don't have to wait 5 minutes even with doubles just to load an SVG
+15:39 < sulix> For all of the hangers on... quadtrees are now slightly more functional.
+15:39 < Pommers> "functional"
+18:40 < iceweaselOS> Apparently talking in ICC isn't allowed
+18:41 < iceweaselOS> ICC
+18:41 < iceweaselOS> dammit
+18:41 < iceweaselOS> it has autocorrect
+18:42 < iceweaselOS> Humphrey the rabbit does not work :(
+18:42 < iceweaselOS> it gets stuck in pause
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au