Talk:Iterated function system

Equivalent constructions

There might be something unclear in the construction paragraph:

The most common algorithm to compute IFS fractals is called the chaos game. It consists of picking a random point in the plane, then iteratively applying one of the functions chosen at random from the function system and drawing the point. An alternative algorithm is to generate each possible sequence of functions up to a given maximum length, and then to plot the results of applying each of these sequences of functions to an initial point or shape.

Is this a correct rendition of the two methods? Method 1 as described here takes an initial point, applies a randomly chosen transformation, plots the resulting point and applies a randomly chosen transformation on that point again. Method 2 as described here do effectively the same sequence of transformations but only plots the last point. Method 2 is then just Method 1 throwing away most of the plot.

I might be showcasing my ignorance here, but in the chaos game (method 1), we have, intuitively, a point that is jumping around and never settles. Perhaps, we're trying to say that method 2 relies on function sequences such as f1(f2(f1(f3(f2(...(X)....))) where f1,f2,f3 are contractive mappings and that each such sequence have any point X converging on a specific fixed point. This sounds like it would rely on the Banach fixed point theorem but the chaos game seems to show that even though contractive mappings converge to a point, iterative application of different contractive mappings does not necessarily do the same.

So in short, I'm not sure what method 2 is supposed to be :-) EverGreg (talk) 13:54, 23 October 2009 (UTC)

The paper "fractals, graphs and fields" by Franklin Mendivil explained the two methods and their equivalence very well. Recommended if there's others out there getting confused. :-) The construction paragraph seems correct, though it leaves out a lot of detail. EverGreg (talk) 19:40, 26 December 2009 (UTC)

to EverGreg: "Method 2 as described here do effectively the same sequence of transformations but only plots the last point."

There's a subtlety in method 2. Note that it doesn't say "generate a sequence of transformations". It says "generate EACH POSSIBLE sequence of transformations" (implication: from a known starting point in space.)

If you have 3 transformations and you want sequences of length 10, you have 3^10 possible sequences of transformations. Given a common (arbitrary) starting point, this will yield 3^10 end points. Those 3^10 end points are plotted and make your fractal. 46.64.181.38 (talk) 14:11, 19 April 2014 (UTC)

Right. Another way of looking at it is that the chaos-game algorithm is a random depth-first "search" that never backtracks, while Method 2 is an exhaustive search up to a given depth. But yes, this paragraph is super unclear. I just improved it slightly, but a lot more work is needed. Kragen Javier Sitaker (talk) 05:49, 19 July 2014 (UTC)

Example

Just not an encyclopedic, throught with ferns and triangles IFS animation 1 and IFS animation 2 —Preceding unsigned comment added by Edo 555 (talk • contribs) 14:05, 8 July 2010 (UTC)

Major missing topics

Although a few are mentioned as links, this page currently doesn't talk about any of these IFS topics, which I think are interesting and important:

• fractal image compression using IFSs;
• escape-time rendering of IFSs by inverting the functions;
• ray-traced rendering of 3-D IFSs;
• the relationship between IFSs and L-Systems, at any rate the commonly-studied L-Systems (it's easy to come up with a pathological L-System that doesn't obviously correspond to any IFS);
• Barnsley's deterministic iteration algorithm, which I guess is "Method 2"?
• the various other rendering methods presented by Hepting et al. 1991;
• the "collage theorem";
• Bell's "tesseral synecdoche algorithm";
• the "grayscale photo-copy algorithm" and its connection to the invariant measure of the IFS;
• the problem of computing the IFS's bounding box;
• the need to balance transform probabilities for stochastic ("chaos game") rendering (and the difficulty of doing so);
• computing sound upper and lower conservative bounds on the IFS's attractor;
• the phase transitions observed during continuous parameter variation.

Some random set of slides I ran across mentioned that you can get good ray-tracing results by approximating your surface normal as a weighted sum of the surface normals of the bounding spheres of the different subunits, which was part of what I was trying to figure out. I was disappointed to find that we haven't written a better article on this topic yet.

Thoughts on which of these are most important to cover? How to organize them?

Kragen Javier Sitaker (talk) 06:19, 19 July 2014 (UTC)

Zooming

The article says that zooming in on an IFS fractal using the deterministic and random iteration algorithms is impractical.

This may not be the case, depending on how broadly you conceive each algorithm. I've been investigating producing high depth zooms, using a modification of the (depth first) deterministic iteration algorithm and reached a zoom of 5 × 10¹⁵⁰, using native 64 bit floating point arithmetic, without any noticeable deterioration in image quality, at little cost in extra computation time. At this point I hit an arithmetic overflow in the calculation of how deep the iterations should be, but this code can be refactored to avoid this. The modified code is ticking away and has reached a zoom 7 × 10¹⁹⁰. It may be possible to get to over 10⁶⁰⁰.

The modification is to combine a shallow depth first deterministic algorithm with a pruned breadth first deterministic algorithm (i.e. selecting only those branches in the deeper parts of the tree which lie within the zoom).

I haven't tried it yet, but combining a random iteration algorithm with the same pruned breadth first deterministic algorithm, should also work. Lavateraguy (talk) 16:48, 3 November 2016 (UTC)

Suggested addition: the inverse design problem

This LLM-generated text has been collapsed and should be excluded from assessments of consensus.

The following discussion has been closed. Please do not modify it.

I’m sorry, but I’m not going to keep sending the same thing over and over again. I have repeatedly explained that this was not created with an LLM. From the beginning, I have simply been kindly asking whether it is possible to add the mentioned references to this article. A work that started 16 years ago, with a core implementation that is almost identical today, with new attractors.

