Por ejemplo, es muy útil para codificar cadenas de caracteres y de esta forma poder realizar búsquedas mucho más rápidamente, o como simple sistema de indexación de datos.
También se utilizan en criptografía y como sistemas de comprobación de integridad de los datos, algunos ejemplos de este tipo de funciones de hash son la CRC, MD5, MD4, Tiger, RMD, SHA, etc.

El principal problema surge cuando es imprescindible que cada secuencia de datos tenga un identificador hash único, si dos o más secuencias tienen el mismo hash se produce una colisión de hash. En este ejemplo las cadenas “Jirafa” y “Tigre” tienen el mismo hash, 02.

Existen infinitas formas de hacer una función de hash y puedes crear la tuya propia fácilmente, el problema es conseguir que la función genere una buena distribución de los hashes y, a ser posible, que produzca las menores colisiones posibles incluso con secuencias de datos muy cortas y similares. Por eso es recomendable utilizar alguna de las muchas funciones de hash que se utilizan desde hace tiempo y están muy probadas.
Aqui dejo un video del MIT de introducción a las técnicas de hashing:

Sin mas historias vamos con algunas de las funciones de hashing de 32 bits más básicas y utilizadas:

Esta surgió de una idea presentada al comité del IEEE POSIX P1003.2 por Glenn Fowler y Phong Vo en 1991, luego Landon Curt Noll la mejoró.
Funciona muy bien, es rápida y produce pocas colisiones. Realiza una buena dispersión de los hashes y va muy bien para hacer hashing en cadenas casi idénticas como URLs, URIs, IPs, nombres de archivo, etc.

Esta es del profesor Daniel J. Bernstein, es una de las más eficientes:

Esta es de Donald E. Knuth, está en el volumen III de su libro “The Art of Computer Programming”:

Esta está basada en el trabajo de Peter J. Weinberger de los laboratorios AT&T.
En el libro “Compilers (Principles, Techniques and Tools)” se recomienda su uso:

Esta es muy similar a la PJW, pero está optimizada para procesadores de 32 bits.
Se utiliza en la mayoría de los sistemas UNIX:

Esta es del libro “The C Programming Language” de Dennis Ritchie y Brian Kernighan:

Esta es una función de hash del libro “Algorithms in C” de Robert Sedgwicks:

Esta es una función de hash de Justin Sobel:

Esta realiza una buena distribución de los hash en muchos tipos diferentes de secuencias de datos:

Esta realiza un simple hashing rotativo/aditivo:

Y por último, ésta hecha a partir de las anteriores, también es una mezcla de hash rotativo y aditivo:

Y el número de 16 bits 0×1020 así:

En big-endian se sigue el orden normal, primero el byte más significativo (MSB) y de último el menos significativo (LSB):

En la plataforma PC (procesadores Intel y AMD) se utiliza little-endian así como en los Z80 y VAX.
Los procesadores Motorola 68000, los PowerPC (de Motorola) y los SPARK (de Sun) son big-endian.
Luego hay procesadores que son configurables y pueden operar en los dos formatos; MIPS, ARM y los SPARC y PowerPC modernos, por ejemplo.

Como regla general si un programa va a ser compilado y ejecutado en diversas plataformas hay que tener en cuenta el endian y programarlo de forma que se detecte el endian del procesador y se actúe en consecuencia en cada caso, de lo contrario te vas a encontrar con una larga serie de preciosos bugs muy difíciles de rastrear y que te pueden dar largas horas de “diversión”.
Hay dos casos principales en donde se debe tener muy en cuenta el endian; el primero es cuando el programa graba/lee archivos y el segundo cuando establece conexiones de red.
El problema en el primer caso es evidente, un ejemplo; con el programa ejecutándose en un PC grabas una serie de estructuras de datos en un archivo, si luego ejecutas el mismo programa en un procesador 68000 y cargas el archivo que previamente habías grabado desde un PC, los datos de las estructuras del archivo se cargarán invertidos ya que el endian de ambas plataformas no es el mismo (se grabaron los datos en little-endian y los lees como big-endian).
Con la programación de red el problema es más simple: todas las transferencias de datos se realizan en big-endian independientemente de la plataforma que las ejecute, éste es el motivo por el cual al formato big-endian también se le conoce como “Network Byte Order”.  Por eso las librerías de sockets incluyen funciones de conversión de endian:

