Fractal Errata

Some of the particularly sharp/anal ones amongst you might have noticed that while the technique for generating fractal lanscapes I previously described works (and works well), it's not 100% correct. Specifically, the fact that it uses the the same scaling factor for nodes created by the diamond and square steps isn't quite right.

Why is this? Because they generate nodes which adhere to different levels of detail, that's why. Lets go back to that last diagram for the post which described the algorithm:

[caption id="attachment_355" align="aligncenter" width="357" caption="Diamand step (left) and square step (right)."][/caption]

Now while you'll note that both steps add nodes that can be addressed using fractions with two as their denominator, the distance of the nodes created by the diamond step to their parents is greater than those created by the square step.

The nodes created by the square step are orthogonal to their parents, so the distance between them is proportional to a half, which as luck would have it has the same as the denominator as the fractions used to address the node. How convenient!

The nodes created by the diagonal step, on the other hand, are diagonal to their parents. This means that the distance to their parents is the pythagorean root of this same distance, so in this specific case:

sqrt(½*½+½*½) = sqrt(¼+¼) = sqrt(½) = something

Once again, the key fraction used to work this out has the same denominator as those used to address the node in the landscape. Thus, if d is equal to the denominator we're using to address a node, the basic scaling factor used to offset a new node from its parents would be the following:

if (diamond step) range = [-sqrt(1/d*1/d*2), sqrt(1/d*1/d*2)]

else range = [-1/d, 1/d]

As I said before, this won't make a lot of difference, but it will be more correct and that's important to some people. Myself included.

For comparison purposes this is the effect this change has on the example landscape I've been using:

[caption id="attachment_366" align="aligncenter" width="296" caption="The original scaling method."][/caption]

[caption id="attachment_388" align="aligncenter" width="296" caption="The updated scaling method."][/caption]

There's some difference visible, but not a huge amount. Mostly, it's just increased the range the data are occupying and expanded the bell curve accordingly. Hence, more high points and more low points, but the land is the same basic shape.

Now In Eye Popping 3D!

It took a little bit of fighting with bugs that weren't showing up in the 2D view, and a bit of time to figure out what was going on with the lighting system in JME, but I finally got the 3D display of the fractal landscapes working.

The first stage was just displaying each node as a discrete point so I could see that each was in about the right place. It looks a little bit like this:

 

[caption id="attachment_372" align="aligncenter" width="481" caption="Fractal landscape as points (click for bigger)."][/caption]

 

I did this by simply piping the spatial coordinates and colour information of each node into a pair of standard Java FloatBuffers, passing these to a JME Point class (which should really be called PointSet, in my opinion) and attaching this to the root display node of my JME application. The colouring scheme is the same as the one used for the 2D display. Some things don't look quite right, largely due to the fact that I've just drawn the "underwater" points as blue, rather than adding any actual "water." Don't fret, it's on the todo list.

That said, the landscape looks about right. All the points seem to be in their correct location. As a quick implementation note, I'm defining the (x, y, z) coordinates of the scene in the following way:

x = east

y = altitude

z = -north

With some scaling factors used to map the values from the [0,1] range used to address them to slightly more real world like dimensions.

The next stage was to display the landscape in wireframe to make sure the connections I'll be using create a more solid looking polygon based display are all working correctly. Why not just go directly to polygons? You can see the the detail better in the wireframe display, making debugging much easier. I'll definitely be using it again later.

This time, instead of piping each and every node into the vertex array, only the nodes at the highest level of detail are used. These are the nodes generated during the final "square stage" of the fractal algorithm, for those of you playing at home. Each draws a triangle (consisting of three separate lines) into the vertex buffer for each pair of parents it has in the landscape. The result looks something like this:

 

[caption id="attachment_374" align="aligncenter" width="493" caption="Fractal landscape as lines (click for bigger)."][/caption]

 

Everything seems to be in good order there, I think. One or two things don't look quite right, particularly the beaches, but the tessellation and coverage of the polygons looks right. Here's a closer in look at some of the polygons so you can see what the tessellation scheme actually produces:

 