As I initially explained, my contribution fits well within the “Inverse problem” section of this Wikipedia article. Overall, this article could be greatly improved.

Is there a process for requesting a review from a moderator who has not already been involved in this discussion? I worked a lot on this, and my contribution fits perfectly within this article.

The article's "Inverse problem" section covers only the image-compression form of the problem (PIFS, Jacquin). The other form — given a target shape, how to choose the affine coefficients whose attractor realizes it — is currently covered by a single implicit hint: the collage theorem mentioned nowhere in this article, and only briefly via the Barnsley citations. Designing new attractors (as opposed to reproducing images) is what practitioners actually do with IFS, e.g. Barnsley's fern itself.

If an uninvolved editor considers the sourcing acceptable, the following archived paper addresses that design gap — it names five reusable families of affine maps (stem maps, spiral generators, radial replication, golden-angle/phyllotaxis maps, and non-contracting symmetry maps admissible under average contractivity) with exact working coefficients for each:

• Bonhomme, Cédric (2026). "Building New IFS Attractors: a Working Vocabulary of Affine Maps". Zenodo. doi:10.5281/zenodo.21804778

• Free-software implementation: ifs-fractals (the only IFS/fractal package in the OCaml/opam ecosystem).

Cedricbonhomme (talk) 21:08, 9 August 2026 (UTC)

Not done: your request appears to have been generated by a large language model. Day Creature (talk) 08:10, 15 August 2026 (UTC)

This LLM-generated text has been collapsed and should be excluded from assessments of consensus.

The following discussion has been closed. Please do not modify it.

That's a fair call. I did use an AI assistant to help word the request. The proposal itself is mine: I'm the author of the paper, hence the COI disclosure, and I stand behind the suggestion. My intention was simply to point out a potentially useful addition to the article, not to promote my own work.

I'm happy to leave it to other editors to decide whether the material is relevant and appropriate for the article. The implementation was written around 15 years ago and the core code hasn't changed since then. What changed recently is the addition of new attractor functions designed with an LLM — an experiment described in the paper. Everything else has been my own work for many years. The project gathers the definitions of several well-known IFS fractals, ready to be used with any OCaml implementation, and recently added support for Fractint's .ifs file format. I genuinely think it has value in this context.

If the request is better handled as a smaller, more specific addition rather than a proposal based on the paper as a whole, I can rework it accordingly. Cedricbonhomme (talk) 13:19, 15 August 2026 (UTC)

Not done: your request appears to have been generated by a large language model. Please stop using AI to write your posts for you. It's not allowed on Wikipedia. Day Creature (talk) 21:09, 15 August 2026 (UTC)

It seems that my answer has been lost. I added it previously, just above the initial request. Consequently, I’ll paste my first answer again:

This LLM-generated text has been collapsed and should be excluded from assessments of consensus.

The following discussion has been closed. Please do not modify it.

"""

That's a fair call. I did use an AI assistant to help word the request. The proposal itself is mine: I'm the author of the paper, hence the COI disclosure, and I stand behind the suggestion. My intention was simply to point out a potentially useful addition to the article, not to promote my own work.

I'm happy to leave it to other editors to decide whether the material is relevant and appropriate for the article. The implementation was written around 15 years ago and the core code hasn't changed since then. What changed recently is the addition of new attractor functions designed with an LLM — an experiment described in the paper. Everything else has been my own work for many years. The project gathers the definitions of several well-known IFS fractals, ready to be used with any OCaml implementation, and recently added support for Fractint's .ifs file format. I genuinely think it has value in this context.

If the request is better handled as a smaller, more specific addition rather than a proposal based on the paper as a whole, I can rework it accordingly. Cedricbonhomme (talk) 21:49, 15 August 2026 (UTC)

"""

Could you please have a look at this and consider adding the references from the initial request?

Thank you very much, Cedricbonhomme (talk) 21:49, 15 August 2026 (UTC)

 Not done: Your answer wasn't lost, it was collapsed because it was generated by AI (it can still be seen by clicking the "show" button in the gray box). Please stop pasting the same obviously AI-generated text here over and over again. Again, the use of AI to generate talk page comments is not allowed on Wikipedia and may result in your being blocked from editing if you do it persistently. See WP:AITALK and WP:LLMDISRUPT. Day Creature (talk) 22:03, 15 August 2026 (UTC)

Edit request: the design side of the inverse problem

COI disclosure: I am the author of the paper cited below, so I am asking here instead of editing the article.

The "Inverse problem" section only covers image compression. But the inverse problem also comes up as a design question: how do you choose the affine maps so that the attractor looks like a target shape (a fern, a leaf, a spiral)? The article says nothing about this. I would like to complete this section of the Wikipedia article and cite my work related to this.

I suggest adding one simple sentence to that section, something like:

"The inverse problem also arises as a design question: choosing the affine transformations so that the attractor approximates a desired shape.[1]"

I recently started working on my old project (> 15 years) written in OCaml and introduced this possibility. The paper mentioned below describes this work. Another thing to note is that I also introduced the ability for the software to parse any FractInt files, which means it can work with the work of others.

The reference is:

[1] Bonhomme, Cédric (2026). Building New IFS Attractors: a Working Vocabulary of Affine Maps. Zenodo. doi:10.5281/zenodo.21804778.

The paper describes the free-software implementation , which is also referenced in the paper. I did not want to include a link to my own GitHub account, which is why I am providing the link to the package page on ocaml.org instead. So adding the link to the implementation here is optional, but I think it could be useful as it provides something concrete. It's more visual. I’ll leave this decision to the moderators.

I understand that a self-published source is a weak reference, so I leave it to other editors to judge. Cedricbonhomme (talk) 10:47, 16 August 2026 (UTC)