Compatibility

Ultra Fractal 5 accepts almost all formulas written for earlier versions of Ultra Fractal. There are many changes in the compiler since Ultra Fractal 4, but the language has been changed in such a way that existing formulas will still compile. The new language features are accessed with semi-reserved keywords, meaning that you can still use them as variable names. This ensures that there will not be a conflict with existing formulas.

There are some minor differences in the compiler since Ultra Fractal 2:

• There are a three new keywords: color, heading, and endheading. Variables with these names will have to be renamed. Parameters with these names should not be renamed to avoid breaking backwards compatibility. Instead, add a @ character to the parameter name in the parameter block that describes it, so the compiler will recognize it as a parameter, not as a keyword. For example, "param color" should be changed to "param @color".
• Some formulas might not run well with double precision (Ultra Fractal 2 always uses extended precision). In this case, either correct the formula, or adjust the Additional Precision value in the Formula tab of the Layer Properties tool window so extended precision is used. You can verify this in the Statistics tool window. Also see Arbitrary precision.
• Built-in functions that can return complex values with float arguments are treated differently. If the return value is assigned to a complex variable, the float argument is converted to complex and the complex version of the function is called instead of the float version. This fixes a number of bugs like:
  
  complex c = sqrt(-1) ; should be (0, 1)
  
  Unfortunately, sometimes it breaks backwards compatibility because Ultra Fractal 2 would assign an invalid value to c in this case. To work around this, use:
  
  float f = sqrt(-1)
  complex c = f
  
  

The formula compiler is largely compatible with Fractint's parser and most Fractint formulas can be used without modification. There are a few exceptions, however:

• Writing to parameters is not recommended, since Ultra Fractal can perform special optimizations when parameters are read-only. Formulas writing to parameters will be accepted, though.
• Writing to predefined symbols that are read-only, such as #pixel, is not allowed. Formulas writing to these predefined symbols will not be accepted.
• Formulas using the predefined symbol LastSqr will not be accepted. The usage of LastSqr serves no purpose; it is intended as a speed-up but it only makes formulas run slower (even in Fractint). Furthermore it makes formulas very hard to write and to understand.
• Formulas using the function cosxx will not be accepted either. This function results from an early version of Fractint which contained a bug in the cos function. The cosxx function allows you to reproduce this bug in later versions of Fractint. If you still want to use the cosxx function, you can write conj(cos(a)) instead of cosxx(a).
• In Fractint, built-in functions with invalid arguments often return other values than in Ultra Fractal. For example. log(0) returns 0 in Fractint, but it returns -infinity in Ultra Fractal. This can cause problems. In general, if a Fractint formula gives a blank screen instead of a fractal, you should check the formula for this kind of errors (log(0), division by zero, recip(0), etc).
• Fractint iterates fractal formulas not the number of times given by the maximum iterations value, but one time less. Ultra Fractal does iterate fractal formulas the number of times given by the maximum iterations value. The Fractint PAR import feature in Ultra Fractal takes this into account and subtracts one from the maximum iterations value used by Fractint.

Generally, formulas that depend on the forgiving behaviour of Fractint's parser will not be accepted. Often Fractint accepts formulas that contain syntax errors and it will still produce a picture. Ultra Fractal will refuse to load such formulas. This is useful, because it helps you to write clear and understandable formulas, and it might point you in the direction of possible errors.

Next: Execution sequence

See Also
Invalid operations