I was going nuts looking at Bootstrap tutorials because they all say exactly what you can read in the docs, and none of them say the very important thing that *isn’t* in the docs, namely just which dependencies you need and the methodology involved to build it all when making your own theme.

I guess the assumption is that anyone using Bootstrap is the sort of person who thinks running everything with JavaScript is a great idea and already has every package ever hosted on npm installed on their machine anyway.

So it was a *huge* relief when I finally found someone who very simply stated the actual steps involved in turning a mess of files into your own CSS. So massive thanks to Alexander Rechsteiner of hackerthemes who put this useful guide and kit together.

I believe I can now finally get to work on making a theme now. This had only been driving me crazy on-and-off for a few months now (most of that time spent not actually looking into it).

]]>So before the irony becomes too excessive, here are some simple definitions of various terms I’ve come across.

- abstraction
- Providing methods that don’t require knowledge of the object’s internal details
- accessor method
- A method that returns the value of a property
- aggregation
- An object containing other objects
- cohesion
- How related something’s different functionalities are
- coupling
- How much detail two things know about each other in order to interact
- dynamic binding
- Determining which version of a method to run at runtime
- encapsulation
- Protecting data from external influences (basically using
`private`

properties) - interface
- How an object is accessed externally
- mutator method
- A method that changes the value of a property
- overloading
- Having multiple definitions of a function/method with different ways of calling each; not limited to OOP
- polymorphism
`a.x()`

doing something different to`b.x()`

. Alternatively, an object`x`

having methods of classes`a`

,`b`

and`c`

- singleton
- A class that is designed to only ever have one instance
- static binding
- Determining which version of a method to run at compile time

Skip this if you already know the details of the Mandelbrot set, unless you want to read what I have to say anyway.

The Mandelbrot set is the set of all points `C` such that, given `Z _{0}` = 0, the iterative function

The reason it is two-dimensional is because it includes complex numbers as well: those with an imaginary part (a multiple of √-1, labelled “`i`“) as well as a real part (a “regular” number). For example, the Mandelbrot set includes `C` = `i` as `Z` follows the sequence 0, `i`, -1 + `i`, –`i`, -1 + `i`, –`i`, … and continues to alternate like that.

You might think that, with the value constantly being squared, the range of included values must be quite limited. And it is; every point that is a member of the Mandelbrot set is within 2 units of the origin (at `C` = 0). Most of the most “distant” points are along the negative real axis, up to and including `C` = -2. That’s why the Mandelbrot set points to the left, by the way.

Most computers are not designed to handle complex numbers. This poses little obstruction: it can be found mathematically that the square of the point `a` + `b``i` is simply (`a`^{2} – `b`^{2}) + (2`a``b`)`i`. If you want to determine this for yourself (and are not already familiar with complex numbers), just remember that `i`^{2} = -1.

The other issue is how to determine whether a particular point is bounded. There is no computer algorithm (or at least, certainly none that I know of) that can reliably determine the result of any point you give it. Thus it is necessary to manually iterate every point of interest, by repeatedly squaring it and adding it back into itself. If the result gets too big, for instance more than 10 units away from the origin in any direction, then the point is not a member of the Mandelbrot set. This distance is called the escape radius as it specifies a radius at which a point is determined to have escaped. Imaginative, isn’t it?

Here’s where the big time sucker is: what if a point *is* a member? You’d be iterating it forever, as it (by definition) would forever remain bounded. Thus the algorithm implements a maximum number of iterations; if any point is iterated more than that many times, it is assumed to be a member. I say “assumed” because, if the maximum iteration count is too low, points will be found that aren’t actually members (since iteration was stopped before that became apparent). This becomes more of an issue near the edge of the set (where you would typically be zoomed-in on, as that’s where all the interesting stuff is), as it’s harder to distinguish what is and what isn’t a member there.

Hopefully you have a solid understanding of what the Mandelbrot set is and how computer programs can render it. Now I will discuss some techniques to render it a bit faster.

Quite possibly the simplest optimisation to make is setting the escape radius to 2 rather than anything higher. Just as the entire set is contained within two units of the origin, no member point will ever iterate beyond two units of the origin either. Unfortunately, such a simple optimisation isn’t very effective either: it only affects points that do escape, and even then any that get that far soon escape after just a few more iterations no matter how large the escape radius is. Numbers square quickly, it is literally exponential.