[caption id="attachment_376" align="aligncenter" width="442" caption="Polygon tessellation (click for bigger)."][/caption]

 

You can (hopefully) see that each of the "active" nodes sits at the centre of a diamond formed from the shape of its parents, so it's the points with four lines branching from them (rather than eight) which are actually being used to draw the scene.

Next: polygons. Again, only the nodes at the highest level of detail are used. This time, each inserts itself into the vertex buffer, then adds its parents if they're not in there already. Each node remembers its postion in the vertex buffer, and these indices are then used to draw the actual polygons. These are declared by passing the indices in sets of three into a standard Java IntBuffer. The buffers are then passed to one of JME TriMesh geometry classes and displayed, like this:

 

[caption id="attachment_373" align="aligncenter" width="512" caption="Fractal landscape as polygons (click for bigger)."][/caption]

 

Again, the beaches don't look quite right, but otherwise I'm reasonably pleased. I still need to add the actual water and improve the form of the landscape itself (and about a million other things), but in terms of display this is looking pretty good. Except for one thing: I'm using far more detail than I need to. Let me illustrate this with a slightly more extreme example. The pictures I've posed so far were generated using seven iterations of the diamond square algorithm. Here's what happens when I use ten iterations (remember, the number of points increases exponentially):

 

[caption id="attachment_377" align="aligncenter" width="614" caption="MOAR POLYGONS! (click for bigger)"][/caption]

 

