The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades. Why?! Let me offer up a parable; I will call it “The Plank.”

Ruth Rosenholtz proposes several measures of Visual Clutter, the most practical of which is to compress the image in question using JPEG2000 – the smaller the resulting file, the less clutter.

JPEG2000 compression never really took off, but you can get JPEG2000 compression using the OpenJPEG or JasPer libraries. GraphicsMagick provides commandline access to the JasPer library.

A colleague of mine once proposed disinvesting in companies based on the clutter found on their home page – an unfocused company would tend to have a homepage beholden to too many competing interests within the company, resulting in a homepage populated with too many grabs for the users attention. Would be an interesting excersise to track measures of homepage visual clutter versus stock price.

This nested loopiness means that if you do anything more complex than filtering or mapping on a collection, for example a join, you will rapidly end up in a world of performance pain and your query starts performing O(n^m), where m is the number of nested loops.

Consider the following LINQ query:

var q = from c in customers
join o in orders on c.Key equals o.Key
select new {c.Name, o.OrderNumber};

This code will get translated into something like this:

foreach (var c in customers)
foreach (var o in orders)
if (c.Key == o.Key)
yield return new { c.Name, o.OrderNumber };

For small collections, this approach is fine, but when they start to get larger, the number of times through the loop is going to get out of control.

Relational databases sometimes have to perform the same algorithm, but they also provide the possibility of indexing the collections, which in the case of the example above, would eliminate the necessity of scanning through all the orders checking each to see if its key matches a customer – instead, the index would be used to rapidly identify the small number of matching orders.

You can bet your bottom dollar that Microsoft has something in the works to address this issue – LINQ to objects is basically useless without indexes. In the mean time, however, there is i4o, a project to do exactly that:

Introducing i4o
Codeplex – i4o

Every programmer with a few years’ experience or education has heard the phrase “premature optimization is the root of all evil.” This famous quote by Sir Tony Hoare (popularized by Donald Knuth) has become a best practice among software engineers. Unfortunately, as with many ideas that grow to legendary status, the original meaning of this statement has been all but lost and today’s software engineers apply this saying differently from its original intent. As computer systems increased in performance from MHz, to hundreds of MHz, to GHz, the performance of computer software has taken a back seat to other concerns. Today, it is not at all uncommon for software engineers to extend this maxim to “you should never optimize your code!” Funny, you don’t hear too many computer application users making such statements. It is unfortunate that Hoare’s comments have been twisted to imply that optimization is unnecessary. The bloat and unresponsiveness found in many modern applications compels software engineers to reconsider how they apply Hoare’s comments to their projects.

the full article can be read here 

The Game of Life is an example of a cellular automata, in which the state of cells in a grid are updated based on the state of the surrounding cells. In the case of the game of life, a cell can be considered alive or dead, and from one generation to the next, a live cell dies if it has less than 2 or more than 3 neighbours, and a dead cell comes to life if it has exactly 3 neighbours. From these simple rules comes an incredible variety of behaviors mimicking the complexity of life itself, and inspiring both professional and amateur scientists to study the game.

A simplistic way to implement this game is to define a the current state as a large 2D array, then iterating across that array, examining neighbours and placing the new state into a new 2D array. This is an O(N) algorithm, where N is the number of cells in the grid. When the grid gets extremely large, and the number of generations of interests hits the billions or trillions mark, a better approach is called for.

Tomas’ clever approach is to recursively subdivide the grid into quarters (a quadtree), while memoizing the pattern in each subdivision. Identical subdivisions will iterate in an identical way. Handling of boundary conditions is a complication, the solution to which is described in detail in his article.

How this relates to functional programming is that iterating a subdivision is equivalent to a function on its state. The same function applied to the same argument gives the same result. By keeping a record of argument->result pairs, we can avoid computing the result more than once, for a possible speedup. This technique is called memoization.

Thomas goes on to memoize not only a single iteration, but multiple iterations for each subdivision, giving a further speedup.

The end result of this incredibly fast implementation the Game of Life can be found at http://golly.sourceforge.net/

Interestingly enough, I had recently been playing with a Game of Life implementation that runs on the GPU, but Golly beats the pants off a GPU implementation, thus proving the maxim that a better algorithm always beats better hardware.

Essentially, Accelerator defines several array-like classes such as FloatParralelArray, IntParralelArray, and BoolParralelArray, with overloads on the various arithmetic operators on these classes. You can then build expressions using instances of these classes, which get converted into expression trees by the operator overloads. The resulting expression trees are optimized, compiled and executed on the GPU at the point that you try to extract the result of your computation.