As I said at the top, I haven’t benchmarked or even tested anything I’m talking about here, so take this at face value. Regardless, I am aware that calculating square roots is not a cheap operation. But in order to calculate the distance from the origin, it’s necessary: apply Pythagoras’ theorem with the real (`x`) and imaginary (`y`) components. If you’re running 10000 iterations of every point, calculating a square root each time, this quickly adds up.

Thus it’s probably best to use a different method to determine escapes. And this is it: check each component individually against the escape radius (which is no longer a radius but more of a square). In your program, it might be written thus: `if(abs(x) > 2 || abs(y) > 2) escaped = true;`

It is true that this won’t register the point 1.5 + 1.5`i` as having escaped, but in every case one more iteration will fix that. I’m quite confident saying that one extra iteration is more efficient than even 1000 square roots.

You could even reduce the number of comparisons by only testing if the real part (`x`) has escaped, as all escaped values along the imaginary (`y`) axis will then register as having escaped after another iteration (this doesn’t hold true for the imaginary axis, as any value without an imaginary component will remain on the real axis forever). You could even skip the absolute value all together and just test if the real part is ever greater than 2, but I’m pretty sure the methods in this paragraph are going too far and might actually *reduce* performance slightly, as well as them just being generally obscure. Stick with using two comparisons as above.

There’s not much to say here. Not all environments (e.g. JavaScript) will allow this, but if you can, be sure to process multiple pixels/points simultaneously. It requires no wizardry to do as each point is entirely independent of the others and can be calculated separately, i.e. it is “embarrassingly/pleasingly parallel.”

I’ve saved the best until last. The biggest timesuck with rendering the set is those points that are members. The algorithm has to go through every single iteration (up to the specified limit) for each of those points, and never gets to quit early. If you use the tool I linked above, you can tell (at high zoom levels) that it visibly slows down on large areas of black, i.e. on points that are members. Fortunately, I think I’ve devised a way to get around this. (again, untested. Some other time, maybe.)

An interesting aspect of the Mandelbrot set is that it is connected: all points are joined to each other with no “islands.” You can somewhat see this in the image up above highlighting the location of `i`: everything is still connected to the main body even if it doesn’t look like it. This property isn’t too useful, but after some research I found that it is also simply connected: there are no holes; any point that is surrounded by members of the set is itself a member.

Maybe you see where this is going.

If you can find a region that is surrounded by members of the set, you know that everything within it is too *without iterating any of them*. All you have to do is implement your algorithm such that it leaves holes to be filled.

An easy way I can think of to achieve this is to initially test points with even `x` or `y` coordinates (assuming you’re counting from 0). The end result of this will be approximately three-quarters of the region tested (it could be slightly more depending on where the boundaries are), with the remaining quarter of points each completely surrounded by eight resolved points (except possibly at the rightmost and bottommost edges). This approach could easily be expanded to leave larger areas bounded; for instance, only cells divisible by three could be initially calculated, leaving 2*2 regions boxed in.

If skipping a quarter of the points in the set isn’t enough, it would be possible to go even further. This makes parallel processing harder as well, unfortunately. What could be done is to calculate points as normal, but as soon as one is found to be a member, stop and try to trace the boundary. Because every point will eventually be calculated anyway, there’s no waste in blindly calculating all the surrounding points, one after another, and only continuing around the boundary of the set. Once this has made its way back to where it started (following the edges of the “screen” if necessary), then you can be certain that the *entire* interior is part of the set and doesn’t need to be iterated *at all*. With a large enough area, the time savings must be highly significant.

At some point I might test and implement these myself, but until then I hope I’ve given you some ideas, or at the very least taught you something interesting about the endlessly-interesting Mandelbrot set.

]]>Come on guys, it’s not hard to do properly.

With `n` as the number of lines you want to show, what should be done is this:

if(items.length > n) { print(items.limit(n-1); print(read_more_link); } else { print(items); }

rather than

n-=1; print(items.limit(n); if(items.length > n) { print(read_more_link); }

It’s not difficult.

]]>Turns out there’s more to the Tower of Hanoi than I knew. Although solving it recursively is quite easy, Wikipedia also lists an iterative system: make alternating moves between the smallest disk and another. Always move the smallest disk in the same direction, and for the other moves there’ll only be one option. All you have to remember is whether or not the smallest was moved in the previous turn.

