Dynamic Attractor

Suppose you have a system where passing each value of x into a function f generates successive values:

 x[n+1] = f(x[n])

This is a dynamic system. All possible values of x are f's state space.

Basins of attraction are areas in this state space where, if x enters the basin, it will "slide down" the basin to the attractor at its bottom, and stay there. Classically, attractors were assumed to be single points or cycles of points. This definition has been expanded with the discovery of strange attractors, wherein the values generated by a dynamic system stay within a bounded region but do not repeat (e.g., the Lorenz attractor or the attractor of Henon).

Not all dynamic systems have attractors (e.g. x[n+1] = x[n]+1).

Here are some introductory Web pages:

From http://wiki.rubygarden.org/Ruby/page/show/FractalLifeEngine

Attractors are one of the EmergentBehaviors.

From news:comp.object:

Recently I have come across http://www.sparkada.com
I am very interested in any technologies that verify correctness of a program at compile time, or earlier.
Are there other tools or other languages that support proof of correctness?
I am very interested in pre-compiler kind of tools which aid the programmer in his task.
Why aren't these kinds of technologies are not more mainstream?

Because of the CombinatorialExplosion problem.

A compiler is essentially a linear translation medium. Our industry works because it performs in roughly O(n) time.

But a symbolic prover is an ArtificialIntelligence critter. It either does not really work, or it works in O(2^n) time. The more lines you have, the more eons this program must run to prove correctness.

Instead of adding a "proof" step to programmers' chores, why not simply adopt programming practices that "attract" correct code as a limit function, not as an absolute value? If you write UnitTests for every feature, and if you Refactor to simplify code between each step, and if you add features one at a time and only after all the UnitTests pass, you will create what mathematicians call an "iterative dynamic attractor". This is a point in a state space that all flows converge on. Code is more likely to change for the better over time instead of for the worse; the attractor approaches correctness as a limit function.

This is the "correctness" that nearly all programmers get by with (except, of course, for medical or aerospace software). But it's better to understand the attractor concept explicitly than to deny it or to disregard its importance.

Adding time is unlikely to add quality in my opinion (though time spent using better techniques will).

Here's how Time works in our favor. Attractors are relevant to software development for the same reason they are relevant to evolution. Animals fornicating in the wild do not - of course - produce bug-free new versions extremely rapidly, but they do reshuffle & refactor their genes as their niche attracts them to its center. (This is the "equilibrium" phase of the "punctuated equilibrium" process.)

Anyone who agrees with the "iterative dynamic attractor" model has to agree that just running the tests over and over again is not enough, without motion across the phase space. You also must reshuffle & refactor your code ... mercilessly.

If it is like optimization problems in general - this sort of approach can settle on a local optimum which may be well short of the best possible result.

That's a problem in all situations.

In my "DynamicAttractor" explanation, the "sweet spot" we achieve is not the best possible algorithm. It's a relatively decent and vanishingly bug-free >implementation< of whatever pathetic algorithm could fit in our puny little human brains. The best one could actually tower over it only a short ways away, but nothing attracts us there automatically.

-- PhlIp

This reminds me of various utopian movements. There is a really large and bad basin that most organizations seem drawn to. It takes an immense amount of energy to go elsewhere.

It takes "activation energy" to get back up out and into a better basin. Look at IncomeTax?. It sucks (for po' folk like us), so the government performs "AddEpicycles?", such as itemized deductions, 401k plans, Flex spending accounts, and tax on taxes spent taxing tax. But we'd have to have a 'Boston Tea Party', and the consequences, just to fix it. Too many useless jobs threatened.

Unfortunately I've see the original code as the golden age and most modifications make everything worse. This is almost always because the forces of get it done now, assigning the work to people who don't know the code, assigning the work to very junior people, the attractor of silence (people not talking to each other), and a general lack of pride, skills, and professionalism. -- AnonymousDonor

The multiple, wildly varying metaphoric uses of attractors, strange attractors, and iterative systems suggest that this is a case where we should StopUsingMetaphors.