Performance is highly dependant on the kinds of algorithms attempted, and ranges from 4-5x slower than the equivalent C++, to 10-20x faster. Performance relative to hand-written shaders is also a little erratic. Its worth looking at the paper above for more info on performance.

One of the pre-requisites for any techniques that leverage randomness is a good random number generator. A bad random number generator can give misleading results, and diagnosing the resulting problems is like wandering around in a blizzard looking for snowflakes that look too alike. You therefore want to start with a good RNG, and ideally you want as much proof of its randomness as possible before you start using it.

On computers, its is more correct to call RNGs Pseudo-Random Number Generators (PRNG), because they aren’t, in fact, random at all. They are instead deterministic, in that starting from the same state, they always give the same resulting sequence of numbers. This can be very useful, for example, when testing algorithms. The basic form of an RNG is a function: (rand,state) = f(state).

Whilst there are sources of real random numbers, for example Lavarnd or HotBits, which generate randomness by observing physical phenomena such as radioactive decay, in general these sources of randomness are too low-bandwidth and/or complicated for high-performance use. They can be good for initializing RNGs (for example, you can grab 2048 bytes of pure randomness from hotbits with a HTTP request). The page on How HotBits Works is pretty interesting reading.

Unfortunately, there is no absolute measure of how random a set of numbers is. Instead, there are various statistical tests that are designed to highlight any variances from ‘true’ randomness. The most famous suite of tests is called the Diehard suite, and was created by George Marsaglia.

One of the simplest possible tests of randomness is to generate a histogram from a set of random numbers, and then compute what the probability of generating that histogram would be if the random numbers were in fact truly random. The basic histogram approach can be extended into multiple dimensions, tracking the probability of sequences of various lengths occurring. Another test is to generate a sorted list of random numbers, and make a histogram of the spacings between the numbers in the list. This is called the Birthday Spacings test and the resulting histogram should follow the Poisson distribution. Other tests are more involved, for example, performing random walks using the random number generator to decide whether you turn left or right, and then measuring various statistics on the resulting paths. In general, however, statistical tests can prove that a random number generator is bad, but not that it is good.

For any given pseudo-random number generator, it is always possible to create a test that it will fail. For example, it will always fail the test that measures the probability of the generated sequence not being the same as that generated by the generator itself.

The simplest PRNG is known as the Linear Congruential Generator. Many of you will already have seen one of these: X[t+1] = (A*X[t] + B) % M, with prime M (usually chosen to be a bit smaller than the largest integer representable in a single word). If you iterate an LCG enough, it will repeat the generated sequence of random numbers. The maximum possible period of an LCG is equal to M-1, or around (2^32 -1) on a 32-bit computer.

Another, less well known random number generator is a generalisation of the LCG, called the Multiple Recursive Generator. The form of this generator is X[t+1] = (a[0]*x[t] + a[1]*x[t-1] + … + a[k]*x[t-k]) % M, with prime M. The maximum possible period for this generator is (M^k – 1), or (2^96 -1) for k=3 on a 32-bit computer.

One of highest quality generators to date is called the Mersenne Twister, which has a period of (2^19937 – 1), a C# implementation of which can be found here.

A long period is important because, over the lifetime of an application leveraging randomness, you would like to ensure than no two runs of the application will use overlapping sequences (depending on the application, this may not be a problem if it happened, but if it was, it would be very difficult to diagnose). Some of you may have heard of the Birthday Paradox, in which there is a 50% chance that two people in any group of 23 will have the same birthday. The same principle applies to random number generators, which generate long sequences of numbers in a single run of an application that may be run a large amount of times. You basically want to ensure that there is a huge amount of possible starting points (birthdays) relative to the number of random starts in the sequence you make (people), thus ensuring that the probability of two sequences overlapping is extremely small.

An excellent introductory (though mathematical) treatment on this subject is Random Number Generation by Paul L’Ecuyer.

So… for the cost of a modest PC and 2 7950GX2 cards (a total of about $3000), you get around 1000 GFlops of computing power and 2GB of memory operating at an aggregate 200GB/sec.

Compare this to a tricked out dual-core PC (a total of about $3000), where you get around 20GFlops of computing power and 2GB of memory operating at an aggregate 10GB/sec.

In general, GPUs have been improving in performance at a rate far higher than Moore’s law, though there are of course questions about whether this can continue. Given that GPUs are now consuming 100+W each, ATI and NVidia have already picked the low hanging performance fruit with their architecture. On the other hand, it looks like Intel and AMD have mastered their heat problems, and are managing major improvements in performance simultaneous with major energy use reductions. I imagine that ATI and NVidia will be able to apply some of these techniques to their designs, enabling them to continue along the performance curve for some time to come. Also – GPUs don’t necessarily need increased clock-speeds for increased performance – that can be achieved by adding more vector processing units. The main limiting factor seems to be memory bandwidth, hence the advent of multi-gpu solutions such as the 7950GX2.