• htonl(): Host to network byte order (long, 32 bits). Convierte una variable de 32 bits del endian del procesador a formato big-endian.
• ntohl(): Network to host byte order (long, 32 bits). Convierte una variable de 32 bits de big-endian al endian del procesador.
• htons(): Host to network byte order (short, 16 bits). Convierte una variable de 16 bits del endian del procesador a formato big-endian.
• ntohs(): Network to host byte order (short, 16 bits). Convierte una variable de 16 bits de big-endian al endian del procesador.

Volviendo al problema de la grabación de archivos, tienes dos alternativas para evitar este tipo de problemas:

• La primera forma es incluir una firma al inicio del archivo que servirá no sólo para identificar el tipo de archivo sino también para saber si fue grabado en una plataforma de distinto endian, y si es así ya sabes que tendrás que leerlo invirtiendo los datos, si por ejemplo usas como firma dos bytes al inicio del archivo como 0xAAFF (un entero de 16 bits) y en otra plataforma al leer el short de la firma se carga como 0xFFAA significa que el programa tendrá que convertir el endian del archivo, si la hubiera leído como 0xAAFF entonces significa que el endian del procesador que grabó el archivo y el endian del procesador que lo ha leído son el mismo y no es necesaria ninguna conversión.
• La segunda es grabar siempre los archivos en un endian determinado (a ser posible en el endian de la plataforma que se vaya a utilizar con más frecuencia), de esta forma, si por ejemplo has decidido que el archivo sea de formato big-endian lo único que tendrás que hacer es grabarlo y leerlo como big-endian siempre, independientemente de la plataforma. Fácil, no?

¿Y cómo detectas el endian de un procesador? Pues muy fácil, comprobando cómo almacena las variables de más de un byte en memoria:

Con un puntero char comprobamos el contenido del primer byte en memoria de los cuatro que forman la variable entera i de 32 bits, si el procesador es little-endian el valor 1 estará almacenado en el primer byte de la secuencia en memoria [0x01, 0x00, 0x00, 0x00] y por lo tanto la comparación será verdadera y se devolverá LITTLE_ENDIAN, si el procesador es big-endian el 1 estará en el cuarto byte en la memoria [0x00, 0x00, 0x00, 0x01] y la comparación será falsa devolviendo por lo tanto BIG_ENDIAN.

Para terminar solo queda por ver cómo cambiar el endian de una variable (de little-endian a big-endian y viceversa), esta función cambia variables de 16 bits (short):

Y ésta cambia el endian de variables de 32 bits:

La forma infija resulta muy sencilla para los humanos, estamos acostumbrados a ella y es muy simple. Sin embargo requiere del uso de paréntesis para establecer el orden correcto de las operaciones a realizar, y esto supone un engorro a la hora de programar un evaluador de expresiones.  El “truco” consiste en convertir la expresión de infja a postfija o prefija, de esta forma nos deshacemos de los paréntesis ya que las notaciones prefija y postfija no los necesitan.

Una vez convertida la expresión a notación postfija o prefija es muy fácil crear un árbol binario para calcular el resultado de la expresión.

Los más observadores ya se habrán dado cuenta de que la notación postfija es también conocida como RPN (“Reverse Polish Notation”, notación polaca inversa). Fué inventada por el filósofo y matemático polaco Lukasiewicz precisamente como una notación alternativa para evitar los paréntesis en la expresiones. Más de uno habrá usado esta notación en las calculadoras RPN, especialmente de HP, ¿verdad?

Vamos a ver con un ejemplo muy simple como, usando simplemente un stack,  se puede convertir cualquier expresión infija (por compleja que sea) a notación postfija. Explicaré solamente la conversión de infija a postfija. La conversión a prefija es igual de sencilla pero lo dejo como ejercicio de pasatiempo para el que le apetezca.

Se va cogiendo cada elemento de la expresión (de izquierda a derecha) y se siguen estos pasos:

1. Si el elemento es un número o variable se copia directamente a la salida.
2. Si es un paréntesis izquierdo se mete en el stack.
3. Si es un paréntesis derecho, se van sacando uno a uno todos los elementos del tope del stack (y copiándolos en la salida) hasta encontrar un paréntesis izquierdo en el stack. Finalmente ambos paréntesis se descartan.
4. Si es un operador y en el tope del stack no hay un operador o hay un operador de menor precedencia entonces se añade el nuevo operador al stack.
5. Si es un operador y en el tope del stack hay un operador de mayor o igual precedencia entonces se saca el operador del stack y se copia en la salida, y se repite la comparación del operador con el nuevo tope del stack.
6. Cuando ya no quedan más elementos en la expresión se van sacando uno a uno todos los elementos del stack y se copian en la salida.

