Wednesday, 21 December 2011

Qt Jambi Event Tutorial

This tutorial / example will show you how to use QT Events (not slots-and-signals). We'll start with the following "hello world" (remember to use command line arguments -d32 -XstartOnFirstThread if you're running it on a mac):

public static void main(String[] args) {
 QPushButton hello = new QPushButton("Hello World!");
 hello.resize(120, 40);
 hello.setWindowTitle("Hello World");;
 Thread.currentThread().setName("MAIN"); // let's label it for clarity
 QApplication.exec(); // jump into the event loop

The last line is the most relevent - it makes the main thread listen to the event queue and dispatch events to the relevent QObjects. When the event loop sends an event to a QObject it calls all the event filters that object has (see later), then invokes public boolean event(QEvent e) with the event. We'll create our own event class:

public class MyEvent extends QEvent {
 private final long time; // our "business logic"
 public MyEvent() {
  this.time = System.currentTimeMillis();

The Type enum is required by the native code as a faster way of accessing the type of the object. This isn't really needed in Java code - most examples use Java's instanceof keyword instead. We'll make a thread to periodically send instances of these events to our hello-world button:

Thread t = new Thread(new Runnable() {
 public void run() {
  while (true) {
   try {
    QApplication.postEvent(hello, new MyEvent());
   } catch (InterruptedException e) {}
 }, "event-firer");
t.setDaemon(true); // so the JVM exits when the window is closed

Make sure you instantiate this before putting the main thread into QT's event loop! The most important line is QApplication.postEvent(hello, new MyEvent()) - this creates an event and puts it on the event loop's queue. The first argument tells the event loop which QObject to dispatch this event to. We could have used QApplication.sendEvent(hello, new MyEvent()) instead; this would still evaluate the event filters and call event, but would do so synchronously, without placing the QEvent on the event loop's queue.

Unfortunately it's not obvious if this is working. We'll add the Qt Event API's equivalent of a println statement, a filter that just prints all the events it receives:

private static void printEvents(final QObject obj) {
 obj.installEventFilter(new QObject() {
  public boolean eventFilter(QObject o, QEvent e) {
    o + 
    ": " + 
    e + 
    " on thread " + 
   return super.eventFilter(o, e);
// and in the main method:
// or instead, install a special global event filter:

This filter will be evaluated before the QEvent gets send to the button's event method. You should see a stream of events on the console (especially if you click the button) like the below - note that the filter is executed on the MAIN thread (the one running the event loop), not the thread that posted the event.

QPushButton(0x1dc9d0) : MyEvent 1324477542957 on thread MAIN
QPushButton(0x1dc9d0) : QEvent(type=ZOrderChange) on thread MAIN
QPushButton(0x1dc9d0) : QMouseEvent(MouseButtonPress, 1, 1, 0) on thread MAIN

If you return true from the eventFilter method you're telling the event loop that that event has been processed completely; the remaining filters and the QObject's event method won't be called. You can try it in the example: if you make the eventFilter method of the filter installed by printEvents return true you'll see that the button doesn't get painted properly (as the QPaintEvents are not getting to the QPressButton) and the button doesn't react if you press it.

The QAppication's notify method is similar to sendEvent (so must be called on the same thread as the QObject was created on), but returns true if any filters succesfully processed the event, and the return value of event on the target QObject if not.

While some QT documentation refers to QEvents being passed to parent QObjects if the QObject they are sent to returns false from event it won't work out of the box for our MyEvent class as it's a custom event type. You'll have to add that functionality yourself, either by overriding the implementation of notify or invoking the parent QObject's event method in the child's event method. You can see the native code implementation of notify here.

Saturday, 8 October 2011

A Monte-Carlo simulation is a way of numerically solving problems that involve randomness. This tutorial explains how they can be used in the context of financial valuation, with examples in Ruby.

I’m going to propose a contract: I will flip a coin ten times, and if I get three heads in a row I will give you $1. How much will you pay me to enter into that contract? To work out how much this contract is worth, I’m going to start by writing a simulation of ten coin flips:
>> def do_10_flips
>>   (1..10).map{rand > 0.5 ? "H" : "T"}.join ""
>> end
=> nil
>> do_10_flips
>> do_10_flips
>> do_10_flips
This is the most important part of Monte-Carlo simulation - how you define the underlying process. I’ve made many assumptions in my function; all coin flips are independent, and all have the same probability of coming up as heads. “rand” returns a number between zero inclusive and one exclusive. This means my coin is ever-so-slightly biased towards heads - to be fair the comparison should be greater-or-equals, not strictly-greater-than (an exercise: see what difference this makes). If I were simulating a stock price instead of a coin flip I’d have a very different function with a much different set of assumptions.

For a single set of ten coin flips, I’m going to work out what the payoff of my contract would be (one if it has three successive heads - i.e. the string contains “HHH” and zero otherwise):
>> def payoff
>>   (do_10_flips.include? "HHH") ? 1.0 : 0.0
>> end
=> nil
>> payoff
=> 0.0
>> payoff
=> 0.0
>> payoff
=> 1.0
This is a single simulation of the value of the contract - a Monte-Carlo simulation essentially estimates the value of this contract by running many simulations (called “steps”) and taking the mean of the values predicted by each step:
>> def monte_carlo_solve n
>>   ret = 0.0;n.times{ret += payoff};ret /= n
>> end
=> nil
Using a Monte-Carlo simulation isn’t a silver bullet - If I attempt a valuation using a single step I’ll either get zero or one. More simulation steps means a more believable answer, but not necessarily a more accurate one. (We've also made the assumption that the "rand" function doesn't return the same numbers for each simulation step, and that each random number is uniformly distributed). Maybe we should pick a precision and increase the number of simulation steps until the valuation to that precision doesn't change? More simulation steps means the valuation takes more time, but the two are not necessarily related by a constant factor (unless you make an assumption about how the "rand" function scales).
>> monte_carlo_solve 1
=> 1.0
>> monte_carlo_solve 10
=> 0.7
>> monte_carlo_solve 1000
=> 0.49
>> monte_carlo_solve 100000
=> 0.50733
>> monte_carlo_solve 1000000
=> 0.507764
In summary, the value of the contract I proposed is 51 cents according to the longest Monte-Carlo simulation I ran. Would you be happy paying that?