Which is all very interesting, but scroll down to the “Graphical representation” section and something else interesting arises: a graph of the possible moves with each node representing the position of each disk.

For instance, the left node on the second row (“baa” ) means the smallest disk is on b, and the second and third are on a. That section lists a bunch of trends, but of note is that any state (except where all pieces are on the same peg) has three possible moves, which is two if you don’t undo. Also interesting is the possibility to encounter every possible state exactly once on the way to the solution.But what gave the title of this post is the similarity to the Sierpinski triangle. With more disks, it looks more and more like it. I believe it would be fairly simple to generate the graph for any number of disks: note that, for instance, every node in the top third ends with “a”. Every node in the top third of that has “a” second, and so on.

Anyway, check out the Wikipedia article, there’s some interesting stuff there.

]]>But have you ever wondered what the proper, SI, power-of-1000 equivalences are? Here’s are some handy conversions.

SI unit | Rough equivalence |
---|---|

kilosecond | 16.67 minutes (quarter of an hour) |

megasecond | 11.57 days (third of a month) |

gigasecond | 31.71 years (third of a century) |

terasecond | 31.71 millennia (what did you expect?) |

petasecond | 31.71 million years (eighth of a galactic year) |

exasecond | 31.71 billion years (2.3 times the age of the universe) |

And in reverse:

Weird unit | Exact SI equivalence |
---|---|

minute | 60 seconds |

hour | 3.6 kiloseconds |

day | 86.4 kiloseconds |

week | 604.8 kiloseconds |

month (30d) | 2.592 megaseconds |

year (365d) | 31.536 megaseconds |

decade | 315.36 megaseconds |

century | 3.1536 gigaseconds |

millennium | 31.536 gigaseconds |

Some fun, suspiciously astronomically-related facts:

- Earth sidereal day: 86.164 kiloseconds
- Neptunian year: 5.197 gigaseconds
- Galactic year: approx. 7.25 petaseconds
- Age of the Universe: 435.17 petaseconds

These values work identically for light-years, e.g. 1 light-year = 31.536 megalight-seconds.

Now go call the Millenium Falcon the “Gigasecond Falcon.” Go on, I dare you.

]]>The true part of it all is that yes, beyond the event horizon the force of gravity is so strong that literally nothing can escape. The key part is “beyond the event horizon.” For anything (significantly) further away, they act like any other object that has mass. The most accurate way to think of black holes is as objects that are heavy but small, mostly because that’s exactly what they are.

So what’s the deal with the whole “light can’t escape” thing? We’ll start with the basics: acceleration from gravity is a function of mass and distance, proportional to m/r^2. If the distance is halved, the acceleration is always quadrupled. Typically there’s a limit to how far this can go, once the two objects make contact. The size of the objects changes how close they can get to each other, and thus changes the maximum possible gravitational acceleration. But there’s no experienced difference between standing on the ground 6370 km from the Earth’s centre and being suspended at the same distance if it had the same mass but were half the size, nor if it were concentrated in a point the size of a pea.

You might have picked up on the key idea here: all that’s special about a black hole is that it’s so small that an object *can* get close enough to experience such a large force that nothing can get out. The technical definition is that a black hole has all of its mass within its Schwarzschild radius (if it’s not rotating and has no charge, but the basic idea is still the same in those cases). Further away, there’s no real difference. Objects can orbit around it just fine for instance, and a black hole can orbit around other things just fine too. If the Sun were compressed into a black hole with the same velocity, less than 6 km in diameter, all planetary orbits would remain unchanged (even the precession of Mercury, as far as I know, unless general relativity works differently when the mass is compressed). It wouldn’t be safe though, because the Sun would no longer be emitting anywhere near as much light as the Sun does (almost none, see below).

Note that any mass has a Schwarzschild radius, and becomes a black hole if compressed to within it. For example, the Earth would need to be about one and half centimetres across (still with all its mass!) to form a black hole. Most black holes are only many times heavier than the Sun because the extreme conditions to create them only occur when a massive star collapses.

What do black holes look like? You’ll probably hear that, because they don’t emit anything, they’re only visible as an empty spot against the cosmic background. This isn’t entirely true. First of all, there’s Hawking radiation, which is faint electromagnetic radiation resulting from the creation of particle-antiparticle pairs near the event horizon. It’s theoretical, but mostly taken for granted.

The more significant effect is gravitational lensing.

