bfbcompiler/doc/informe.md

5.7 KiB

Informe

Tabla de contenidos

Introducción

El presente informe detalla las decisiones tomadas por el grupo a la hora de resolver el Trabajo Práctico Especial de la materia 72.39 - Autómatas, Teoría de Lenguajes y Compiladores. El mismo consistió en diseñar y desarrollar un lenguaje y su compilador, construyendo sus dos componentes principales: el frontend, y el backend. Para esto se utilizaron el lenguaje C y Flex + Bison como analizadores léxico y sintáctico, respectivamente.

La idea original era "desarrolar un lenguaje que permita trabajar con funciones". El lenguaje permitirá declarar funciones, evaluarlas, conseguir el valor de la derivada de orden n en un punto, realizar integrales definidas, componer funciones, realizar operaciones aritméticas, entre otras.

Consideraciones adicionales

Las propiedades intrínsecas del lenguaje definido (detalladas en la siguiente sección) requieren especial atención al manejo de punto flotante durante las operaciones realizadas.

Lenguaje

El lenguaje originalmente preveía ofrecer las siguientes prestaciones:

  1. Se podrán crear una o varias funciones, las mismas pueden ser partidas o contar con un dominio acotado.
  2. Se podrán evaluar las funciones.
  3. Se podrán calcular las derivadas de cualquier orden en un punto.
  4. Se podrán calcular integrales definidas.
  5. Se podrán componer funciones.
  6. Las variables podrán ser de tipo function, string o double.
  7. Las variables podrán ser vectores de alguno de los tipos anteriores.
  8. Se proveerán operadores relacionales como <, >, =, !=, <= y >=.
  9. Se proveerán operaciones aritméticas básicas como +, -, * y /.
  10. Se proveerán operaciones lógicas básicas como AND, OR y NOT.
  11. Se proveerán estructuras de control básicas de tipo IF-THEN-ELSE, FOR y WHILE.

Sin embargo, a la hora de implementarlo, se debió prescindir de algunas de ellas a causa de las restricciones temporales del proyecto (a saber: definir variables de tipo string y definir vectores de algún tipo de dato).

En contraste, al resolver algunas de las dificultades detalladas en la sección Dificultades, se pudo añadir nueva funcionalidad gracias a las soluciones propuestas. Esta consiste en poder conseguir la función derivada de orden n (simbólica) de una f cualquiera, en lugar de limitarnos a evaluar la derivada en un punto. Es por esto también que se eliminó la opción de pasarle un error a la derivada (como se había planteado en la primera entrega).

Una limitación que consideramos importante destacar de nuestro lenguaje es que, a la hora de definir funciones partidas, en ningún momento se valida que los dominios definidos para dicha función sean excluyentes, retornando, en el caso de no lo sean, la suma de ambas partes de la funciión. A su vez, si se intenta evaluar una función en un punto no contenido en su dominio, la misma retornará 0. Esto se debe a que la forma en la que pudimos resolver la función partida fue multiplicar la función en cuestión por un booleano que indica si la variable de entrada pertenece o no al dominio indicado.

Restricciones del lenguaje

variables o funciones no pueden ser x solo se peuden escribir funciones que tengan a x como incognita las variables y funciones son globales no es tipado -> puedo pisar una funcion con una variable algo mas?

• Descripción de la gramática/sintaxis del lenguaje diseñado. • Descripción del desarrollo del proyecto y de las fases del compilador.

Desarrollo y fases

Dificultades

Al realizar el backend del trabajo surgieron dificultades relacionadas a los métodos numéricos usados, principalmente debido al error de la representacion de punto flotante. Es por esto que se optó por el uso de octave y la librería SymPy para el calculo de derivadas, que deriva la función de manera simbólica (sin utilizar métodos numéricos). Así mismo se utiliza la función quadv que utiliza el método de Simpson 3/8 compuesto para el cálculo de integrales.

Aquí surgieron distintas alternativas:

  1. Hacer un llamado a octave cada vez que necesitemos derivar o integrar.
  2. Generar código octave.
  3. Generar código C++ con octave embebido.

De aquí se descartó rápidamente la primera opción pues es muy ineficiente. Se estaría haciendo un fork por cada llamado a Derivate o Integrate lo cual resultaría muy costoso. Por otro lado, la tercera opción también se dejó de lado ya que si bien se embebía a C++ y se generaba un código objeto (siendo así la más eficiente de las tres) hubiera requerido investigar sobre C++ y la API de octave y no era el objetivo de este trabajo. Es por todo esto que se terminó optando por la segunda opción (pese a ser interpretado).

Futuras extensiones

Se pueden agregar arrays (que no impondría una gran dificultad) y distintas funcionalidades como por ejemplo taylor, limites, etc. Estas últimas tampoco serían díficiles pues octave las soporta de forma nativa (con el paquete de symbolics que es el que se usa actualmente).

Bibliografía