another day of arr and arr

Just chilling. Yeah, yeah, I know. I have a thesis to write. The chilling will stop on Monday. I can tell that this week of rest, especially today has done a lot of good, feel a lot better today partly because I'm not waiting for a call, but partly because I've had that requisite putcherselftagether time.

Attended Y's présoutenance (go!), had lunch, got sleepy, proofread G's English, helped another G with a bit of Haskell, am helping A with a pseudo-unification algorithm (but just trying to understand what she wants to build exactly), and now am installing C's new Mac.

Monday we return to battle.

I got 1/4 of the job.

I think I might not actually have gotten *the* job, but I have gotten *a* job, one which will be bringing me to Brighton for 8 months (from Dec 2007) and perhaps longer if everything goes well.

It's something we discussed informally, sort of a thesis-friendlier (among other things) Plan B. I also kind of like it better that way, an 8 month contract, while less stable also seems a lot less intimidating (less risk of screwing it up?), and if my assumptions about this are correct (C1 got offered the job job?), it has a non-zero sum aspect which would please the silliest of Erics (puppies and free software, rah rah)

In any case, considering how awfully I blundered my way through that interview, I think this is already much more than I could have asked for. Yay?

(Hey wait, nothing is sure yet. This is conditional on [a] me finishing the thesis [b] me getting a work permit. If only the prefecture were more open to the idea of me becoming French. Could have saved us all a bit of paperwork)

back, but not ready to roll

Back from the UK. Spent yesterday just vegetating, recuperating from the process. Not entirely operational, mostly talking to people about how it went (many little bits of good, one or two really big chunks of bad), clarifying [I think] the relationship between our stuff and the metagrammar stuff to Y and then vegetating some more. Used the afternoon to empty out ye olde inbox, put my claims form together, take care of some non-work office business, read up on Functional Morphology (sort of a just relax kind of deal). Have downloaded GF and am in the midst of compiling it, trying to see if I can get a French morphological generator out of it. Nothing important, just the kind of thing you do while you're waiting for the Phone Call and you're pretty much useless otherwise.

how did it go?

What a dummy. I was so busy getting that presentation right that I just sort of neglected to actually think about and prep for the interview. Hoo-boy did it ever show. Very standard interview questions, what can you contribute etc, but me, the oncoming car, the headlights, uh... say what? All this after a friend had even sent the Joel on Software guerilla interviewing guide (skimmed). One track mind, omg, gotta get that presentation right, stupid stupid stupid (smack smack smack). Just answer honestly and you'll be fine is SO not good enough, because the problem is that when they ask you the question, you're not going to figure out what your REAL answer, the Honest one, the one you really wanted to say, the one that's really you... you're not going to figure that you, you're just going to thrash around wildly like an idiot. Just answer honestly is one thing... priming yourself so that you've got your honest answers ready to roll, that's another. And geez, could it hurt you to read that proposal a little more carefully (well actually in my defense, I did read it a couple of times, red pen and all, but I think this is exactly the kind of thing that you need to write about, get your thoughts on paper, make sure the bits connect together). It really could have gone so much better.

practice talks

Gave two practice talks for the job interview. The first one went pretty well, had lots of feedback on things to fix, cutesy things to nix. Second one was crap. I guess it's the erician one-talk-per-day rule. The first talk I'm a nervous wreck, somehow a very disciplined and enthusiastic wreck that sticks to the lines he rehearsed. The second talk, I'm tired, trying to say things differently, trying to work with new material. Very susceptible to details like that, details like not having the videoprojector to beam the talk with (#2) or having my screen dimmer go on every N seconds (probably due to it being on battery mode).

Many thanks to C, P and everybody else chez us for the helpful comments.

I wonder if in the future I will be able to do off-the-cuff. I'm still at the stage where giving a talk is partly theater (something which certain purists seem to hate - if you can't present it simply enough, you don't know what you're talking about, get off the stage). I need lines, a script. Not something I'm going to write, memorise and repeat, but I need to have things preformulated, keywords, keyphrases and keyhandmovements. It's like putting a bunch of beacons into the ocean. I can be spontaneous only within the confines of the beacons, swimming from one beacon to the other. No beacons and I just drown.

handouts

Here's what I do to produce handouts:
page setup - landscape
(adobe reader print dialogue) page scaling - fit to printer margins
(print dialogue) layout - 6 pages per sheet, the first setting

slide hacking

Rather distressing day, trying to get those slides together, just not coming. Well, I guess it's getting better, hope to be done tonight or early tomorrow morning. This is going to be tight. I usually like to rehearse my rehearsals tout seul chez moi, but I might not have the time for it.

