Se bienvenido a estas tierras digitales...
...especialmente si eres un molino....
June 10, 2011
Johns Hopkins University professor Gregory Eyink has determined through computer experiments that turbulent fluid flows are dominated by randomness, and has confirmed earlier theoretical predictions that two identical beads dropped into the same turbulent flow at precisely the same starting point will end up in random destinations.
Eyink performed his study using a virtual stream that is part of an online public database of turbulent flow, and into this stream were dropped virtual particles at exactly the same point. Eyink then kicked each particle at random, and the particles followed different pathways when subjected to different kicks. However, Eyink observed that the particles still followed random, divergent paths even as the kicks got progressively weaker, suggesting that particles would follow different paths even without the kicks.
Eyink’s experiments also verified that the magnetic lines of force that are carried along in a moving magnetized fluid move in an entirely random manner when the fluid flow is turbulent. This operates against the basic precept of magnetic flux-freezing, which dictates that magnetic lines of force are carried along in a moving fluid like strands of thread dropped into a flow.
Extraído de JHU Gazette
La importancia del siguiente texto radica en ofrecer al lector de mi blog una interesante alternativa para la generación de números aleatorios, más aleatorios y más rápidos. De hecho se puede leer cómo usar una técnica de generación de números aleatorios, muy rápida y eficaz (sin llegar a los extremos enunciados en el artículo que se cita en este post). Estos recursos se pueden obtener de : http://www.pgroup.com/lit/articles/insider/v2n2a4.htm
¿Metodología o computadora?. Reflexión.
Concepcion–>Descomposición–>Análisis–>Diseño–>Cod.Fuente–>Cod. Objeto–>Ejecutable
Navegalia.
Allá por el 98 el uso de Internet no estaba tan extendido como ahora, ni mucho menos. Tampoco usabamos google, si acaso algún privilegiado usaba lynx en la universidad porque alguien le daba acceso. Era la época del IRC en clase. Del windows 95, del Netscape y del Internet Explorer. Pero nada más. Era la web pura y dura HTML a pelo, con gifs que ahora se miran como retro-art. Pero, una empresa, Navegalia ( ver opiniones de la gente en el 2001: http://www.ciao.es/navegalia_com__Opinion_329098 ). La siguiente imagen es una captura del portal. Qué recuerdos.
La verdad oculta tras los tipos de datos.
Es evidente que las metodologías nos alejan de la forma en la que trabaja el procesador. Pero lo hacen en favor nuestro. Siempre he pensado que las metodologías son como la “religión” en el software. Uno es libre de adoptar una o ninguna, e incluso de aunar varias para construir sus propias reglas. Trabajar sin un conjunto de normas puede ser muy bueno o muy muy malo.
Ejemplo. Siempre recomiendan que las variables tengan un nombre “adecuado”. Desde el principio he pensado en qué querrá decir adecuado. Cada uno tenemos una forma de trabajar y lo que para uno es adecuado para otro no lo es. Pero si pensamos en que una variable ocupa “una dirección de memoria” y todos los bytes (sizeof(tipo_de_esa_variable)) que le acompañan, podemos pensar que definir variables alegremente es pernicioso. Si le damos un nombre adecuado, siempre podremos re-usar variables sin necesidad de tener que crear miles de ellas, cada una para un propósito diferente.
Luego, según en que casos, las metodologías también ayudan a alcanzar “rendimiento” en la computación. Como es el caso de la orientación a objetos. Claro, ayudan a alcanzar alto rendimiento, en lenguajes suficientemente alejados del procesador, como los que se diseñan para programar en ese paradigma. El ejemplo de la utilidad de las metodologías lo tenemos presente a la hora de crear las clases y la relación entre ellas para “modelar” un problema. Si seguimos las normas y realizamos un diseño limpio, nuestro programa puede llegar a ser óptimo. De no seguir la metodología, la semántica de la ejecución, incluso, puede verse afectada.
En otros casos como en los de los lenguajes de bajo nivel, la metodología no es de gran ayuda, aunque sirve para “organizar” y “compartir” el código. Como en el caso del lenguaje C, en el que siempre se recomienda crear funciones y llamar funciones en tiempo de ejecución. Cuando debido al modo de operación de los procesadores, este modo de trabajo es ineficiente (de ahí que surgieran en estos lenguajes palabras clave como “inline” para poder aliviar el impacto de la metodologia).
¿La orientacion a objetos solo puede entenderse desde la perspectiva de una metodologia? SI. Su diseño es recomendable seguirlo a través de las directrices básicas de una metodología. Pero su implementación REAL, es decir, una vez que sabemos CUANTAS y QUE clases tenemos y COMO se relacionan, podemos por ejemplo implementar los objetos/clases en ensamblador o embutir ensamblador NATIVO en los METODOS de los objetos si hablamos de C++, o ensamblador para la JVM (Oolong) si hablamos de JAVA, o MSIL para .NET si hablamos de C#, C++ Managed Extensions …..
Asi pues, puedo indicar el uso de las metodologias como algo que ayuda a vivir en un mundo digital más ordenado, pero siempre existirán formas de arrancar rendimiento al procesador, rendimiento sustraido por la existencia de las citadas metodologías.
El Quijote Digital 