Tuesday, October 20, 2009

[research] Rigour

This evening we were discussing with colleagues about rigour, and how to avoid mistakes to bleed into your code / paper / results. Of course, this is of the highest importance when, as a researcher, you intend to propose new methods and show that they do produce better results than previous ones (or at least that they do what they are supposed to!). Rigour is a minimal requirement.

Unfortunately, being rigorous is not something easy. For me, a key difficulty is detecting typos in text and formulas. Sometimes, it seems that regardless of how much time I read and triple (quadruple) check formulas, there is always some mistake managing to get in. For instance, we are about to publish an errata on one of our paper. Nothing horrible, but still a few formulas got wrong due to a last minute change (!) in notation. None of us, none of our careful proof-readers (who spotted many other typos), nobody saw the problem until a very careful reader pointed it out. I think at some point the brain just replaces what you read by what you know should be written. This is really annoying as we spent a large amount of time checking every single detail. I wonder whether some of you might have good tips on how to avoid this kind of mistakes? (I know that putting the paper aside for a few days and then re-reading it helps - unfortunately this is often not an option due to tight time constraints).

I have, however, some tips and tricks for writing code and checking results that I'd like to share. Most of these have been learned the hard way: In graphics, many errors can go silent and in spite of a bug your algorithms still produce results (possibly even 'good' ones, that's the problem!). There is one project in particular that really made me switch to a 'triple check everything' mode. I was student at the time. After getting all excited about early results - showing them to my entire lab of course ;-) - I had discovered a bug that totally invalidated everything. It was a huge setback, and I also think it revealed a weakness in my way of doing things. This should not happen, because you must be sure of your results. You must be sure that you are sure. You must be able to claim without fear that you know what is going on, and that you understand every little thing happening under the hood. You may not disclose any result before you get to this point. Is that possible? I think yes - there is no magic involved after all - and we should at least do everything we can to get to this level of certainty.

Here are a few tricks I learned during my studies, from my supervisors, and from experience:

- Assert everything. You are writing the code and you are thinking 'haha, this variable will never go below zero so I can take advantage of this'. Well, if you expect it, then assert it right away! Same goes for file IO (how many mistakes due to bad data?), out of bound accesses, null pointers, user inputs, and so on. It is not reasonable to write research code without asserting every little piece of it. Research code is way more fragile than production code - it is constantly going through revisions and changes. So why should it contain less checks? I basically assert every little piece of knowledge I have about variable values, array statuses (is it still sorted?), pixel colors, etc. Apply this strictly and never diverge from it, it will save you tons of time by detecting errors early. Of course, make sure you can compile with a NO_ASSERT flag for max performance when doing final measures.

- You shall not remove a failing assert. 'Darn, it's 11pm, this assert fails and if I comment it everything works. Must be useless.' This is the perfect recipe for the most horrible errors. Never step over a failing assert. If it fails you must understand why and you must fix the cause, not the consequence. An assert is a sacred safe guard. Removing an assert should only occur if you have a clear understanding of why this assert somehow became outdated.

- Verify your code with sanity checks. Try the following: If you give your image processing method an entirely black image, what would happen? Once you think you know what will happen, test it. If something unexpected happens then understand why and correct any potential problem. Try that with the most simple and straight forward inputs. Make sure they all do produce the proper results.