sloppy screwup

C asked me today why we have 116 sentences for parsing and 140 for generation. Eh... oops. I screwed up there; was not using the same sentences for parsing as for generation. Got that fixed after some digging around, so we should have some new 140-based parsing numbers. Also discovered another screwup in my methodology for the other paper, another data mismatch, grabbing numbers from not-quite-the-same-place within the same paper. Nothing deliberate, but still pretty bad. It's all about protocol, I guess... starting to get better about it, putting things in nice tidy places so that I don't screw things up. In the case of the previous paper, I was really in a hurry or something and must not have thought through completely where my data were coming from. Gah. Anyway, should all be fixed in time for submission, or resubmission-if-accepted in the case of the earlier one. This is also the kind of stuff you need to learn in order to become a good programmer, I guess; part of good protocol is good automation (he says grandly); you want to set everything up to be fool-proof, or eric-proof as the case may be, just hit go and everything gets cranked out. And don't think that it's not worth it because you're just doing it once, because you know you'll be needing to get that data back someday. Making shit reproducible is all.

making slides

One thing which are useful for making slides:

while echo; do make; sleep 5; done

(Works best if you have -halt-on-error in your latex command). This avoids me hitting make every time I make a stupid little change. I still have to unlearn the reflex though. Kinda cool to just be writing my slides up, hitting :w once in a while and having the thing refresh in TeXniscope. The problem with running make in your text editor is that it prevents you from working on the slides for the time it's compiling (it's eating up your screen)... this kind of thing can pop you out of concentration.

Another thing is pdftricks. I had to edit my Makefile so that I'm calling pdflatex -shell-escape. Also had to include this in my slides:

\usepackage[shell]{pdftricks}
\begin{psinputs}
\usepackage{pstricks}
\usepackage{tree-dvips}
\end{psinputs}

What's nice about this is that I can just use pdflatex for the rest of it. Everytime I want a pstrick, I just wrap the whole thing in pdfpic. Said thing could be any arbitrary block of TeX, for example, a tabular with a bunch of pspictures inside. I think you have to make the beamer frames fragile, but I'm not entirely sure.

slides shmides

Early morning: putting together numbers for the paper.

Gave up on my profiling binge, silly silly eric... found that it goes pretty fast if I do (XML => splitted XML => geni text => geni binary). You can't do (split XML => geni binary) directly, at least not the way I was doing it, which consist of mapM'ing (read >>= write) on each one of the input files. Obviously that's not going to work for pickling because you'll only get the results for the last file (duh). Oh space-leak (oh Canada?)... if only I was a better programmer. I'd just look at that code and go, "oh! that's easy!" (hack hack hack hack, ding), no more leak. I think what upset me more than anything else was that yesterday I somehow managed to convinced myself to go off on this adventure when I clearly had more pressing things to do. LATERAL thinking, eric. Go around the rock, not through it. Oy.

I am quite pleased with this idea of putting the experiments, its scripts a README, everything you need for easy reproducability in its own directory. The directory now contains before and after snapshots of the geni text format, the counts, and a version number of the software we used (namely GenI). It may not be painless in 3 months when I want to pull that data back, or regenerate something, but it's way better that what I've been doing for the past 2.5 years. It took me that long to figure it out? Methodology.

Late morning and all afternoon: working on slides for the presentation on FriMonday. Really don't want to do it. Spent the afternoon falling asleep and resisting this task in any way I could think up, sadly not always doing the ol procrastinate-by-doing-something-useful. Only towards the end of the afternoon did I come to senses and start working on the easy parts of the slides where I wasn't as likely to resist. So talking about grammar hacking, because that's freshest in my mind. Guess we'll hit the paraphrase selection stuff next. Might skip the polarities...

just being dumb

Spent today setting up a profiling harness for geniconvert, trying to figure out how on earth it balloons to 2G for converting a simple 50M XML file (and I know it's something related to the XML, because it's way faster and smaller for converting the equivalent GenI format). Spent the evening just being stupid stupid stupid, scattering strictness annotations and bang patterns throughout the code like breadcrumbs, saving each time I got the allocation down just a tiny bit. One thing that seems to help is using HaXml's lazy parsing, but other than that, not thinking clear and hard enough.

One thing that does seem to help is when I split up the file into little bits and parse them all at once. But doesn't that just feel silly?

Geeeeeeeez

It really is soooooo much better behaved when I split it up. Stays under 100M, and finishes in less than 5 minutes, rather than 3 hours. Guess it works, sticking with the technique until maybe after the thesis. geniconvert is not my job.

sleepy eric and the half day

