Economic Models for Turbulent Times Part I

Crust is an algorithm for reconstructing surfaces of any topology. In other words, it is a computational method for digitally rendering any 2-D shape, using data in three-dimensional space as input.

CSAIL buildings at MIT

Strange topology at MIT

Such methods garner a lot of attention these days. Here are a few reasons why: Graphical simulation models are increasingly needed for visualization and testing purposes in the field of particle physics. World of Warcraft and Second Life rely heavily on computationally intensive computer graphics, and scalable distributed systems. The U.S. economy is a highly complex system, partly guided by the results of mathematical models.

Crust was developed as a collaborative effort between two staff scientists at Xerox PARC and a researcher at MIT.

None of this happened recently. In fact, Crust hasn’t been semantically linked with the word “new” since its debut at the 1998 ACM SIGGRAPH Conference.

What is so special about Crust?

The Crust algorithm is special because it has certain features uncommon in most quantitative models, yet highly sought after.

First, Crust offers results with “provable” guarantees. Given a good sample from a smooth surface, Crust’s results are guaranteed. That is, Crust guarantees that its output is topologically correct, converging to the original surface with increasing faithfulness depending on the input data density.

Voronoi pig

Graphical computation with Crust: Voronoi Piggy

The third member of the Crust project team was Manolis Kamvysellis, a Ph.D. student at MIT. Manolis did much of the implementation and testing work—he wrote a short-form version, A New Voronoi Based Reconstruction Algorithm [PDF], of the original ACM journal publication. Happily, he had the good sense to demonstrate Crust with this fine pink pig! Let’s do the same.

Highly efficient porcine reconstruction in three dimensions

Recall that Crust’s criteria for acceptable sample size is determined dynamically . A single topological surface, such as Piggy, may have very detailed surfaces, with high data density. Observe this near Piggy’s ears and snout. Other areas like the hindquarters are quite featureless.

Crust dynamically adjusts its smallest acceptable sample size accordingly. Even minimally detailed surfaces such as Piggy’s lower hind quarters above the hooves can be reconstructed accurately.

To be continued…

Published in: on December 5, 2010 at 7:58 am  Comments (5)  
Tags: , , , , , ,

Random Numbers in Java

This post is about alternatives to the java.util.Random class, the most commonly used method to generate random numbers in Java.

Dice players of antiquity

Random: Playing the odds in Ancient Rome Osteria della Via de Mercurio

 java.util.Random

This class generates “random enough” values, which are described as having an informal level of randomness. Such numbers have a superficial appearance of randomness to an observer, usually a human observer, not a machine. These are considered low-quality random numbers. They should never be used in any security application.

True randomly-generated numbers must have the following characteristics:

  • Any number is equally likely to be generated on every iteration. This is also known as a uniformly distributed series of numbers.
  • The second criterion follows directly: No dependency exists between successive numbers as they are generated.

Alternatives to better match your random needs

Neil Coffey of Javamex describes three alternative random number generation methods. Each approach continues to use class java.util.Random, while replacing the underlying algorithm. The first, called the XORShift generator, produces medium-quality random numbers very quickly, with only a single state variable and very simple code. This method is very well suited to J2ME games.

The next algorithm generates much higher-quality random numbers. It is a combined generator, using two XORShift generators of the sort described above. Mr. Coffey provides the code and explanation for the algorithm. This combined XORShift yields good-quality random numbers. It is suitable for non-gambling games and simulations, although it runs slightly slower than java.util.Random.

A cryptographic quality random number generator should have the following properties:

  1. It should be impossible to predict prior and future numbers from any number generated;
  2. The numbers should have no discernible biases;
  3. The generator has a large period;
  4. The generator can seed itself at any position within that period with equal probability.

A cryptographically secure random number generator is appropriate for security applications such as producing a web-server session id or picking encryption keys. Very high-quality random numbers are generated using java.security.SecureRandom as the replacement for java.util.Random. The trade-off in quality versus CPU cycle consumption is hardly surprising.  java.security.SecureRandom runs 20 to 30 times slower than any of the other algorithms.

Relative comparison between the methods

Here is a very simplified way of understanding the difference between each algorithm.

Let’s say that we need to generate a 128-bit encryption key. java.security.SecureRandom actually picks from a pool of 2 raised to the 127th power number of possible keys. Of course java.util.Random can also be used to generate a 128-bit key. However, the values will be selected from a smaller pool of numbers, on the order of 2 raised to the 47th power number of possible keys. This is because java.util.Random has a much shorter period, equal to 2 raised to the 48th power.

The single XORShift generator method falls between the two, as it has a slightly longer period, of 2 raised to the 64th power. The combined XORShift generator approach extends the period a bit further.

Note than neither java.util.Random nor either of the XORShift generators are seeded randomly. This is why java.security.SecureRandom, with a machine-generated and much more truly random random seed, is superior.

* The machine-generated random seed is what is called entropy in random number generators.