Attracting Fractals

So, more summer and more fractal fun. First of all, now everything is coloured by shaders. A shader, per my definition, picks the colour for any given point/line-segment depending on direction, iterations, or group - where group can be the factor set used (IFS fractals) or angle in predefined steps (L-systems) or just zero (all other fractals).

Below, you can see a maple leaf coloured based on the factor set used to get the specific point.

The latest addition to the number of supported fractals are attractors. Below, you can see a gradient coloured Lorenz attractor from a paralell projection showiing the X and Y axes (ignoring the Z axis).

The introduction of attractors really exposed the lack of properties. The idea is that each fractal provides a range of properties (be it ints, doubles or compex numbers - perhaps also enums). These can then be queried and set from the UI using a standardized interface.

I'm exploring all these fractal types with the goal to create a base class, AbstractFractal, that I can put into a GUI. Then, fractals can be created from plug-ins, where the plug-in factory can get the actual fractals from a set of definition files - hopefully compatible with FractInt (or very similar, so that machine conversion is possible).

Then, all that is left is to create a nice Qt GUI and utilize QtConcurrent to get some performance from it. Also, have a bit of a sit-down and think through the whole memory situation - right now the application is somewhat hungry...

Fractalicious

Ever since I first played with FractInt, it must have been at least 15 years ago, I've been intrigued by fractals. At first, they seemed like magic to me, but as I learned more maths, I can understand the why, but not always the how.


A couple of years ago I set out to write a fractal exploration application called Frakter. To be honest, it sucked pretty much, but it was an attempt. The nice things about it where:

• Fractals where kept in external scripts, so that the application could be extended.
• Colouring was done using special colour maps that could be loaded and saved.
• It used a background thread to render the fractals.
• It had a zooming history that one could type right into to find interesting ranges in the complex numbers realm.

Now and then I visit Paul Bourke's great collection of fractals (and loads of other stuff too). Each time, I feel an urge to write something that can handle everything that he shows.

I want to be able to fit all different types of fractals into a class tree that I can write a GUI around. The data carried from the fractals to the UI would be enough to do basic 2D rendering, 3D rendering, psychedelic colouring, and so on.


I've had a couple of half hearted attempts this far, but now I started from the other direction, i.e. starting with the fractal types I never get to otherwise.


Right now I've implemented IFS and L-systems. The implementation is not even an attempt at being efficient and uses loads and loads and loads of memory, but it works. The next step is to create a colouring class that one can inherit to do the funky stuff. Last value, current value and current iteration, fractal specific category are the "input values" I plan to use. Right now, fractal specific category, is "last used transformation set" when dealing with IFS, for L-systems, it is zero.

VB Porting Issues

Dear Lazy-web,

I was hoping that someone out there remembers good old VB4. I have an issue when helping out to port a VB4 system to XP. The thing is that I've got a really old system for managing club members and race results that is used by the local bicycle club. I did not write this system, and I'm helping them for free. Anyhow, it uses VB4 + Crystal Reports 1.x.

Installing these tools on Windows XP works on some machines, but not all. For instance, Swedish XP installations seems to crash Crystal Reports (somewhere in ntdll.dll). Just starting the app, that is.

Does anyone know what is causing this and how to circumvent it? I would be very pleased...

Standard Template Library - readable?

Since I called some STL code readable, I've recieved numerous mails and comments. Fellow Qt/KDE-er dhaumann added his 0.02 EUR to the pile and showed the nicety of template specialization.

Today I thought I'd follow up on some more comments.

First of all, my personal opinion is that C++ is just as readable as most other languages. Even in this case. What can be less readable are the horrendus error messages that one can end up with. I've even compiled a small list of error messages and what they really mean in plain English, but this does not - of course - help in ugly template cases. (Yes, the css of digitalfanatics.org is ugly and somewhat broken...)

Back to readability. Even plain English cannot express the two operations that I suggested in a short way. Both cases results in fairly long sentences. Also, try to formally parse and express such sentences with more "interesting" transformation functions.

"For every item in the source list, add 42 to it and replace it in the source list."

"For every item in the source list, add 42 to it and append it to the end of the destination list."

As the commenter zwabel pointed out, in the put-the-result-in-another-list a simple foreach loop showing the actual operation is good enough and reads better. I agree, but that kind of break my do-everything-on-a-line-thesis.

Titus Brown pointed out that I do too much on a single line. I have to disagree with this - looping and doing something on each item is simple enough.