Had a day and half off since yesterday, with a couple of friends coming to visit from the States. Spent today just sleepy as heck. Discussed the paper with C, who liked the stuff that I struggled to write Saturday. I wonder if there's a general rule there, the more it hurts to write, the more you've been thinking about it? Split up the graph-making script so that it does just that. Next time, we can adapt it to whatever data we want, same old graphs... I hope anyway. Recompiling grammars. Slow slow, swaps-a-lot makes my computer slow down. It's my fault by the way, geniconvert going from TAGML to genib pickles. Leaking space somewhere, but I don't use this enough to really care. Really ought to sit down, profile that thing and figure out what it takes me sooo long to convert 54 itty bitty widdle megabytes of XML (grr).

plodding along on the paper

Spent today very sloooooooooooooowly working on that paper. Wrote a crappy-assed conclusion, like pulling teeth, that was. But now it's pushed in, and we can work on making it better later.

Have also been working on the interview stuff. I guess I'm going to go with good old latex-beamer after all, not going to experiment with anything I don't yet know how to manage (i.e. paper handouts accompanied by minimalistic one-word slides). My only concession might be to produce a printout of the slides which I can distribute so that the audience can control the flow a bit better.

sparky sparky

selling me

Since my "deadlines" for the job interview and the paper are the same, I'm trading one of the other; when feeling dead on the paper, I switch to interview stuff, (preparing a presentation of my PhD work, I guess). Anyway, that was early this morning, spending my kiloword outlining the talk, spending the office-mates-being-talkative time making this:

Pen and paper test of programming skills? I feel like I'm interviewing for some company. Mostly nervous about the "informal" chats...

sleepytalk

I keep falling asleep during talks. Something about hand-parsing mathematical texts, marking them up with a simple grammar and then... I dunno, I fell asleep, argh.

writing up overgen

Talked with C about the paper, have a more solid outline. Wrote up some of the overgen.

shrinkage

Got to admit that HTML mail does have _some_ uses (grumble). Table below associates number of paraphrases with new grammar with its size relative to old grammar. The smaller, the better. We can sort of see that the bigger the cases get, the bigger the reductions. Suites with under 10 paraphrases have 51% paraphrases from before, whereas those with over 300 paraphrases have 16% paraphrases from before

new size	% of previous
10	51
20	47
30	37
40	-100
50	40
60	40
70	39
80	35
90	29
100	24
110	24
120	-100
130	-100
140	-100
150	-100
160	28
170	-100
180	26
190	23
200	23
210	18
220	18
230	-100
240	20
250	-100
260	21
270	-100
280	-100
290	22
580	16

more bug stomping

Fixed the annoying derivations bug this morning. Took me a while to figure out what I was doing wrong, just stupid reasoning, failing to grasp the significance of having a LIST of things to work with, can just concat things willy nilly, sort of the same kind of stuff that makes me really bad at working with databases. Type system was handy here, (1) because I wanted to change my code, for example, replacing all my lists with sets, and that would have been a nightmare without runtime checking (2) because it helped me to reason about what I was really after. I'd try something, the type checker would complain, and I'd be like, "huh?"... think about it some more... and grudging admit that yeah, so it had a point there, and my first attempt was completely bogus. So yeah, the initial bug was exactly the kind of think you can't check with a type system [yet?], but whilst trying to solve that bug, I made loads of little deep reasoning errors which the type system did catch.

