Ghost in the machine.

Este sábado tuve, de nuevo, un momento Andrómeda.

Como podéis intuir por mi post anterior llevo dedicando ciclos de máquina sueltos a resolver un problema llamémosle dificil. En mi caso se trata de representar una línea quebrada con una fomulación estrictamente lineal sin necesitar variables discretas y sin error.

Pues el sábado lo tuve, por un instante, representado en la pantalla. Mi línea quebrada y las bandas de ajuste de los puntos para los que probé reducidas a su mínima expresión sobre la misma.

Al principio no entendí el gráfico. Luego me dio miedo. ¿Algo tan bonito puede ser cierto?.

De mis lecturas en programación lineal lo más que puedo decir es que lo dudo muchísimo. Mucho no, muchísimo. A lo más puedes usar una parte del zigzag, pero no un zigzag completo, en tu programa.

Y sin embargo, corrí el programa varias veces, allí estaba mi preciosa.

Me llevó el fin de semana desenterrarla, con mimo, preparando otros programas de comprobación, buceando entre los informes que la máquina me proporcionaba.

Buscando la razón que todavía no tengo (y mis amigos dicen que hace tiempo que perdí).

Y sigo sin tenerla hasta el punto de rodearla con mis brazos y hacerla mía y llamarla por su nombre. Pero la he vislumbrado. Y le he puesto un nombre.

Ahora entiendo a Asimov y a su I, robot.

En pocas palabras, es la máquina. Es el programa. Es ello.

La formulación no es correcta, no hasta el punto de garantizar el resultado. No puede serlo (debe ir contra la termodinámica de las matemáticas supongo), su única virtud es no descartar nada.

Dígamos que obliga a la máquina, al programa, a elegir. A elegir para este mi caso particular, uno entre cientos, hacerlo como siempre y hacerme fracasar o hacer lo imposible y darme un susto visual.

¿Podéis creer que siempre hace lo imposible?, mi formulación le deja ser creativa hasta ese punto, se lo permite. Y, al menos para ese problema, es sistemática y lo hace siempre.

¿Y si tuviera un defecto "genético" mi máquina que le permitiera resolver contra natura estos complicados problemas?. Sé que sería poco científico, de locos más bien. Sería como la historia de QT.

Reconozco que esta no es una buena forma de programar linealmente, sin teoría garantista, contando con el fallo del eter. Hay tantas manos detrás de una implementación buena de los algoritmos de resolución de este tipo de formulaciones que todo puede ser supongo, especialmente en lo tocante a las condiciones iniciales del problema.

Pero la máquina, como la fortuna o la fama, sin embargo, se vuelve esquiva cuando pruebo otras cosas.

No es mi fórmula, es ella.

Fantasma en la máquina.

servido por scifish 2 comentarios compártelo

Rant on Celko.

Ok, this one is in English (for those the rant is about to notice if ever google upon this).

First of all I have to say I adore Joe Celko. I read with great admiration is columns on SQL and specially those applying hierarchies on top of it.

He even linked us to his book for most of the interesting answers we were looking for. And so I went searching for the book.

I even have to say I have been lucky to have it without having to pay for it because a friend of mine was so kind of sharing it with me.

Celko is smart on his book as he is on his columns. He is even smart enough to put content from his readers in his book, and I do not criticize him for this, in fact I think it is great to sum up the good ideas of several people in one information source catalyzed by someone who is brilliant enough to inspire such responses.

But, and I know we all live in a hurried world, there are things that cannot just be copy-pasted into a book without further testing. A book should not be a pink laced piece of sofware given on AS IS basis and be glad of finding dangling death with it. Perhaps not.

So I spent the whole weekend fighting with chapter 5 of his Joe Celko's trees and hierarchies in sql for smarties.

It is not only slight changes on notation from one line to the next. It is not that some of these changes might be important to go without noticing (like x and y for right and left).

Not about not being told which divisions to make (integer or floating point ones) at any point. That we could figure in the end.

This rant is not about Vadim Tropashko whose work is quoted.

If I were to blame somebody, and blaming anybody I am not, it should be Celko himself or his Elsevier editors. They did not just simply had the time to check.

It is just that some of the code snippets were simply plain wrong in my understanding. And even if we can hack around that it is not nice to see bad things being published by a big firm under a big name.

For instance let us take:

CREATE FUNCTION Child_Denominator

(IN num INTEGER, IN den INTEGER, IN child INTEGER)

RETURNS INTEGER

LANGUAGE SQL

DETERMINISTIC

RETURN den * (child * child);

And then it says:

For example, the third child of the node '1' (encoded as 3/2) is the node '1.3' (encoded as 19/16).

But if we do:

den = 2
child = 3

we would get according to the code mentioned: 2 * (3 * 3) = 18, not 16.

And I had to fight to come with an implementation at the end reversing the parent equations to get the child ones. Not difficult but unexpected.

And this type of thing goes on an on. On other fields, I could cite here papers like from Chib and Greenberg with some mistakes in. I even helped correcting some minor things in papers from people I know.

Of course I am not free of making mistakes of my own and I am grateful enough so as to reckon that without the work of all these wonderful people I would have not had such brilliant things in front of my eyes, the ideas are always theirs.

But guys, simply check what you write on your books. Part of my scarce weekend time was devoted to this and my projects delayed.