The 1000 GFlops I mentioned above is a theoretical maximum. Its only on certain kinds of problems that rate can be achieved. In general, the problems that can leverage this power are said to have high “arithmetic intensity”, i.e. more computation than memory accesses. An example of a computation that is unsuitable is matrix-matrix multiplication which has O(N^3) memory accesses to produce O(N^2) results. CPUs have the advantage here because they can chunk the operation into tasks that can fit in cache.

Current GPUs operate only on 32-bit floating point values, and not even IEEE-754 standard 32-bit floating point at that. (When rendering computer graphics, you don’t really care if the final results of your computations are out by ± 0.2%, so the 32-bit floating-point operations tend to be a bit lax when it comes to rounding the last bit, and operations such as division and transcendental instrinsics (sqrt, sin, cos, exp, log, etc) are also less accurate. It is possible, however, to perform computations at a higher precision, by emulating double-precision with two single-precision values, but at the cost of more instructions – and many more in the case of transcendental instrinsics. GPUs also offer 16-bit floating-point values, which, if lower precision is acceptable, can improve performance by reducing memory and bandwidth requirements. Whilst current GPUs have no support for integer or bitwise operations, the next generation of cards will (DirectX 10 class cards).

The programming model for GPUs is quite constrained. Computation is rendering. That is, the result of rendering is a 2D array of ‘pixels’, which are currently limited to 4 planes of 4 floats each. Computation is performed by assigning to each “pixel” in turn one of the N vector processing units, whose job it is to compute that pixel. Those vector processing units can read from many random memory locations, but can only write to one location – the pixel they are assigned to. This memory model is called CREW, or Concurrent-Read Exclusive-Write. Computing something like a histogram, which involves examining a sequence of ‘things’ and throwing each of them into one of N ‘bins’, also known as a scatter operation, is not a natural fit for this architecture, though, of course, where there’s a will, there’s a way. It is probably easier to compute a histogram on the CPU, however.

A major differentiating factor between GPUs and CPUs is the design of their memory systems. The individual processors in a GPU have small caches, designed for 2D coherent memory accesses, and are around twice as fast as main memory. GPU main memory systems are optimised for fast sequential access, with random access being around 3-5 times slower. Given this architecture, something like a dot-product between multiple vectors, z[j] = sum(x[j][i]*y[j][i]), is a perfect operation for GPUs.

GPU code can be written using a number of tools, from assembly language, through one of several C-like languages designed for graphics programming (Cg from NVidia, HLSL from Microsoft, GLSL from OpenGL, all of which are pretty much interchangeable with each other), and on to specialized languages designed to make programming GPUs easier for non-graphics programmers (i.e. stream-processing languages such as BrookGPU and Sh). The stream-processing languages seem overly-complex and somewhat inefficient for my tastes (Sh is based on C++, and the C-like BrookGPU is no longer under active development, though there are rumours that ATI is sponsoring further development of Brook for a future API of theirs). It seems to me that Cg/HLSL/GLSL as the most effective ways of programming these devices for now. Cg/HLSL/GLSL are very close to C, with support for loops, conditionals, function calls, along with a number of extensions oriented around vector and matrix processing (floating point vectors of up to 4 elements, and matrices of up to 4×4 elements). Also, by operating at the graphics level rather than the specialised stream-processing languages, one can leverage graphics-specific operations. For example, a graphics operations known as an “Occlusion Query” can be very handy – it very quickly totals up how many pixels pass a test specified in arbitrary Cg/HLSL/GLSL code. An example of the use of the occlusion query is in computing the median of a set of numbers (i.e. in log(N) passes, you can binary search for a value which has an equal number of samples above and below it)..

Some other limitations of GPUs are that, even in a multiple GPU configuration, each GPU has only a certain amount of local RAM to operate on (512MB in the case of the 7900GTX), and that transfers to/from the CPU tend to be around the 500-1000MB/sec mark (well below the theoretical 4GB/sec available on the PCIe X16 bus interface, so there’s room for improvement). Another limitation is that textures (2D arrays) are currently limited in size to 4096×4096.

On a historical note, we have seen these cards increase in features and capabilities almost yearly. Loops are the most recent addition to their capabilities, and the one that I believe pushed us over the threshold into general purpose computing. In the not too distant future, we will see DirectX 10 class cards implementing integer/bitwise operations and a suite of other features, along with 64 or more execution units. In general, the architectural model seems fairly firm, and unlikely to undergo huge changes. What is likely to change is that the various vendors are preparing APIs for general purpose computing on their architectures. Whilst not much is known about these APIs at this point, their goal is to remove the necessity of programming in DirectX/OpenGL with their graphics-oriented abstractions, which requires knowlege of graphics terminology and techniques, and can be somewhat awkward when applied to other programming tasks.

A good source for more information on this field can be found at www.gpgpu.org

To the developer, the API appears as a “scene graph” or strongly typed DOM tree called the “Visual Tree”, and changing what is displayed on screen is effected by making changes to the “Visual Tree”.

Theres really two parts to this API, one of which is hidden from the user. Manipulations to the “Visual Tree” are asynchronously sent across to the hidden API as deltas. Presumably, the hidden API maintains a copy of the “Visual Tree”, which it then uses for rendering. The advantage of this approach is in enabling remote-desktop capabilities. The “Visual Tree” can exists on one machine, while the rendering of that tree can happen on another computer, the deltas being sent across the net.

When writing high-performance code for WPF, its important to recognise that this asynchronous communications channel exists, and comes with a price. Optimisation now spans not only considerations of what is being displayed, but also the volume of changes being made to the Visual Tree (and therefore the aggregate quantity, size, and complexity of the deltas being sent across to the hidden API).

A prime example of the impact of this architecture is animation. In WPF, a number of animation classes are provided, for example, for animating an object along a path. Using these animation classes is a huge win, because the parameters for the path are fairly compact and need only be sent across to the hidden API once (and there are possibly other rendering optimisations the hidden API can make by knowing the animation path ahead of time). If you attempt to animate an object along a path by sending it new coordinates N times per second, performance suffers.

Another example of the impact of this communications channel is that it is often more efficient to make one large change to the visual tree rather than many small changes. In practice, this will entail taking a clone of a subtree, making the required changes, and then swapping this modified subtree into place. This last technique is a very important one to be aware of.

Whilst what I know about this communications channel is limited mostly to educated guesswork, I would say that there is some kind of serialization involved, with the tree deltas being serialized to something like BAML (a Binary-XML-like serialization format) before being sent across the wire. Even when the visual tree and the renderer exist on the same machine, the communications channel still exists and is relatively expensive. It is quite possible to saturate the channel (i.e. go to 100% CPU usage), by trying to push too many deltas through it.

Optimisation for WPF is in some ways a data compression problem. If you can get your data “over to the other side” once, and then send compact control parameters over to manipulate or select that data, you get a net win. For rich-media applications, this stuff isn’t too much of a problem, but for applications with volumes of unanticipated data, such as real-time visualisations, grids of ticking stock data, and so forth, its a bit of a problem.

What would be interesting is if the communications channel was in some way programmable, such that the programmer could push code over the channel “to the other side”, and then push a stream of data to be interpreted by that code.

Again, my understanding of this communications channel comes mostly from seeing the shadows it casts, rather than having dragged the beast out into the harsh light of day and beating the life out of it. If anyone can correct me on anything I have said, or help me understand this better, I would greatly appreciate it.america first creditalmondnet adverse credit remortgage httpprograms accredited nurse anethesiaaccreditation abft costunion abnb creditaccreditation ct acr phantomcredit card processingcom merchant washington accountcredit union alcona alpena Map

A relevant excerpt:

Inform does not aspire to recognise anything like the whole sweep of natural language, and in a few cases usefulness has been allowed to trump linguistic fidelity: in particular, it does not attempt to reject all un-natural language. But on the whole Inform tries to avoid eccentricity. The four self-imposed guidelines for the language were as follows:

1. A casual reader should easily be able to guess what a sentence does, and that guess should be correct.
2. The language should be economical, but not to the point where this compromises its intelligibility.
3. If in doubt as to syntax, imitate books or newspapers.
4. Contextual knowledge is best supplied by the author, rather than being built in.

Rules 1 and 2 are motivated partly by the basic aesthetics of natural language: the whole point was to be able to write a text, and a text should be legible. But there is another justification. One reason for COBOL’s unexpected survival to the 21st century as a language for handling, say, financial transactions in the City of London, is that however much today’s coders look down on COBOL as a verbose anachronism, they can still understand COBOL programs written in the 1970s and continuously used since: COBOL’s priority of intelligibility over economy (rules 1 and 2 above) acts as something of a preservative against “code rusting”.

Some Inform 7 code:

A thing has a property called scent. The scent of a thing is usually “nothing“.

A procedural rule: ignore the block smelling rule.

Carry out smelling something:
say “From [the noun] you smell [scent of the noun].“

Instead of smelling a room:
if a scented thing can be touched by the player, say “You smell [the list of scented things which can be touched by the player].“;
otherwise say “The place is blissfully odorless.“

Definition: a thing is scented if the scent of it is not “nothing“.

Before printing the name of something scented while smelling a room: say “[scent] from the “

A floor is a kind of thing. Before putting something on a floor: try dropping the noun instead. Before facing down in the presence of a floor (called target): try examining the target instead. A floor is always scenery. Instead of looking under a floor: say “Nice idea if you can figure out how.” Understand “floor” or “ground” as a floor.

Some generic surroundings are backdrop. It is everywhere. Understand “walls” or “wall” or “ceiling” or “ground” or “area” or “room” or “here” as the generic surroundings. Understand “floor” or “floorboard” or “floorboards” as the generic surroundings when the location is not floored. Before putting something on the generic surroundings: try dropping the noun instead. Instead of examining the generic surroundings: say “You take another look around.“; try looking. Instead of touching the generic surroundings: say “You encounter nothing extraordinary.” Instead of touching the generic surroundings when in darkness: say “You try feeling your way around, but the space you are in is too large to allow you to navigate by touch.”

Before touching a direction, try touching the generic surroundings instead. Before pushing or pulling a direction, try pushing the generic surroundings instead. Instead of smelling the generic surroundings, try smelling the location. Instead of listening to the generic surroundings, try listening to the location.

More code can be found here

• 20+ cores
• 80+ hardware threads
• 1+ TerraFlops of computing power (today < 5 GigaFlops)

So sayeth Tim Sweeney in “The Next Mainstream Programming Language: A Game Developers Perspective”

When programming Model-View-Controller patterns, I tend to think that there is an equivalence between model and database. The model is the repository of all of the information relating to the state of the application, while the relational database is the repository of all the information relating to the state of the enterprise. Obviously, the scope is different, but many of the data design problems are similar. Just as with an enterprise relational database, you want to design for the data, in the hopes that a well structured schema will persist over time, as the demands on it change from iteration to iteration. Object-oriented databases are one way of approaching this problem, and with the advent of Linq in the C# world, the day of being able to arbitrarily query the model may soon be upon us.

One of the problems with the object database approach is that of defining and maintaining relationships between objects/entities. As object-oriented programmers, we tend to want to be able to say foo.bar and have that mean “the bar objects that belong to foo“. But what happens when we want access the reverse relationship, bar.foo. Assuming that the relationship of foos to bars is many-to-many, both foo.bar and bar.foo should represent multiple objects, or collections. The problem is keeping the maps of foos-to-bars and of bars-to-foos in sync.

The paper above outlines an interesting approach in which the relationships between classes are separate from the classes themselves. Now, a traditional object-oriented language can do this, but the syntax is awkward, and the authors propose a java language variant (with its own compiler), that supports first-class relations.

Interestingly enough, as part of the Linq system, C# will acquire a mechanism by which first-class relations can be created and defined, with a nice syntax, and without having to write your own language. That mechanism is extension methods, and it has been mooted that extension properties may also be added to Linq, which will enhance the approach no end. (truth be told, extension properties seemed somewhat useless to me until I read the paper above).

A fairly good introduction to extension methods can be found here. Basically, an extension method is a static method, with an explicit “this” parameter, and which is accessible as a method on the the type pf “this“. Probably best if I give an example.

public static class StringExtender
{
public static string CamelCase(this string s)
{
// do my camel case thing
return camel;
}
}

When imported, this class now “adds” the CamelCase method to all string objects. Well, not really, its just syntactic sugar, and in fact its called just like any other static method. Heres how the translation goes:

string s = "how are you gentlemen?"
Console.WriteLine(s.CamelCase())
translated:
string s = "how are you gentlemen?"
Console.WriteLine(StringExtender.CamelCase(s))

So how does this relate to object oriented databases and first class relationships?

Well, consider the following code:

class Trader { /* add stuff to do with traders */ }
class Instrument { /* add stuff to do with instruments */ }

static class TraderInstruments : Relationship<ManyToMany, Trader, Instrument>
{
public static ICollection<Instrument> Instruments(this Trader trader) { return GetFirst(trader); }
public static ICollection<Trader>Traders(this Instrument instrument) { return GetSecond(instrument); }
}

Now what this code is doing is adding a Trader.Instruments() method and a Instruments.Traders() method to the entities I previously defined, without having to modify the Trader or Instrument classes themselves.

I can now do the following:

Trader trader = new Trader();
Instrument instrument = new Instrument();
trader.Instruments().Add(instrument);
Debug.Assert(instrument.Traders().Contains(trader) == true);

Which, by adding a “method” and providing intellisense, is a more readable, learnable and discoverable, and less verbose than the static method calls this might get translated into:

Trader trader = new Trader();
Instrument instrument = new Instrument();
TraderInstruments.Add(trader, instrument);
Debug.Assert(TraderInstruments.Traders(instrument).Contains(trader) == true);

Now the extension method approach works very well for many-to-many relationships, but its gets a bit ugly for one-to-many and many-to-one relationships, in that what should really be nullable extension properties is instead represented by extension methods returning collections constrained to contain 0 or 1 item only.

Even so, the possibility of separating the relationships from the entities seems like quite a powerful mechanism. You can easily add or change relationships without having to change the entities themselves, while keeping an object-oriented style.

Extension methods are very powerful things, and should be used sparingly (as with implicit type casts and operator overloading), because of the potential confusion they can create about what code is being executed. Even so, I think they are a great addition to the language.

Basta!

Haskell is a lazy functional language, which means that almost everything in Haskell is expressed as a function, and that those functions are evaluated on an as-needed basis only. This approach means that you never quite know when or in what order your functions are going to be evaluated. It only becomes a problem when your functions have side-effects, such as interacting with the world outside Haskell. Input and output are the cannonical examples of such side effects.

Monads are Haskell’s way of controlling the order of evaluation. At least, thats the way they look to me right now.

So how do they work? Well, I only have a vague idea at the moment, but my current understanding is that they leverage Continuation Passing Style. Heres an example of CPS:

cps_add x y next = next x+y
-- here we pass in a function to be called with the result of our computation

Now, lets say we had a sequence of functions, f1, f2, f3, and we wanted them to be evaluated in that order. Normally, Haskell would evaluate them in whatever order it felt like, but if we made each function depend on the result of the previous one, then they would have to execute in sequence.

Monads seem to wrap up two facets of this requirement; the transformation of a sequence of functions into a CPS-like form such that each function depends on the result of the previous one, as well as defining the opaque data/class thingy that is passed between the transformed functions.

That was my insight for today, rough and unpolished as it may be. Am I on the right track? Anyone? Anyone? Bergman?

In an imperative language, such as C#, you would normally leverage arrays to create a resizeable circular buffer or somesuch. In functional programming languages, all datatypes are immutable, which tends to encourage one to avoid arrays and instead prefer linked lists.

How can you create a queue from linked lists of immutable nodes? You cant use a single linked list, because whilst you have easy access to the head, accessing the tail requires traversing the whole list (well, you can use a singly linked list, but its terribly inefficient).

The trick is to use two linked lists, called front and rear. The rear list holds its elements in reverse order:

For example, a queue containing items [1,2,3,4,5,6] might look like this: (front=[1,2,3], rear=[6,5,4])

Enqueuing an item inserts it at the head of the rear list, e.g. enqueuing 7 results in rear=[7,6,5,4]

Dequeuing an item removes the head of the front list, e.g. dequeuing from (front=[1,2,3], rear=[7,6,5,4]) results in (front=[2,3], rear=[7,6,5,4])

Thats all fine and good, but after dequeing all of the elements fron the front list, what do you do?

Well, you reverse the rear list and make it the front list, e.g. after dequeing two more items, we have (front=[], rear=[7,6,5,4]) and one more dequeue operations results in (front=[5,6,7], rear=[])

Ah, you might say, but reversing a list costs the same as traversing a whole list. And you would be right.

But not in an amortised sense.

Lets consider the behavior of this queue over time, as we add a few items, then remove a few items, and so on and so forth. Lets be explicit here, we add, say N items, then remove, say N items, and repeat.

Now at the point where the front list is empty and we want to remove an item from the queue, we have to reverse the rear list, which takes N steps. But we only got to that point by taking N steps, over time, adding items to the queue. The pattern of costs for adding and removing items would look something like this [1,1,1,1,1,5,1,1,1,1,1,5,...]. Once you smooth out the costs, you get an average of 2, no matter what N is.

The most common data structure that leverages this amortised behavior is the resizeable array, which, when its gets full, doubles in size. The pattern of costs for a resizeable array looks like this [1,1,2,1,1,4,1,1,1,1,8,1,1,1,1,1,1,1,1,16,...], where the numbers that arent 1 are the costs of doubling the array size. Smooth out the costs, and the average is also 2.

For those that are interested the Haskell code for the two-list Queue is here:
data Queue a = Q [a] [a]
isEmpty (Q front rear) = null front
fillf (Q [] rear) = Q (reverse rear) []
fillf q = q
tail (Q (x:front) rear) = fillf (Q front rear)
tail (Q [] _) = error "Empty Queue"
snoc (Q front rear) x = fillf (Q front (x:rear))

Windows Presentation Foundation (formerly codenamed “Avalon”), or WPF for short, is a brand new Microsoft framework for developing very rich and powerful Windows applications. It will ship as part of Windows Vista, the next major version of Windows that will be released in the coming months, but WPF will also be available on Windows XP SP2 and Windows Server 2003. There is much to be said about Windows Presentation Foundation and its numerous new and enhanced capabilities, but this article will in stead focus on an old trusted friend, who has finally been given a dedicated room in the big house of Windows User Interface development: the “Command” pattern. This design pattern basically abstracts all actions the user can perform in an application into the notion of “commands”; it has been implemented in many different ways on top of various UI frameworks, but now, it has finally made it into the gut of the system itself. Note that this article is based on a public preview of WPF, so it’s possible that there are implementation details that will change over time as the product matures into completion.

go here for the full text of his article.

This powerpoint document describes the text rendering architecture of avalon.

Until the advent of DirectX 10 hardware, we should’nt expect any performance increases over and above that found in GDI+, which achives approximately 100K glyphs per second using a CPU-intensive process. With DirectX 10 hardware (not currently available), this should improve by a factor of 10, making it comparable to the GDI text rendering with the kind of hardware acceleration found on a VGA card circa 1996.

Plus ca change, plus c’est la meme chose.

For really fast text rendering on DirectX 9 class hardware, you should use a monospaced font, assigning each character in the font to a sprite, and using the 3D rendering hardware to assemble the characters into words and sentences. Conceptually identical to, but somewhat less capable than a Gutenberg printing press, multi-million glyphs per second performance levels should be within reach that way.

At the first Indie Game Jam in 2002, a number of games programmers experimented with using what was modern 3D graphics hardware at the time, trying to come up with games that featured a LOT of simple guys (or dudes). What they found was that you could manage a LOT of guys (or dudes) using that hardware, i.e. a GForce 2 could manage 100K guys (or dudes). My favorite game that came out of that IGJ was called “angry god bowling”.

Interestingly enough, similar techniques are what is called for when trying to maximise text rendering performance. At the same time, you could use the capability of independantly moving each character around for some highly disturbing and entertaining effects. Im thinking along the lines of a barely perceptible wavy motion, or of a particle effect such as each character flying off the screen in different directions. Something to think about on long cold nights, eh?

I claim the following simple experiment supports this depressing claim. Run your favorite set of benchmarks with your favorite state-of-the-art optimizing compiler. Run the benchmarks both with and without optimizations enabled. The ratio of of those numbers represents the entirety of the contribution of compiler optimizations to speeding up those benchmarks. Let’s assume that this ratio is about 4X for typical real-world applications, and let’s further assume that compiler optimization work has been going on for about 36 years. These assumptions lead to the conclusion that compiler optimization advances double computing power every 18 years. QED.

This means that while hardware computing horsepower increases at roughly 60%/year, compiler optimizations contribute only 4%. Basically, compiler optimization work makes only marginal contributions.

Perhaps this means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena.

I think that the gains to be had in programmer productivity lie in the automated production and optimisation of higher level constructs, for example, matrix math, queries (i.e. LINQ), or even incremental versions of programs.

hot moviesporn movie samplesmovies nudemovies horse matingclips free porno moviemovie hentai clips freemovies lolita freemovie clips gay Map

Consider the following C++ code, which allows access to Object.GetHashCode(), regardless of whether or not that method has been overriden.


namespace ObjectHash
{
int Obj::GetHashCode(Object^ obj)
{
return obj->Object::GetHashCode();
}
}


Now, for my application (pointer joins), this is very usefull. If, on the other hand, you are using virtual methods to provide security or semantic guarantees, then you should look to delegation instead.

Escape analysis is an optimization that has been talked about for a long time, and it is finally here — the current builds of Mustang (Java SE 6) can do escape analysis and convert heap allocation to stack allocation (or no allocation) where appropriate. The use of escape analysis to eliminate some allocations results in even faster average allocation times, reduced memory footprint, and fewer cache misses. Further, optimizing away some allocations reduces pressure on the garbage collector and allows collection to run less often.

Escape analysis can find opportunities for stack allocation even where it might not be practical to do so in the source code, even if the language provided the option, because whether a particular allocation gets optimized away is determined based on how the result of an object-returning method is actually used in a particular code path. The Point returned from getLocation() may not be suitable for stack allocation in all cases, but once the JVM inlines getLocation(), it is free to optimize each invocation separately, offering us the best of both worlds: optimal performance with less time spent making low-level, performance-tuning decisions.

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

loan $50,000 high riskland refinace loans alabamaloan bad credit 50,000 cashbill add a to loan calendarabout stafford loansloan personal all accepptedacquired loans reporting student creditcompany sloane and alanpersonal credit $5,000 loan bad withgrants loans adoption

One aspect of LINQ is the “from … where … select …” query pattern. Most of the examples show how this operates on IEnumerable<T> collections, and a set of extension methods for this are provided in the System.Query.Sequence static class, for example, the Where() method is defined as follows:

public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate)
{
foreach (T element in source) {
if (predicate(element)) yield return element;
}
}