Spent this afternoon counting things, not sure where exactly it all went, but I know a good chunk of it was just compiling the big grammar, trying to put together some makefile targets to automate that (didn't get quite so far... eh...). Don't really know what happened this afternoon. Seems like a giant black hole.

Late afternoon, I got interested in the idea that a little overgeneration goes a long way. I wanted to do another distribution, something like, do cases with lots and lots of overgeneration get a stronger reduction in overgen? Or is it pretty evenly spread out? In other words, is overgeneration sort of combinatorial like I was thinking? Or is it no more than the rest of the grammar is? More hazy thinking.

not super productive

Not being as productive as I'd like these two days.

Yesterday was giving C a hand with a class. Kids at least try the exercises, which is quite heartening.

Well, I guess this morning/afternoon were pretty reasonable. Was hacking a bit on GenI, generalising the rootcat mechanism into a rootfeat one. I like the latter one better, feels a bit less hacking. Gave me a chance to clean up some polarity code as well, avoiding copy-and-paste programming. Was confused for a while why the gui seemed to be broken all of a sudden... took me a while to figure out that it's because I'm an idiot. I'm reading instructions from stdin... so if I just call the gui without any instructions, it's going to sit there waiting for me to type stuff... stupid stupid. So now it's a flag.

Spent a good chunk of the afternoon getting confirmation about my 26 march interview, booking tickets, that kind of thing.

Puzzling over the weird derivations output that C gave me, but my thoughts are kind of fuzzy right now. Take care of it tomorrow morning.

done with script hacking?

Came in to the lab yesterday morning, worked a bit on the article and on the scripts. Discovered some bugs later on, typical erician boolean inversion disease.

First thing this morning was working some more on the article. Spent the rest of the morning and bit of early afternoon fixing a largish bug in the summarisation script, the stuff I was working on this Saturday. Je suis une usine à bug, I believe. One of my solutions this morning was to take it easy this morning, just go nice and slow, take my time and work my way through it. One of things I did to slow myself down was to add types where none existed, for example, I have two types for the same thing:

data Rule = Rule Char String String deriving (Eq,Ord)
data SimplifiedRule = SimplifiedRule Char String String deriving (Eq,Ord)

with a little conversion between the two. This way I don't try to do things with simplified rules when I only have rules. It doesn't solve the bugs, but it traps one source of errors. So slowing down and adding more types, that's the solution so far. It would help if I actually thought harder about things.

This afternoon, trying to work on the paper a bit, but not concentrating very hard.

Oh, and I'll be interviewing for that job I was applying for... 26 March. Will have a 20 min presentation of my research interests to prepare. Uh... research interests?

meh... slow hacking

Being awfully slow today. Just trying to improve the summaries script. Wasted a lot of time trying to figure out a good way to present the derivations information. No clear answer yet.

Now working on extending GenI so that we can specify more than one test suite. The goal would be to integrate with the 'instructions' mechanism from this experiment, and thus the big Makefile.

infrastructure in place (13::3325/46::17868)

Early morning: Copied and pasted more stuff into the polarity filtering chapter, hashed out in the kiloword some more thoughts for the chapter. Still not going as well as I'd like.

Late morning: Got all the basic Makefile operation in place. It's basically just a subset of the Makefile of Despair, cut lots of stuff out, hope to refactor someday much later. Had to do some minor extensions to scripts, made a variant of geniselect which reads from the instructions file.

Early afternoon: demoed the infrastructure to C real quick... and set to work producing operation sites (for adjunction nodes, but includes subst too) along with the derivation tree. Lucky for me; this was real easy. Had done most of the work sometime earlier, don't know when.

Late afternoon: extended the summariser script so that it prints out failed traces for each tree. You get output like this:

Tn0Vs1intan2 (all) - EmptySubject SententialInterrogative activeVerbMorphology n0Vs1intan2
 211 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithComplementizer ImperativeSubject
 212 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithComplementizer ImperativeSubject
 185 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithComplementizer InfinitiveSubject
 186 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithComplementizer InfinitiveSubject
 217 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer ImperativeSubject
 218 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer ImperativeSubject
 195 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer InfinitiveSubject
 196 CanonicalIobject CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer InfinitiveSubject
 193 CanonicalSententialObjectInterrogativeFiniteWithComplementizer CleftIobjectOne InfinitiveSubject
 194 CanonicalSententialObjectInterrogativeFiniteWithComplementizer CleftIobjectTwo InfinitiveSubject

The code is fairly ugly:

  -- failed traces
  getFailedTs i = thatOnlyFailed . buildTraceMap $
                  M.filterWithKey (\k _ -> snd (lFamily k) == i) lmap
  failedTs     = map getFailedTs is
  isShared t   = all (\x -> t `elem` x) failedTs
  sharedFailures = sort . filter isShared . nub . concat $ failedTs
  uniqueFailures = M.map (filterOut isShared) $ M.fromList $ zip is failedTs

After: There's still a little more work to do: C needs to be able to run the graphical GenI a little more easily; would be nice if it could read from the instructions file to, or something like that - perhaps propagate the changes over to the main GenI? Maybe just have her pass command line flags?

more scripting

Spent the day scripting, or refactoring scripts. The little adhoc format I'm using for this experiment now has its own module for parsing/outputting. Got three new pieces of the puzzle: the generator now accepts an instructions file as input (this tells it which test suites/cases to run), the summary annotation script now understands multiple test cases in the same file and the big one, we can now merge together and compare two different runs on the same set of test cases. Hopefully, this means that we're basically one Makefile short of a regression testing workbench.

I will admit with no uncertain embarrassment that the whole thing weighs 650 lines of Haskell code and took me a week to cobble together. Sigh... I am clearly a long long way from programming Zen... that state of getting many things done with a minimal amount of code. I mean, geez; it's just supposed to be a bunch of ad-hoc scripts for, like, one experiment (then again, maybe this will become part of the official toolkit, the SemTAG grammar development workbench, now with extra support for hunting down overgeneration).

Oh, and did some more writing today, very light, just trying to stitch in the multiliteral and zeroliteral semantic stuff. Never lose touch with the thesis, keep yourself slightly used to writing every day, that kind of deal.

more hackery (9::1957/39::16500)

Still inching (centimetering?) forward on the polarity filtering chapter. I'm annoyed that I'm rewriting it, but I can't seem to help it. Meh.

Data.Binary progress

Was ecstatic rather this morning when I found that the pickled grammar actually loads in GenI. The basic idea is that if it fails to load in Parsec, I try loading it as a pickle, using decodeFile. What I ought to do is trap any decodeFile errors and then just return the Parsec error, or something like that. Anyway, at first I was feel all triumphant and shit (mostly grateful to the Binary Strike Force) because GenI loaded up instantly with the new pickled grammar. Well, it's probably somewhat related to lazy evaluation; there is still a slight delay before the thing starts to generate stuff (it was just the graphical user interface; i was returning a count of trees loaded to indicate that I had finished reading the file, but that probably didn't mean anything). So... it was quite as great as I thought. But it did cut generation time from 40s on some simple example to 20s... and I'm thinking that there is some work I do after reading the grammar, where I start shoveling trees into Data.Map... thinking that something like that could be made Binary. Maybe load up even faster. Oh well, it's progress for sure, not quite the first bit of joy when I saw everything seeming to go zoom.

