1. This routine is intended
for plotting 3D or 2D trajectories {*x1(t), y1(t)*},* *{*x2(t),
y2(t)*} with the following requirements:

(a) **A pixel-by-pixel mode**
as though shooting with a machine gun so that the bullets (pixels) lie next to
each other (or with the given pixel distance).

(b) **If no real time mode
was set**, the plotting must take the shortest possible time, about a few
milliseconds so that it be negligible in comparison with the user designated play
time interval (usually many seconds).

(c) **If the real time mode
is activated**, each curve must evolve in a real time in accordance with time
*t* and the length of the time interval designate for this process. Contrary
to the fastest possible pixel plotting in the mode (b), the real time evolution
of the curves should be achieved by adding a calculated delay after plotting
each pixel so that summarily all the delays add up to the given time interval
designated for playing these curves.

2. The curves are represented
with their multiple Taylor expansions, each expansion representing a curvy
segment. The routine should plot pixels comprising one of those curvy segments corresponding
to the current node. The time length of a segment is denoted *step*.

3. "**The conflict of
interests**". In order to meet the requirement (a), the routine must
implement computation which accurately determines the proper time step *dt*
such, that to avoid excessive pixels shot into the same pixel position, and yet
that the shooting do not leave gaps in curves. To achieve this goal, ideally we
would need a parametric representation of the trajectories depending not on *t*
(as is given), but on the arc length *s*: {*x1(s), y1(s)*}*, *{*x2(s),
y2(s)*}, … Then, given the desired pixel distance *ds*, we could
merely increment *s* with the step *ds* obtaining the plotted pixels
with the desired distance.

However the parametric
representation depending on arc length is not available, and even if it were,
it would not help to meet the requirement (b), because the plotting must evolve
dynamically according to the real time *t* (rather then according to arc
length *s*). That is why designed this algorithm as *dt*-driven
rather than *ds*-driven.

4. The *dt*-driven
algorithm utilizes the differential geometry formula

*ds = sqrt( (x') ^{2}
+ (y')^{2} )*dt* or

(*x, y* and all their
derivatives are available, and *ds* is given). This formula allows to
obtain the desired *dt* providing that the point is not stationary i.e.
that *sqrt( (x') ^{2} + (y')^{2} ) > 0 .* The graphs
obtained according to this formula looks continuous and well if

*ds / sqrt( (x') ^{2}
+ (y')^{2} ) = dt << step * or

Thus, in vicinities of stationary points, this formula was not applicable, some heuristic assumptions were made, which could cause gaps in curves near such points.

5. In order to avoid gaps
near stationary points, since the current version the algorithm was improved
relying on the following procedures. Before beginning the plotting process for
a given Taylor expansion within the time interval *step*, first
the program computes an approximate curve length for the segment *step*
for each of the trajectories approximating curves with the respective broken
lines (consisting say of 10 straight segments). Let the longest of those
lengths be L. Recalling about the given pixel distance *ds*, the value *n*=*L/ds*
therefore stands for a number of pixels in *L* so that *step/n = ds*step/L
*is the upper boundary for *dt* in order that curves have no gaps.

6. Therefore instead of
computing *dt* according to formula (*), first program sets *dt *:= *L/ds
. *Then, if *(x') ^{2} + (y')^{2 }> 0, *the program
modifies

*dt = min*{ *ds*step/L, **ds / sqrt( (x') ^{2}
+ (y')^{2} ) *}

so that even in the vicinity
of stationary points *dt* is not allowed to become big and cause any gaps.