# HG changeset patch # User Robert Smith # Date 1297019933 21600 # Node ID 78222ee5341bf8ce9cff81c316bdf794b6c99cf1 # Parent 2483387038e127397f9e3225c3781df11132e61a files can be in utf8, which means \'a can be written as á diff --git a/apology.tex b/apology.tex --- a/apology.tex +++ b/apology.tex @@ -1,146 +1,146 @@ -\chapter{Apolog\'ia} +\chapter{Apología} -Quiero empezar ofreciendo unos pensamientos del manual en espa\~nol de +Quiero empezar ofreciendo unos pensamientos del manual en español de \TeX{}macs\footnote{\TeX{}macs es un editor principalmente de textos - matem\'aticos que usa \TeX para formatear el texto y una interfase - tipo GNU Emacs para la edici\'on. Naturalmente, \TeX{}macs tambi\'en - es software libre.} acerca del software libre y su relaci\'on con -las matem\'aticas: + matemáticos que usa \TeX para formatear el texto y una interfase + tipo GNU Emacs para la edición. Naturalmente, \TeX{}macs también + es software libre.} acerca del software libre y su relación con +las matemáticas: \begin{quote} -Como un matem\'atico, estoy profundamente convencido que s\'olo los -programas libres son aceptables desde un punto de vista cient\'ifico. +Como un matemático, estoy profundamente convencido que sólo los +programas libres son aceptables desde un punto de vista científico. Veo dos razones principales para esto: \begin{itemize} - \item Un resultado computado por un sistema ``matem\'atico'', cuyo - c\'odigo fuente no es p\'ublico, no puede ser aceptado como parte de - una prueba matem\'atica. + \item Un resultado computado por un sistema ``matemático'', cuyo + código fuente no es público, no puede ser aceptado como parte de + una prueba matemática. - \item As\'i como a un matem\'atico deber\'ia ser capaz de construir - sobre teoremas encima de otros teoremas, deber\'ia ser posible - modificar y liberar algoritmos de software matem\'atico libremente. + \item Así como a un matemático debería ser capaz de construir + sobre teoremas encima de otros teoremas, debería ser posible + modificar y liberar algoritmos de software matemático libremente. \end{itemize} -Sin embargo, es extra\~no, y una verg\"uenza, que los principales -programas matem\'aticos que est\'an siendo usados actualmente sean -privativos. La principal raz\'on para esto es que los matem\'aticos -muchas veces no consideran la programaci\'on como una actividad -cient\'ifica completa. Consecuentemente, el desarrollo de software -\'util es delegado a ``ingenieros'' y los programas resultantes son +Sin embargo, es extraño, y una vergüenza, que los principales +programas matemáticos que están siendo usados actualmente sean +privativos. La principal razón para esto es que los matemáticos +muchas veces no consideran la programación como una actividad +científica completa. Consecuentemente, el desarrollo de software +útil es delegado a ``ingenieros'' y los programas resultantes son usados como cajas negras. -Esta subdivision de la actividad cient\'ifica es muy artificial: con -frecuencia es muy importante desde un punto de vista cient\'ifico -saber que est\'a dentro de la caja negra. Rec\'iprocamente, un -profundo conocimiento cient\'ifico usualmente conduce a la -producci\'on de mejor software. Consecuentemente, pienso que los -cient\'ificos deber\'ian abogar por el desarrollo de software como una -actividad cient\'ifica total, comparable a la escritura de -art\'iculos. Entonces es claro tambi\'en que tal software deber\'ia +Esta subdivision de la actividad científica es muy artificial: con +frecuencia es muy importante desde un punto de vista científico +saber que está dentro de la caja negra. Recíprocamente, un +profundo conocimiento científico usualmente conduce a la +producción de mejor software. Consecuentemente, pienso que los +científicos deberían abogar por el desarrollo de software como una +actividad científica total, comparable a la escritura de +artículos. Entonces es claro también que tal software debería ser difundido en una forma que sea compatible con los requirimientos -de la ciencia: disponibilidad p\'ublica, reproductibilidad y +de la ciencia: disponibilidad pública, reproductibilidad y usabilidad libre. \end{quote} -Esta tesis de maestr\'ia es software libre, distribuida bajo los -t\'erminos de la GNU\footnote{GNU quiere decir ``GNU's not Unix'', un +Esta tesis de maestría es software libre, distribuida bajo los +términos de la GNU\footnote{GNU quiere decir ``GNU's not Unix'', un proyecto de mediados de los 80 del siglo pasado para crear un sistema operativo completamente libre y compatible con Unix. En la - actualidad, el proyecto GNU junto con el n\'ucleo Linux han + actualidad, el proyecto GNU junto con el núcleo Linux han alcanzado esta meta dando a luz el sistema operativo GNU/Linux.} GPL\footnote{General Public License, la licencia bajo la cual se distribuye casi todo el software GNU y aproximadamente el 60\%-70\% de la totalidad del software libre. Es una licencia tipo copyleft. Es decir, exige que cualquier obra derivada de otra obra cubierta - por la GPL tambi\'en sea GPL y por lo tanto libre.} versi\'on 3 u -opcionalmente cualquier versi\'on posterior. Adem\'as de la -justificaci\'on dada por Joris van der Hoeven, el autor de \TeX{}macs + por la GPL también sea GPL y por lo tanto libre.} versión 3 u +opcionalmente cualquier versión posterior. Además de la +justificación dada por Joris van der Hoeven, el autor de \TeX{}macs y el texto que acabo de citar, quisiera agregar algunas palabras. -En cierta forma, me veo legalmente obligado a liberar el c\'odigo de -mi tesis bajo la GPL, pero la obligaci\'on en realidad es m\'as bien -moral que legal. Explicar\'e por qu\'e. En la elaboraci\'on de esta +En cierta forma, me veo legalmente obligado a liberar el código de +mi tesis bajo la GPL, pero la obligación en realidad es más bien +moral que legal. Explicaré por qué. En la elaboración de esta tesis he usado \begin{itemize} \item \emph{GNU Emacs} como editor y entorno integral de desarrollo, \item \emph{gcc} como compilador, - \item \emph{kdbg} como interfase gr\'afica al depurador \emph{gdb}, + \item \emph{kdbg} como interfase gráfica al depurador \emph{gdb}, \item La \emph{GNU Scientific Library} como biblioteca para - operaciones num\'ericas b\'asicas, + operaciones numéricas básicas, \item La biblioteca \emph{Boost} para suplementar algunas funciones - b\'asicas de C++ que se espera sean parte del pr\'oximo est\'andar + básicas de C++ que se espera sean parte del próximo estándar de C++ disponible en 2009, - \item La biblioteca \emph{Qt} para generar una interfase gr\'afica + \item La biblioteca \emph{Qt} para generar una interfase gráfica para mi tesis, \item \emph{GNU Octave} para depurar brevemente algunas ideas - num\'ericas antes de programarlas en C++, + numéricas antes de programarlas en C++, \item \emph{Octaviz} para visualizar junto con Octave los resultados - de los c\'alculos que a su vez usa la biblioteca \emph{VTK} para - generar gr\'aficas mediante \emph{OpenGL}, + de los cálculos que a su vez usa la biblioteca \emph{VTK} para + generar gráficas mediante \emph{OpenGL}, \item \emph{te\TeX{}} y \emph{\TeX{}live} como distribuciones \TeX{} para formatear el texto de mi tesis, \end{itemize} -entre otros. Todo este software est\'a bajo la GPL excepto VTK y Boost -que est\'an bajo una licencia libre tipo BSD, no copyleft, y \TeX{} -que tambi\'en tiene su propia licencia, pero como he enlazado mi -c\'odigo con software GPL, las cl\'ausulas copyleft de la GPL me -obligan a que mi mismo c\'odigo tambi\'en se distribuya bajo los mismo -t\'erminos que la GPL. +entre otros. Todo este software está bajo la GPL excepto VTK y Boost +que están bajo una licencia libre tipo BSD, no copyleft, y \TeX{} +que también tiene su propia licencia, pero como he enlazado mi +código con software GPL, las cláusulas copyleft de la GPL me +obligan a que mi mismo código también se distribuya bajo los mismo +términos que la GPL. -Hay tambi\'en mucho m\'as software que aqu\'i no menciono -expl\'icitamente que he usado en la elaboraci\'on de esta tesis, pero +Hay también mucho más software que aquí no menciono +explícitamente que he usado en la elaboración de esta tesis, pero todo el software que he usado, desde los editores y compiladores hasta -el mismo n\'ucleo del sistema operativo en el que he trabajado es +el mismo núcleo del sistema operativo en el que he trabajado es software libre. No hay absolutamente nada oculto en lo que he hecho, -ni una sola l\'inea de c\'odigo en ning\'un nivel que no est\'e -disponible para el escrutinio de cualquier p\'ublico. Como van der +ni una sola línea de código en ningún nivel que no esté +disponible para el escrutinio de cualquier público. Como van der Hoeven, creo que esto es sumamente importante para el desarrollo de -software relevante para las matem\'aticas. +software relevante para las matemáticas. -Aunque mi obligaci\'on legal de liberar esta tesis bajo la GPL -es por haber enlazado mi c\'odigo con bibliotecas GPL como Qt y la -GSL, siento que mi obligaci\'on moral es mucho mayor por la deuda -k\'armica que le tengo a todos los autores de software libre que -generan software matem\'atico adecuado para muchos usos. Tengo la +Aunque mi obligación legal de liberar esta tesis bajo la GPL +es por haber enlazado mi código con bibliotecas GPL como Qt y la +GSL, siento que mi obligación moral es mucho mayor por la deuda +kármica que le tengo a todos los autores de software libre que +generan software matemático adecuado para muchos usos. Tengo la esperanza de que esta tesis demuestre que el software libre no es idealismo vacuo, sino una realidad factible y una alternativa al -desarrollo de software que esconde el c\'odigo fuente e intenta -limitar legalmente la cooperaci\'on entre matem\'aticos, cient\'ificos -e ingenieros. El software privativo es anticiencia, antimatem\'aticas -y anticooperaci\'on. No hay ninguna raz\'on para tolerarlo. +desarrollo de software que esconde el código fuente e intenta +limitar legalmente la cooperación entre matemáticos, científicos +e ingenieros. El software privativo es anticiencia, antimatemáticas +y anticooperación. No hay ninguna razón para tolerarlo. -Tampoco no hay ninguna raz\'on para suponer que software matem\'atico -como Mathematica, Maple o Mathematica s\'olo se puede desarrollar bajo +Tampoco no hay ninguna razón para suponer que software matemático +como Mathematica, Maple o Mathematica sólo se puede desarrollar bajo el modelo del software privativo. Tenemos muchos ejemplos de software -libre especializado como \emph{GAP} para teor\'ia de grupos. -\emph{Pari/GP} para teor\'ia de n\'umeros y \emph{Singular} para -\'algebra conmutativa y geometr\'ia algebraica que demuestran la -posibilidad de crear software matem\'atico de calidad, pero sobre -todo, libre. Tambi\'en en a\~nos m\'as recientes empezamos a ver -software para prop\'ositos generales como \emph{Maxima} o \emph{SAGE} -que quiz\'as alg\'un d\'ia logren suplantar la verg\"uenza que van der -Hoeven isin\'ua son las tres grandes M's. +libre especializado como \emph{GAP} para teoría de grupos. +\emph{Pari/GP} para teoría de números y \emph{Singular} para +álgebra conmutativa y geometría algebraica que demuestran la +posibilidad de crear software matemático de calidad, pero sobre +todo, libre. También en años más recientes empezamos a ver +software para propósitos generales como \emph{Maxima} o \emph{SAGE} +que quizás algún día logren suplantar la vergüenza que van der +Hoeven isinúa son las tres grandes M's. -Cierto es que en ingenier\'ia y an\'alisis num\'erico el software -libre tiene un poco menos de difusi\'on y no dudo que esto pueda ser -el resultado de que los ingenieros est\'an m\'as acostumbrados que los -matem\'aticos y cient\'ificos a trabajar en grandes corporaciones +Cierto es que en ingeniería y análisis numérico el software +libre tiene un poco menos de difusión y no dudo que esto pueda ser +el resultado de que los ingenieros están más acostumbrados que los +matemáticos y científicos a trabajar en grandes corporaciones donde las patentes, los secretos industriales y los acuerdos de no -divulgaci\'on son muy comunes. No obstante, no creo que el software -num\'erico o ingenieril se deba someter a ning\'un est\'andar -diferente al de cualquier otro software matem\'atico y que por lo -tanto, tambi\'en deber\'ia de ser libre. +divulgación son muy comunes. No obstante, no creo que el software +numérico o ingenieril se deba someter a ningún estándar +diferente al de cualquier otro software matemático y que por lo +tanto, también debería de ser libre. -As\'i pues, esta tesis es software libre, incluyendo el texto de la +Así pues, esta tesis es software libre, incluyendo el texto de la misma. Esto significa que hasta la misma fuente \LaTeX{} que estoy ahora -escribiendo estar\'a disponible para cualquiera en la direcci\'on +escribiendo estará disponible para cualquiera en la dirección web \url{http://www.cimat.mx/~jordi/thesis}, o en el mismo sitio donde -se encontr\'o el texto formateado, para ser analizada, distribuida y -de ser necesario, modificada. Los t\'erminos exactos bajo los cuales -esto es posible se dan en el ap\'endice. +se encontró el texto formateado, para ser analizada, distribuida y +de ser necesario, modificada. Los términos exactos bajo los cuales +esto es posible se dan en el apéndice. -Suficiente filosof\'ia. Demos ahora lugar a las matem\'aticas. +Suficiente filosofía. Demos ahora lugar a las matemáticas. %%% Local Variables: %%% mode: latex %%% TeX-master: "thesis" diff --git a/code.tex b/code.tex --- a/code.tex +++ b/code.tex @@ -1,247 +1,247 @@ \chapter{Kwantix} -A continuaci\'on detallaremos un poco de la estructura de -\emph{Kwantix}, una biblioteca de num\'erica para la resoluci\'on de +A continuación detallaremos un poco de la estructura de +\emph{Kwantix}, una biblioteca de numérica para la resolución de problemas de funciones base radiales basada en C++. -\section{Introducci\'on} +\section{Introducción} Hemos decidido programar casi todo en C++, por varios motivos. Primeramente, porque C++ es un lenguaje compilado muy cerca del -c\'odigo m\'aquina y por lo tanto muy eficiente. Segundo, porque hay -muchas bibliotecas de C y C++ que nos ayudaron en la elaboraci\'on de +código máquina y por lo tanto muy eficiente. Segundo, porque hay +muchas bibliotecas de C y C++ que nos ayudaron en la elaboración de nuestros algoritmos, entre las cuales destaca en particular la -biblioteca est\'andar de C++ (tambi\'en conocida a veces como la -\emph{Standard Template Library}, biblioteca est\'andar de -plantillas), de la cual hacemos amplio uso sin ning\'un escr\'upulo. -Tambi\'en usamos la \emph{GNU Scientific Library} (GSL), el +biblioteca estándar de C++ (también conocida a veces como la +\emph{Standard Template Library}, biblioteca estándar de +plantillas), de la cual hacemos amplio uso sin ningún escrúpulo. +También usamos la \emph{GNU Scientific Library} (GSL), el \emph{Visualisation Toolkit} (VTK) y algunas funciones de \emph{Boost} para mayor funcionalidad. -Una \'ultima raz\'on puede llegar a ser m\'as contenciosa, sobre todo -entre numeristas donde C++ no tiene una tradici\'on tan extensa como C -o Fortran. Estoy hablando sobre la programaci\'on orientada a objetos -y algunas otras cualidades m\'as avanzadas de C++, como excepciones, -plantillas, manejo autom\'atico de memoria, espacios nominales -\footnote{En ingl\'es, \emph{namespaces}.} y otras abstracciones que -en mi opini\'on facilitan el desarrollo de software. Justificaremos -brevemente la elecci\'on de haber usado algunas de estas cualidades de -C++, pues hemos visto que todas ellas han sido criticadas por -numeristas. +Una última razón puede llegar a ser más contenciosa, sobre todo +entre numeristas donde C++ no tiene una tradición tan extensa como C +o Fortran. Estoy hablando sobre la programación orientada a objetos +y algunas otras cualidades más avanzadas de C++, como excepciones, +plantillas, manejo automático de memoria, espacios +nominales\footnote{En inglés, \emph{namespaces}.} y otras +abstracciones que en mi opinión facilitan el desarrollo de +software. Justificaremos brevemente la elección de haber usado +algunas de estas cualidades de C++, pues hemos visto que todas ellas +han sido criticadas por numeristas. \begin{description} - \item[La bilblioteca est\'andar] La biblioteca est\'andar de C++ es + \item[La bilblioteca estándar] La biblioteca estándar de C++ es un software sumamente desarrollado y probado. Los algoritmos que se - encuentran ah\'i son el producto de muchos a\~nos de trabajo de - excelentes programadores de todo el mundo. La implementaci\'on - particular de GCC que hemos usado es una derivaci\'on de una - implementaci\'on libre iniciada por Hewlett Packard, SGI y otras - compa\~n\'ias de renombre. + encuentran ahí son el producto de muchos años de trabajo de + excelentes programadores de todo el mundo. La implementación + particular de GCC que hemos usado es una derivación de una + implementación libre iniciada por Hewlett Packard, SGI y otras + compañías de renombre. - \item[Excepciones] Las excepciones son un m\'etodo alterno para + \item[Excepciones] Las excepciones son un método alterno para manejar condiciones de error en el programa. La GSL tiene - predeterminadamente un manejo de error algo fr\'agil, donde - cualquier error por peque\~no que sea para en seco la ejecuci\'on - del programa, pero nos pareci\'o m\'as c\'omodo reemplazar este + predeterminadamente un manejo de error algo frágil, donde + cualquier error por pequeño que sea para en seco la ejecución + del programa, pero nos pareció más cómodo reemplazar este mecanismo por excepciones. Una ventaja en particular de las - excepciones es que permiten separar el c\'odigo principal del manejo + excepciones es que permiten separar el código principal del manejo de condiciones de error. \item[Espacios nominales] El uso de espacios nominales es una alternativa a ponerle prefijos a los nombres de todas las variables. En cierto sentido, simplemente son prefijos que opcionalmente se pueden hacer invisibles dentro de ciertos contextos - y no complican en nada la elaboraci\'on del c\'odigo. Hemos optado + y no complican en nada la elaboración del código. Hemos optado por poner todo bajo un solo espacio nominal, \vb{kwantix}. - \item[Plantillas\footnote{En ingl\'es, \emph{templates}}] Tengo - varias clases que est\'an en plantillas, lo cual resulta en que es - muy f\'acil cambiar la FBR de la definici\'on o inclusive agregar + \item[Plantillas\footnote{En inglés, \emph{templates}}] Tengo + varias clases que están en plantillas, lo cual resulta en que es + muy fácil cambiar la FBR de la definición o inclusive agregar otras FBRs que no hayamos ya definido. - \item[Apuntadores inteligentes] Para simplificar en el c\'odigo el + \item[Apuntadores inteligentes] Para simplificar en el código el manejo de memoria y preservar el polimorfismo propio de C++, hemos recurrido al apuntador inteligente \vb{shared_ptr} de la biblioteca Boost. Estos apuntadores implantan un conteo de referencias de tal suerte que cuando ya no haya referencias al objeto apuntado, - autom\'aticamente se reclama la memoria alojada con una reducci\'on - despreciable del desempe\~no del c\'odigo. Usamos exclusivamente en - el c\'odigo este tipo de apuntadores en vez de los apuntadores - b\'asicos de C. + automáticamente se reclama la memoria alojada con una reducción + despreciable del desempeño del código. Usamos exclusivamente en + el código este tipo de apuntadores en vez de los apuntadores + básicos de C. \end{description} -Estos detalles no son tan importantes sobre la implementaci\'on. La -elecci\'on de programar con orientaci\'on a objetos es m\'as peculiar -y requiere una justificaci\'on y explicaci\'on m\'as plena. +Estos detalles no son tan importantes sobre la implementación. La +elección de programar con orientación a objetos es más peculiar +y requiere una justificación y explicación más plena. -\section{Programaci\'on orientada a objetos} +\section{Programación orientada a objetos} -En c\'odigo num\'erico no es muy com\'un ver prognramaci\'on orientada -a objetos, pero sostengo que no hay raz\'on para ello. Las mismas -abstracciones que son \'utiles para otros motivos son \'utiles para -las matem\'aticos y el software num\'erico. Por ejemplo, en mi -c\'odigo hay clases para dominios, operadores diferenciales, +En código numérico no es muy común ver prognramación orientada +a objetos, pero sostengo que no hay razón para ello. Las mismas +abstracciones que son útiles para otros motivos son útiles para +las matemáticos y el software numérico. Por ejemplo, en mi +código hay clases para dominios, operadores diferenciales, funciones, interpoladores y funciones base radiales, con subclases y -relaciones entre s\'i que modelan las mismas relaciones que tienen los -objetos matem\'aticos correspondientes. Se dice que usar clases reduce -la eficiencia del c\'odigo final, pero yo he comprobado que el +relaciones entre sí que modelan las mismas relaciones que tienen los +objetos matemáticos correspondientes. Se dice que usar clases reduce +la eficiencia del código final, pero yo he comprobado que el desperdicio de recursos con clases es absolutamente despreciable si es que existe. En efecto, a menudo las optimizaciones que el mismo -compilador hace producen c\'odigo objeto que no difiere del mismo -c\'odigo sin clases. Por contraparte, el ahorro de tiempo que +compilador hace producen código objeto que no difiere del mismo +código sin clases. Por contraparte, el ahorro de tiempo que programar con clases ofrece durante el proceso de desarrollo y -depuraci\'on del software da contrapeso a cualquier deficiencia real o -imaginaria que pudiera haber en el desempe\~no del programa durante su -ejecuci\'on. +depuración del software da contrapeso a cualquier deficiencia real o +imaginaria que pudiera haber en el desempeño del programa durante su +ejecución. -Algo \'util de la programaci\'on orientada a objetos es que se puede -obtener un manejo casi autom\'atico de la memoria por medio de -constructores y destructores de C++, as\'i como el uso de apuntadores +Algo útil de la programación orientada a objetos es que se puede +obtener un manejo casi automático de la memoria por medio de +constructores y destructores de C++, así como el uso de apuntadores inteligentes. -Un punto muy importante de la programaci\'on orientada a objetos es la -reusabilidad del c\'odigo, que fue para nosotros una meta clave en la -elaboraci\'on de este software. Por medio de la orientaci\'on a -objetos, es posible crear interfases para el c\'odigo, mover c\'odigo -com\'un a clases madre e implantar detalles en clases derivadas. A -continuaci\'on describiremos c\'omo estructuramos las clases -del c\'odigo. +Un punto muy importante de la programación orientada a objetos es la +reusabilidad del código, que fue para nosotros una meta clave en la +elaboración de este software. Por medio de la orientación a +objetos, es posible crear interfases para el código, mover código +común a clases madre e implantar detalles en clases derivadas. A +continuación describiremos cómo estructuramos las clases +del código. -\section{Descripci\'on de clases} +\section{Descripción de clases} -A continuaci\'on detallaremos el contenido de cada cabecera y su -contenido. Esto es s\'olo un breve esquema de la estructura del -c\'odigo, los detalles completos se encuentran en la documentaci\'on -Doxygen del c\'odigo.\footnote{Por el momento se pueden encontrar en +A continuación detallaremos el contenido de cada cabecera y su +contenido. Esto es sólo un breve esquema de la estructura del +código, los detalles completos se encuentran en la documentación +Doxygen del código.\footnote{Por el momento se pueden encontrar en \url{http://bitbucket.org/jordigh/kwantix}. } Hemos optado por -separar el c\'odigo en varios m\'odulos cuyos detalles se pueden -consultar a fondo en su documentaci\'on de Doxygen. +separar el código en varios módulos cuyos detalles se pueden +consultar a fondo en su documentación de Doxygen. -\subsection{M\'odulo \vb{utils}} +\subsection{Módulo \vb{utils}} -En este m\'odulo colocamos varias funciones miscel\'aneas que no -encajaron en ning\'un otro y que consideramos demasiado rutinarias -para ahondar mucho en ellas, as\'i que remitimos al lector interesado -a la documentaci\'on completa de Doxygen. +En este módulo colocamos varias funciones misceláneas que no +encajaron en ningún otro y que consideramos demasiado rutinarias +para ahondar mucho en ellas, así que remitimos al lector interesado +a la documentación completa de Doxygen. -\subsection{M\'odulo \vb{linalg}} +\subsection{Módulo \vb{linalg}} En este espacio definimos algunas funciones envolventes para la GSL. La idea es generar una interfase sencilla de C++ para la GSL. La idea era imitar la manera de indicar elementos como en Fortran, tal -como lo hace GNU Octave y similares. As\'i, adem\'as de una sintaxis -sencilla, tambi\'en los \'indices comienzan desde $1$, no $0$ como en +como lo hace GNU Octave y similares. Así, además de una sintaxis +sencilla, también los índices comienzan desde $1$, no $0$ como en C++, y es posible rebanar matrices y vectores respetando ciertas -restricciones. Las clases m\'as importantes de este espacio nominal +restricciones. Las clases más importantes de este espacio nominal son \vb{kwantix::matrix} y \vb{kwnatix::vector}, por supuesto -compatibles entre s\'i. Todas las funciones aritm\'eticas b\'asicas de -\'algebra lineal que se puedan esperar se encuentran aqu\'i. Todas -est\'an implantadas por medio de BLAS\footnote{BLAS son las siglas en - ingl\'es de ``Subsistema B\'asico de \'Algebra Lineal'', que es una +compatibles entre sí. Todas las funciones aritméticas básicas de +álgebra lineal que se puedan esperar se encuentran aquí. Todas +están implantadas por medio de BLAS\footnote{BLAS son las siglas en + inglés de ``Subsistema Básico de Álgebra Lineal'', que es una interfase estandarizada que define funciones gaxpy y - saxpy\cite{Golub/Van-Loan:1996} para aritm\'etica de matrices y + saxpy\cite{Golub/Van-Loan:1996} para aritmética de matrices y vectores.} tal como lo implanta la GSL. -Para las funciones m\'as avanzadas que ya no caen dentro de BLAS, +Para las funciones más avanzadas que ya no caen dentro de BLAS, detallamos los siguientes funciones: \begin{description} - \item[\vb{kwantix::matrix::inv()}] Funci\'on miembro que regresa + \item[\vb{kwantix::matrix::inv()}] Función miembro que regresa la inversa de la matriz. El algoritmo que utiliza es una - factorizaci\'on $LU$ con pivoteo parcial. La factorizaci\'on $LU$ se + factorización $LU$ con pivoteo parcial. La factorización $LU$ se guarda internamente y se reusa tantas veces como sea posible. Es - decir, si ya se calcul\'o una vez la inversa, llamadas sucesivas a - \vb{inv()} usar\'an la misma factorizaci\'on. + decir, si ya se calculó una vez la inversa, llamadas sucesivas a + \vb{inv()} usarán la misma factorización. - Como argumento opcional, se puede dar un vector $b$ como par\'ametro - a esta funci\'on para resolver el sistema lineal $A\vec{x} = - \vec{b}$. Normalmente, \'esta es la \'unica forma de esta funci\'on + Como argumento opcional, se puede dar un vector $b$ como parámetro + a esta función para resolver el sistema lineal $A\vec{x} = + \vec{b}$. Normalmente, ésta es la única forma de esta función que se utiliza; nunca directamente la matriz inversa. - \item[\vb{kwantix::matrix:cond()}] El n\'umero $L^2$ de - condici\'on de la matriz, calculado por medio de una - descomposici\'on en valores singulares. Una vez calculada, esta - descomposici\'on tambi\'en se guarda hasta que la matriz sea - modificada. Hay que recordar al lector que una descomposici\'on en + \item[\vb{kwantix::matrix:cond()}] El número $L^2$ de + condición de la matriz, calculado por medio de una + descomposición en valores singulares. Una vez calculada, esta + descomposición también se guarda hasta que la matriz sea + modificada. Hay que recordar al lector que una descomposición en valores singulares puede ser costosa para una matriz grande. \end{description} Hay otra funciones menos importantes, como trazas y determinantes, -estos \'ultimos calculados tambi\'en a partir de la descomposici\'on +estos últimos calculados también a partir de la descomposición $LU$ de la matriz. -\subsection{M\'odulo \vb{error_handling}} +\subsection{Módulo \vb{error_handling}} De manera predeterminada, la GSL maneja errores de una manera muy -fr\'agil: cualquier error detiene completamente el programa y no -permite continuar su ejecuci\'on. Considerando que \'esta no es la +frágil: cualquier error detiene completamente el programa y no +permite continuar su ejecución. Considerando que ésta no es la mejor manera de manejar errores, hemos decidido mejor usar excepciones de C++. -Hay dos importantes filosof\'ias para el manejo de errores: o bien -pedimos permiso antes y verificamos que la condici\'on de error no se -puede cumplir, o bien pedimos perd\'on y arreglamos la condici\'on de -error despu\'es de ejecutar el c\'odigo que gener\'o dicho error. Las -excepciones de C++ piden perd\'on, el manejo de error m\'as +Hay dos importantes filosofías para el manejo de errores: o bien +pedimos permiso antes y verificamos que la condición de error no se +puede cumplir, o bien pedimos perdón y arreglamos la condición de +error después de ejecutar el código que generó dicho error. Las +excepciones de C++ piden perdón, el manejo de error más tradicional pide permiso. Creyendo fielmente que es mejor pedir -perd\'on que pedir permiso, hemos reemplazado la funci\'on de manejo -de error de la GSL con una funci\'on que arroja excepciones en -vez. Asimismo, cada condici\'on de error de la GSL la hemos -reemplazado por una estructura de C++ que nuestra funci\'on de manejo -de error arroja en caso de encontrar alg\'un error. +perdón que pedir permiso, hemos reemplazado la función de manejo +de error de la GSL con una función que arroja excepciones en +vez. Asimismo, cada condición de error de la GSL la hemos +reemplazado por una estructura de C++ que nuestra función de manejo +de error arroja en caso de encontrar algún error. -Algunos comentarios adicionales sobre c\'omo funcionan las -excepciones, ya que consideramos que es un m\'etodo de manejo de error -no del todo com\'un entre los numeristas. Cuando alguna funci\'on -cualquier arroja una excepci\'on, esto tiene el efecto de desenrollar -la pila de llamada de funciones hasta que en alg\'un nivel de la pila -alguna funci\'on decida atrapar la excepci\'on. La funci\'on que -atrape la excepci\'on debe de tener alg\'un mecanismo para lidiar con -la misma. La pila se ve desenrollando hasta que alguna funci\'on logre -lidiar con la funci\'on. Si en ning\'un nivel ocurre esto, el programa -aborta. De esta manera, al usar nuestro c\'odigo como biblioteca base -para cualquier otra aplicaci\'on, se puede usar un manejo flexible de +Algunos comentarios adicionales sobre cómo funcionan las +excepciones, ya que consideramos que es un método de manejo de error +no del todo común entre los numeristas. Cuando alguna función +cualquier arroja una excepción, esto tiene el efecto de desenrollar +la pila de llamada de funciones hasta que en algún nivel de la pila +alguna función decida atrapar la excepción. La función que +atrape la excepción debe de tener algún mecanismo para lidiar con +la misma. La pila se ve desenrollando hasta que alguna función logre +lidiar con la función. Si en ningún nivel ocurre esto, el programa +aborta. De esta manera, al usar nuestro código como biblioteca base +para cualquier otra aplicación, se puede usar un manejo flexible de error por medio de excepciones. -\subsection{M\'odulo \vb{RBF}} +\subsection{Módulo \vb{RBF}} En este espacio, mejor descrito por la Figura \ref{fig:rbf-tree}, consiste -en un \'arbol de clases FBR. Contiene las clases puramente abstractas +en un árbol de clases FBR. Contiene las clases puramente abstractas \vb{radial_basis_function} y dos clases derivadas. La base abstracta -especifica que una funci\'on radial debe de tener la posibilidad de -evaluarse en un punto (de hecho, en un \vb{kwantix::point}), as\'i como -poder evaluar la primera y segunda derivada en cualquier direcci\'on +especifica que una función radial debe de tener la posibilidad de +evaluarse en un punto (de hecho, en un \vb{kwantix::point}), así como +poder evaluar la primera y segunda derivada en cualquier dirección coordenada. \begin{figure}[!ht] \begin{center} \includegraphics[width=0.9\textwidth]{rbf} \end{center} - \caption{Diagrama de las clases del m\'odulo \vb{RBF}} + \caption{Diagrama de las clases del módulo \vb{RBF}} \label{fig:rbf-tree} \end{figure} -Las hojas de este \'arbol son las clases concretas particulares. Entre +Las hojas de este árbol son las clases concretas particulares. Entre la clase abstracta base y las concretas en las hojas hay un par de clases intermedias para distinguir las FBRs $C^\infty$ de las -seccionalmente suaves. Aqu\'i podr\'ia caber otra clase abstracta +seccionalmente suaves. Aquí podría caber otra clase abstracta intermedia para las funciones de soporte compacto, pero por el momento no lo hemos implantado. -Obs\'ervese que las funciones base radiales todas descienden de -\vb{kwantix::realfunc}, una clase que detallaremos m\'as adelante. En -efecto, puesto que una funci\'on radial es una funci\'on $\varphi : +Obsérvese que las funciones base radiales todas descienden de +\vb{kwantix::realfunc}, una clase que detallaremos más adelante. En +efecto, puesto que una función radial es una función $\varphi : \RR^n \to \RR$, la herencia es razonable. Muchas clases que se -detallar\'an en el m\'odulo \vb{BVP} usan las clases de \vb{RBF} -como par\'ametros de plantillas. Consecuentemente, es f\'acil escoger -una FBR distinta para los varios m\'etodos definiendo y pasando -diferentes miembros del espacio \vb{RBF} como par\'ametros de +detallarán en el módulo \vb{BVP} usan las clases de \vb{RBF} +como parámetros de plantillas. Consecuentemente, es fácil escoger +una FBR distinta para los varios métodos definiendo y pasando +diferentes miembros del espacio \vb{RBF} como parámetros de plantillas. -\subsection{M\'odulo \vb{BVP}} +\subsection{Módulo \vb{BVP}} -En este espacio se encuentran la mayor\'ia de las clases y -funcionalidad de nuestro c\'odigo. Recordando el PVF \eqref{eq:thebvp}, +En este espacio se encuentran la mayoría de las clases y +funcionalidad de nuestro código. Recordando el PVF \eqref{eq:thebvp}, observamos que tiene varios componentes: \begin{itemize} \item Un operador diferencial interior $\mathcal{L}$. @@ -250,25 +250,25 @@ \item Funciones $f$ y $g$ en la parte derecha de las ecuaciones. \end{itemize} -Cada uno de estos componentes lo modelamos en el c\'odigo de la +Cada uno de estos componentes lo modelamos en el código de la siguiente manera: \begin{description} - \item[La jerarqu\'ia \vb{diff_op}] Aqu\'i tenemos varios operadores + \item[La jerarquía \vb{diff_op}] Aquí tenemos varios operadores diferenciales. Un operador diferencial puede ser interno o fronterizo. Entre los operadores diferenciales internos distinguimos - los linales y de orden dos, y usamos un toque de herencia m\'ultiple + los linales y de orden dos, y usamos un toque de herencia múltiple en caso de que a futuro deseemos extender la funcionalidad de - nuestro c\'odigo a operadores no lineales o de orden superior. Las - hojas de este \'arbol hasta abajo son clases concretas y todas las - hojas intermedias desde le ra\'iz son clases abstractas. N\'otese - que hemos definido tambi\'en un operador fronterizo para el m\'etodo - de descomposici\'on de dominios, del cual hablaremos m\'as adelante. + nuestro código a operadores no lineales o de orden superior. Las + hojas de este árbol hasta abajo son clases concretas y todas las + hojas intermedias desde le raíz son clases abstractas. Nótese + que hemos definido también un operador fronterizo para el método + de descomposición de dominios, del cual hablaremos más adelante. \begin{figure}[!ht] \begin{center} \includegraphics[width=0.9\textwidth]{diff_op} \end{center} - \caption{La jerarqu\'ia de operadores diferenciales} + \caption{La jerarquía de operadores diferenciales} \label{fig:diff_op_tree} \end{figure} @@ -283,17 +283,17 @@ objetos \vb{set} y el tercero por medio de \vb{map}\footnote{Las clases \vb{set} y \vb{map} - est\'an dentro del espacio nominal est\'andar \vb{std}, as\'i que - hemos omitido la designaci\'on de alcance \vb{std::}. Un \vb{map} - representa un conjunto ordenado de \'indices (en este caso, - \vb{point}) que apuntan a ciertos valores (aqu\'i, + están dentro del espacio nominal estándar \vb{std}, así que + hemos omitido la designación de alcance \vb{std::}. Un \vb{map} + representa un conjunto ordenado de índices (en este caso, + \vb{point}) que apuntan a ciertos valores (aquí, \vb{kwantix::vector}) y frecuentemente se implanta mediante - \'arboles binarios rojinegros, mientras que un \vb{set} es un - \vb{map} donde los \'indices no apuntan a nada, es decir, es un + árboles binarios rojinegros, mientras que un \vb{set} es un + \vb{map} donde los índices no apuntan a nada, es decir, es un simple conjunto ordendado. La clase \vb{point} es un \vb{typedef} de \vb{kwantix::vector}.}. Esta clase provee varias funciones para manipular la entrada y salida de los puntos que definen a un - dominio as\'i como verificar la validez de los mismos. + dominio así como verificar la validez de los mismos. \item[La clase \vb{realfunc}] Consideramos conveniente definir una clase general para modelar funciones $f : \RR^n \to \RR$ con una @@ -301,79 +301,79 @@ de \vb{realfunc} provee funciones virtuales derivadas parciales de primer orden aproximadas con diferencias centradas pero clases derivadas pueden sobreescribir estas aproximadas con derivadas - exactas calculadas previamente simb\'olicamente. La interfase de una - \vb{realfunc} tambi\'en especifica derivadas de segundo orden, - pero por el momento no las aproxima num\'ericamente. + exactas calculadas previamente simbólicamente. La interfase de una + \vb{realfunc} también especifica derivadas de segundo orden, + pero por el momento no las aproxima numéricamente. - Esta clase es madre de varias otras clases. Adem\'as de ser madre - todos los miembros del espacio nominal \vb{rbf}, tambi\'en es + Esta clase es madre de varias otras clases. Además de ser madre + todos los miembros del espacio nominal \vb{rbf}, también es madre de las interpolantes \vb{interpolator} y \vb{schwarz_ddm} - que veremos m\'as adelante. Tambi\'en tiene envolturas para el tipo + que veremos más adelante. También tiene envolturas para el tipo de apuntadores a funciones que la GSL requiere mediante la clase \vb{gsl_function_wrapper}. \end{description} Esta familia de clases definen los ingredientes necesarios para poder -especificar en su totalidad un PVF. Formalizamos esta especificaci\'on -con la clase \vb{kwantix::BVP} que no es mucho m\'as que una estructura -con los componentes del PVF \eqref{eq:thebvp}. Definimos tambi\'en una +especificar en su totalidad un PVF. Formalizamos esta especificación +con la clase \vb{kwantix::BVP} que no es mucho más que una estructura +con los componentes del PVF \eqref{eq:thebvp}. Definimos también una clase derivada que ha resultado suficiente para nosotros y que modela un PVF lineal de orden $2$, \vb{linear_BVP2}. \section{La clase \vb{interpolator}} -Todas las clases descritas arriba son tan s\'olo el esquema general +Todas las clases descritas arriba son tan sólo el esquema general bajo el cual estamos trabajando, definen los ingredientes del problema. Pues bien, ahora nos enfocaremos en la primera clase que en -efecto implanta el algoritmo de soluci\'on del PVF \eqref{eq:thebvp}. +efecto implanta el algoritmo de solución del PVF \eqref{eq:thebvp}. Dicha clase es \vb{interpolator}, donde \vb{RBF} es un -par\'ametro de plantilla para representar el tipo de FBR que se -usar\'a para resolver. La clase \vb{interpolator} supone modelar +parámetro de plantilla para representar el tipo de FBR que se +usará para resolver. La clase \vb{interpolator} supone modelar el ansatz o interpolador $\tilde{u}$ definido en \eqref{eq:theinterp}. -Ahora bien, nuestra intenci\'on tambi\'en es amarrar \'intimamente -este interpolador a un PVF, as\'i que los primeros ingredientes de +Ahora bien, nuestra intención también es amarrar íntimamente +este interpolador a un PVF, así que los primeros ingredientes de \vb{interpolator} son \begin{itemize} \item los coeficientes $u_p$ de $\tilde{u}$, \item las FBRs $\phi_p$ y \item un PVF. \end{itemize} -Observamos que el interpolador requiere tambi\'en conocer los puntos -del dominio en los cuales est\'a interpolando, pero esta informaci\'on -ya est\'a contenida tanto en las FBRs como en el PVF. +Observamos que el interpolador requiere también conocer los puntos +del dominio en los cuales está interpolando, pero esta información +ya está contenida tanto en las FBRs como en el PVF. Antes de proseguir, algunos comentario. Propiamente, aunque -\eqref{eq:theinterp} es el mismo objeto matem\'atico, deber\'iamos +\eqref{eq:theinterp} es el mismo objeto matemático, deberíamos llamarlo \emph{ansatz} cuando se utiliza para resolver un PVF y llamarlo \emph{interpolador} cuando resuelve el problema de -interpolaci\'on. Claro que el problema de interpolaci\'on se puede +interpolación. Claro que el problema de interpolación se puede tratar sin ninguna dificultad adicional como un PVF trivial donde el operador interior y frontera ambos son el operador identidad, y en -efecto, justamente as\'i lo hemos tratado en nuestro c\'odigo. En lo +efecto, justamente así lo hemos tratado en nuestro código. En lo que sigue, nos seguiremos refiriendo al $\tilde{u}$ de \eqref{eq:theinterp} como ``interpolador'' acordando que el mismo objeto -lo podemos usar tambi\'en para resolver un PVF. +lo podemos usar también para resolver un PVF. -Usamos un \'unico m\'etodo de soluci\'on de colocaci\'on asim\'etrica -tal como est\'a descrito en la secci\'on \ref{sec:unsymcolloc}. Esto -requiere invertir la matriz de Gram que por motivos de optimizaci\'on -que ser\'an aparentes en breve, nuestro interpolador almacena en la +Usamos un único método de solución de colocación asimétrica +tal como está descrito en la sección \ref{sec:unsymcolloc}. Esto +requiere invertir la matriz de Gram que por motivos de optimización +que serán aparentes en breve, nuestro interpolador almacena en la memoria. Nuestro interpolador resuelve los problemas de -interpolaci\'on y de valores en la frontera de la misma manera. De -cualquier forma, hay ciertas diferencias en la implementaci\'on de la -soluci\'on del PVF \eqref{eq:thebvp}. +interpolación y de valores en la frontera de la misma manera. De +cualquier forma, hay ciertas diferencias en la implementación de la +solución del PVF \eqref{eq:thebvp}. \subsection{Constructores} Los constructores de la clase \vb{interpolator} preparan al -interpolador al resolver el problema de interpolaci\'on al efectuar -una factorizaci\'on $LU$ de la matriz de Gram. +interpolador al resolver el problema de interpolación al efectuar +una factorización $LU$ de la matriz de Gram. \begin{description} \item[\vb{interpolator (shared_ptr< linear_BVP2 > bvp)}] Con este constructor resolvemos el PVF lineal de segundo orden definido por el apuntador \vb{bvp}. - \item[\vb{interpolator (const map< point, double > &Xi)}] Aqu\'i en + \item[\vb{interpolator (const map< point, double > &Xi)}] Aquí en vez, dado un mapeo $\Xi : \RR^n \to \RR$ de puntos a valores (\vb{Xi}), inicializa un interpolador para este mapeo. \end{description} diff --git a/preamble.tex b/preamble.tex --- a/preamble.tex +++ b/preamble.tex @@ -1,4 +1,5 @@ \documentclass[10pt,oneside,a4paper]{book} +\usepackage[utf8x]{inputenc} %TeX files can be UTF-8 \usepackage{lmodern} %Latin Modern, updated glyphs, better monospace, etc. \usepackage{amsmath, amsthm, amssymb} \usepackage{fancybox, url, graphicx} @@ -16,13 +17,13 @@ \newtheorem*{lema}{Lema} \newtheorem{cor}{Corolario} \newtheorem*{eg}{Ejemplo} -\newtheorem*{prop}{Proposici\'on} +\newtheorem*{prop}{Proposición} \newtheorem{ej}{Ejercicio} \theoremstyle{definition} -\newtheorem*{defn}{Definici\'on} -\newtheorem*{notn}{Notaci\'on} -\newtheorem*{obs}{Observaci\'on} +\newtheorem*{defn}{Definición} +\newtheorem*{notn}{Notación} +\newtheorem*{obs}{Observación} \theoremstyle{remark} \newtheorem*{com}{Comentario} @@ -57,12 +58,12 @@ \newcommand{\cd}{\lstinline[basicstyle=\ttfamily,language=C++]} -\author{Jordi Guti\'errez Hermoso \\ Asesores de tesis: Miguel \'Angel - Moreles V\'asquez \\ y Pedro Gonz\'alez Casanova} +\author{Jordi Gutiérrez Hermoso \\ Asesores de tesis: Miguel Ángel + Moreles Vásquez \\ y Pedro González Casanova} \date{\today} -\title{Funciones base radiales y ecuaciones diferenciales parciales} +\title{Funciones base radiales\\y\\ecuaciones diferenciales parciales} %%% Local Variables: diff --git a/rbf-ddm.tex b/rbf-ddm.tex --- a/rbf-ddm.tex +++ b/rbf-ddm.tex @@ -1,16 +1,16 @@ -\chapter[FBR y MDD]{Funciones base radiales y descomposici\'on de dominios} -\section{Introducci\'on} +\chapter[FBR y MDD]{Funciones base radiales y descomposición de dominios} +\section{Introducción} \label{sec:unsymcolloc} -Empecemos con una definici\'on clave. +Empecemos con una definición clave. \begin{defn} \label{def:rbf} - Una funci\'on $\phi : \RR^n \to \RR$ es \emph{radial} si existe - alg\'un punto $c \in \RR^n$ y una funci\'on $\tilde{\phi} : \RR \to + Una función $\phi : \RR^n \to \RR$ es \emph{radial} si existe + algún punto $c \in \RR^n$ y una función $\tilde{\phi} : \RR \to \RR$ tal que $\phi(x) = \tilde{\phi}(\abs{x - c})$. \end{defn} -Brevemente, una funci\'on radial depende solamente de la distancia -desde alg\'un punto en $\RR^n$. Pronto daremos ejemplos relevantes de -funciones radiales. Antes, consid\'erese de manera general el problema +Brevemente, una función radial depende solamente de la distancia +desde algún punto en $\RR^n$. Pronto daremos ejemplos relevantes de +funciones radiales. Antes, considérese de manera general el problema de valores en la frontera (PVF) \begin{equation} \label{eq:thebvp} @@ -22,21 +22,21 @@ donde $\mathcal{L}$ y $\mathcal{B}$ son operadores diferenciales lineales, $\Omega$ es un dominio abierto y conexo como todos los dominios considerados en esta obra, y $f$ y $g$ son funciones reales -en $\RR^n$ sin ninguna suposici\'on adicional. El operador +en $\RR^n$ sin ninguna suposición adicional. El operador $\mathcal{B}$ puede representar condiciones de Dirichlet, Neumann, -Robin o alguna mezcla de \'estas en diferentes puntos de la frontera. +Robin o alguna mezcla de éstas en diferentes puntos de la frontera. La idea de \emph{funciones base radiales} (FBR) es en principio muy -sencilla. Escogemos algunos puntos $\Xi_I \subset \Omega$ y $\Xi_F -\subset \del\Omega$. En el m\'etodo de colocaci\'on asim\'etrico, el -\'unico que consideramos en esta obra y el m\'as sencillo de plantear, -centramos una FBR $\phi_p$ en cada $p \in \Xi := \Xi_I \cup \Xi_F$ y -proponemos la aproximaci\'on +sencilla. Escogemos algunos puntos $\Xi:=\Xi_i\cup\Xi_F$ donde $\Xi_I +\subset \Omega$ y $\Xi_F \subset \del\Omega$. En el método de +colocación asimétrico, el único que consideramos en esta obra y el más +sencillo de plantear, centramos una FBR $\phi_p$ en cada $p \in \Xi$ y +proponemos la aproximación \begin{equation} \label{eq:theinterp} \tilde{u} := \sum_{p \in \Xi} u_p \phi_p, \end{equation} -donde las $u_p$ son constantes. Al introducir la aproximaci\'on +donde las $u_p$ son constantes. Al introducir la aproximación propuesta \eqref{eq:theinterp} en el PVF \eqref{eq:thebvp} y evaluar en cada punto de $\Xi$, obtenemos el sistema lineal \begin{align*} @@ -64,71 +64,71 @@ g(\Xi_F) \end{bmatrix}, \] -donde los sub\'indices $I$ y $F$ indican FBRs, coeficientes, o puntos +donde los subíndices $I$ y $F$ indican FBRs, coeficientes, o puntos del interior y de la frontera respectivamente. Abreviemos este sistema lineal por medio de $M\vec{u} = \vec{f}$. Entonces basta invertir $M$ -para obtener una soluci\'on a \eqref{eq:thebvp}. Observemos que si +para obtener una solución a \eqref{eq:thebvp}. Observemos que si tomamos el PVF trivial con $\mathcal{L}$ igual al operador identidad $I$ y usamos $\Xi_F = \emptyset$, entonces obtenemos un simple -problema de interpolaci\'on. Las propiedades de las FBRs para -problemas de interpolaci\'on han sido m\'as estudiadas como base -te\'orica para su uso en resolver PVFs y ecuaciones diferenciales +problema de interpolación. Las propiedades de las FBRs para +problemas de interpolación han sido más estudiadas como base +teórica para su uso en resolver PVFs y ecuaciones diferenciales parciales. -Obs\'ervese que este m\'etodo recuerda vagamente al m\'etodo de +Obsérvese que este método recuerda vagamente al método de elementos finitos (MEF), salvo que no hay uso de ninguna malla. En vez -de malla, s\'olo se escogen algunos puntos de colocaci\'on que no -tienen por qu\'e tener ninguna estructura en particular. Tambi\'en -n\'otese que la dimensionalidad de $\Omega$ es irrelevante en toda -esta formulaci\'on. Como evaluar una FBR no se vuelve m\'as complicado -conforme el n\'umero de dimensiones de $\Omega$ aumenta, no hace falta -ninguna modificaci\'on al m\'etodo general en dimensiones superiores. +de malla, sólo se escogen algunos puntos de colocación que no +tienen por qué tener ninguna estructura en particular. También +nótese que la dimensionalidad de $\Omega$ es irrelevante en toda +esta formulación. Como evaluar una FBR no se vuelve más complicado +conforme el número de dimensiones de $\Omega$ aumenta, no hace falta +ninguna modificación al método general en dimensiones superiores. -Por supuesto que el m\'etodo no es panacea, como no lo es ning\'un +Por supuesto que el método no es panacea, como no lo es ningún otro. A cambio de ahorrarnos los mallados complicados del MEF, nos vemos obligados a invertir una matriz $M$ que a priori no tiene por -qu\'e tener ninguna propiedad agradable; en efecto, hemos observado ya -que $M$ tiende a ser una matriz grande, llena, no sim\'etrica y mal +qué tener ninguna propiedad agradable; en efecto, hemos observado ya +que $M$ tiende a ser una matriz grande, llena, no simétrica y mal condicionada, la pesadilla de todo numerista. -Veremos c\'omo se puede aliviar un poco este problema usando -descomposici\'on de dominios. La idea es sencilla, y nos concentramos -solamente en el llamado \emph{m\'etodo aditivo de Schwarz}. -Brevemente, la idea en los m\'etodos de Schwarz (hay tambi\'en uno +Veremos cómo se puede aliviar un poco este problema usando +descomposición de dominios. La idea es sencilla, y nos concentramos +solamente en el llamado \emph{método aditivo de Schwarz}. +Brevemente, la idea en los métodos de Schwarz (hay también uno llamado \emph{multiplicativo} que es muy similar), es descomponer el dominio $\Omega = \bigcup_{i=1}^k \Omega_i$ donde cada $\Omega_i$ se traslapa con otra $\Omega_j$ y resolver el PVF resultante en cada $\Omega_i$, donde en cada frontera artificial interior (es decir, donde $\del \Omega_i \cap \del \Omega = \emptyset$) imponemos -condiciones de Dirichlet iterativamente seg\'un donde dicha frontera +condiciones de Dirichlet iterativamente según donde dicha frontera artificial se traslape con otro subdominio $\Omega_j$. Se mide entonces la convergencia con respecto a estas fronteras artificiales. -Los m\'etodos de descomposici\'on de dominios (MDD) ofrecen entonces -matrices m\'as peque\~nas y ligeramente mejor condicionadas, aunque -habr\'a m\'as matrices que invertir. Con suficientes subdominios -escogidos juiciosamente, est\'a claro que el trueque entre una matriz -grande y mal condicionada y muchas peque\~nas pero ligeramente mejor -condicionadas es conveniente. Veremos tambi\'en que las iteraciones -sobre las fronteras artificiales pueden ser muy r\'apidas sin +Los métodos de descomposición de dominios (MDD) ofrecen entonces +matrices más pequeñas y ligeramente mejor condicionadas, aunque +habrá más matrices que invertir. Con suficientes subdominios +escogidos juiciosamente, está claro que el trueque entre una matriz +grande y mal condicionada y muchas pequeñas pero ligeramente mejor +condicionadas es conveniente. Veremos también que las iteraciones +sobre las fronteras artificiales pueden ser muy rápidas sin necesidad de hacer demasiadas factorizaciones $LU$ de las matrices. \section{Funciones base radiales} -Para efectos de esta obra, nos enfocaremos en s\'olo seis tipos de -funciones base radiales. Sea $\tilde{\phi}$ seg\'un la definici\'on +Para efectos de esta obra, nos enfocaremos en sólo seis tipos de +funciones base radiales. Sea $\tilde{\phi}$ según la definición \ref{def:rbf}. En el cuadro \ref{tab:the-rbfs} vemos algunas posibilidades para $\tilde{\phi}(r)$ que dan lugar a FBRs distintas. \begin{table}[ht] \begin{center} \ovalbox{ \begin{tabular}{r|l} - \text{Polinomial seccional o c\'onica} & $r^n,$ \text{$n$ impar} \\ + \text{Polinomial seccional o cónica} & $r^n,$ \text{$n$ impar} \\ \text{Trazador (\emph{spline}) de capa delgada} & $r^n \log r,$ \text{$n$ par}\\ - \text{Multicu\'adrica} & $\sqrt{1 + (\epsilon r)^2}$ \\ - \text{Multicu\'adrica inversa} & $(1 + (\epsilon r)^2)^{-1/2}$ \\ - \text{Cuadr\'atica inversa} & $(1 + (\epsilon r)^2)^{-1}$ \\ + \text{Multicuádrica} & $\sqrt{1 + (\epsilon r)^2}$ \\ + \text{Multicuádrica inversa} & $(1 + (\epsilon r)^2)^{-1/2}$ \\ + \text{Cuadrática inversa} & $(1 + (\epsilon r)^2)^{-1}$ \\ \text{Gaussiana} & $e^{-\epsilon r^2}$ \end{tabular} } @@ -137,8 +137,8 @@ \label{tab:the-rbfs} \end{table} -De estas FBRs, las \'ultimas cuatro con par\'ametro $\epsilon$ son -$C^\infty$ y las primeras dos con par\'ametro $n$ tan s\'olo son +De estas FBRs, las últimas cuatro con parámetro $\epsilon$ son +$C^\infty$ y las primeras dos con parámetro $n$ tan sólo son seccionalmente suaves \cite{Larsson/Fornberg:2003}.