Then I had lots of suggestions that I say that C++ isn't functional, but I use a functional style in my example. I'm not sure that I agree. My impression of the STL is that it can perform a number of functions on lists that I'm interested in, for instance.

• Iterating (for_each)
• Filtering (remove_if)
• Searching (find_if)
• Processing (transform)

To make these operations flexible, they accept a functor - either a predicate or an actual transformation operation. This isn't really functional programming in my eyes, even if it can be used for functional programming. To me, it is just a set of ways to perform iterations and common tasks.

Anyway, some fun thought that have poped up while discussing this topic. What if we combine these operations with the QtConcurrent framework. I have not tried the framework myself, but I was in Munich and listened to Morten's presentation of it, and to me it looks like it could be done. What is missing is a nice set of flexible map and filter functions, binders and such goodies that the STL carries.

STL, redux

Funny to see that claiming that the following code is readable stirred up quite a few comments.

std::transform( list.begin(), list.end(), std::back_inserter( res ), std::bind2nd( std::plus<int>(), 42 ) );

Now, there are basically three points that you guys like to point out:

Try another language - the short answer, no. The longer answer, I like C/C++, much because I've grown to know them, but also because I can see the actual machine code that the code I write will produce. This, to me as an electronics guy, is really neat. It gives me a sense of control.

Also, I've tried Haskell and Lisp (and Excel, if you want another functional language), and I like the concept, but creating something large and actually useful using these tools... I don't know. I'm sure that you can point out a million examples, but... nah. Not for me. At least not for proper work.

C++0x can do this better - but why change a winning concept. Lambda expressions does not belong in C++. The C-family of languages contains imperative languages, not functional ones. Call me old, call me granddad, but I like it the way it is. If I could go back in time, I'd rather spend my time pushing MS to improve their implementation than changing the specs.

You call that readability? - yes I do, and seeing examples from other languages, I do so even more. The trick is to read code from the right direction. For example, compare reading an ordinary mathematical expression to reading it in RPN. Neither is fun, but as soon as you know how to approach it, both are simple.

I try to read C/C++ from the inside out. Take, the troublesome expression that started this. I would start with the arguments. The first two are simple - just limiting the input data. The third is a bit more tricky: std::back_inserter( res ). Try starting from the inside, what is res? A list of integers. What could a back_inserter do to a list? Perhaps insert stuff at the back of it.

Continuing with the operation: std::bind2nd( std::plus<int>(), 42 ). Again, starting from the inside, plus probably adds two arguments together, integers judging from the template specialization. So, bind2nd? Coming from an engineering background (and having done this a couple of times) I thing that it is quite clear that it binds (locks) the second argument to a value, in this case 42. I can admit that this is not 100% clear if you're not familiar with the topic.

So, taking one last step out I find myself looking at the word transform. So, a list of items is transformed into another list. Again, not too hard to grasp, but you might want to look up the details in an STL reference. Speaking of such, SGI hosts are really good STL reference. So, for the curios readers, given these links I think that you also can call the transform expression readable:

• plus
• bind2nd, or actually binder2nd. Kind of hard to look up, but Google knows the way.
• back_inserter (back_insert_iterator)
• transform

STL rocks

I've just been writing a small article on the "gems of STL" and found that I really like what I'm seeing. A personal favorite is the transform operation (found in the functional header file). For example, lets do some adding.

#include <functional>
#include <list>

...

{
std::list<int> list;
list.push_back( ... ); // Populate

std::transform( list.begin(), list.end(), list.begin(), std::bind2nd( std::plus<int>(), 42 ) );
}

So, the transform method takes three iterators and an functor. The operators are, from the left, the starting point of the input, the end point of the input and the starting point of the output. The function simply specifies what to do with each list entry to create the output. In this case, std::plus takes two arguments, but we bind the second argument to 2. What this does is that it adds 42 to every item in the list (between begin and end), and replaces the original items (the results are placed from begin and onwards).

If you want the results to end up in another list, just use the back_inserter magical interator and point it to your results list.

{
std::list<int> list, res;
list.push_back( ... ); // Populate

std::transform( list.begin(), list.end(), std::back_inserter( res ), std::bind2nd( std::plus<int>(), 42 ) );
}

Quite readable and really cool code if you ask me.

QCodeEdit

A spin-off from the Edyuk project has finally been released with a website of its own. The QCodeEdit project looks really promissing. What you get is a code editor with syntax highlighting for a range of languages (yes, you can add support for more languages) developed using Qt - i.e. 100% cross platform - and good looking as well.