This doesnt mean, however, that “from … where … select …” queries can only operate on IEnumerable<T>. In fact, LINQ does a relatively simple program transformation into code which the compiler then interprets.

For example, the following code:

from c in customers
where c.City == "London"
select c


can be thought of as literaly being transformed into this code, before being compiled:

customers.Where(c => c.City == "London")


In C# 3.0, the Where() method can come from several different places. It can come from a method in the class of customers, or it can come from an extension method. Whats important to recognise is that the transformation can be thought of as a purely text based transformation, and that the normal rules of method lookup (including the new extension method rules) then apply to determining which Where() method applies.

If I defined customers as being of class MyIndexedCollection which happened to define a Where() method in it, that method would be used.

If customers was of type IIndexedCollection<T> and there was an extension method Where(this IIndexedCollection<T> items, Func<T, bool> predicate) then that extension method would be called.

Of course, things get more interesting yet, for a Where() method with the following signature:

Where(this IIndexedCollection<T> items, Expression<Func<T, bool>> predicate)

In this case, our predicate is no longer a simple delegate, but is rather the expression tree that results from parsing the anonymous function that would have become the predicate. By rummaging around in this expression tree, we can see if our predicate depends on, for example, any properties that we might already have indexed – if so, then we dont have to scan the entire collection. In the case of the query above, if we already had the collection indexed on the City property, a more efficient Where() implementation would be possible.