The intense gravity of the black hole bends light around it significantly. In the above image, light from the Milky Way is visible on both sides as it wraps around. The event horizon lies around the dark circle in the centre.

Another feature visible with some amount of black holes (all the ones that have been detected, since it’s the only feature visible enough from Earth) is an accretion disk.

It consists of random dust in orbit around the black hole, heated by friction to give off considerable amounts of light. In a lot of cases, such as the nearest known black holes, the matter of the disk is pulled from a nearby star. “But you spent the first four paragraphs saying how black holes *don’t* suck in everything around them!” True, but this process is analogous to the disintegration of an object into rings when it gets too close to another. The star is quite large and very close, so in order for its centre of mass to maintain a stable orbit, the parts closest to the black hole don’t have enough orbital velocity (required velocity increases the closer you get) to stay away and end up falling in. Note that they still don’t make a beeline for the centre of the black hole, but get caught in a disk around it.

Here it is, more from the side, so you can see the comparative size of the actual black hole:

The white bulge is just an effect of gravitational lensing. The black hole (or rather, its event horizon, because what’s beyond the event horizon is literally impossible to observe without going there) is closer to about a third of that (you can see a small black bit near its top).

If you ever get confused about how a black hole works or what something near one should be doing, just remember: black holes are heavy and small, and that’s all.

]]>This time it’s Golly, a desktop application for simulating cellular automata. And I use the general term intentionally: rather than just Conway’s Game of Life (CGOL, GOL or even just “Life”) for which it is named, it supports:

- variations like High Life, Diamoeba, and Day and Night
- “Generations” patterns like Star Wars where dead cells take up space for a few generations
- The one-dimensional “Wolfram” rules, like rule 110
- Non-totalistic rules where relative position around a cell matters, such as “Just friends” which won’t let a cell be born when its neighbours are on opposite sides
- “Larger than life” rules that take into account cells beyond the neighbouring ones
- Automata with many uniquely-interacting states like Langton’s ant, Wireworld and John von Neumann’s automaton

And really, that last one basically means “anything.” It also supports the HashLife algorithm which allows huge patterns to be computed quickly by effectively skipping intermediate generations (but still resulting in the correct pattern). I strongly recommend increasing its maximum memory from the pitiful default of 500MB under File -> Preferences -> Control and changing settings for HashLife (Generations, JvN and RuleLoader also have similarly low limits) so you can compute very large timesteps more easily.

It comes with a large collection of patterns and rules already, most unsurprisingly for Conway’s original rule. If you’re as confused as I was about how to access John von Neumann’s CA, there are simulations under Patterns/Self-Rep/JvN. I’m not sure if the words “John von Neumann” actually appear anywhere.

Another site of interest is the aptly-named LifeWiki, which contains lots of information about various cellular automata, again with a focus on regular “Life”. You’ll find that the people who have studied this stuff apparently had a sense of humour, with a set of “blinkers” forming a “traffic light,” four “loaves” making a “bakery,” and a “knightship” that involves a “half-bakery” being dubbed the “half-baked knightship.”

It’s quite easy to get lost in looking at the vast collection of patterns and being in awe of quite a fair few of them, but it’s fun too.

]]>It has three further subcategories, but those aren’t important.

As you can see, if you looked, the lengths of the various sides are not quite intuitive. This is important for when you’re drawing something in that style, as it’s not easy to tell what proportions it should be in. Unfortunately, information on how to determine these ratios is hard to come by.

Thus, I set to work to write a calculator. Info on how to use it is also there.

What’s special about this one is that it displays a dynamic diagram using an HTML canvas. Even better, you can drag the lines around if you don’t feel like typing angles directly. That is certainly the best feature.

I might add the functionality of calculating angles from side ratios, but as I was still implementing the angles I realised that nobody would probably ever need that. Maybe if I have some time to kill.

This is the first thing I’ve ever done with HTML canvases, and I hope that’s not too apparent from looking at it. If you’re interested, there’s a good guide on the MDN that I used to get started. Naturally jQuery is as awesome and useful as ever for dealing with javascript’s various weirdness.

]]>These are good steps to properly introduce something new without having the player at a loss:

- Have an extremely simple puzzle, where the crucial elements of the new mechanic are the only ones present, and allow the solution to be found accidentally.
- Immediately follow it with one that still has only the crucial elements, but it must be consciously set up
- Now you can have it as part of a larger puzzle, preferably soon after the previous step