- Stress your code with wrong data. 'Why would I throw this crazy data at my method?
I don't want to see it fail!'. This is all the contrary. You want to see your program crash, fail and die in all possible ways. When it no longer crashes despite what you are throwing at him, you may try with reasonable data. Before that, you must ensure improper input is detected and that asserts fail as appropriate. Do not discard any problem (... 'anyway, that's crazy' ...) or it will come back and bite you. You can be sure of it. Never leave out a loose end.

- Quit 'Darwin programming'. 'Hmmm, should this be plus or minus 1? Let's try until it works...'. I used to do that a lot, it never was a good idea. If you wonder about a detail, then put the keyboard aside and go to the black (/white) board and figure it out. Random programming does not work. At best it will seem to work and will let you down on the first occasion. And how are you going to justify this '0.1234567' scaling in the paper? Because I assume you'll mention it, right? Stop trying random stuff. It is just not compatible with the rigour required by research.

- Verify your results with another approach. This is not always an option, but whenever possible implement a different way of getting the same results (even if very slow), just to double check your approach with another piece of code. I often do that between CPU and GPU implementations. This lets you track down small implementation errors by comparing outputs. In our last project we even did two implementations (CPU/GPU) by two different coders. This was really great in terms of tracking down problems.

- Match notations and names between code and paper. To reduce the risk of wrong formulas in the paper I try to match notations in the code and the paper - even if this means modifying the code while the paper is being written. This is yet another sanity check on both the paper and the code. Last time I diverged from that an error was introduced, so I am going to strictly enforce this rule now.

Sure, even with all that mistakes still happen. But I believe mistakes are fine -- not trying to avoid them is however unacceptable.

Monday, October 12, 2009

[wubi] Transfering your wubi on another computer

The other day my desktop hard drive failed, putting an end to my Vista partition and everything in it. With the I3D 2010 deadline arriving fast, I needed a way to get up to speed quickly (data was backed up but not the system). I did not want to reinstall all applications under Windows.

Since our project compiles under both Windows and Linux, and since I have it running under Ubuntu / Wubi on my laptop I tried the following: I did a fresh Windows + Wubi install and replaced the new 'root.disk' by the one from my laptop.

And it worked!

After booting it was like being on my laptop but ... on my desktop. Everything worked but for the NVidia drivers - even though my laptop has NVidia hardware like my desktop. I had to reinstall the driver, which for some reason could not find the kernel sources (really strange since this was the same file system after all). I simply had to specify the path explicitly (--kernel-source-path). This saved my day!

Friday, August 28, 2009

[game] Fun with the WiiMote

I have been enjoying some time off and, as always, I tried to explore a few new things. I have seen many cool applications exploiting Wiimotes, and I decided it was about time for me to give it a try.

To start with something, I decided to hack in Ragdoll Smasher and to use the accelerometer to drive the ragdoll.

I plugged in the bluetooth USB dongle that some vendor convinced me to buy with my first mobile phone - I'd have never guessed that I would actually use it one day! - and I downloaded what seemed to be the main library for talking to a WiiMote from C++: WiiYourself!

WiiYourself! comes as a single cpp file, and a commented demo code - that's just perfect to start. Everything works very well, and apart from the painful part of downloading and installing the Windows Driver Kit it was really easy to get the wiimote working, and to call WiiYourself from my own code.

I put all the WiiYourself intialization in a separate thread, so that it can handle gracefully waiting for new Wiimotes or Wiimote disconnections.

Now, here is when the interesting part kicks in. What I wanted to achieve is to let the user give some impulses to the Wiimote to throw the ragdoll in one direction or another.

However, this is an accelerometer, and you do not get a nice, clean vector telling you in which direction the user moved the Wiimote. On the images below, I have overlaid the output of the Wiimote accelerometer x,y and z axis. The user has applied a left ( +x ) impulse. The x axis is shown in red.

Now the same for a right ( -x ) impulse:

You can probably see the pattern appearing: For a left impulse, the curve goes up first, then down and then comes back to low values. For a right impulse the curve goes down first, and then up. I used this property to implement a simple 'impulse' detector on each axis. The idea is illustrated by the image below:

The blue line is the 'zero' (Note: the z axis is not centered on zero due to gravity! On my Wiimote it is centered on 1). I am using a threshold to detect when the curve goes up and down. By simply tracking whether the curve does a up/down or down/up impulse - in a limited time window - I can easily detect impulses applied by the user to the controller. The 'height' of the bumps gives me an indication of the strength.

This very simple approach works quite well in practice, and I can throw the ragdoll in all directions with small impulses applied to the Wiimote.

Monday, July 6, 2009

[linux] Wubi and the 'no disk' issue

This evening I wanted to try Wubi at home. I already gave it a try earlier on my office computer, and it had failed with a strange error: "No disk" message box displaying "Exception Processing Message c0000013 Parameters 75b6bf7c 4 75b6bf7c 75b6bf7c"

Same thing happened at home. I was quite disapointed and searched for this error on Google. The problem is explained here.

It turns out my Dell screen has a card reader. This card reader creates drive letters with nothing attached to them (until a card is inserted that is). This disturbs the Wubi installation script.

There are several ways around (such as clicking like crazy on 'continue') but instead I looked for a way to remove these 'empty' drive letters. And, I found a nice small tool doing exactly that, among other useful USB drive letter management options: USBDML.

Give it a try, it works like a charm. Now Wubi can install!

Friday, July 3, 2009

[various] market segmentation

Coding horror has an interesting post about market segments. I think it strongly relates to the euro / dollar / ip-based region locks problems I have been confronted with. I especially like this piece of the post:

Sure, don't make us customers think. Unless you want us to think about how much we'd like to pay you, that is.

Exactly :-) I see two possible outcomes for the current 'region segments' imposed by retailers:
  1. They disappear
  2. We won't be allowed to order oversea anymore, and shop websites will be unaccessible from outside the country