the paper

Been hacking away at the Makefile stuff. My scripts are slightly less dumb now. Got the geniselect script accepting multiple test suites on the command line. Likewise, have the JustCount thing (just for this paper) doing the same _and_ printing out sentences. Was worried that this was going to be a pain, but then realised I was just being silly. Relief. It's still not user friendly yet, but we're creeping forward towards more and more automation.

Oh, and in case you're in to this kind of thing, p1 has from 0 to 230 paraphrases ; the whole suite goes from 0 to nearly 5000 paraphrases . I wonder if sparklines really are useful for this kind of thing. Just thought it might be amusing to try.

playing with Data.Binary (8::1865/38::16408)

playing with Data.Binary

Been playing with Data.Binary a bit. It's not really the priority right now, but I'm sick of waiting for the stupid grammar to load. Hoping that having pickles would make it all better. It's pretty painless. You just have to

import Data.Generics (Data)
import Data.Typeable (Typeable)

And throw deriving (Data,Typeable) into your data definitions. Then you can use their auto-derivation tool to write the Get/Put instances for you. I wrote a smaller wrapper around their script, just for my needs:

#!/usr/bin/env runhaskell

import NLP.GenI.Btypes
import BinaryDerive
import Data.Generics.Basics

main =
 do putStrLn "module NLP.GenI.BtypesBinary where"
    putStrLn ""
    putStrLn "import Data.Binary"
    putStrLn "import NLP.GenI.Btypes"
    putStrLn ""
    putStrLn "-- auto-generated by the Data.Binary BinaryDerive tool"
    putDerive (undefined :: Ptype)
    putDerive (undefined :: GeniVal)
    -- ... repeat for each type needed

putDerive :: Data a => a -> IO ()
putDerive = putStrLn.derive

