Mandelbrot Orbits

May's Fractal

May's fractal is really really late, but here it is anyway:

For all the applets before May's I had picked fractals that I already knew something about and had implemented before (though perhaps without a UI). I wanted May to be different, and unfortunately my first attempt at a new (for me) fractal turned out to be a bit of a mess. I created some silly 4D fractal viewer with a way too complicated set of UI controls. It didn't make sense to anyone who used it.

I wasted a lot of time on that dead end, and just last week I decided to abandon it and try a different, simpler fractal. I picked Newton Raphson because it's one that I've never implemented before, but I knew that it should fit within the existing framework I had.

The Newton Raphson has worked out quite nicely. It worked very quickly, and I was able to spend a couple of days optimizing the thing to be fast.

The good:
  • More colour.
  • Reasonably fast on Java6 VMs.
  • Reused a lot of code from earlier fractals.

The bad:
  • Just the Mandelbrot fractal from before with a different iteration function.
  • Slow on Java5 VMs (including Mac OS X).
  • Don't have much time to make the June fractal.
Mandelbrot Orbits

February's Fractal

February's Fractal is here, only a few days late:

The instructions are a bit scant, basically you drag the orange dot around to explore the Julia sets that are associated with each point on the Mandelbrot set. Click the big button to view the high-res version of the Julia set.

The Good:

  • I copied the idea of dragging a control tool (the orange spot) from ChaoticDust.

  • Less late that my January one...

The Bad:

  • I created a real complex number class for hiding away some of the arithmetic, so the rendering is now slower than the January release.

  • Dragging the orange dot can be quite laggy.

  • My interactively updated julia sketch isn't as dense as other ones I've seen:

  • Still goes a bit nuts if you zoom too far.

  • Caching in your browser may mean you don't see the correct newly updated applet. You will know this if you don't see an orange spot.

Mandelbrot Orbits

New year's resolution

Last year I followed the progress of Petri Purho and his Kloonigames Blog where Petri attempted to churn out a simple game once a month. He managed to keep it up for a whole 12 months, and his First Season of games was quite impressive.

As a sort-of new year's resolution I've decided to attempt something similar myself. I like the idea of having regular monthly releases of small programs that when viewed together as a collection might be quite interesting.

So my topic..

Well I've always been interested in fractals, and I see that there is a gap on the web for some nice friendly interactive applets. The current ones on the web are a bit clunky, usually lacking intuitive navigation and requiring that you type in coordinates etc. The ones I create will hopefully be a bit more "google-map-y" in the way you interact.

I have also been impressed with Paul Bourke's Fractal pages for a long while. If I could slowly create something similar but with with small interactive versions, that'd be very cool.

My first applet happens to be late. I was hoping to post it at the end of January. I had the applet ready by then, but unfortunately I wasted about a week trying to get the thing embedded into my Wiki. Tonight I gave up and have decided to simply to place the applet on a static html page, and link to my Wiki instead.

So here it is:

Be kind!
Mandelbrot Orbits

Christmas update

Hello chaps. My christmas and new year holidays are nearly over, and to be honest I'm looking forward to going back to work. Sarah is already back at work and even with christmas toys to play with it's still a bit boring on my own. I've spent a lot of time mucking about on Facebook and playing with the rats.

For christmas this year Sarah gave me a lovely classical guitar. I owned one when I was living in Colorado a few years ago, it's good fun having one again that I can play some simple tunes on. :D I wrote a guitar tuner yonks ago, and so it has been given a bit of a dust off recently.

I've put some christmas money towards ordering a new push bike (in the sale of course). It'll replace the one I've got that's very heavy, very rusty, and in need of several repairs that the repair shop tell me aren't worth the expense. The new one is a bit lighter and has fancy hub gears that should be easier to maintain. I'll be able to pick it up this Sunday or Monday, I'm quite excited.. :D

I'm going to a pantomime tomorrow with Dad and some of his friends. Should be good fun I reckon. Though it does mean I'll miss out on some bathroom shopping with Sarah. :/ I'm sure she won't pick anything too hideous. :p
Mandelbrot Orbits

Inheritance (the OOP kind)

I've recently noticed that deciding class inheritance requires looking at the behaviour you want from your classes a lot more than I'd previously realised[1]. Looking at what they represent isn't enough. Looking at the classic Rectangle and Square example in OOP..

If we are interested in creating a couple of read-only and immutable classes (Get methods only), then everything we can ask of a Rectangle we can also ask of a Square (GetWidth() and GetHeight()). So leading from this we'd be inclined to make Square inherit from Rectangle.

Alternatively.. If we are interesting in write-only classes and we focus only on the Set methods then we come to the opposite conclusion. Having Rectangle as base would imply that Square would need to implement SetWidth() and SetHeight(), not very clever. Only SetSize() makes sense for both shapes, and so we conclude that Square should be the base, with Rectangle derived (presumably SetSize() on a rectangle would set both the width and height in one go).

Can this sort of issue (where looking at different behaviour requirements for the same set of objects could lead to different decisions about inheritance) crop up with real classes? Or is this an artifact of the slightly dodgy example[2]? I'm inclined to think it is a real problem, but I can't think of an instance in which this has bitten me for real.

Is there a name for this kind of analysis? Can any of the more experienced programmers out there suggest a good book?

Also.. What happens if you have an existing class hierarchy and are interested in adding a new feature, only to discover that the new feature would require a different inheritance layout? (Maybe we have read-only shape classes, and want to extend them to be mutable).

[1] Hmm, books always say that classes should focus on behaviour more than anything else.
[2] We probably shouldn't have a Square class, or at least it should be unrelated to Rectangle.
  • Current Mood
    geeky geeky
Mandelbrot Orbits

Combo Boxes

Combo Boxes have strange behaviour when you type into them. I've got an example one here to illustrate.
  • If you repeatedly press the same character into a combo box, it'll iterate through all of the options beginning with that character.
  • If you type a word without pausing between the keystrokes, it'll jump straight to that word.

It's a shame these two things conflict when the entry you want begins with a repeated letter.

In the example above, give the combo box focus and then try typing "e3", "24", "38" or any entry that is two different characters. It works great. Try typing again to jump to "44", "55", or "ee" (in an attempt to find "eek"), and you'll see the problem I'm talking about.

So here the UI is behaving differently for only subtly different input, and for the user this is just going to be confusing.

What's the solution? For me I can simply replace my combo boxes with spinners or plain text fields. I'm not sure what the workaround is if you need combo boxes...
Mandelbrot Orbits

Oooh! Journal renamed...

Finally! That old crufty "pauldoo" journal I started when in 1st year uni and abandoned after ten minutes has expired. This "pdoo" one has been renamed to my preferred title. :)

Apparently all linky things from the old one should have been automagically updated to follow.