Guess what's most likely?

Friday, June 26, 2009

[research] We're hiring PhDs!

I am looking for a PhD student, starting around next September (2009) at INRIA Nancy on this topic . The profile is a student with a master degree, a strong background in Computer Graphics, familiar with Graphics APIs (OpenGL and/or DirectX) and image processing. Optionally, a background in machine learning would be appreciated. But, most importantly, I am looking for someone with a strong motivation to learn new things and explore novel ideas and algorithms. Is that you? Then contact me!

Tuesday, June 23, 2009

[various] 1 dollar = 2 euros

We all know pricing policies do not exaclty match the globalization trend. But sometimes it becomes so ridiculous that it is worth noting.

I need a new keyboard, and I need it to be a QWERTY keyboard (here shops sell AZERTY keyboards which is not great for coding - I am in fact using a QWERTY layout on an AZERTY keyboard ... confusing!). I was shoping for books on Amazon US, and decided to have a look. I found the 'Logitech Illuminated Keyboard' to my taste. At this date it is 66.48$. Here I am, checking out, when suddenly the killer message pops up 'This item doesn't ship to your country'. Well, no big deal, let's check out Amazon.fr. Bad news: 1) AZERTY only 2) out of stock 3) 87,89 euros! That's only ... wait ... 122.852$ !!! (today's rate). On Logitech website it is even better: The keyboard (QWERTY version) sells 94.99 euros, or 132.7$.
Yes, that's twice more. Pretty nice huh? (I am assuming Logitech is preventing amazon from shipping - this is more or less what is implied by Amazon as the reason for not shipping. EDIT: Apparently none of the keyboards on Amazon ship to Europe! I'll have to stick with my AZERTY for a little longer)

[code] The library watch

"There are no bad tools, there are only bad workers" Well, there may be some truth to this, but surely good tools cannot hurt! Any skilled programmer has a few libraries up his sleeve, ready to be launched after some nasty problems lurking at him.

In fact, I find libraries to be an essential tool for a researcher in a hurry to prototype ideas - which often involves solving non-trivial sub-problems. So, what libraries are you using in your every day endeavors?
Here are my favorites (I'll skip the basics such as libpng, zlib, etc.):

  • Loki - the libary that made me realize what templates are for. Andrei Alexandrescu's book is a must read!
  • TAUCS - linear solver for sparse matrices
  • ANN - approximate neighbor search
  • AntTweakBar - GL/D3D gui, simple, clean and powerful
  • LUA - scripting, very easy to integrate
  • tolua++ - makes lua even easier to integrate with c++
  • TClap - command line parameters, template based
  • ODE - physics
  • Bullet - physics
  • fftw - fast Fourier transforms
  • SDL / SDL_net - media library. I essentially use it for multiplatform threads and networking. A bit old-school but still very effective.

Now, some libraries I am planning on using much more regularly:

  • Boost - how could I live without it! (the answer is Loki+Tclap+SDL+home-grown-stuff ;-) but of course Boost is a must-use)
  • SQlite - SQL database in a local file (no server, no config, all is done from your application). Thanks to Anteru for pointing this one out!