You are the big guns.

Thanks for being so.

End of rant.

servido por scifish sin comentarios compártelo

Lo que Sql ha hecho mal.

Sql es el lenguaje básico de consultas a bases de datos relacionales. Y no está mal para ser un lenguaje al que tildan de declarativo.

Hasta ahora bien, por cierto, ¿sabéis quién ganó el premio O'Reilly y Google al mejor software de fuente abierta en 2005?.

Pues fue ni más ni menos que sqlite, que, puestos a mencionar, hay que decir que tiene unos excelentes bindings a tcl, su (meta)lenguaje interpretado favorito.

No en vano, DRH (D. Richard Hipp) es un auténtico fiera del tcl como podréis comprobar si os asomáis a los foros y al wiki.

Quizás la cita más famosa del mundo del tcl sea la de que everything is a string (o si no es un string tiene una representación que sí lo es).

Y todo esto venía a colación porque una de muchísimas cosas interesantes que encontraréis en las páginas de sqlite es la siguiente declaración:

Manifest typing

Most SQL database engines use static typing. A datatype is associated with each column in a table and only values of that particular datatype are allowed to be stored in that column. SQLite relaxes this restriction by using manifest typing. In manifest typing, the datatype is a property of the value itself, not of the column in which the value is stored. SQLite thus allows the user to store any value of any datatype into any column regardless of the declared type of that column. (There are some exceptions to this rule: An INTEGER PRIMARY KEY column may only store integers. And SQLite attempts to coerce values into the declared datatype of the column when it can.)

The SQL language specification calls for static typing. So some people feel that the use of manifest typing is a bug in SQLite. But the authors of SQLite feel very strongly that this is a feature. The authors argue that static typing is a bug in the SQL specification that SQLite has fixed in a backwards compatible way.

Fijáos que en el segundo párrafo apunta a algo que Sql ha hecho mal en la opinión de los desarrolladores de sqlite.

Y definitivamente he tenido que darle la razón a DRH et al cuando me he encontrado que tenía que leer cosas en bloque como texto de un Excel y tener que desmenuzarle los tipitos a Oracle.

Me parece que todos las comprobaciones de tipos del mundo, esas que parece nos prometen la máxima seguridad en el manejo de nuestros datos, están en cualquier lenguaje para ser violadas. Ya sea con los apropiados casts o de formas más salvajes.

E indeleble al ser humano, creo que siempre encontraremos la manera de necesitar esas excepciones, como cuando en series temporales necesitamos marcar algún dato como desconocido.

Por eso, y por la inherente belleza del paradigma propuesto por tcl y apoyado por sqlite, creo que DRH tiene razón y definitivamente algo había mal pensado en Sql.

Que no está mal para ser declarativo.

servido por scifish 2 comentarios compártelo

Serendipia++.

Ayer me preguntaron por la creación de arrays en C++ con un número de elementos no conocido en tiempo de compilación.

Mi respuesta no pudo ser otra que la de manual:

Pero luego me aseguraron que si lo hacían así el código les cascaba en algún lugar, no muy bien identificado.

Me comentaron que la solución que habían encontrado finalmente era hacer:

Con mis conocimientos previos de C++ yo pensaba que esto no podía ser, no se podía usar la "fórmula" de creación de un array estático para hacer uno dinámico.

Pero luego, a base de empeñarme, encontré en la red esto, que parece que quiere decir que desde hace algún tiempo los compiladores g++ te posibilitan este truco siempre y cuando seas consciente de que tu array se comporta como una variable local dentro de un ámbito y que cuando el nombre de la variable sale del mismo la memoria es liberada. La reserva de memoria en este caso se hace contra el stack.

Me quedé sorprendido cuando, además, me dijeron que ellos no sabían que esto era una particularidad de g++ (y no sé de cuantos compiladores más).

Habían llegado a formar esta curiosa expresión que les funcionaba por analogía con los arrays de Pascal.

Serendipia++.

Ps.

Y ahora que levante la patita el que ya supiera esto, lo hubiera usado antes o tenga más información acerca de esta construcción, por ejemplo, si se sabe que pertenezca o no al estándar.

Yo de momento, aunque sea elegante y cómodo, y vaya contra el stack no lo utilizaría por motivos de posible no portabilidad.

¿Cuánto código de gnu utilizará esta característica?.

servido por scifish sin comentarios compártelo

Brainfuck.

En esta sección trataremos de levantar una torre más alta que la de Babel.

Y el primer ladrillo no podía ser otro que el de Brainfuck, el lenguaje más sencillo de programación que conozco y, a la vez, el más complejo.

La gracia de este lenguaje consiste en que solamente tiene 8 comandos, cada uno de ellos representados por un carácter. Los programas se desarrollan, ala Turing, sobre una cinta (finita) lineal de posiciones de memoria.

Gran pasatiempo (debería haber una sección de bf en los diarios en vez del ubicuo sudoku), tal vez sea de utilidad en dispositivos con procesadores ridículos.

Una curiosidad. Una rareza.

Por último, unos interesantes enlaces como son este y este en los que se nos proporcionan herramientas para procesar bf desde tcl.

Aceptamos barco, pero en Brainfuck.

servido por scifish 2 comentarios compártelo