SQL Optimisation article

Thanks to Martin for pointing me to this Microsoft article on SQL optimization: Best Practices for Semantic Data Modeling for Performance and Scalability. A tightly packed and in depth look at various SQL Server optimisation techniques.

The Grand Design

I've just finished "The Grand Design": Stephen Hawking's explanation of how the universe came to be. Chapter 7, 'The apparent miracle', addresses the problem of fine-tuning whereby many fundamental constants of the universe appear to be fine-tuned for life. This appearance of fine-tuning is a fairly widely accepted phenomena and demands explanation. But his explanation still leaves me wanting.
As most do, Hawking appeals to the anthropic principle, which for our purposes can be read as "of course it looks suitable for life, because if it didn't then we wouldn't be here asking questions". Now this only works if there are many universes. If there are countless universes with different parameters, then it seems reasonable that some might fluke the right parameters, and those are the ones that would have curious life forms. However if there is only one universe, then the incredible odds-against suggest that chance alone could not given us the right parameters. By analogy, it is not surprising that people win Lotto sometimes, given the number of games and people being played. But if in all of history there had only been a single player playing a single game of Lotto, then a jackpot result would have to be viewed with suspicion.
In chapter 7 he gives us the succinct: "We saw in Chapter 5 that our universe seems to be one of many, each with different laws.". Yet chapter 5 seems to do nothing of the sort. The closest we get is "The laws of M-theory therefore allow for different universes". In my mind it is a fairly substantial and unwarranted leap of logic from 'the universe could have different constants' to 'there exists oodles of universes with different constants'.
Typically, the home for all these universes is the multiverse. But there does not seem to be any good reason to think we can ever test for or prove the existence of a multiverse (and suggestions to the contrary are fairly hand-wavy), as it is by definition outside the realm of our observable universe. It seems that the usual motivation for invoking a multiverse is in order to enable the anthropic principle, thereby providing a naturalistic explanation for the apparent design we see in our universe. For example, Wikipedia gives us:

The concept of other universes has been proposed to explain why our universe seems to be fine-tuned for conscious life as we experience it.

However this is circular reasoning: in order to demonstrate that the universe has naturalistic causes, we had to invoke an untestable extra-natural multiverse that we only invented to solve the problems with a naturalistic causes.
Hawkins believes he escapes the problem of a multiverse by instead packing all of these universes as different possible histories of our own universe, in the freaky quantum 'everything possible history is happening at once' kind of sense (i.e. Feynman's sum of histories). The universe then collapses onto life-sustaining constants because we're observing it. But this still seems to suffer the same kind of problem: declaring that the universe could have had different constants and laws is very different to declaring that there are different histories that would take on all these possible combinations. I'd love to hear from someone who understands the physics better whether there is any valid explanation to bridge this gap.

XmlSerializer inheritance woes

OK, this just drove me crazy for about an hour. I'm using the XmlSerializer, and my object graph has derived types.

I was using the XmlInclude attribute in the correct manner, but I still kept getting:

The type Child was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.

It didn't work when I passed the extraTypes parameter to the XmlSerializer constructor either.

In the end it turns out that the 'Namespace' declaration was the problem. Adding an identical namepsace to the Child class fixed the problem. Strange because up until using inheritance things have worked fine only specifying it on the root class.

[XmlRoot(Namespace = "somenamespace")]
public class Root
{
 public Parent Field { get; set; }
}

[XmlInclude(typeof(Child))]
public class Parent
{
 public string Data { get; set; }
}

public class Child : Parent
{
}

...
Root r = new Root();
r.Field = new Child();

Markov analysis of Beetle

Having young kids, we seem to have a lot of games around the house at the moment. The geek in me starts looking at them as maths challenges. Beetle, by Milton Bradley, is a variant on the classic dice game. I was curious to use Markov chains to figure out the average game length, and which positions were closer to victory.

Basic rules:

• Take turns spinning the spinner to build a piece of the beetle
• 1/6 chance of getting the body
• 1/6 chance of getting the head
• 1/6 chance of getting one of two eyes
• 1/6 chance of getting one of two antenna
• 2/6 chance of getting one of six legs
• Must get the body before getting anything else
• Must get the head before the antenna or eyes

This allows for 71 states as depicted in the diagram below:

The 71x71 matrix is basically formed from the above diagram. There are three regions:

• no body
• body, but no head
• body and head

Within each region there are various combinations of legs or other pieces, as permitted. E.g. state 'A' has no pieces; state 'B' has a body, no head, and five legs; state C has a head and body, one antenna, two eyes and one leg; state 'D' is a completed beetle. Each successful spin moves either to the right or down (or 'out') to an adjacent state.

Result: 31.498 spins on average.

The following table shows the average number of moves remaining to victory from each position, sorted by moves remaining (hopefully the notation is self explanatory):

Combination	Average turns to victory
b h e2 a2 l6	0.00000
b h e2 a2 l5	3.00000
b h e1 a2 l6	6.00000
b h e2 a1 l6	6.00000
b h e2 a2 l4	6.00000
b h e1 a2 l5	7.00000
b h e2 a1 l5	7.00000
b h e1 a2 l4	8.66667
b h e2 a1 l4	8.66667
b h e1 a1 l6	9.00000
b h e2 a2 l3	9.00000
b h e1 a1 l5	9.50000
b h e1 a1 l4	10.58333
b h e1 a2 l3	10.77778
b h e2 a1 l3	10.77778
b h a2 l6	12.00000
b h e2 l6	12.00000
b h e2 a2 l2	12.00000
b h e1 a1 l3	12.18056
b h a2 l5	12.33333
b h e2 l5	12.33333
b h a2 l4	13.11111
b h e2 l4	13.11111
b h e1 a2 l2	13.18519
b h e2 a1 l2	13.18519
b h a1 l6	13.50000
b h e1 l6	13.50000
b h a1 l5	13.70833
b h e1 l5	13.70833
b h e1 a1 l2	14.18287
b h a1 l4	14.27778
b h e1 l4	14.27778
b h a2 l3	14.33333
b h e2 l3	14.33333
b h e2 a2 l1	15.00000
b h a1 l3	15.26736
b h e1 l3	15.26736
b h e1 a2 l1	15.79012
b h e2 a1 l1	15.79012
b h a2 l2	15.95062
b h e2 l2	15.95062
b h e1 a1 l1	16.48650
b h l6	16.50000
b h l5	16.60417
b h a1 l2	16.66705
b h e1 l2	16.66705
b h l4	16.94097
b h l3	17.60417
b h a2 l1	17.89712
b h e2 l1	17.89712
b h e2 a2	18.00000
b h a1 l1	18.42943
b h e1 l1	18.42943
b h e1 a2	18.52675
b h e2 a1	18.52675
b h l2	18.63561
b h e1 a1	19.00662
b h l1	20.03252
b h a2	20.10700
b h e2	20.10700
b h a1	20.49312
b h e1	20.49312
b h	21.76282
b l6	22.50000
b l5	22.53472
b l4	22.67014
b l3	22.98148
b l2	23.53286
b l1	24.36608
b	25.49833
empty	31.49833