Ive been trying to absorb the new LINQ framework, and one tool that is especially usefull is Lutz Roeder’s Reflector, which is a browser and decompiler for .NET assemblies.

You can download it here: http://www.aisto.com/roeder/dotnet/

LINQ stands for Language INtegrated Query, and is a set of extensions to the C# language which allow SQL-type capabilities to be integrated into the language itself.

In addition, the C# 3.0 spec details a continued development of the C# language, with many new features appropriated from various programming paradigms, and some completely novel ones too.

http://msdn.microsoft.com/netframework/future/linq/

or maybe not?

The paper first demonstrates that a logarithmic distribution of fault with component complexity closely fits the observed data over a range of component sizes and languages up to around 200 lines or so, (deemed medium size here), after which approximately quadratic behaviour is observed. The paper will review mitigating influences for this non-intuitive behaviour before concluding that none is really satisfactory. It then unites this complex behaviour in a simple mathematical model of the physiology of the human two-level memory system. The resulting component fault rate model accurately predicts the observed data for all languages in this study.

million $250 loanloans fax payday no online 100report 1000 loanloans business 300,00072 monthes loanballoon 7 23 loan90 note day loan$200,000 loan6,000 in a dollars loanapplication loan accepted

A couple of weeks ago, I posed the following in my blog: what are the grand challenges of software and software engineering? What do we know we don’t know?

I had about a dozen people rise to the question and a lively discussion among many of them unfolded via email. Following are some highlights of that correspondence.

Read the entire post:
what are the grand challenges of software and software engineering?

The Spec# programming system is a new attempt at a more cost effective way to develop and maintain high-quality software. Spec# is pronounced “Spec sharp” and can be written (and searched for) as the “specsharp” or “Spec# programming system”. The Spec# system consists of:

• The Spec# programming language. Spec# is an extension of the object-oriented language C#. It extends the type system to include non-null types and checked exceptions. It provides method contracts in the form of pre- and postconditions as well as object invariants.
• The Spec# compiler. Integrated into the Microsoft Visual Studio development environment for the .NET platform, the compiler statically enforces non-null types, emits run-time checks for method contracts and invariants, and records the contracts as metadata for consumption by downstream tools.
• The Spec# static program verifier. This component (codenamed Boogie) generates logical verification conditions from a Spec# program. Internally, it uses an automatic theorem prover that analyzes the verification conditions to prove the correctness of the program or find errors in it.
• An interface to the Spec Explorer tool for test generation and model-based testing.