Lenguaje de fórmulas FRM

Escribe fractales con FRM

Aprende el subconjunto FRM probado de FractalPark, entiende cómo el código fuente se convierte en un shader de GPU y construye tres fórmulas funcionales a partir de los mismos ejemplos que usa el editor.

Qué es FRM

FRM es una forma compacta y basada en texto de describir un fractal iterativo. Una fórmula nombra su estado inicial, el cálculo que se repite para cada órbita y la condición que decide si la iteración continúa.

El formato nació del ecosistema de Fractint, donde los archivos de fórmulas permitían intercambiar experimentos sin reconstruir el programa de renderizado. FractalPark lleva esa idea de autoría a un flujo de trabajo en el navegador, documentando su propio subconjunto probado en lugar de reclamar compatibilidad completa.

Para los orígenes y la historia del proyecto en general, consulta el sitio del proyecto Fractint.

Soporte de FRM en FractalPark

FractalPark tokeniza, analiza, valida y compila un subconjunto deliberado de FRM. La tabla separa las construcciones que funcionan directamente, las que tienen semántica documentada de FractalPark y las que el flujo de trabajo actual no puede conservar.

Nivel	Significado	Ámbito verificado
Compatible	Cubierto por las pruebas del compilador y utilizable sin una salvedad semántica.	Una declaración de fórmula por documento de código fuente Secciones init, loop y bailout Asignaciones y variables de usuario Literales reales y complejos; expresiones aritméticas, de comparación, lógicas, unarias y de magnitud Ramas if / elseif / else / endif z, c, pixel, zPrev, p1–p5, constantes y funciones integradas probadas Comentarios FRM Diagnósticos estructurados y mapeo de código fuente de FRM a GLSL
Adaptado	Aceptado con una diferencia semántica documentada o como extensión de FractalPark.	ismand se asigna al modo de ejecución Mandelbrot/Julia actual de FractalPark fn1–fn4 usan despacho de funciones en tiempo de compilación @mode: native, @default-view y @default-coloring son extensiones de FractalPark; las directivas predeterminadas solo se aplican en modo nativo
No compatible	No se conserva con el compilador ni el flujo de archivos actual; se rechaza en lugar de reescribirse silenciosamente.	Seleccionar entre varias fórmulas en un archivo Conversión automática de dialectos clásicos de Fractint Directivas arbitrarias de código fuente Identificadores no ASCII Funciones o macros definidas por el usuario Funciones del preprocesador Cualquier construcción rechazada por el pipeline de compilación actual

Esta es una línea base de compatibilidad probada, no una afirmación de compatibilidad total con Fractint. Cuando el compilador cambie, esta matriz y sus pruebas deben cambiar juntas.

Compatibilidad verificada

Estos recuentos de capacidades provienen del manifiesto versionado: 588 entradas objetivo comprenden 579 aprobaciones strict-v2 y 9 exenciones documentadas; 117 entradas independientes se excluyen con motivos estables.

Entradas objetivo: 588
Aprobaciones strict-v2: 579
Exenciones documentadas: 9
Excluidas con justificación: 117
Tipos de descriptor de bailout: 4
Funciones integradas: 20

Descriptores de bailout

Motivos de rechazo estables

unknown-predicate
unknown-magnitude-form
threshold-not-loop-invariant
chained-logical

Funciones integradas

sin
cos
tan
sinh
cosh
tanh
exp
log
sqrt
abs
sqr
conj
flip
recip
cabs
real
imag
atan2
cosxx
cotanh

Parámetros: p1, p2, p3, p4, p5 · Ranuras de función: fn1, fn2, fn3, fn4

Manifiesto de capacidades v1 · Semántica estricta v2

Anatomía de la fórmula

Una fórmula FRM de FractalPark tiene una declaración con nombre y tres secciones explícitas. Juntas definen la transición de estado para cada píxel.

init:

Se ejecuta una vez por píxel. Define aquí el valor inicial de la órbita y cualquier variable auxiliar.

loop:

Se ejecuta una vez por iteración. Actualiza z y cualquier estado que necesite la siguiente iteración.

bailout:

Devuelve la condición para continuar la órbita. Cuando se vuelve falsa, el punto ha escapado.

Los nombres de las secciones son estructurales, no comentarios: omitir o escribir mal uno produce un diagnóstico.

Guía de sintaxis

El lenguaje se mantiene deliberadamente pequeño: las expresiones describen aritmética compleja, las sentencias actualizan el estado de la órbita y el flujo de control selecciona entre actualizaciones.

Declaración y secciones: Envuelve una fórmula con nombre entre llaves y luego escribe init:, loop: y bailout: en ese orden.
Valores y variables: Usa números reales como 0.15, pares complejos como (0.05, -0.02), valores de órbita integrados o tus propias variables asignadas.
Expresiones: Se pueden combinar aritmética, potencias, comparaciones, operadores lógicos, operadores unarios, la sintaxis de magnitud |z| y funciones complejas probadas.
Flujo de control: Usa if, elseif, else y endif cuando una actualización de la órbita dependa de una condición. Los bloques deben estar balanceados.
Funciones integradas: Los nombres principales incluyen z, c, pixel, zPrev, p1–p5, pi, e, maxit, ismand, fn1–fn4 y las funciones cubiertas por las pruebas del compilador.
Comentarios y directivas: Los comentarios con punto y coma documentan el código fuente. Las directivas @ reconocidas configuran el comportamiento nativo de FractalPark; las directivas desconocidas no se ignoran silenciosamente.

