Invisible wrote:
> Invisible wrote:

Insanity? What's the first sign of madness??

Post a reply to this message

Weee... I think I might have to Zazzle some of these when I got the 
program working smoothly. ;-)

I could stare at this for quite some time. (Especially if it was at a 
decent resolution.) But nothing compares to seeing it move! ;-)

Post a reply to this message

Attachments:
Download 'frame0062.jpg' (389 KB)

Preview of image 'frame0062.jpg'

Invisible wrote:
> According to Wikipedia (which is never wrong), a chaotic system must 
> possess three attributes:
> 
> 1. Sensitive dependence on initial conditions.
> 2. Topologically mixing.
> 3. Its periodic orbits are dense.
> 
> I know the system has property #1. I believe it has property #2. I have 
> no idea WTF #3 even *means*.

Basically it means that there are infinitely many periodic solutions as 
well as the non-repeating ones, which I'm pretty sure is true of this 
system.  I was more just pointing out that your assertion a few posts 
back "chaos if arbitrarily close starting points diverge violently" was 
incomplete.

Note that this is *total* nit-picking on my part, I know that you 
intuitively understand what chaos is.

>> Thirdly, although it's possible I'm wrong here, if you have *any* 
>> dampening I don't think the system can be counted as chaotic because 
>> all paths will eventually converge to a point.
> 
> According to Wikipedia, the important thing is that the orbits have 
> "significantly different" behaviour. (And apparently what you define as 
> "significant" can affect what counts as chaos.)

I can believe this, and certainly it's fine to call the dampened system 
chaotic since everyone will know what you mean.  I think (without proof) 
that the issue is that a dampened system doesn't actually display 
sensitivity conditions in that points which are close enough will be 
sucked into one of the attractors before they can diverge.  Of course, 
this distance will probably shrink exponentially and you increase the 
dampening half-life so it'll be below numerical precision pretty quickly.

>> Finally, I'm not sure that your system is chaotic.  For inverse-square 
>> springs it's known as Euler's three-body problem and appears to have a 
>> (rather complicated) analytic solution.
> 
> Well, maybe...

I'm actually way less sure than I used to be on this.  This is 
extra-interesting, as I wasn't aware that it was possible to 
analytically solve a chaotic ODE at all.

Reading back, my email comes off as more snarkey than I intended. 
Basically what I mean to convey is that there's a whole large and 
interesting mathematical theory of chaos beyond one's intuitive 
understanding of it, and it strikes me like the sort of thing you might 
  be interested in.

Post a reply to this message

Invisible wrote:
> Weee... I think I might have to Zazzle some of these when I got the 
> program working smoothly. ;-)
> 
> I could stare at this for quite some time. (Especially if it was at a 
> decent resolution.) But nothing compares to seeing it move! ;-)

Sweet!  What's the coloring scheme?

Post a reply to this message

Kevin Wampler wrote:

> Sweet!  What's the coloring scheme?

For each pixel, initialise a particle to that starting point, and let it 
wander under the influence of the attractors in the system. (Three 
"magnets" plus a "string" force to simulate a gravitational pull towards 
the center.) Colour each pixel according to the current X, Y coordinates 
of the particle. (X = red, Y = green.)

It actually comes out looking far more interesting if you colour by 
magnet proximity, and I'm investigating other possible colouring 
algorithms too. (The sharp lines are where the red or green intensity 
"wraps around" back to zero. They're not part of the actual system. It's 
just quick and easy to implement the colouring this way to check whether 
the rest of the program is working OK.)

Obviously, since all these particles are in motion, the image constantly 
changes colour - most obviously with large repeating oscilations, which 
gradually go out of phase with each other as various areas of particles 
pass particularly near a magnet. Hence the fractal nature of the image.

If you're paying attention, you'll note that the magnets aren't *quite* 
in a triangle formation; the top two are slightly too close together, 
compared to the bottom one. Hence the lack of 3-fold symmetry.

There are *so* many animation possibilities here. You can animate the 
orbits of the system, or you can show the system after X seconds and 
move the magnets around. Or just change the colouring algorithm. (Thus 
far I haven't used particle velocity at all yet...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> I still don't really comprehend why RK4 is different to just integrating 
> in smaller steps.

RK4 takes into account how the slope of the function changes during the 
step, Euler just assumes it's constant (equal to the value at the beginning 
of the step).  Of course to the "outside" user of such a function there is 
no difference, RK4 just gives a certain level of accuracy or stability for 
much less CPU time than Euler.

> RK4 manages apparently total stability with really quite large integration 
> steps, which is puzzling.

The effect of RK4 over Euler is squared when you are doing it twice (from 
acceleration to velocity, and from velocity to position) so it's not too 
surprising.  Also your forces are smooth and easily predictable for RK4 
(just sums of 1/r^2) so it should perform very well.  Compare to eg a car 
suspension going over rough terrain, there are often sharp changes in forces 
which RK4 (or any other continuous curve predictor) is not so good at.

Post a reply to this message

> For each pixel, initialise a particle to that starting point, and let it 
> wander under the influence of the attractors in the system. (Three 
> "magnets" plus a "string" force to simulate a gravitational pull towards 
> the center.) Colour each pixel according to the current X, Y coordinates 
> of the particle. (X = red, Y = green.)

Those images are really cool!  So let me get this straight, you colour each 
pixel based on where the point that started at that pixel is at that 
instant?

Must be really cool to see it being animated.

You could calculate the speed of each point, and assign that to the blue 
channel :-)

Post a reply to this message

scott wrote:
>> For each pixel, initialise a particle to that starting point, and let 
>> it wander under the influence of the attractors in the system. (Three 
>> "magnets" plus a "string" force to simulate a gravitational pull 
>> towards the center.) Colour each pixel according to the current X, Y 
>> coordinates of the particle. (X = red, Y = green.)
> 
> Those images are really cool!

Thank you. :-D

> So let me get this straight, you colour 
> each pixel based on where the point that started at that pixel is at 
> that instant?

Yep, that's the one. Start a particle from each pixel, colour that pixel 
according to where the particle is now. (Using any arbitrary colouring 
algorithm you fancy.) You *could* use an image map, for example...

> Must be really cool to see it being animated.

Clearly I'll have to put the result on YouTube at some point. ;-)

> You could calculate the speed of each point, and assign that to the blue 
> channel :-)

Yeah, possibly. Or maybe add some white or something. Of course, when 
it's in motion, you can tell by how quickly each point changes colour.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Kevin Wampler wrote:

> Sweet!  What's the coloring scheme?

The *other* possibility is to colour each pixel by the density of points 
that have reached there. (Kind of "backwards" compared to the current 
algorithm.) I suspect the result wouldn't be as pretty though.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

OK, now this is just *weird*... I just reimplemented the same program at 
home, and it now produces the same images. However, it runs very, very 
much slower than at work. And yet, the PC at work is an AMD AthlonXP 
1700+, while the PC here is an AMD Athlon64 X2 4200+.

In other words, somehow I've made a mistake somewhere that makes the 
program slower than it should be. But it produces the right answers, so 
finding the program is going to be... uh... "interesting". o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message