Because the player likely will not know the mechanic yet, the first puzzle must have them “discover” it rather than work it out. Its stripped-down nature should make it obvious there aren’t many options so the player won’t waste time trying other solutions. Hopefully at some point they will start to muck around and try anything they can. If the puzzle is too complicated they might not happen across the correct solution, but again, the puzzle should be simple so this doesn’t take too long. The simplicity should also help make it apparent what exactly happened, as if there is too much involved then it won’t be obvious which aspect worked.

The next part is where it gets back into intentional puzzle-solving. While the concept is still fresh in the player’s mind, you introduce a puzzle that reuses it in a similar fashion, but where it can’t so easily be stumbled upon accidentally. The idea is that the player should actively and intentionally set up the solution so they can be confident it is intended and clarify their understanding of it. The design should still be simple to make it clear there are limited options, and should possibly resemble the previous puzzle where it was introduced to make the connection more obvious.

Once that’s done, the player should have a good idea of how this new mechanic works and it can be used as part of a larger puzzle. That doesn’t necessarily mean you should throw them straight into the deep end with dozens of layers of obscurity, especially if you adding to what is already known about the mechanic. If new knowledge is required but the core idea is the same, it still needs to be properly introduced as above. Even if not, following puzzle making use of it shouldn’t be too complicated so that it’s still clear where it is needed. A few larger puzzles making use of it should give the player an idea of all the ways it is useful.

I shall discuss two examples: how Valve introduced the fling mechanic in *Portal*, and my own idea for a new mechanic involving the redirection cubes in *Portal 2*. Portal games make good examples because the rely on using known mechanics in interesting ways to solve puzzles. Making a puzzle where the solution can’t be determined from what can be seen about the test is generally frowned upon.

At first, it’s just a small gap that needs to be crossed. This isn’t so much to introduce flinging, more just that you can get to the other side of a gap from a vertical surface. It does have the pushed-out panel to help establish the visual language surrounding other flings, and it’s possible the player will get across by placing a portal underneath them which sort of acts as a fling since that is sufficient to get across. Also note the narrow, streamlined nature of these chambers, removing any unnecessary details.

The next section can be solved accidentally. Standing on the edge of the “diving board”, you might jump down into the pit since there’s nothing else to do (the brown metal surfaces prevent any placement of portals). With no way out, you place a portal underneath yourself. You come out and this happens:

I didn’t move when taking this screenshot, you will always end up right on the edge of the platform. Once again, without any options, you would probably jump down again, this time going through the portal and landing on the other ledge. No doubt this sequence of events is intentional.

Now the player has been led to perform a fling, it is time to make sure they understand how it works. What changes is that the stationary orange portal is now on the floor, requiring you to place the other half. Also note that there are stairs this time, since the accidental component is finished.

This chamber also requires three flings from two different heights, reinforcing that the height matters.

Once this is done, the player has a firm understanding of how flinging works, despite having never encountered it nor known it was even possible beforehand.

Say you wanted to introduce a mechanic where a loop of laser redirection cubes would cause them to overheat and “dissolve”. Here’s how I would do it:

This would be the initial, introduction chamber. The button is clearly causing the exit to be blocked, and the structure above it prevents the cube from coming out. The only thing to interact with is the other cube, and eventually a player would probably point it at the other cube like so:

Then they would dissolve, there’d be no cube on the button, and the laser field would turn off. The white surface provides variety, but possibly also subtly hints that something should go on it.

Now there would need to be a test that is less likely to be solved accidentally. I would do that by not having the laser pointing into the button cube immediately, so that the player would actively be targeting it first. That could be done with two cubes, but I decided to add a third so a little more effort would be necessary:

It’s a similar layout so the player still knows what to do: destroy the cube on the button. Again, it can’t be removed or rotated. With two cubes, the button one would be pointed towards the white strip and the other cube would be placed at the intersection of where the laser and first cube are pointing. Three cubes allow for more freedom, however, and by not having one particular configuration, it shows that such a loop can be set up at will without the level having to cater to it. One way to get past this would be the below setup, with the loop running clockwise:

Alternatively, the top right cube could point into the button cube directly. Either way, it requires understanding of the requirement for a loop and how to form one.

I would make a map making use of this concept (I mean, I pretty much did to take those screenshots), but I have no idea how to actually detect a loop. Oh well.

]]>