Usaré el ejemplo inicial en notación infija: (1+2)*(3-4).

• ( Se mete en el stack.  
  STACK[ ( ]  SALIDA[ ]
• 1 Se copia en la salida.
  STACK[ ( ]  SALIDA[ 1 ]
• + Operador, en el tope del stack no hay otro operador, se mete en el stack.
  STACK[ +( ]  SALIDA[ 1 ]
• 2 Se copia en la salida.
  STACK[ +( ]  SALIDA[ 12 ]
• ) Se sacan del stack y se copian en la salida todos los elementos hasta encontrar un paréntesis izquierdo.  
  STACK[ ]  SALIDA[ 12+ ]
• * Operador, en el tope del stack no hay otro operador, se mete en el stack.  
  STACK[ * ]  SALIDA[ 12+ ]
• ( Se mete en el stack.  
  STACK[ (* ]  SALIDA[ 12+ ]
• 3 Se copia en la salida.
  STACK[ (* ]  SALIDA[ 12+3 ]
• - Operador, en el tope del stack no hay otro operador, se mete en el stack.  
  STACK[ -(* ]  SALIDA[ 12+3 ]
• 4 Se copia en la salida.  
  STACK[ -(* ]  SALIDA[ 12+34 ]
• ) Se sacan del stack y se copian en la salida todos los elementos hasta encontrar un paréntesis izquierdo.  
  STACK[ * ]  SALIDA[ 12+34- ]
• Ya no quedan más elementos en la expresión, se sacan todos del stack y se copian en la salida.  
  STACK[ ]  SALIDA[ 12+34-* ]

El resultado final en notación postfija es 12+34-*

Ahora resulta muy sencillo evaluar la expresión utilizando de nuevo un simple stack.
Vamos cogiendo cada elemento de la expresión en notación postfija (de izquierda a derecha);

• Si el elemento es un operando (número, variable o constante) se mete en el stack.
• Si el elemento es un operador (+, -, *, /, sin, sqrt…) se saca del stack tantos elementos como parámetros necesite el operador, se realiza la operación y el resultado se mete en el stack.
• El proceso se repite hasta que no queden más elementos en la expresión. Al final del proceso habrá en el stack un sólo elemento que corresponde con el resultado final de la evaluación de la expresión.

Veamos como evaluar la expresión 12+34-*

• 1 Es un operando, se mete en el stack.
  STACK[ 1 ]
• 2 Es un operando, se mete en el stack.
  STACK[ 21 ]
• + Es un operador, como + es un operador binario (necesita dos elementos) se sacan del stack y se realiza la operación (1 + 2) y el resultado se mete en el stack.
  STACK[ 3 ]
• 3 Es un operando, se mete en el stack.
  STACK[ 33 ]
• 4 Es un operando, se mete en el stack.
  STACK[ 433 ]
• - Es un operador binario, se sacan dos elementos del stack y se realiza la operación (3 – 4) y el resultado se mete en el stack.
  STACK[ (-1)3 ]
• * Es un operador binario, se sacan dos elementos del stack y se realiza la operación (3 * (-1)) y el resultado se mete en el stack.
  STACK[ (-3) ]
• Resultado final: -3

También se puede utilizar un árbol binario para evaluar las expresiones. Para crearlos usamos un stack y vamos cogiendo cada elemento de la expresión en notación postfija (de izquierda a derecha);

• Si el elemento es un número o variable se crea un nodo con él y se mete en el stack.
• Si el elemento es un operador binario se crea un nodo con dicho operador, se extraen del stack dos nodos y se le añaden como hijos, finalmente el nuevo nodo se añade al stack.
• Si el elemento es un operador unuario se crea un nodo con dicho operador, se extrae del stack un nodo y se le añade como hijo, finalmente el nuevo nodo se añade al stack.
• El proceso se repite hasta que no queden más elementos en la expresión.

Para terminar, simplemente recorriendo recursivamente el árbol en inorden podemos calcular el resultado final de la expresión o incluso reconstruirla en su notación infija:

1. Imprimimos paréntesis izquierdo.
2. Visitamos subárbol izquierdo (*).
3. Imprimimos la raíz.
4. Visitamos subárbol derecho (*).
5. Imprimimos paréntesis derecho.

(*): El proceso se repite recursivamente en los pasos 2 y 4.

Esta es una función de interpolación cuadrática (“Easy In”):

Y por último una interpolación cuadrática (“Easy In-Out”):

En los tres casos se fija el rango a interpolar con los parámetros inicio y fin, y con el parámetro tiempo se indica el punto de interpolación (por supuesto se asume que tiempo tendrá un valor comprendido entre 0.0 y 1.0).

Con el código anterior leemos la matriz actual MODELVIEW y la almacenamos en el array m.

¿Y cómo están estructurados los elementos de la matriz? Pues muy sencillo, secuencialmente:



Ahora el programador puede decidir interpretarlo como una matriz de tipo columna:



O como una matriz de tipo fila:



Matemáticamente es indiferente cómo prefieras interpretarlas, pero recuerda que si utilizas el formato columna debes realizar post-multiplicaciones, y si usas el formato fila pre-multiplicaciones.

Supongamos que tienes una matriz que representa una rotación y la matriz que realiza una traslación, y quieres combinarlas en una matriz , de forma que la matriz de trasformación resultante realice primero la rotación y luego la traslación. Si usas el formato fila tendrás que hacer una pre-multiplicación: (Esto se lee: la matriz R pre-multiplica a la matriz T).
Pero si usas el formato columna el orden se invierte ya que es una post-multiplicación: (Y esto se lee: la matriz R post-multiplica a la matriz T).

Otro ejemplo; quieres transformar el vector por la matriz para obtener el vector transformado .
Si la matriz es de tipo fila pre-multiplicas:
En cambio, si es de tipo columna post-multiplicas:

En algebra matricial siempre se multiplican filas por columnas, por lo tanto si la matriz es de tipo fila y deben ser interpretados como un vectores fila, y si es de tipo columna entonces y deberán ser interpretados como vectores columna.

Un último ejemplo; transforma el vector por las matrices (en éste orden).
La pre-multiplicación sigue el orden natural de las transformaciones por lo que resulta más intuitiva:
La post-multiplicación sería el proceso inverso:

Para terminar un truco para no liarte; cuando utilices matrices y vectores columna (post-multiplicación) debes interpretar las transformaciones como series de funciones:

No es extraño que sea poco comprensible ya que las declaraciones en C y C++ mezclan operadores que se evalúan de forma infija con otros de evaluación postfija, para el compilador esto no supone ningún problema pero para los programadores sí.
El truco está en interpretarlas tal y como lo hace el compilador; a partir del identificador avanzar hacia la derecha siempre que sea posible, y si no lo es, avanzar hacia la izquierda.

Quedará más claro con un ejemplo mucho más simple:

¿Qué representa var?, ¿es un puntero a un array de floats, o es un array de punteros a float?
Es un array de punteros a float:

Encontramos char (extra es un array de 32 punteros de función que reciben una referencia a float constante y devuelven un puntero a un array de 16 chars…).

El hecho de que puedas crear y entender declaraciones de cualquier grado de complejidad no significa que debas hacerlo. Es siempre recomendable intentar no complicarlas demasiado y, si no queda más remedio, simplificarlas usando alias con typedef. Aquí unos ejemplos muy desglosados:

typedef int *I;

I es un puntero a int.

typedef I J[];

J es un array de punteros a int.

typedef J K();

K es una función que devuelve un array de punteros a int.

typedef K *X;

X es un puntero a una función que devuelve un array de punteros a int.

typedef bool Y(X);

Y es una función que devuelve un bool y recibe un puntero de función que devuelve un array de punteros a int.

typedef Y *Z[10];

Z es un array de 10 punteros de función que devuelven bool y reciben un puntero de función que devuelve un array de punteros a int.

Declarando una variable var a partir del alias Z esta sería su declaración:

Z var; // Esto es equivalente a declarar: bool (*var[10])(int *(*)()[])

Es evidente que usando typedef la declaración es mucho más simple que hacer declaraciones complejas directamente. Aunque hay que tener en cuenta que este es un ejemplo y en realidad no es ni mucho menos necesario declarar el alias Z usando seis typedefs tan simples, se podría haber declarado usando solamente dos, tres… los que se consideren necesarios… o incluso sólo una:

typedef bool (*Z[10])(int *(*)()[]);

El uso correcto de typedef es esencial para mantener un código lo más sencillo y claro posible, porque sino, entre otras cosas, puede pasar ésto:

]]> http://www.neptalium.com/blog/2009/06/declaraciones-complejas-en-cpp/feed/ 0 http://www.neptalium.com/blog/2009/05/raiz-cuadrada-optimizacion-redonda/ http://www.neptalium.com/blog/2009/05/raiz-cuadrada-optimizacion-redonda/#comments Thu, 07 May 2009 17:36:13 +0000 admin http://www.neptalium.com/blog/?p=197 En programación 3D hay pocas funciones tan necesarias como la raíz cuadrada. ¿Quién no recuerda el famoso teorema de Pitágoras? El cuadrado de la hipotenusa es igual a la suma de los cuadrados de los catetos por lo tanto la hipotenusa será

Esto lo podemos emplear con cualquier número de dimensiones, en 3D tendremos tres coordenas que definen un punto o vector en un espacio tridimensional, aplicando el mismo teorema podemos saber el módulo (longitud) del vector y a partir del módulo podemos, por ejemplo, normalizarlo (hacer que el vector sea de módulo 1).

Un ejemplo práctico:

1 2 3 4 5 6 7 8 9 10 11 12

V3 &NormalizarVector(V3 &v) {   float modulo = sqrt( v.x*v.x + v.y*v.y + v.z*v.z);   assert(modulo != 0.0f);   v.x /= modulo;   v.y /= modulo;   v.z /= modulo;   return(v); }

La función anterior para normalizar vectores es perfectamente correcta pero se puede optimizar bastante. En primer lugar calcular raíces cuadradas tiene un coste computacional bastante importante y en aplicaciones 3D como juegos se usa constantemente por lo que es interesante optimizarla todo lo posible. Además de la raíz cuadrada también podemos sustituir las tres divisiones por tres multiplicaciones, ¿cómo lo hacemos? usando la inversa de la raíz cuadrada que nos permitirá multiplicar en lugar de dividir ya que la división está implícita en el cálculo.

¿Y cómo optimizamos la raíz cuadrada? Existen muchas formas de hacerlo pero vamos a ver la más rápida y sencilla, la raíz cuadrada inversa rápida (Fast InvSqrt):

1 2 3 4 5 6 7 8 9 10

float InvSqrt (float x) {   float x_div2 = x * 0.5f;         // Dividimos x entre 2   int i = *(int*) &x;              // Pasamos de float a int (ambos de 32 bits)   i = 0x5f3759df - (i >> 1);       // Hacemos una primera aproximación del resultado   x = *(float*) &i;                // Pasamos de int a float   x = x * (1.5f - x_div2 * x * x); // Recalculamos para aproximar más el resultado   return(x); }

Esta función se aprovecha de la forma interna de trabajo de la unidad de punto flotante (normativa IEEE 754)  para calcular una buena aproximación del resultado exacto. No es más que una simple aproximación por el método Newton.
Este código se hizo muy popular por haber sido utilizado en el Quake 3 y aunque su origen no está nada claro parece que surgió de SGI (Silicon Graphics) hace bastantes años.

La nueva función de normalización vectorial quedaría de la siguiente manera:

1 2 3 4 5 6 7 8 9 10

V3 &NormalizarVector(V3 &v) {   float m = InvSqrt( v.x*v.x + v.y*v.y + v.z*v.z);   v.x *= m;   v.y *= m;   v.z *= m;   return(v); }

El incremento de velocidad conseguido es muy importante pero también hay que tener en cuenta que el resultado es una aproximación y que este código sólo puede usarse en procesadores cuyas unidades de punto flotante sigan la normativa IEEE 754.

]]> http://www.neptalium.com/blog/2009/05/raiz-cuadrada-optimizacion-redonda/feed/ 0 http://www.neptalium.com/blog/2009/02/en-ocasiones-veo-tanques/ http://www.neptalium.com/blog/2009/02/en-ocasiones-veo-tanques/#comments Fri, 27 Feb 2009 03:05:14 +0000 admin http://www.neptalium.com/blog/?p=144 Crear y entrenar correctamente RNAs (Redes Neuronales Artificiales) tiene más de arte que de ciencia.

En primer lugar debes decidir el tipo de red más apropiada para el trabajo que debe realizar (Backpropagation, Hopfield, Adaline, Kohonen, Perceptrón Multicapa, máquina de Boltzman, etc. Incluyendo también la elección de sus funciones de propagación, activación/transferencia) y luego decidir su topología (monocapa, multicapa o recurrente), después viene su entrenamiento (con aprendizaje supervisado o no supervisado) para lo cual debes escoger una buena selección de ejemplos del problema que deba resolver y entrenarla lo justo y necesario para que entienda el problema correctamente en lugar de simplemente memorizar los ejemplos que ha visto durante su entrenamiento. O lo que puede ser aún peor; que entienda el problema de una forma completamente distinta a la que tu esperas…  …bueno, lo cierto es que siempre lo entienden como les da la gana, y como casi todo en IA una pequeña dosis de caos es esencial.

Para cada problema es necesario encontrar la mejor elección de su tipología (tipo de red), topología (número de capas y número de neuronas por capa -en el caso de redes multicapa-), cuál es la estructura y codificación de la información de entrada y salida que sea más adecuada; muestras y método de entrenamiento, tipo de función de transferencia…
Si diseñas una red demasiado grande para el problema a tratar o la sobreentrenas lo único que hará será memorizar las muestras de entrenamiento, si es demasiado pequeña o no has escogido una buena y variada selección de muestras no logrará entenderlo o lo hará de una forma parcial. No te queda otra que probar y probar hasta encontrar el balance ideal para que la red pueda generalizar en base a su entrenamiento.

Toda su inteligencia reside en el peso de sus conexiones, en el caso de las redes multicapa, cada neurona recibe las señales de las neuronas de la capa anterior, multiplica cada señal por el peso asociado a cada conexión y hace un sumatorio de todas, si su valor es positivo la neurona excitará a las neuronas de la siguiente capa y si es negativo las inhibirá. A ésto se le denomina como función de propagación.
Generalmente se programa también una función de activación o transferencia, que sirve para normalizar la salida de la función de propagación dentro de un intervalo determinado, las más utilizadas son:

• Sigmoidea: 1/1+exp(-x) (para un intervalo de 0 a 1).
• Tangente hiperbólica:  tanh(x) (para un intervalo de -1 a 1).

Es también habitual realizar un escalamiento de la salida de la función de activación simplemente multicándolo por un valor de escala más la suma de un valor de desplazamiento. Integrándolo directamente en las funciones de activación que he puesto de ejemplo quedarían así:

• Sigmoidea: 1/1+exp(-2*s*(x+t))
• Tangente hiperbólica: tanh(s*(x+t))

Siendo x el valor de entrada, s la escala y t el desplazamiento.

Ejemplo de una red Perceptrón Multicapa (MLP) de 3 capas; una de entrada de 27 neuronas,
una capa oculta de 22 y una capa de salida con una neurona. Haciendo un total de 13.090 conexiones sinápticas.

Y ahora el mejor ejemplo de cómo las RNAs hacen lo que les da la gana. En los 80 los militares norteamericanos se gastaron un buen montón de millones de dólares en un proyecto para incorporar en sus tanques un sistema de detección de tanques enemigos. El sistema consistía en una cámara conectada a un ordenador que iba analizando constantemente las imágenes y avisaba en el caso de que detectase un tanque.

Para este problema decidieron usar una red neuronal. La entrenaron con 200 fotografías; 100 fotos de tanques ocultos tras arboledas y 100 de árboles sin tanques. Hasta aquí todo bien, el entramiento funcionó perfectamente y el sistema era capaz de clasificar las fotos del entrenamiento.



Llegó el momento de probarlo y… oh! sorpresa! El sistema fallaba por todos lados y no daba ni una! En primer lugar pensaron que había memorizado las fotos de entrenamiento (y por lo tanto estaría intentando recordar en lugar de generalizar), pero después de mucho investigar, comprobar, verificar, analizar  y gastar pasta, se dieron cuenta de que las 100 fotos con tanques las habían sacado en días nublados y las otras 100 sin tanques en días soleados, la red había aprendido a reconocer lo que era más evidente; el cielo!
Millones de dólares para que un tanque te diga si hace sol… Ummm, un poco caro, no?



Y ahora os dejo con un buen ejemplo muy original de una red neuronal de 10 millones de conexiones sinápticas y una tasa de aciertos del 80% que es capaz de adivinar en qué objeto estás pensando con menos de 20 preguntas.

]]> http://www.neptalium.com/blog/2009/02/en-ocasiones-veo-tanques/feed/ 0 http://www.neptalium.com/blog/2009/02/falsas-entrevistas-y-cpp0x/ http://www.neptalium.com/blog/2009/02/falsas-entrevistas-y-cpp0x/#comments Sat, 21 Feb 2009 19:05:03 +0000 admin http://www.neptalium.com/blog/?p=29 Queda oficialmente inaugurado este pequeño blog, tengo poco tiempo pero intentaré actualizarlo al menos un par de veces por semana. Hace tiempo que tenía ganas de hacer uno pero siempre la falta de tiempo para atenderlo iba posponiendo la idea, ahora he decidido hacerlo pero, como indica su título, pretendo no emplear nunca más de 10 minutos para crear cada nueva entrada. Como veis los comentarios están desactivados (al menos de momento) así no quedo de maleducado si no me paro a responderlos ; )

Bromas aparte, no se me ocurre nada mejor para comenzar que dedicarle la primera entrada al padre de C++, Bjarne Stroustrup. Un danés que ahora enseña ciencias de la computación en la Universidad A&M de Texas pero que se ha pasado la vida trabajando en los laboratorios Bell de AT&T en USA en donde, allá por 1980, creó el primer prototipo de C++ llamado “C con clases” y que todavía no era un compilador sino que, por medio del preprocesador, traducía el código a C para poder ser compilado. Posteriormente creó el primer compilador de C++ llamado CFront aunque también seguía generando código C de salida.
Por cierto, el CFront fue programado con el “C con clases”… tiene su punto el asunto; C++ creando a C++. Ala! ya teneis un nuevo koan tipo huevo-gallina.
El resto ya es historia conocida.

Bjarne Stroustrup

Hace 10 años comenzó a circular entre los programadores de C++ una supuesta entrevista suya que nos dejó, estaba claro que tenía que ser una coña pero hasta tal punto llegó la discusión que para confirmarlo y cerrar de una vez el asunto le envié un e-mail y a los 3 minutos justos me responde con:

Hola,

Claro, es una broma, y de no muy buen gusto por cierto. Por favor visita siempre mi web personal en donde pongo las entrevistas que me van haciendo.
(…)

Ésta es una de las perlas de aquella mítica y falsa entrevista:

Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought ‘I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers?’
Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.

—————————————————–

Bueno, un día, cuando estaba sentado en mi oficina, pensé sobre este pequeño sistema que compensaría la balanza un poco. Pensé ‘Me pregunto ¿qué pasaría si hubiese un lenguaje tan complicado, tan difícil de aprender, que nadie pudiera saturar el mercado de programadores nunca más?’
En realidad cogí algunas ideas del X10, ya sabes, el X-windows. Era un sistema gráfico tan cabrón que sólo se podía ejecutar en aquellos Sun 3/60. Tenían todos los ingredientes que quería. Un sistema con una sintaxis tan ridículamente compleja, funciones oscuras, y arquitectura pseudo orientada a objetos. Incluso ahora nadie programa directamente código para X-windows. Utilizar Motif es la única manera si no quieres volverte loco.

Si nunca habíais oído hablar de esta entrevista y aún no la habeis leído ya va siendo hora… os vais a hartar de reir un buen rato.

Bueno, vamos al tema, aquí os dejo con una conferencia que dio hace un par de años sobre el futuro nuevo estándar C++0x que reemplazará al actual C++03 (ISO/IEC 14882):

PD: Como veis estoy cogiendo un vicio insano con los muñequitos amarillos, los alérgicos/as manténganse a distancia prudencial, no me hago responsable de posibles efectos secundarios de una larga exposición a estos bichos amigos de PI…

]]> http://www.neptalium.com/blog/2009/02/falsas-entrevistas-y-cpp0x/feed/ 0 http://www.neptalium.com/blog/2009/02/probando/ http://www.neptalium.com/blog/2009/02/probando/#comments Fri, 20 Feb 2009 22:24:54 +0000 admin http://www.neptalium.com/blog/?p=3 Probando…

123

]]> http://www.neptalium.com/blog/2009/02/probando/feed/ 0