This way I can regenerate stuff easily if I ever change my code. (Wait, am I metaprogramming yet? It's too painless to tell yet). One minor complaint is that the derivation tool doesn't seem to like my strict fields. I had to make them lazy, run the derivation thingy, and then make them strict again. Hope that's ok.

Not sure about the results yet. The resulting file is 2.5 times bigger, but I'm hoping that reading from it will be way way faster than what I can do with Parsec

Makefile of Devolution

Thinking a little bit more about the Makefile of Drawbridges; trying to see if it would be good to have a submakefile for the current experiment. The mother makefile is just get unwieldy; crazy stuff I'm doing to make it general. Maybe it's like GenI. You don't need to go more general, you need to go smaller, break it up.

writing stuff

Made some progress writing up the polarity stuff. Wrote a slow slow super slow "intuitive" approach to the polarity stuff. The idea is that I would have this one, no technical details and then the algorithm. Kinda worried, maybe it's too handwavy. Maybe people need sets and names and indices, something between the friendly but useless and the correct but incomprehensible.

bit tired

It's not helping. Still struggling with the polarity filtering intro. Kinda pathetic.

Improved the distributions code from yesterday. Now it looks like this:

distribution :: (Ord a, Num a) => a -> [a] -> [(a, Int)]
distribution i xs = map (second length) $ clump i xs

clump :: (Ord a, Num a) => a -> [a] -> [(a,[a])]
clump i xs = unfoldr f (minimum xs, xs)
 where
  f (_,[]) = Nothing
  f (c,ps) =
    let c2 = c + i
        (bigger, smaller) = partition (> c2) ps
        point = (c2, smaller)
        next  = (c2, bigger)
    in Just (point, next)

I like this better because the counter manipulation stuff is self-contained. No knowledge stupidly leaking all over the place.

Implemented the summarisation module that C asked for on Friday. Annoyed that this kind of stuff took me so long. Good part of it was Parsec debugging. It's quite possible that I would have been happier writing this with a regexp library instead... hard to tell. Problem working with Parsec is that you have to 'try' in tricky places sometimes. Just irritated with myself. 200 lines of script; the stuff should be be smaller than this, probably making life way more complicated than needed. Works anyway; here's the output for our small case:

failures for demander

Tn0ClVs1int
  3563 3584 3598 3599 3600 3601
Tn0Vs1intan2 (all)
  2868 2869 2876 2877 2878 2879 2894 2895 2900 2901
failed traces
  CanonicalIobject 
  CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer 
  CleftIobjectOne CleftIobjectTwo EmptySubject ImperativeSubject 
  InfinitiveSubject InvertedNominalSubject activeVerbMorphology 
  n0Vs1intan2

Idea in the tram this morning was that we could even use a simple n-gram based ranker to detect passes and fails. It doesn't have to be perfect, just good enough to give us a rough idea where the weird parts in our grammar are. I'm guessing you'd have to do some pre-processing to the corpus, lemmatise it (because GenI doesn't do morphology, poor thing), replace all the noun phrases by a generic NP tag or something. Anyway, not worth thinking about now. Focus on getting all the infrastructure in place. Got distribution counting, got the summary of failures. Now need to make it easier to hack on the grammar and check to see if the (1) the overgeneration situation has improved (2) we're still producing all the passes as before (3) we're producing any new sentences.

day of scripting

I was struggling this morning with the intro to the polarity filtering chapter. Have some random thoughts jotted down, but no really progress... gah! Spent the rest of the day writing scripts. Now have a version of geni that just counts the number paraphrases for each case in the suite. Output that stuff to a file, and then run it through another script which clumps it and spits out a distribution (number of paraphrases with < n paraphrases = X). Took me quite a while to figure out. Had some old code, but somehow didn't taste good... too adhoc. The code below is somewhat better, but probably still quite silly. The problem is that once you've programmed in Haskell for a while, you expect everything to be expressed as one-liners, and when you can't figure out how, you feel like an idiot. Oh well, at least I know how to use unfoldr now.

distribution :: (Ord a, Num a) => a -> [a] -> [(a, Int)]
distribution i xs = zip (drop 1 $ iterate (+i) $ minimum xs)
                        (map length $ clump i xs)

-- | Given an increment i and a list of points, group the points
--   by every ith increment, for example,
--     distribution 3 [1,2 , 3,3,6,8,  9,10,  12,13,14,  15]
--                 = [[1,2],[3,3,6,8],[9,10],[12,13,14],[15]]
clump :: (Ord a, Num a) => a -> [a] -> [[a]]
clump i xs = unfoldr f (minimum xs, xs)
 where
  f (_,[]) = Nothing
  f (c,ps) =
    let c2 = c + i
        (bigger, smaller) = partition (> c2) ps
        next  = (c2, bigger)
    in Just (smaller, next)

In the meantime, I've be rearranging the src directory of GenI: now split into three distinct packages, libgeni, geniprog and geniconvert. What's nice now is that the libgeni package no longer requires wxhaskell, nor HaXmL. Similarly, geni doesn't need HaXmL and geniconvert doesn't need wxhaskell. Each will have their own Cabal files. To make it convenient, I'll have a mother Makefile which will lead the user through (1) making and installing libgeni (2) making and installing the satellites. There will be something like a make world target which does everything; convenient if you're using --user --prefix=$HOME/opt.

Handy trick is to have something like -include user-settings.inc with the contents configure-dirs=--user --prefix=$HOME/opt. Note the - on the include, which makes it optional.

C's laptop had wifi troubles today... had a look at it, spinning around in circles. Turns out that it was a simple matter of hitting Fn-F2 to turn the wifi device on/off. Oh.

splish splosh (7::1282/37::15825)

No, I did not just write 1282 words in 1 hour. This wordcount jump here would be the work of yank and paste, me trying to mash up some DEA stuff with the ESSLLI'05 article. It's not readable yet, just got it so that all the macros compile, and will have to think about how to scuplt it into something thesis friendly. I spent a good bit of time wondering about what I might use as a good structural ambiguity example, but I think I'm going to just give up on that and go with my standard 'the painting costs a lot' lexical ambiguity. The rough plan would be

