Automatic commit of irc logs
authorC R Onjob <matches@ucc.asn.au>
Fri, 4 Jul 2014 17:00:03 +0000 (01:00 +0800)
committerSam Moore <matches@ucc.asn.au>
Fri, 4 Jul 2014 17:00:03 +0000 (01:00 +0800)
You have a truly strong individuality.

irc/#ipdf.log

index 9455ca4..45cca1c 100644 (file)
 17:30 < matches> I put the code repository on github
 17:32 < matches> This is where a more hip and cool person would say something like "#yolo" but I prefer to wonder how I got 26K of lines and you have 65K...
 17:32 < matches> "How many lines of code does it take to draw a rectangle?" 91000
+--- Day changed Fri Jul 04 2014
+12:59 < matches> Found my rational bug
+13:00 < matches> ...
+13:00 < matches> Copy paste strikes again
+13:00 < matches> My operator/ looked suspiciously similar to operator+ -_-
+13:00 < matches> -____-
+13:02 < matches> Not sure how it got like that, it was definitely working at one point
+13:02  * matches should probably use git properly
+13:12 < matches> Pushed it
+13:21 < matches> So yeah, it should work fine until you zoom
+13:21 < matches> Then crazy things happen
+16:44 < matches> I think all the references you added at the last minute break my litreview
+16:45 < matches> (he says several months later :P_
+21:00 <@sulix> Question: in Rational::Simplify(), why is (-P)/(-Q) becoming (-P)/(Q) rather than P/Q?
+21:01 <@sulix> Shouldn't P = -P here? http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/rational.h;h=41cce09078b4e96eb17a6bb6e28478ea64637b57;hb=HEAD#l74
+21:02 <@sulix> Also zoom can be improved (but not totally fixed) by reducing precision when overflow would be possible.
+21:19 < matches> Yeah, that's the idea of using the Stern Barcot tree Tim was talking about
+21:20 < matches> Which I still need to read about
+21:20 < matches> Also yes P should be -P because I am just that amazing at maths
+21:22 < matches> In other news assembly happened
+21:22 < matches> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s
+21:22 < matches> Which no doubt has terrible bugs in it :P
+21:23 < matches> It was a bit confusing how passing and returning arguments with x64 was completely and utterly different from x86 and almost every tutorial is from at least ten years ago talking about x86
+21:24 < matches> x64 is actually much easier though
+21:25 < matches> At least, I think they are different, I didn't have to mess with the stack which seemed to be a thing with x86 and also that motorolla language we used in first year
+21:25 < matches> Just got all the arguments in a bunch of registers
+21:31 <@sulix> I think I just worked out why you have 16 "inc" instructions, and am loving it!
+21:32 <@sulix> inc doesn't change flags!
+21:32 < matches> I wonder if it would be faster to just store the carry flag in a register though
+21:33 < matches> Actually probably not because there'd be branches involved
+21:33 < matches> Hmm
+21:33 <@sulix> Traditionally, mucking about with flags is slow.
+21:33 < matches> Yep cool
+21:34 < matches> I've got the AMD64 ABI
+21:34 < matches> Chapter 2 is a good one
+21:34 < matches> "Software Installation"
+21:35 < matches> "This document does not specify how software must be installed on an AMD64 architecture machine"
+21:35 < matches> End chapter
+21:35 <@sulix> Just a thought, can use use the lea instruction instead of all of those incs.
+21:37 <@sulix> Like lea rsi, [rsi+8h]?
+21:37  * sulix ponders.
+21:38 < matches> Maybe, my assembly is very rusty and was based on those ELEC1301 labs in the first place...
+21:38 < matches> I don't even remember if they had lea
+21:39 <@sulix> (Also I just got a message from KDE: "could not launch a process. perhaps you have reached the limit of running processes")
+21:39 < matches> :S
+21:40 < matches> When did you last reboot?
+21:40 <@sulix> This morning, actually.
+21:40 < matches> Integer overflow in PID?
+21:40 <@sulix> It looks like it was an out-of-memory problem.
+21:40 <@sulix> On a related note, the intel instruction set documentation is a 3 and a half thousand page pdf.
+21:41 <@sulix> and firefox has a PDF viewer written in javascript.
+21:41 <@sulix> ...that runs by default.
+21:44 < matches> Hahaha
+21:44 < matches> Yes, pdf.js is apparently the best thing since sliced bread...
+21:45 < matches> I'm having some difficulty with lea, possibly the syntax
+21:47 < matches> "lea (%rsi+8), %rsi" is wrong
+21:48 <@sulix> Yeah, gcc's assembler uses whacked syntax.
+21:48 < matches> I thought it was just () instead of [], add % to all the registers, and swap destination and source
+21:48 <@sulix> http://git.ucc.asn.au/?p=ipdf/code.git;a=blob;f=src/tests/add_digits.s;hb=HEAD
+21:49 <@sulix> They replaced the arithmetic operators with strange things, too.
+21:49 < matches> Riight
+21:49 < matches> Thanks
+21:49 < matches> So 8(,%rdi,1) means [rdi+8]
+21:49 < matches> That is dumb
+21:49 <@sulix> I'm not sure if it's worth using nasm or the ".syntax intel" directive.
+21:51 < matches> Hopefully there won't be too much more assembly to write...
+21:51 <@sulix> Technichally lea (and other memory addressing instructions) take the form "[register+register*(1,2 or 4)+(number)]" in intel and "number(%register,%register,(1,2 or 4))"
+21:51 <@sulix> in gcc
+21:51 < matches> ok
+21:51 < matches> Well once I know the syntax I can cope with it
+21:51 < matches> But all the documentation being written in a different syntax doesn't help :P
+21:52 <@sulix> Yeah, there are a lot of people who hate gcc syntax, which was an (unsuccessful) attempt to make assembly for different machines more consistent)
+21:52 < matches> I decided to go with it because I vaguely remembered your commander keen patches looked like they were in gcc syntax :P
+21:53 <@sulix> Hah: they were in "ckpatch" syntax.
+21:53 <@sulix> And were just the final output bytes.
+21:53 < matches> The memory can play strange tricks...
+21:54 <@sulix> I used the "debug.com" utility that came with dos to assemble them, which let you write assembly to arbitrary memory.
+21:54 <@sulix> and then read the contents of that memory to see what it assembled down to.
+21:55 < matches> So, I need subtraction and multiplication but not division to implement arbitrary rationals
+21:55 < matches> I'll try sort those out tomorrow
+21:56 < matches> I'm pretty sure I'm doing better than at least one arbitrary integer representation
+21:56 < matches> Which had a int32_t word and int64_t "double" word
+21:56 < matches> So they could tell if they had a carry by doing the additions using double words
+21:57 < matches> The code in C was longer than add_digits is in assembly
+21:57 < matches> Although to be fair it might actually work on things that aren't amd64
+21:57 <@sulix> Well, the good news is that there's an "sbb" instruction like "adc"
+21:57 < matches> Excellent
+21:58 <@sulix> The bad news is that multiplication is harder.
+21:58 < matches> Yeah, at least I don't need division though
+21:59 < matches> Although converting it to a string will be annoying
+21:59 <@sulix> IIRC, the IMUL instruction gives an output twice as long as the inputs, to prevent overflow.
+22:00 <@sulix> Converting to a string won't be so bad if you get division done.
+22:00 <@sulix> And you can always just implement multiplication and division by slow recursive addition/subtraction.
+22:03 < matches> There's a bunch of papers on number representations that use things that aren't floats or rationals from a quick look
+22:04 < matches> I guess I just need to implement as many things as possible and compare them all
+22:04 < matches> Seems easy enough...
+22:04 < matches> (Famous last words)

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