On the bright side the beaches look better, but that's a lot of polygons. Far more then we actually need to display. 1579008 polygons, in fact. We need to reduce that somewhat, if we're going to make things more complicated and maintain a reasonable frame rate (I'm getting about 60fps with this view at the moment). You can see the problem more clearly if I show you the same view using lines rather than polygons:

 

[caption id="attachment_378" align="aligncenter" width="614" caption="MOAR LINES! (click for bigger)"][/caption]

 

You can just about see the individual triangles up close, but further away the lines just mush together. I think we can afford to reduce the level of detail as we get further away, don't you?

Well, I'll get right on that, then...

Some Random Landscapes

I don't have any 3D views of the fractal landscapes I've been making to show you yet, as I'm still working through the different implementation options. I did get a little distracted with the 2D views of the landscape this morning, though, and play with the colouring scheme.

First of all, let's start again with the example landscape used in yesterday's post, only with slightly more sober colours and a bar on the right showing how the height values map to actual colours:

[caption id="attachment_363" align="aligncenter" width="296" caption="Fractal coastlines."][/caption]

Now that looks reasonably neat already, in a "my first atlas" kind of way, but clearly there's a lot of information missing. We can see this if I plot the height values in monochrome, giving the landscape a more "plasma cloud" appearence:

[caption id="attachment_364" align="aligncenter" width="296" caption="Plasma cloud landscape."][/caption]

Now we can see the extra information, but we've lost a lot of the sense that what we're looking at is a landscape. It looks more like a cloud. We can get some of that back by combining the two approaches and using different shades of blue and green:

[caption id="attachment_365" align="aligncenter" width="296" caption="Shaded landscape."][/caption]

Now this looks a lot better. I think the water looks quite reasonable using this scheme, but the landscape is a bit... homogenous. Is every part of the land covered in grass? How boring!

We can make things a bit more interesting by adding a thin band of "sand" around the coast, and some "mountainy" colours (and snow!) higher up, like so:

[caption id="attachment_366" align="aligncenter" width="296" caption="More in depth colouring scheme."][/caption]

Now this looks better, the sand in particular. The mountains look okay, but not quite right. Something's a little off. That's not what mountains actually look like. We also don't have any rivers or above sea level lakes. These are problems I'm going to look at later, after I get a reasonable 3D display system working. In the mean time, though, here are a couple more 2D landscapes for your viewing pleasure:

[caption id="attachment_367" align="aligncenter" width="296" caption="A bit more snow and an inland sea."][/caption]

[caption id="attachment_368" align="aligncenter" width="296" caption="Yet another coastal region."][/caption]

You're Speaking My Landscape, Baby.

No, that isn't a typo... but yes, it is a bad play on words. That's the bad news. The good news: finally! A Clockwork Aphid implementation post!

If you're building something which relates in some way to virtual worlds, then the first thing you're going to need is a virtual world. This gives you two options:

1. Use a ready made one;


2. Roll your own.

Option 1 is a possibility, and one that I'm going to come back to, but for now let's think about option 2. So then, when building a virtual world the first thing you need is the lanscape. Once again you have two options, and let me just cut this short and say that I'm taking the second one. I did used to be a bit of a CAD ninja in a previous job, but I'm not a 3D modeller and I have no desire to build the landscape by hand.

So I'm going to generate one procedurally. As to what that means exactly, if you don't already know... well I'm hoping that will become obvious as I go along.

Traditional Fractal Landscape Generation

There are several ways of generating a landscape. A pretty good one (and one I'm quite familiar with, thanks to a certain first year computer science assignment) is the fractal method. It goes something like this:

Start off with a square grid of floating point numbers, the length of whose sides are a power of two plus one. I'm going to use a 5*5 (2*2 + 1) grid for the purposes of this explanation.

Set the four corners to have the value 0.5 (the centre point of the range I'll be using), thus:

[caption id="" align="aligncenter" width="164" caption="Grid based starting point."][/caption]

Now, we're going to generate the landscape by repeatedly subdividing this and introducing fractal randomness (random fractility?) using the diamond square algorithm. First the diamond step, which in this iteration will the set the value of the central cell based on the value of the four corners:

[caption id="" align="aligncenter" width="163" caption="The first diamond step."][/caption]

To do this we take the average of the four corners (which I calculate to be 0.5 in this case, because I did maths at school) and adding a small randomly generated offset, which has been scaled according to the size of the subdivision we're making. How exactly you do this varies between implementations, but a good simple way of doing it is use a random number in the range [-0.25,0.25] at this stage and half this at each subsequent iteration. So, on this occasion let's say I roll the dice and come up with 0.23. This now leaves us with:

[caption id="" align="aligncenter" width="164" caption="Result of the first diamond step."][/caption]

Next, we have the square step, will set the cells in the centre of each of the sides. Once again we take the averages of other cells as starting point, this time in the following pattern:

[caption id="" align="aligncenter" width="163" caption="The first square step."][/caption]

Now we generate more random numbers in the same range and use them to offset the average values, giving us this:

[caption id="" align="aligncenter" width="164" caption="Result of the first square step."][/caption]

That completes an iteration of the algorithm. Next we half the size of the range to [-0.125,0.125] and start again with the diamond step:

[caption id="" align="aligncenter" width="163" caption="The second diamond step."][/caption]

...and so on until you've filled your grid. I think you get the general idea. I've left out one potentially important factor here and that's "roughness," which is an extra control you can use to adjust the appearance of the landscape. I'm going to come back to that in a later post, because (hopefully) I have a little more that I want to say about it. I need to play with it some more first, though.

Once you've finished here you can do a couple of different things if you want to actually look at your creation. The simplest is to pick a threshold value and call this "sea level," then draw the grid as an image with pixels set to blue below the threshold and green above it:

[caption id="" align="aligncenter" width="256" caption="Generated fractal landscape."][/caption]

This was obviously generated with a slightly larger grid (513*513), but as you can see it creates quite reasonable coastlines. You can do slightly fancier things with it, such as more in depth colouring schemes and 3D display. For 3D, the simplest method is to use each cell as a vertex in your 3D space and tessellate the grid into triangles like this:

[caption id="" align="aligncenter" width="136" caption="Simple grid based tessellation."][/caption]

You can then do a couple of fancy things to remove the triangles you don't need, either based on the amount of detail they actually add or their distance from the user (level of detail).

This system works quite well, but tends to produce quite regular landscapes, without of the variation we're used to or the things generated by rivers, differing geology, coastal erosion, glaciation and other forces which affect the landscape of the real world. Additionally, because the data is stored in a height map, there are some things it's just not capable of displaying, such as shear cliffs, overhangs, and cave systems. The grid structure is also very efficient, but quite inflexible.

How I'm Doing it

Needless to say that's not exactly how I'm doing it. Of course there's generally very little sense in reinventing the wheel, but sometimes it's fun to try.

I'm not doing too much differently with the actual algorithm, but I am using a slightly different data representation. Rather than a grid, I'm using discrete nodes. So you start off with something like this:

[caption id="" align="aligncenter" width="121" caption="Node based starting point."][/caption]

Which then is transformed like this to generate the actual landscape:

[caption id="" align="aligncenter" width="357" caption="Adding further nodes."][/caption]

..and so on.

What you you can't see from the diagrams is that I'm using fractions to address the individual nodes. So, for instance, the node in the centre is (1/2,1/2) and the node on the centre right is (1/1, 1/2). This means I don't need to worry about how many nodes I have in the landscape, and the adress of each never has to change. The next set of nodes will be addressed using fractions with 4 as the denominator, then 8, 16 and so on. Before looking up a node you first reduce its coordinates down to a lowest common denominator (which is a factor of 2) and then pull it out of the correct layer. I'm currently using maps as sparse arrays to store the data in a structure which looks like this:

Map<int, Map<int, Map<int, LandscapeNode>

If you're thinking that this isn't possible in Java, you're half right. I'm actually using one of these. The first int addresses the denominator, then the east numerator, then the north numerator. I've looked at another couple of strategies for hashing the three ints together to locate a unique node but this one seems to work the best in terms of speed and memory usage. I might look at other options later, but nor yet.

This is a much more flexible representation, which removes some of the limitations of the grid. I can keep adding more detail to my heart's content (up to a point) and I don't have do it in a regular fashion. i.e. the native level of detail doesn't have to be the same across the entire map. More remote areas can have less detail, for instance. By the same token, I can keep the entire "landscape" in memory, but flexibly pull individual nodes in or out depending on where the user actually is in the world, saving memory. This also potentially gives me the following:

1. The possibility to decouple the geometry of the landscape from the topography of the representation;


2. A "native" way of implementing different levels of detail;


3. A natural tessellation strategy based on connecting a node to its parents (maybe you spotted it);


4. Enough data to allow the landscape to be modified to produce more dramatic features across different levels of detail;


5. The processes for the above should be very parallelisable.

There are still a couple of things I'm working on (3D display for a start), as I've been obsessing over how to organise the data structures I'm using. Hopefully I'll be back tomorrow with some 3D views.

If you're interested in the code you can find it here. If what you found at the end of that link didn't make any sense to you, then you're probably not a programmer (or you're still learning). If you still want a look drop me a comment and I'll see what I can do.

Disclaimer: As far as I'm aware I didn't steel this from anybody, but I don't claim it's completely original, either.

 

Language Post Mortem and Some Other Notes

A couple nuggets of knowledge came out of my "You're Speaking My Language, Baby" series of posts, so I though I'd just take a quick moment to talk about them.

The first two are perhaps the most obvious by far. Firstly: if you actually write blog posts, people are more likely to read your blog. Funny that, huh? While my post on installing Celtx on the Acer Aspire one is still my most popular by some margin (probably because it actually provides some utility), I actually had my highest numbers of hits per day during the last week. Secondly: I get less hits over the weekend. Lax working habits for the win!

What's also interesting is the relative popularity of the individual parts of the series. Most popular first, it goes like this:

1. Introduction


2. C++


3. Conclusion


4. Java


5. Objective-C

Now, my number of hits still isn't exactly stellar, so this is a fairly small sample size, but it's still quite interesting. People seem to be far more interested in reading about C++ than any of the other languages. In general, readers tend to want to know what it is I'm actually talking about, and what conclusion I come to, but when it comes to specifics, C++ gets the most interest. Is this a recommendation of the language, or the oposite, though? People could be reading what I say about it because they think it's the sensible option... or because the folly of the language makes them seethe with rage. Hard to say. Perhaps I'll look for some metrics of programming language popularity online.

In one of those curious events the internet throws up, the writer of a blog I read on a regular basis also just started to work on a project of a potentially similar nature, and started off with some musings on which programming language to use. I'm talking about Shamus Young in his Twenty Sided blog (I should really add it to my blog roll). Interestingly, and slightly comically, he came came to an equal and oposite conclusion to my own. He didn't consider Objective-C (not out loud, anyway), but decided that Java was the language to use if he wanted to produce something with commercial viability, but C++ was the language to use if he wanted to do some prototyping.

I'm still scratching my head at this in some ways. I don't care how much experience you have in C++, you're still likely to program faster in almost any language other than C. But in other ways it makes perfect sense. He has about a decade's worth of experience with C++ (likewise I have about ten years worth of Java under my belt), but only limited exposure to Java. He's looking at building a complete game, so he's being influenced by games like Minecraft (which I will be talking about more later) which were successfully developed by an individual (in Java, as I understand it). If you're making something a bit niche and you don't have massive amounts of resources, then having a game which can be effortlessly ported to every major operating system is a good thing.  You want to expand you potential audience as much as possible. Also, if your target demographic slants towards the nerd side of the spectrum then you don't want count out Linux, nor OSX (which gets more nerd love than you might expect). Having your game be able to run out of a browser doesn't hurt, either.

I'm not (at this point) looking at building a complete game, but a piece of technology which could potentially be used by multiple games, though. Something of the order of a physics engine. Middleware is the term I seem to hear used. Thus Java (which I have more experience with) is my prototyping language, but C++ makes sense as an eventual target.

I've been holding back on what I'm actually doing, but I essentially outed myself when I said it was similar to what Shamus is. So: I'm doing something connected to procedural content generation. I'll explain more about what that means as I go along.

In other news I have two weeks off work. Seems I haven't used the vast majority of my holidays this year and taking the entire month of December off is not considered to be ideal. Thus: I have two weeks to do with as I please. So long as what I please doesn't cost too much or inconvenience my girlfriend. I may visit my parents or even some of my friends down south. I'll also spend quite a bit of time sitting in coffee shops with a book and a note pad. Coffee shops are good places to think, I find. Just the right amount of bussle. I'm also going to crack on with Clockwork Aphid. I'm tinkering with some implementation details at the moment, but I plan on writing about what I have so far as well. I'm also hoping to make the Heston Blumenthal chilli con carne I mentioned in a previous post, but there are complications. Firstly, he's quite specific about the types of chilli powder you should use and some only seem to be available from the good ol' USA. They're on order, so hopefully they'll arrive fairly soon. Secondly, there's clearly a mistake in the recipe, unless Heston want me to boil a pan of water and prepare a bowl of ice water for purely ornamental purposes. This isn't completely outside the bounds of reason.

More updates soon. Look to the skies!

You're Speaking my Language, Baby. Part 5: Conclusion.

Author's note: As this post started out HUGE, it's been split into parts. You'll find the introduction here, my comments on Java here, my comments on C++ here, and my comments on Objective-C here.

So... what's the conclusion? It mostly comes back to the fact that I'm doing this mainly for fun (though you may have trouble believing it). That being the case I'm going to start working in Java. In fact I already have started working in Java, and I've already written the first bits of code. I'll talk about and make them available soon.

I just can't ignore the sheer applicability of C++, though, much as I may dislike it as a language. Most game developers are going to have the majority of their legacy code written in C++ and that creates a lot of momentum. Games are among the more demanding things most people do with their computers, so they generally try to squeeze every last drop of performance out of the system they're running on. C++ does have the potential to provide a performance advantage over Java (even if you might end up loosing that to your AI system when you starting having to use Lua to script behaviours). Another one of the reasons for this project was to create a bit of work which might act sort of like a portfolio piece. So, once the project has reached an early, but functional, stage of development I'm going to re-implement it in C++ and then see how I feel about the two different implementations before continuing. It's not impossible that I'll end up keeping both, but more than likely I'll kill one and just stick with the other.

By a process of elimination you might have realised that I'm now counting Objective-C out. This is true, but I have another side project I may end up using it on. One which lends itself quite well to being either an iPhone/iPad app or a website. Or all three. Objective-C is clearly quite applicable to the first two, and surprisingly applicable to the last, if you go the Objective-C -> MacRuby -> Ruby on Rails route.

That was the plan, at least, until I went ahead and did something silly. I have more than a passing interest in programming language design and so found myself reading about other programming languages. Stupidly, I found a couple which have enough merit that I really can't count them out.

The first of these is D, which is designed to fix a lot of the problems with C++ whilst maintaining its advantages. It seems to succeed at this quite well, so far as I can tell. It also seems to have direct access to a lot of things built directly for C/C++.

Then we have Scala and Fantom, which use the Java virtual machine as their runtime. Both seem capable of achieving the same level of performance as Java itself, but take away some of the legacy cruft which Java has been unable to shake, whilst adding extra useful features. Scala I'm only just starting to learn about, but people seem to like it a lot. Fantom, I think, might be perilously close to being the perfect programming language by many metrics, though. Don't take my word for it, have a read about it. I dare you not to be impressed (assuming, of course, that you are the sort of person who gets impressed with these sort of things). It adds some very cool extensions and has direct support for some very useful things, such as allowing both dynamic and static typing under the developer's control.

Both Scala and Fantom can transparently use libraries written in Java, though Fantom can also deploy to both .net and javascript (for web development).

All three of the these languages are interesting enough for me for to not count them out entirely, so I might also try a port to one or more of them.

As always, comments are welcome, so please feel free to try and convince me of the error of my ways. Keep it civil, though, I know how excited programming language discussions seem to make some people.

Web Frameworks, Desktop Application and My Newly Melted Brain

Let's get the preliminaries out of the way: Hello, long time no see, how have you been? Etc...

So, whilst writing up my PhD (experiments finally finished!) and working three days a week (going fully full time at the end of September!) I have a fair bit on my plate at the moment. So obviously I've also started cooking up a side project...

I don't want to talk too much about what it actually is (mostly because I don't know how "open" I want it to be yet), but it's definitely going to require a web service. It might also require a fully fledged website (lets call this the spotify model), or it might just use a desktop application which connects to the service when it needs to (lets call this the iTunes model). Then again it might have both, with the desktop application providing some extra functionality which is hard to do over the web or in the browser. I think there's also scope for a mobile application, so lets throw iPhone and (what the hell) Android into the pot as well.

I had a bit of a poke around with some web development frameworks first, since this is probably the bit I know least about.

One of the first solutions I came across was Django, which is based on the python language. It looks good, through I have some issues with its handling of "one to many" relationships. Python is a language I have limited experience with, but it gets a lot of love, and people are putting a lot of work into into making it better. It also has good integration with native libraries. So that's nice. It's also named after Monty Python, which only raises my opinion of it.

I'll essentially skip over TurboGears and Web2Py, two other python based frameworks I did some reading about. Django seems like the best choice out the python based frameworks I've looked at.

Soon afterwards I discovered Grails which is based on the very cool groovy dynamic language. Groovy, as well as being fun to say, is implemented directly on top of Java, by far the language I'm most comfortable with. The are a lot of existing Java libraries, and groovy has perfect integration with them. Groovy and grails have some serious weight behind them, also.

One framework I hadn't really considered was Ruby on Rails, which is in many ways the daddy here. This is mostly because I dismissed Ruby as a language out of hand. It looks mental. For reasons I'll come to in a minute, I've re-evaluated this desision, and will be having a good long look at it. On the one hand it's been around a good long while, so has had the oportunity to become more refined. On the other hand, it was the first of its kind, which means it might also be stuck with some bad early design desicions. It's the original, this might not make it the best. I don't know yet.

In order to build this... thing, I'll need data representation, I'll need algorithms for processing this data, and I'll need ways of displaying it. I'd rather not have to deal with multiple implementations in different languages, particularly with the algorithms.

Problem.

If I want to make desktop applications, python is a possibility. It has good bindings to GTK and QT for linux, and Cocoa for OSX (there's probably also something which will work on windows, and at some point I'll probably have to care about this). Java will work anywhere, but it's quite difficult to make a desktop application with Java which won't look like crap. My priority in this area is going to be OSX, and Java does not measure up here. I had not considered Ruby, until I came across MacRuby, which is a very interesting idea. It's not a bridge or a set of bindings, you see, it sits right on top of the objective-c runtime. All of a sudden, Ruby and Rails are a contender.

In the mobile space, things get shitty. iPhone requires objective-c, Android requires Java. Bugger.

So here's where I am: I think groovy is a better language than python (and probably ruby), and I think grails is a better framework than django (I'll get back to you regarding rails)... but I'm not sure I want Java hanging around my neck when it comes to building a desktop application. I might also need some serious grunt in the algorithm stakes, and I'm not sure I want to do that in a scripting language. Yes, I need to be able to implement it quickly, but I also need it to run quickly. I'm not sure I want to do that in either C or C++. Java would be good for this (and yes, it's plenty fast). Objective-c is an option I haven't discounted.