1. chapter intro
2. core method
3. extensions
4. structural vs lexical ambiguity [short, but just mention that although you could just this for the latter, we focus on the former)
5. evaluation
6. related work
7. future extensions

So much for my little bit of thesis a day.

looking at slides

Anyway, short Saturday afternoon: spent some time just thinking about this chapter and not doing any actual writing (aside from the ol' copie-coller). Retrieved and printed out what I hope to C's Python course stuff [egads my Python is rusty... thinking maybe that hey static typing is great, but maybe for newbies, it's best to start off without it? chop wood and carry water? not sure]. My role is to help some students play around with NLTK... students who have never seen Unix, Emacs or done any serious programming before, mind you. Maybe we should make them use GEdit or something, just reduce the number of things they have to learn at once. Dunno... or maybe trying to teach all this stuff together, without trying to piecemeal it is better in the long run, the idea being that you learn better if you can make associations between stuff... shaky hand wavy.

Data.Binary

Tried to play around with Data.Binary, because I'm sick of waiting X seconds for GenI to load the stupid grammar; but got frustrated in automatic derivation of instance Binary. Nothing related, really, it's just that GHCi blows up trying to load the wxhaskell package (why?). What I would love is for Cabal to have (optional) builddepends entries for each stanza. This way, I can have a libgeni which doesn't require many libraries, and a GenIGui in the same package, but which requires wxcore/wx. Was vaguely disappointed that there isn't something like instance Typeable a => Binary a (maybe I'm asking a lot)... yeah, there is automatic derivation, but it would be nicer to have even less grunt work! Just put deriving Typeable everywhere and go.

enlg test

The big Makefile of Destruction does appear to work after all (relief). Was just a silly little bug in my depedencies, kinda subtle, but explained in the ChangeLog. Ran it on paraphrases-1 and paraphrases-2. It didn't really come back on paraphrases-3... kind of embarassing. I wish GenI performed better, used less memory, etc. I wish I had figured out the chart stuff earlier instead of going around in stupid little circles all last year [yes I realise that going around in stupid little circles is why I understand the chart stuff better, but still]. And agh! That CKY code in GenI. I hope nobody ever sees it. Mortifyingly bad. Will need to work out some way of presenting the number-of-paraphrases distribution. Hopefully just bricole something out of the scripts I have already, should be nothing new...

short day

Today felt very short: team meeting (saw a good talk by one of our PhD newbies, and had some enjoyable cake by another newbie); sat around having coffee after lunch; now leaving early for gym.

Got in this morning and started to stub out the polarity filtering article; got kiloword written, but it's all freewritten crap, same old page blanche problems. I'm wondering how much of my Masters thesis and my ESSLLI (or other) papers I can melt into this. Also worried about our examples, can't seem to find a good example that illustrates structural ambiguity; everything we have to sell the techinque shows lexical ambiguity, which might confuse things because we really are just using it for structural. Problem with structural ambiguity is finding a simple, minimal example using the same lexical items, with two mutually incompatible things. You want something that looks like

A1 B1
A2 B2

such that A1 and B2 don't really go well together. (Anyway not incrementing my page counter because the text is all filler)

Writing some more code. Have a new 'experiments' directory dedicated to scripts and results related to specific experiments. Definitely LOVE the new libgeni (ghc -package GenI) because I can now do scripts like this without making a mess of the GenI stuff or writing huge Makefiles, whatever. Just cute little one-off packages that do one specific job without trying to save the world. Sorry I keep going on about this libgeni shit... it's just that sometimes you do something, and you keep finding out, time and time again that it was the right decision after all and you wonder what the heck you've been putting it off all this time. This is one of those situations, one less headache!

Building now a simple parser for the annotated pass/fail/output stuff. Just a bit of Parsec code, nothing special (yay Parsec! simplifies life so much). Hope I'm doing this the right way. I hope I'm not programming too much. I always have this problem of making things too complicated. If I was a better programmer, I would figure out how to do this in a simple elegant fashion that doesn't actually involve writing a new script/program.

bayesian reasoning for idiots (erics)

Also reading this very nice intro to Bayesian reasoning. I see this stuff OVER and OVER again, and each time I have to think very hard and derive the theorem myself to make sure it makes sense. I convince myself and then forget all the intuitions. I sound like a combination of all the things is this blurb:

Maybe you don't understand what the equation says. Maybe you understand it in theory, but every time you try to apply it in practice you get mixed up trying to remember the difference between p(a|x) and p(x|a), and whether p(a)*p(x|a) belongs in the numerator or the denominator. Maybe you see the theorem, and you understand the theorem, and you can use the theorem, but you can't understand why your friends and/or research colleagues seem to think it's the secret of the universe.

talk UI

I'm not going to comment on the content of the talk I saw this morning (which I did appreciate, although I don't have enough background or big picture knowledge to see its full significance), but I can say that it seemed to get all the UI parts right: no fluff (stupid flashy things), but discrete where-are-we markers, bib references on the slide without needless mention à haute voix, highlighting the ONE thing you need to pay attention to; etc. It's all about small details. The reason I get so obsessed with this kind of stuff [again, probably doing it badly myself] is that (i) it is relatively easy (ii) it can go a long way, be a big difference between me getting lost and disconnecting or following along and learning something. Hard, because you don't want people to worry too much about presentation (instead of content), but you do want them to worry just enough to make the presentation as easy-to-digest as humanly possible. It's not about dumbing things down but getting the stupid little details exactly right.

derivations (18::8321/31::14600)

Word counts going down is a good thing. This morning, spent my equivalent kiloword rewriting the bit about defaults, much less fluff, getting a little bit further into what I want to do with it. Actually, I think I've finished up talking about defaults as a possible extension the paraphrase selection mechanism. Tomorrow morning, I might consider putting this chapter aside, waiting for C's comments; and start the polarity filtering one.

Today was mostly spent coding. I mentioned to C that I was stuck on reconstructing a derivation tree from a list of operations. It's really horribly embarrassing; I "see" how to do it, just having a block putting it down into acutal code. I have my thing which merges labeled trees together, but it's pretty fragile, incorrect, to be precise. Anyway, C got me very simply and efficiently unstuck by suggesting I just move on and use what I have, i.e. just print out the list of operations. A very agile idea, keep moving forward, don't dick around, trying to achieve some subsubsubgoal when you can just push ahead on the other aspects of the problem. So mark me relatively happy today.

libgeni

I've removed all the derivations output from GenI, now that we have libgeni to take care of that. Have also extended libgeni so that we output derivation operations instead of just the elementary trees used. GenI-proper no longer tries to print derivations, just sentences and stats. If you want to do funky things for experiments, you don't use GenI. Instead you write a small program using GenI as a library. Advantage is that the experiment-specific program can be clean and simple because you're not trying to cover 36 different ways of doing things. Just one stupid job. One reason to be happy: the libgeni thing I've been meaning to do for so long has paid off.

printing derivations

It works... sort of... We haven't killed overgeneration yet, but by clustering the outputs according to lexical selection, you can see some illegal adjunction in action. Output sorta looks like this:

output:[demander ce etre paul que il venir à jean]
venir      <-(a)- demander
venir      <-(s)- paul
demander   <-(s)- jean

output:[ce etre paul demander que il venir à jean]
venir      <-(a)- demander
venir      <-(s)- paul
demander   <-(s)- jean

output:[ce etre paul que demander il venir à jean]
venir      <-(a)- demander
venir      <-(s)- paul
demander   <-(s)- jean

demander Tn0Vs1intan2-2901
  CanonicalIobject 
  CanonicalSententialObjectInterrogativeFiniteWithoutComplementizer 
  EmptySubject ImperativeSubject SententialInterrogative 
  activeVerbMorphology n0Vs1intan2
jean Tpropername-3221
  propername
paul Tpropername-3221
  propername
venir Tn0V-806
  CleftObject ImpersonalSubject NonInvertedNominalSubject 
  activeVerbMorphology n0V

derived trees?

Was thinking that maybe I should try printing out simplified derived trees for the outputs, like remove as much bracketing as possible, remove all categories except for S and N. I suspect that makes for structures which are both readable and communicative. Only thing is that it's going to be a slight pain in the ass code-wise. Will have to circumvent all that generalised crap I wrote when I thought I'd have a bunch of different algorithms that worked differently. Will have to see what C thinks.

S(demander S(ce être paul que S(il venir) à jean)
S(ce être paul demander que S(il venir) à jean)
S(ce etre paul que S(demander S(il venir)) à jean)

cabal stuff

What a relief! The new exclusively Cabalised GenI still compiles on C's GHC 6.4.2 (albeit with Cabal 1.16; haven't tried a vanilla one). Installing with --user --prefix=$HOME/opt is really great... a bit like what you do when you have an ozmake --install. Also, Conal Elliot's cabal-make is quite handy for making sure the Makefile still does what you'd expect, using Cabal as a backend.