Wednesday, May 6, 2009

[research] Video of our SIGGRAPH paper

Our paper on procedural textures was accepted at SIGGRAPH 2009!!!

We will release the paper soon, but in the meantime you can check out our paper's video on the project webpage.

Wednesday, April 1, 2009

[conference] Eurographics 2009

I am currently at EG 2009. Interesting papers, brainstorming, fun and - since we are in Germany after all - a fair amount of good beer :-)

Marcio Cabral will be presenting our 'Mesh Puzzle' paper, and I'll be sharing a talk with Li-Yi Wei to present our STAR report on texture synthesis; co-authored with Vivek Kwatra and Greg Turk.

Btw, don't miss the tutorial implementation of our Parallel Controllable Texture Synthesis algorithm (SIGGRAPH 2005).

Saturday, March 14, 2009

[various] RotoPath

How much time do you spend navigating through folders every day? For me, the answer was: Way too much.

I decided to give a try to an old idea and created a very simple app to navigate through folders (folders only, this is not a file explorer!!). It presents folders in a wheel. A left click goes to the next folder, a right click opens explorer on the folder. The wheel can be displayed at any time by pressing Left-Control and Left-Windows simultaneously.

As can be seen some folders are shown in red: These are the folders you use most often. Hence, they are visually outlined so that you can quickly get to the places the most important to you.

There are three special icons in the middle: Open command line at current folder, Show favorite folders, Go back to the computer root.

RotoPath is brand new and will likely have a few bugs, but it already helps me a lot on an everyday basis. Maybe you'll find it useful as well.

[No longer available]

Monday, March 2, 2009

[linux] Fedora saved my day!

Today I just lived what I consider to be a true computer technology miracle.

I was teaching in Paris today. The class involves powerpoint slides and then some OpenGL programming (each student has a computer to work with). As usual, I prepared my slides and the source code for the gl tutorials on my laptop. What was not usual is that I *forgot* to backup the files on my usb stick. 'So what?' did I think when arriving at the airport, it would really be bad luck if my laptop crashed today.

Guess what.

Windows soon refused to boot, chkdsk kept detecting more and more bad sectors at every run, and so on. The usual story. The dell repair tool only knows how to format the entire thing (I have a XPS M1330, and yes the NVidia card was faulty), and there was no booting windows. After the first battery emptied I felt very lonely, with my faulty computer, in the middle of the airport with no power plug in sight. 'If only I was home, I could boot from my Knoppix CD, access the NTFS drive and save the whole thing on a USB stick.'. And then I saw the light. Here it was, looking at me through the book shop window: The February issue of 'Planete Linux' - a French magazine about the Linux OS - and the distribution of the month was Feodra 10 Live with an included CD!!!

After spending 6.20 euros on the magazine - not a bad read by the way - I quickly tried it out. After a few minutes I had a full fledged Linux running! I was able to mount the faulty ntfs partition (with scary errors) and was able to retrieve my slides!

Arriving in the classroom, already feeling lucky enough, I was planning to ask a student for his laptop to display the slides. But, out of curiousity, I tried the included openoffice. It did open the slides with success! So, while I was at it, feeling quite invicible, I plugged the projector to my laptop-with-fried-hdd-but-working-Live-Fedora. And *it* *worked* *just* *fine*.

So here I was, with my CD-only OS, displaying my slides with OpenOffice on a DLP projector and all this for 6.20 euros when 2 hours earlier I was screaming over my dying Windows-powered fried-hdd laptop.

Needless to say, Fedora just won an unconditional fan!!!! I am actually writing this entry using the very same Fedora Live CD, through the included WiFi support.

Thanks guys for saving my day :-)

Tuesday, February 3, 2009

[code] SAPI

I recently rediscovered SAPI, the Microsoft speech API. I used it a long time ago, and basically forgot about it. Which is a shame, because it is a really fun tool to play with. It is extremely easy to make your computer talk. While the voice is a bit aging under XP, the Vista voice is reasonnably good.

For those interested, here is how to call SAPI from C#.