The search continues... any thoughts?

Call by the what now?

Some not work related computery bits and pieces have been percolating around my head for some time now. I think we should talk about them for a while. That is: I'll talk. You listen.

I'm probably going to write a couple of more techy blogs, all loosely interrelated. I am going somewhere with them, but I'm not entirely certain as to how much of this journey I will share with you.

First of all, I'm going to talk about the fairly simple computer related concept of "Call by reference" versus "Call by value". This is fairly basic computer science (though I wish they'd taught it properly earlier on in my course). It's possible (probable, even) that this example (or variations of it) has been used a thousand times before. I'm not going to go look for one (or the absence of one), I'm just going to write down my own particular take on it. I assure you that any plagiarism I'm about to commit is in no way deliberate. So, without further ado...

Let's say you want to send a specific piece of information to someone via email. Let's say it's part of today's featured article on Wikipedia (William I of Orange, at the time of writing). In today's connected digital world, you have too main options. First of all, you could send them the information itself, like so:

William was born in the castle of Dillenburg in Nassau, present-day Germany. He was the eldest son of William, Count of Nassau and Juliana of Stolberg-Werningerode, and was raised a Lutheran. He had four younger brothers and seven younger sisters: John, Hermanna, Louis, Mary, Anna, Elisabeth, Katharine, Juliane, Magdalene, Adolf and Henry.

There are several things your recipient can do with this. They can read it. They can edit it, but this will only edit their local copy. The original remains unchanged. If they want to request that a change be made, they can, however, edit it and send it back to you. This is "calling by value."

Your second option is to send them a link to the information:

http://en.wikipedia.org/wiki/William_I_of_Orange#Early_life

This, again, allows them to read it. They have to follow the link to the information it points to first, though. This time, if they make an edit (this being wikipedia) they actually are changing the original copy. They can also see what other information is around it, and if they feel so inclined they can change that is well. You might consider this to be an undesirable consequence. This method has the aditional advantage, however, that you did not have to take the time and effort to make a copy, and the amount of information you had to actually send is significantly smaller. This is "calling by reference."

If you deal with this sort of thing on a day to day basis, you may well be aware that when you do this sort of thing in a computer program you have another option. You can send a constant reference, which would be analagious to sending a link to a website the recipient has no write access to. For example:

http://www.britannica.com/EBchecked/topic/644041/William-I