Pipeline de FRM a AST a GLSL

FractalPark no pega texto FRM en un shader. Pasa el código fuente por un compilador por etapas para que la sintaxis, el significado, el código generado y los diagnósticos permanezcan conectados.

1
Código fuente FRM
El texto exacto del editor, del pegado o del archivo local es la entrada autoritativa.
2
Tokens del lexer
El lexer reconoce nombres, números, operadores, marcadores de sección, comentarios y directivas, conservando las ubicaciones del código fuente.
3
AST analizado
El analizador construye un árbol de fórmula estructurado y reporta declaraciones, expresiones y bloques de flujo de control malformados.
4
Validación y forma canónica
El validador revisa nombres, tipos, secciones y la semántica compatible antes de crear una fórmula canónica.
5
GLSL y mapa de código fuente
La generación de código emite funciones de shader y registra mapeos del GLSL generado de vuelta al código fuente FRM.
6
Plugin de fórmula
Una compilación exitosa se convierte en el mismo contrato de plugin de fórmula que usan el renderizador y el sistema de ensamblado de shaders.

El contrato compartido del compilador mantiene Explorar, el Editor independiente, las fórmulas personalizadas guardadas, los ejemplos y las pruebas en una sola ruta de implementación.

Tutoriales progresivos

Estos ejemplos avanzan desde la fórmula cuadrática más pequeña hasta los parámetros y la retroalimentación con estado. Cada bloque de código se toma directamente del registro compartido de ejemplos y se compila durante las pruebas.

Lección 1

Mandelbrot de inicio

starter-brotAbrir en el Editor FRM

La fórmula de tiempo de escape más pequeña, útil para aprender primero la estructura init / loop / bailout.

Enfoque: la declaración y la estructura init / loop / bailout. Cambia el exponente o el umbral de escape solo después de que esta versión compile.

starter-brot.frm

StarterBrot {
init:
  z = 0
loop:
  z = z^2 + c
bailout:
  |z| < 4
}

Lección 2

Deriva de parámetros

parameter-driftAbrir en el Editor FRM

Demuestra los espacios de parámetros p1 / p2 y la diferencia entre cabs y |z|.

Enfoque: los espacios de parámetros p1 y p2, un literal complejo y cabs(z) como función de magnitud explícita.

parameter-drift.frm

ParameterDrift {
init:
  z = 0
loop:
  z = z^2 + c + p1 * 0.15 + p2 * (0.05, -0.02)
bailout:
  cabs(z) < 8
}

Lección 3

Eco de órbita

orbit-echoAbrir en el Editor FRM

Usa zPrev como memoria de retroalimentación y combina bien con la coloración orbitEcho para envolventes de órbita.

Enfoque: zPrev como el estado de órbita anterior. La retroalimentación agrega memoria sin introducir una segunda variable de estado administrada manualmente.

orbit-echo.frm

OrbitEcho {
init:
  z = pixel
loop:
  z = sqr(z) + zPrev * (0.30, -0.12) + pixel * (0.85, 0.0)
bailout:
  |z| < 48
}

El Editor FRM abre estos mismos ejemplos verificados por compilación mediante un ID estable. El código fuente de la fórmula permanece solo en la pestaña actual hasta que lo guardas en tu biblioteca de fórmulas en la nube y nunca se incorpora en la URL.

Errores y diagnósticos

La compilación se detiene en la etapa insegura más temprana y reporta mensajes orientados al código fuente. Una construcción rechazada nunca se reescribe en algo que solo se parece.

Errores léxicos

Los caracteres inesperados y los identificadores no compatibles se reportan con su línea y columna.

Errores de análisis

Las secciones, expresiones o bloques de flujo de control malformados se diagnostican antes de la validación semántica.

Errores de validación

Las variables desconocidas, las asignaciones inválidas, los desajustes de tipo y la semántica no compatible impiden la generación de código.

Mapeo del código fuente del shader

El GLSL generado conserva mapeos que pueden apuntar un fallo de compilación del shader de vuelta a la ubicación FRM de origen.

Al corregir un error, empieza con el primer mensaje reportado: los diagnósticos posteriores pueden ser consecuencias del mismo token faltante o de la misma expresión inválida.

Ejemplos, siguientes pasos y referencias

Ve el renderizador en contexto

Abre Explorar para comparar el comportamiento de las fórmulas integradas, la coloración, las transformaciones, la animación y los controles de exportación antes de escribir una fórmula personalizada.

Abrir Explorar

Usa el Editor FRM dedicado para compilar, previsualizar, importar y descargar fórmulas; inicia sesión para guardar una en tu biblioteca de fórmulas en la nube antes de enviarla a Explorar.

Referencias

El contexto histórico y los detalles de implementación se enlazan por separado para que la guía pueda distinguir el linaje de Fractint del contrato actual del compilador de FractalPark.