FractalPark
PhoenixMedium

Multi-Phoenix

A quadratic recurrence with memory: a complex coefficient carries the previous orbit value into the next step, producing feathered, flame-like forms.

Open in Explorer
Multi-Phoenix fractal with feathered spokes and ember-like filament clusters ("Ember Compass")
FractalPark’s Multi-Phoenix ("Ember Compass"): compass-like spokes radiate through glowing clusters of filaments.

Overview

Multi-Phoenix remembers its last step. This second-order recurrence uses both the current z and the immediately previous orbit value, weighting the latter by the complex memory coefficient p. That memory changes a feature’s direction and how long it persists.

The standard Julia step, z → z² + c, has no memory. Phoenix brings the earlier z forward as p·zₙ₋₁. Change p and the past carries a different weight; because p is complex, that weight can rotate as well as grow or shrink. Feathered spokes, flame-like fans, compass rosettes, and ember-like clusters follow.

The filaments suggested the wings and tail of the mythical bird, hence “Phoenix.” Shigehiro Ushiki of Kyoto University discovered it and published it in 1988.

The Mathematics

Phoenix recurrence

z(n+1) = z(n)^2 + c + p times z(n-1)

Take the standard quadratic step zₙ² + c, then add p times the value from two steps ago. A second-order recurrence needs two starting values before its first iteration: z₀ and the “previous” value, usually 0. FractalPark exposes p as an adjustable complex control.

Try the classic Phoenix parameter pair c = 0.5667 and p = −0.5. Starting with z₀ = 0 and z₋₁ = 0, the first few values stay bounded and trace angular, wing-like arcs. Make p positive with a similar magnitude and the feathered structure can break apart or rotate: the memory term now reinforces the earlier direction instead of opposing it.

History

Shigehiro Ushiki, a mathematician in Kyoto University’s Graduate School of Human and Environmental Studies, discovered the Phoenix fractal. In 1988, he published the Phoenix iteration in IEEE Transactions on Circuits and Systems. He presented it as a complex-one-dimensional section of a Julia-like set derived from a complexified Hénon map. The paper is simply titled "Phoenix." The classic parameter pair (c = 0.5667, p = −0.5) produces the named Phoenix curve, later well known in fractal-rendering communities.

Ushiki’s broader research covers complex dynamical systems, Julia sets with polyhedral symmetries, higher-dimensional complex Hénon maps, and the dynamics of surface automorphisms. His Kyoto University homepage lists publications from the 1980s to the present.

The Phoenix family later appeared in Ultra Fractal and other fractal software in both Julia-mode and Mandelbrot-mode variants. FractalPark’s Multi-Phoenix uses the same core recurrence and adds a multi-preview parameter interface.

Visual Characteristics

That one-step memory is visible in feathered spokes radiating from centres, flame-like fans curling along filaments, and compass forms with a sense of direction. A standard quadratic Julia does not make these in the same way; they rely on the directional persistence of p·zₙ₋₁.

With different parameters, the same rule can close into ember-like clusters, open into radiating pinwheels, or dissolve into dust-like regions. FractalPark’s “Ember Compass” foregrounds the compass spokes and warm filament clusters.

Parameters

Memory
The complex memory coefficient p sets both the strength and the rotational direction of the previous orbit value’s influence on the next step.

Remix and Examples

Start from the canonical Document

Open the same approved formula state used by this guide, then change the view, coloring, transforms, or animation in the interactive Explorer.

Frequently Asked Questions

Why does this formula need the previous value?

The recurrence is second-order: its next state depends on the current and immediately preceding orbit values. It is a discrete analogue of a delay differential equation, where the past feeds back into the present. The extra parameter p sets how much of that past continues forward.

Does the initial previous value matter?

Yes. A second-order recurrence requires two initial conditions — z₀ and the value of z before iteration begins (z₋₁) — for a deterministic orbit. FractalPark initializes z₋₁ to zero by default, the standard convention for the Phoenix family.

References

Source walkthrough

  1. frm-v1:a9fa9931913aeafac8b527f31cae7b519db79c8d54829ffcea20bcb6fc9dce4d:init/0

    The ismand branch assigns z = 0 on its true path and z = pixel on its false path.

  2. frm-v1:a9fa9931913aeafac8b527f31cae7b519db79c8d54829ffcea20bcb6fc9dce4d:loop/1

    This assignment sets nextZ = z2 + c + phoenixMultiP * previousZ after z2 has been set to z * z.

  3. frm-v1:a9fa9931913aeafac8b527f31cae7b519db79c8d54829ffcea20bcb6fc9dce4d:loop/2

    This state shift assigns previousZ = z before the following assignment replaces z with nextZ.

  4. frm-v1:a9fa9931913aeafac8b527f31cae7b519db79c8d54829ffcea20bcb6fc9dce4d:bailout

    The termination comparison keeps iterating only while |z| <= 256.

Syntax features

source-sequence

The branch establishes the starting z; the recurrence combines the square, c, and retained previousZ before the state shift.

Parameter experiment

phoenixMultiP

Steps

  1. Use the pinned 96-iteration profile with phoenixMultiP = 0.5 as the baseline. Keeping center, zoom, rotation, and iterations fixed, change only phoenixMultiP to 0.0, render, then restore the baseline and change only phoenixMultiP to 1.0, rendering each trial.

What to observe

For the phoenixMultiP trials, record a visible difference or no visible difference from the 0.5 baseline.

Exercise

Explain how ismand chooses z and how previousZ enters nextZ; compare the 0.5 and 0.0 trials.

Completion check

Your response explains all 4 annotated operations, records the requested comparison, and mentions `ismand` and `previousZ`.

Sources and rights

Pinned runtime revision a9fa9931913aeafac8b527f31cae7b519db79c8d54829ffcea20bcb6fc9dce4d and its publication decision ground this unit.

rightsStatus: project-owned; implementationBasis: project-owned; publicationDecision: publish; decisionReason: publish-project-owned-native-recipe. This statement makes no broader claim about any third-party original.

Formula Record

phoenixMulti

This canonical FractalPark implementation is published and runnable.

Deterministic preview of phoenixMulti

Canonical source

Language
frm-like/1
Standard library
1
Profile mode
parameter-plane
Profile center
-0.5, 0
Profile zoom
0.4
Profile iterations
96
Profile evidence
mechanical

Parameters

  • phoenixMultiP: real

Canonical source

This verified canonical revision is read-only. Remix creates a separate editable fork.

Loading canonical source…

Source and implementation

Formula ID
0f49d971-917e-50a5-ae83-20e11fd4854c
Canonical name
phoenixMulti
Original name
phoenixMulti
Historical source
FractalPark
Current implementation
Project-owned

This is a FractalPark project-owned implementation. The linked file is the pinned canonical Definition.

Rights or attribution concern?

Send the Formula ID and supporting evidence. The maintainer can hold or withdraw the implementation while the claim is reviewed. contact@fractalpark.com