El Tao de VIPERS: Bitácora de un Científico Revolucionario.: enero 2012

lunes, 30 de enero de 2012

ANOTACIÓN 2012 Serie 1 No 1

ANOTACIÓN 2012 Serie 1 No 1: 31 de enero, 2012

BIENVENIDOS AL MUNDO DE “VIPERS”:

“VIPERS” es un acrónimo inglés (“Visually Interactive Programming EnviRonment for Systems”) para un sistema de computación ideado para el diseño, simulacro y manutención de nuevos sistemas, o para el análisis y simulación de sistemas preexistentes – reales o artificiales. Vivimos en un mundo creado por la imaginación colectiva de nuestra especie, pero la complejidad y la interdependencia de ese mundo artificial supera las capacidades de nuestras mentes, y de nuestras disciplinas, metodologías y tecnológicas para su entendimiento, manejo, y planificación. Como resultado es imprescindible que fijemos nuestra atención en la necesidad de crear nuevas herramientas dedicadas a ayudarnos a comprender y a controlar esa complejidad. Dicho de otro modo, hemos creado un mundo demasiado complicado para entenderlo, para monitorearlo, y para manejarlo y ahora – para nuestra supervivencia misma – tenemos que crear la tecnología necesaria precisamente para la comprensión, para la observación, y para el dominio de ese mundo. VIPERS es precisamente un ejemplo de esta nueva tecnología.

Carecemos de herramientas que nos puedan ayudara a predecir, por ejemplo, el impacto económico y ecológico del establecimiento de una nueva planta de automóviles en una zona originalmente agrícola; el efecto que causaría la eliminación, o la introducción, de una especie animal en el equilibrio de un determinado ecosistema; las consecuencias meteorológicas globales de la eliminación de millones de acres de bosque ecuatorial en el Amazonas; las ramificaciones socioeconómicas de la legalización de la marihuana; cómo establecer una cooperativa de intercambio óptimo y no-monetario de productos entre los países latinoamericanos; cómo diseñar un programa de nutrición equilibrado para nuestras necesidades alimenticias y calóricas basadas en los alimentos disponibles; cómo diseñar un plan económico sustentable y cuál sería su índice de crecimiento, inflaciones; cuales serán los efectos económicos y laborales – locales y globales – de cambiar de la gasolina como combustible a gas natural, etc. VIPERS está ideado específicamente para este tipo de análisis, diseño y desarrollo de sistemas – y más.

En breve, VIPERS es un sistema computacional creado para asistir al analista en:

1. Modelar, hacer prototipos, y programar simulaciones de sistemas naturales (ecológicos, biológicos, fisiológicos, etc.,) o artificiales (económicos, comerciales, industriales, de computación, etc.); o

2. Diseñar, hacer simulacros, realizar simulaciones, implementar, y mantener sistemas artificiales.

VIPERS integra:

1. REPRESENTACIÓN diagramáticA: En sistema VIPERS la interacción con el usuario llevará a cabo no en un lenguaje de programación textual, sino en lenguaje completamente diagramático implementado en ambientes visuales.

2. OPTIMIZACIÓN: El sistema VIPERS está proyectado para calcular niveles de interacción óptimas entre los varios componentes (entidades o subsistemas) de producción y consumo en el sistema.

3. HOMEOSTASIS: El sistema VIPERS está proyectado para calcular niveles de interacción ESTABLES entre los varios componentes (entidades o subsistemas) de producción y consumo en el sistema.

ANOTACIÓN 2012 Serie 1 No 2

ANOTACIÓN 2012 Serie 1 No 2: 2 de febrero, 2012 12:25 AM

NOTA PERSONAL

VIPERS representa la culminación de mi carrera como científico – como estudiante de física, de química, de múltiples ramas de la biología (fisiología, botánica, zoología, ecología, etc.), y de las neurociencias cognitivas-afectivas; como matemático – como estudiante de la estadística, del cálculo diferencial e integral, de la lógica difusa, del algebra lineal, de las ecuaciones diferenciales, etc.; y como filósofo, creador de un nuevo paradigma: el paradigma MAMBA. De hecho es precisamente la herramienta tecnológica que demuestra cómo aplicar el paradigma MAMBA a la vez que lo muestra en aplicación.

VIPERS demostrará, a nivel empírico, matemático y científico, que efectivamente “TODO ES TODO”, que el paradigma del “pensamiento sistémico” (“systems thinking”), del “procesamiento distribuido en paralelo” (“parallel distributed processing”) y el del “conexionismo” (“connectionism”) son variantes de una misma realidad.

VIPERS es – junto con MAMBA (“Mastering the Art of Mind-Body in Action”) y mi obra literaria completa, de las cuales es una extensión paradigmática – mi magnum opus, mi gran obra, mi máxima aportación. VIPERAS no solamente abarca todo mi conocimiento informático, matemático y científico en todas las ramas de las mismas, sino que me requerirá emprender un estudio amplio, profundo e interrelacionado de todas las disciplinas del conocimiento matemático y científico.

¿Por qué? Porque el propósito de VIPERS es precisamente ser un sistema computacional que sirva para: 1) por una parte modelar sistemas existentes (naturales o artificiales), y 2) para diseñar nuevos sistemas artificiales o (pseudo-) naturales. Las diversas ciencias son las disciplinas a través de cuyo estudio logramos comprender diferentes manifestaciones, aspectos, facetas, o dimensiones de un dado sistema. Si tomamos al ente humano, por ejemplo, tenemos muchas disciplinas que lo estudian, pero ninguna de una forma tan integrada y completa como MAMBA que de hecho abarca el estudio integrado y armonioso de todas las disciplinas del estudio del ser humano:

· Psicología – Cognitiva, Social del Deporte, Clínica, de la Religion (programa integral que yo mismo cree), etc.

· Antropología – Cultural, cognitiva. chamanismo.

· Ciencias de la Religión – misticismo, las religiones del mundo en perspectiva histórica y comparativa.

· Paleoantropología: Estudio del ser humano en su evolución y en su ambiente prehistórico.

· Sociología: Estudio del ser humano en sociedad.

· Medicina Psicosomática: Hipnosis clínica, estudio de la relación entre los estados mentales – los pensamientos, la imaginación y las emociones – y la salud.

· Historia: Record de la conducta humana a través del tiempo y espacio geopolítico.

· Literatura: Estudio de la condición existencial humana a través del arte, de la cultura y del pensamiento en forma escrita.

· Filosofía: La disciplina que se dedica a la “verdad”.

· Artes Marciales y Pensamiento Oriental: Budismo, taoísmo, confucionismo, bushido, yoga, Zen, KAIZEN, etc.

· Cultural y Civilización Mundial:

· Ciencias Políticas: Estudio del poder político dentro y entre naciones y entidades sociopolíticas.

· Economía: Estudio las entidades generadores y consumidoras de bienes, recursos y servicios manejan la distribución de los mismos.

· Pensamiento Estratégico: Juegos Estratégicos, Arte de la Guerra, etc.

Todas esas disciplinas y muchas más representan estudios de diferentes aspectos del sistema que conocemos como el “ser humano” – pero solamente el programa de MAMBA los integra para crear un plan de ser y estar en el cosmos. ¿Por qué MAMBA lo logra? Porque es el resultado de un paradigma que enfoca en el estudio integralmente multidisciplinario para el estudio de cualquier sistema o fenómeno.

VIPERS es la herramienta automatizada para implementar ese mismo paradigma fundamental para la creación, análisis, y manejo de cualquier sistema. Para lograr su creación es preciso:

1. El estudio de una gran diversidad de sistemas para tener ejemplos claros y concisos de las propiedades generales por las que se rige cualquier sistema;

2. El estudio de las múltiples disciplinas que estudian diferentes aspectos de un sistema.

3. Definir cómo se integrarán estas disciplinas para implementar los principios de esa integración en la base de conocimiento del sistema experto que es VIPERS.

4. Descubrir cómo implementar en el ordenador las funcionalidades de VIPERS.

ANOTACIÓN 2012 Serie 1 No 3: 4 de febrero, 2012

ANTECEDENTES HISTÓRICOS, primera parte: LOGDIAL:

LOGDIAL – CNRC, OTTAWA, CANADÁ. 1982-1983

En mi consciencia científica, la semilla paradigmática que engendró a VIPERS comienza en un laboratorio en el sótano del Consejo Nacional de Investigación del Canadá o “CNRC” en el verano del 1982, semanas antes de mi 19 cumpleaños. Bajo la tutela de mi padre yo llevaba casi un año trabajando en mi nueva profesión como programador-analista, Había programado varios diseños suyos, incluyendo un sistemas denominado “OBAL” (“Overton Basic Assembly Language”) que hacía simulacros de programas de ordenador escritos en una versión elemental del lenguaje elemental de computación conocido como un “assembly language” – un “lenguaje ensamblador”. Un “lenguaje ensamblador” (o “assembler”) es un lenguaje de programación de bajo nivel para los computadores, y OBAL era un programa que mostraba visualmente a los alumnos estudiando assembler cómo se ejecutan en la computadora los pasos de las instrucciones de sus programas escritas en ese lenguaje de programación básico a la vez que se ejecutaban las instrucciones del programa mismo. (En términos de computación lo que había programado con OBAL era un “interpretador” de programas, es decir, un programa que a su vez toma las instrucciones de otro y lo “interpreta”, va ejerciendo las instrucciones decodificando los mandos de las mismas. El interpretador más común es el sistema de programación llamado BASIC, universalmente conocido y en muchos casos muy, muy sofisticado y nada ‘básico’. Más sobre eso en adelante.)

En el CNRC tuve un proyecto mucho más complicado del que jamás había tenido, un proyecto que no solamente lanzaría mi carrera como programador-analista y también como analista de sistemas, sino que cambiaria mi forma de pensar y de estar en el mundo. Comenzó como un proyecto de mi padre que él mismo llevaba concibiendo desde sus días como ingeniero de computación y sistemas en ITT, España un par de años antes. Se trataba de una metodología para hacer simulacros visuales de diseños de sistemas de información, de programas de computación en general, que comenzaba con una innovación ya en la representación diagramática.

Los diagramas de la metodología de mi padre combinaban el flujo de la data, es decir, la transformación de la data (o ‘información’) a través del programa – junto con el flujo de la ejecución del programa mismo, o sea, del orden de la secuencia de los de las instrucciones. Tradicionalmente flujo de data y flujo de ejecución se representaban por separado y en representaciones diagramáticas diferentes y no integradas. De ahí que se tenía “Flow Charts” para representar el flujo de la lógica de las instrucciones por un lado, y “Data Flow Diagrams”, para captar las transformaciones de la data o información a través del sistema por su parte. El diseño completo de un sistema de información se podría lograr por primera vez en una sola representación que integraba tanto la información o data misma como las instrucciones que la transformaban.

La segunda gran innovación, que surgía como resultado de la primera, era la idea de poder hacer un simulacro computarizado del diseño diagramático. Es difícil explicar para alguien que no haya trabajado en el campo de la informática, sobre todo en sistemas con más de 50,000 líneas de código de programación – los denominados “proyectos grandes” – la revolución metodológica y tecnológica que supondría esta innovación. Pocos pueden comprender el estado horrendo del diseño, de la implementación, de la corroboración (comprobación), y del mantenimiento (ajustes a los sistemas de acuerdo a los cambios requeridos para el cliente o usuario) en el campo del software. Mientras que el desarrollo del software en general ha sido un éxito – eso es obvio, no precisa de mayor confirmación que la experiencia empírica, estamos rodeados de programas que funcionan o al menos nos sirven – el costo de ese éxito es insólito. El estado de desarrollo de software – programas para los ordenadores o computadores – es tremendamente costoso debido a muchos, muchos factores. Gran parte del problema viene a ser en función de la dificultad de poder hacer buenas cotizaciones. Todo programador experimentado aprende que el tiempo verdadero de lo que tarda su proyecto es de DOS a TRES veces lo que originalmente cotizó. Y aun así, muchos proyectos de centenares de millones de dólares USA acaban siendo eliminados por completo antes de poder llegar a su conclusión.

Más de dos décadas después de haber comenzado ese proyecto en el CNRC de Ottawa, Canadá, la industria del software sigue estando repleta de casos representativos de fracasos multimillonarios. Creo que un artículo de una página web dedicado precisamente al estudio de problemas y fracasos de software lo capta perfectamente:

15 de mayo 2006

La larga, triste historia del fracaso de proyectos de software

Del artículo de la IEEE “Por qué el software falla”[1]:

El octubre pasado, por ejemplo, el gigante minorista de alimentos británico “J Sainsbury” tuvo que cancelar su inversión de $ 526.000.000 EE.UU. en un sistema automatizado de gestión de la cadena de suministro. La mercancía se estaba quedan atrapada en los depósitos y almacenes de la compañía y no llegaban a entregarse en muchas de sus tiendas. Sainsbury se vio obligado a contratar alrededor de 3.000 empleados adicionales para abastecer sus estanterías de forma manual.

Este es sólo la última de una larga historia, triste de proyectos [de Software] que salieron mal. La mayoría de los expertos en TI {Tecnología de la Información} están de acuerdo en que estos fallos se producen con mucha más frecuencia de lo que deberían. Es más, los fracasos son universalmente libres de prejuicios: se producen en todos los países, hasta en las grandes empresas y en las pequeñas, en las organizaciones comerciales, sin fines de lucro y las gubernamentales, y sin importar el estado o la reputación. Los costes empresariales y sociales de estos fracasos, en términos de dólares de los contribuyentes y pérdidas de los accionistas, así como las inversiones que no se pueden hacer, son ya bien entrados los miles de millones de dólares al año.

El problema empeora a medida que se hace ubicuo. Este año, las organizaciones y los gobiernos se gastaron un estimado de $ 1 billón {un trillón americano} en hardware, software y servicios en todo el mundo. De los proyectos de TI que se inician de un 5 a un 15 por ciento será abandonado antes o poco después de la entrega como totalmente inadecuados. Muchos otros se entregarán tarde y por encima del presupuesto o que requerirán una remodelación masiva. Pocos proyectos de TI, en otras palabras, son verdaderamente exitosos.[2]

Cualquier innovación que permita un desarrollo más detallado del diseño y una confirmación de su validez – en términos tanto de cumplimiento de los requisitos del usuario – y de su eficacia – y de si funciona o no, supondría una revolución en el campo.

Y así mismo comenzaron los problemas en nuestro propio proyecto: el diseño original de mi padre, una vez codificado en el lenguaje de programación NATAL II – creado en ese mismo laboratorio – no funcionó. Después de revisarme a mismo media docena de veces para asegurarme de que no había sido error mío, mi padre y yo ambos dimos un repaso al código de programación para ver si el error era mío en la programación o suyo en el diseño: efectivamente era un error de diseño. En retrospectiva era de prever puesto que el diseño mismo del programa estaba en la metodología de “Logic Data Diagrams” que por su parte no se había desarrollado lo suficiente para ser aplicado en un proyecto de esa complejidad. Es decir, la metodología de diseño diagramático no estaba a un nivel de usarse para diseñarse a sí misma. No se logró dar en por qué el diseño no funcionaba, así que dando muestras de quizás una capacidad o adquirida o innata o ambas para el análisis y desarrollo de sistemas, le dije a mi padre, “explícame en palabras lo que quieres que haga el programa, y yo lo programaré” – dicho y hecho. A partir de entonces se convirtió en mi proyecto heredado.

El “tropiezo” inicial con el diseño fue una señal muy importante de las muchas innovaciones imprescindibles que se precisarían para que el proyecto tuviera éxito a largo plazo. Empecé a descubrir problemas con la metodología misma, o al menos con uno de los principios fundamentales: la idea de que un diseño efectivo pudiera hacerse a un nivel abstracto sin entrar en detalles. Ante lo errada de esa premisa hice un cambio fundamental en el concepto metodológico, decidiendo que en realidad lo que se precisaba no era una herramienta para hacer una SIMULACIÓN de diseños a un nivel abstracto para luego entregarle al programador y que codificara – tradujera en código de lenguaje de computación a mano – sino un lenguaje para una EJECUCIÓN del diseño y después hacer la traducción automática al lenguaje, convirtiendo de esa forma el diseño en el programa – es decir, el mapa se convierte en el terreno. Así fue como se pasó de la idea de un simulador para un diseño diagramático a alto nivel se pasó a lo que denominé “LOGDIAL” de LOGic-data DIAgram Language”. LOGDIAL no era simplemente un lenguaje de programación diagramático, sino un ambiente que regulaba la formación del diseño de acuerdo a reglas y principios para evitar ciertos errores típicos de programación que después se convierten en pesadillas a la hora de la verificación del sistema.

Durante casi dos años continuó el desarrollo de sucesivas versiones de LOGDIAL dando demostraciones a altos funcionarios de empresas locales de software en la región de Ottawa, o lo que se llama el “valle del silicón del Canadá” por la concentración de empresas de computación similar al “valle del silicón” del norte de California. La meta era lograr una versión de LOGDIAL capaz de poder representar un diseño tan elaborado de cualquier programa que luego se traduciría, automáticamente, en los lenguajes de programación de la época, y conseguir un inversionista que patrocinara el esfuerzo. Cada presentación en el laboratorio a ejecutivos y expertos generaba una serie de comentarios y crítica que yo luego integraba para mejorar el producto y demostrar las mejorías en la siguiente versión.

El acceso a las instalaciones del CNRC en Ottawa no era para un tiempo indefinido y se logró lo que se prometió a cambio de su uso: un prototipo funcional que demostrara el poder del lenguaje de programación NATAL II, creación de ese laboratorio a gran costo del gobierno canadiense pero que nunca logró despegar en el mercado. Pero nuestras expectativas de lograr un inversionista que aportara el capital necesario para un desarrollo completo y comercial del producto nunca se lograrían.

¿Por qué? Por dos motivos. Una fue que, mi habilidad ‘natural’ para la programación aparte, me faltaba mucho conocimiento técnico necesario para crear una versión comercial, conocimiento relacionado, por ejemplo, a la implementación de programas como sistemas operativos y compiladores, conocimiento que no lograría obtener hasta pocos años más tarde en Queen’s University donde, aunque me licenciara en Estudios Ibero-Latinoamericanos, obtendría una concentración en ciencias de la informática (precisamente en pos del conocimiento necesario para desarrollar lo que para aquel entonces sería APEX). Por otra parte, la extrema novedad del producto y la naturaleza conservadora del canadiense (cuyo símbolo nacional es el castor) siempre ocasionaba la misma respuesta: “cuando tenga una versión comercial avísennos”.

LOGDIAL – CADMICS AUTOMATION/MONTREAL, 1983 – 85

Mi carrera de programador/analista me llevaría a un contrato con la gigante corporativa “Hydro-Quebec”, una de las empresas hidroeléctricas más grandes del planeta. Como resultado del proyecto me trasladé a vivir en Montreal, donde residí durante un total de dos años aproximadamente. Terminado el proyecto con Hydro Quebec, CADMICS Automation, la empresa de mi padre y mía, consiguió algo de capital bajo un incentivo gubernamental de deducción de impuestos por inversión en proyectos de pequeña industria. Se implemento una nueva serie de prototipos en un sistema de Hewlett Packard usando su lenguaje de programación BASIC. Hubo avances en el prototipo, pero nunca se llegaría a la creación de una versión comercial antes de que los fondos se evaporaran.

Pero hubo algo que me llevaba royendo desde una exhibición que hice en un congreso de software en Ottawa, un comentario que me hizo un miembro del público del extranjero – alemán o suizo quizás – cuando describí las funciones que queríamos implementar en LOGDIAL para hacerlo compatible con los lenguajes de programación actuales: “¿Para qué limitarse a eso? ¿Ya que es algo nuevo, por qué no hacer algo completamente radical y totalmente nuevo?” Precisamente para ese tipo de retroalimentación era bueno exponerse a la crítica – práctica que continuo hasta la fecha con compartiendo mis libros en progreso con mis lectores, convirtiendo la autoría en un proceso dinámico. Mi respuesta en el momento fue algo así, “para encajar mejor con la tecnología actual,” pero su punto era valido – bien valido. ¿Por qué no? Una, porque no se nos había ocurrido, pero con la sugerencia ya sería más que suficiente. Dos, para ello habría que cambiar la idea de raíz, incluso modificando la estructura y el concepto de los diagramas mismos: ya no sería LOGDIAL. Y esa idea dio lugar a APEX – “Automated Programming EXpert system.”

Se continuará.

[1] http://spectrum.ieee.org/computing/software/why-software-fails

[2] http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html (Traducción propia.)

ANOTACIÓN 2012 Serie 1 No 4: 4 de febrero, 2012

ANTECEDENTES HISTÓRICOS, segunda parte: APEX 1985 - 1995

APEX – TORONTO, y KINGSTON, ONTARIO

Después de Montreal la asociación profesional entre mi padre y yo se disolvió, y con eso LOGDIAL llegaría al final de su recorrido. Mientras, mi carrera como analista de sistemas y programador-analista veterano continuaría en un contrato muy importante con Honeywell, en Toronto, Ontario. Si bien LOGDIAL había llegado a su fin en Montreal una vez libre de los parámetros establecidos de esa metodología puede pensar “fuera de la caja”. Empezó en Toronto entonces una reformulación de la idea fundamental de representar no solamente un sistema en términos tan directos de la implementación empleando los modelos tradicionales de la informática, (representados en las estructuras de datos y de control de los lenguajes de programación) sino un afán ya de modelar sistemas con una base más amplia en mente, empecé a preguntarme, “¿Qué es un sistema?”.

APEX retenia el concepto de una ejecución visual, dinámica para el usuario a la vez que una efectiva – es decir, los resultados del programa en funcionamiento. En LOGDIAL uno podría ver exactamente como, a través del flujo de control o de lógica, las variables cambiaban de valores y el índice del número de veces que un diagrama ha “ejecutado” quedaba visualmente presentable al usuario. Así podrías ver que partes de tu diseño/programa estaban funcionando con la data inicial de entrada. No obstante las similitudes, conceptualmente APEX ya mostraba unas modificaciones significativas comenzando en una nueva estructura de los diagramas. En LOGDIAL, el diagrama es rectangular y el flujo de información o data se representaba de izquierda a derecha en los diagramas, y el flujo de control de arriba hacia abajo, mientras que APEX empleaba una forma hexagonal y las entradas quedan en la parte superior del hexágono y las salidas en la parte inferior; el flujo de control aún permanecía de arriba hacia abajo. En APEX se distinguían, en el mismo diagrama individual, entre entradas de información o materiales que provinieran desde adentro del mismo módulo o subsistema, de aquellos que provenían desde afuera del mismo, es decir, lo que se denominan variables y constantes locales de los globales; igual sucedía con las salidas – los materiales de exportación del proceso – podría salir al mismo módulo donde está ubicado éste, o pueden ser exportados al exterior. Por lo tanto, cada diagrama de APEX era más informativo que el de LOGDIAL, y menos limitado al concepto tradicional de “procesamiento de data”.

APEX, no obstante, nunca llegaría a un nivel de prototipo programado, permaneciendo en el tintero de mi mente como una idea que para su desarrollo requeriría mucho más conocimiento de absolutamente todo tipo, tanto de los tipos sistemas mismos que quería lograr modelar, como de las matemáticas y de la informática en general imprescindibles para lograr implementar tal sistema. Con ese propósito al terminar mi proyecto con Honeywell en Toronto, me ingresé en la Universidad de Queen’s en Kingston, Ontario.

En la Universidad de Queen’s experimenté un tremendo boom intelectual general – en todas las direcciones imaginables, con la excepción del departamento de música, el de drama y el de bellas artes, cursé estudios en todos los departamentos imaginables. ¿Con cuál propósito? Simple: aprender lo más posible de todo. En los 10 años que estuve presente en Kingston completaría un licenciatura en estudios ibéricos y latinoamericanos pero con cursos completados para varias especializaciones adicionales, incluyendo psicología y ciencias de la informática; una maestría en literatura española y latinoamericana; media maestría en administración (MBA) – durante la cual precisamente estuve haciendo trabajo de investigación en APEX bajo la tutela del Profesor Law, un doctor en zoología convertido en profesor de análisis de sistemas – y una licenciatura a en la Universidad de Waterloo en Ciencias Generales con una concentración en psicología de la religión.

En ese tiempo mis intereses profesionales se habían dividido en tres. Por una parte estaba el maestro de artes marciales fundador de Black MAMBA en la primavera de1989. Por otra parte habían dos intereses académicos aparentemente totalmente divergentes. Uno era el resultado de mi tesis de literatura-antropología cultural sobre el chamanismo en la literatura latinoamericana que me llevaría a indagar en las bases neurofisiológicas del chamanismo. Finalmente estaba mi fascinación – y compromiso – por completar APEX, algo que para mí había quedado pendiente desde el sótano de CNRC años atrás.

Tuve la fortuna de dar con un mismo programa de doctorado donde podría desarrollar las herramientas y el conocimiento necesario para estudiar ambas facetas de mi interés académico: Ciencias Cognitivas de la Universidad de San Diego. Recomendado por una parte por el mismo Profesor Law para continuar mi desarrollo de APEX, el departamento de Ciencias Cognitivas de UCSD eran los pioneros en un nuevo campo conocido “redes neuronales artificiales” (artificial neural networks) y el “paradigma conexionista”, relacionados con un nuevo concepto de la inteligencia artificial basado en las redes neuronales biológicas. Por otra parte, buscando un programa de estudios graduados donde podría estudiar la neurofisiología cognitiva y afectiva del viaje chamánico, varias referencias totalmente independientes me apuntaron en la misma dirección: el departamento de Ciencias Cognitivas de UCSD.

Se continuará…

ANOTACIÓN 2012 Serie 1 No 5 - 6 de febrero 2012 - ANTECEDENTES HISTÓRICOS, Tercera parte: 1995 - 1997– UCSD SAN DIEGO.

ANTECEDENTES HISTÓRICOS, Tercera parte: 1995 - 1997– UCSD SAN DIEGO.

REDES NEURONALES ARTIFICIALES Y EL PARADIGMA DEL “PROCESAMIENTO DISTRIBUIDO EN PARALELO”

El modelo tradicional de procesamiento de información en un sistema de computación es secuencial, con una instrucción o módulo activado a la vez, pero en el procesamiento distribuido en paralelo, muchos módulos están activados simultáneamente – precisamente lo que ocurre en un sistema real: la hierba crece, el conejo se alimenta, el zorro acecha, el gavilán vuela, el viento sopla, el sol reluce, etc., y todo a la vez a su propio ritmo y respondiendo ambas a sus propias motivaciones interiores a la vez que a las exigencias o los estímulos exteriores. Es decir, en un sistema natural hay una independencia de cada unidad que forma, a la vez que una dependencia simultanea que surge de la relación, influencia, etc., de las demás unidades al igual que de factores ajenos al, pero influentes en el sistema (la cantidad, horario e intensidad de luz solar, la temperatura, la humedad, etc.) ocasionando una interdependencia entre todos los elementos del sistema, lo que venimos llamar la “red de la vida”. No se puede representar adecuadamente esa realidad con los sistemas de computación tradicionales que se desarrollaron primordialmente para el procesamiento de sistemas comerciales como son los de las nóminas de salarios, o estado de inventario, o entregas por paqueterías, etc. En ese tipo de sistemas aunque existe un procesamiento múltiple, es decir, en la que varios componentes están ejerciendo sus instrucciones independientes de los demás, la base del procesamiento sigue siendo secuencial en cada componente. Por eso mismo se nos dificulta desarrollar modelos que acertadamente pronostiquen el estado de la economía o el de la bolsa de valores – estos tipos de sistemas, a pesar de ser artificiales son muy “naturales” en su comportamiento ya que surgen directamente de la interacción de componentes completamente naturales: los seres humanos.

En un sistema de información o de computación típico, el conocimiento del sistema – su capacidad para resolver problemas – está representado en una secuencia de instrucciones fijas que conocemos como “algoritmos”:

“En matemáticas, ciencias de la computación y disciplinas relacionadas, un algoritmo (del griego y latín, dixit algorithmus y este a su vez del matemático persa Al-Juarismi) es un conjunto preescrito de instrucciones o reglas bien definidas, ordenadas y finitas que permite realizar una actividad mediante pasos sucesivos que no generen dudas a quien deba realizar dicha actividad. Dados un estado inicial y una entrada, siguiendo los pasos sucesivos se llega a un estado final y se obtiene una solución… En la vida cotidiana, se emplean algoritmos frecuentemente para resolver problemas. Algunos ejemplos son los manuales de usuario, que muestran algoritmos para usar un aparato, o las instrucciones que recibe un trabajador por parte de su patrón. Algunos ejemplos en matemática son el algoritmo de la división para calcular el cociente de dos números, el algoritmo de Euclides para obtener el máximo común divisor de dos enteros positivos, o el método de Gauss para resolver un sistema lineal de ecuaciones.”[1]

Aunque el concepto de algoritmo sea de gran utilidad para resolver problemas de índole secuencial, no es así como funciona el sistema más adepto para la resolución de problemas en todo el universo conocido: el cerebro humano. De hecho ningún cerebro opera de acuerdo al modelo algorítmico.

Aquí vemos un algoritmo típico para descubrir por qué la lámpara no funciona. La metodología del algoritmo es muy útil para resolver problemas que se prestan a ello. Nos resulta “natural” porque es secuencial igual en apariencia igual que el lenguaje humano – digo en apariencia porque gran parte de la comunicación humana se lleva a cabo de forma no-verbal, en los gestos, en el tono, en el ritmo de comunicación, e incluso a nivel subliminal en las feromonas, en los instintos, en las intuiciones – y ninguna de esas es por su naturaleza algorítmica. Vemos una película y seguimos la secuencia de las frases compuestas por secuencias de palabras a su vez compuestas por secuencias de silabas y a su vez de letras, pero no olvidemos que simultáneamente nuestros ojos y nuestros oídos está tomando una enorme cantidad de información visual y auditiva (música, ruidos) que se presenta no de forma solamente lineal, secuencial, sino simultanea.

En el departamento de Ciencias Cognitivas de la Universidad de California, San Diego, aprendí un nuevo paradigma para la representación del conocimiento integrado en, y del procesamiento de información por, un sistema: el denominado modelo de “procesamiento distribuido en paralelo”. Efectivamente, lo que sucede en las redes neuronales de cualquier cerebro es que varios, numerosos, estímulos sensoriales activan redes perceptivas que operan en conjunto, en paralelo, procesando la información no en una secuencia algorítmica, sino a través de otra metodología completamente distinta, una metodología de procesamiento distribuido en unidades – neuronas – en paralelo cada una contribuyendo con su activación – ya sea de excitación, de inhibición, o de modulación, hacia la resolución del problema. Así por ejemplo, oímos un ruido que se destaca de entre los demás que nos acosan y conforme miramos en la dirección del mismo la mente revisa sus bases de datos interiores a la vez que los sentido toman información del exterior – en paralelo – para una explicación que puede venir antes, durante o después de la indagación visual; mientras tanto, una cascada de eventos internos – secreción de hormonas como la adrenalina nos baña nuestro ambiente interior prestando al sistema fisiológico para una lucha a muerte o una fuga en evasión de la misma.

El paradigma del procesamiento distribuido en paralelo tiene sus orígenes en un estudio de la realidad biológica-cognitiva de las redes neuronales de los animales (incluyendo los seres humanos) y dio lugar a la tecnología de las denominadas redes neuronales artificiales o RDA, que suponen un nuevo avance en la inteligencia artificial. La “solución” al problema – el “conocimiento” del sistema – ya no está en los pasos de un algoritmo, sino en las fuerzas y naturaleza de las conexiones entre las capas de redes neuronales artificiales. Para las redes neuronales artificiales hay un proceso inicial de “entrenamiento” de la red – ajuste del valor de las conexiones – durante el cual se aplican diversos algoritmos (ahora sí) al valor de las mismas para llegar a una combinación óptima que resuelva el problema dado:

Con un paradigma convencional de programación en ingeniería del software, el objetivo del programador es modelar matemáticamente (con distintos grados de formalismo) el problema en cuestión y posteriormente formular una solución (programa) mediante un algoritmo codificado que tenga una serie de propiedades que permitan resolver dicho problema. En contraposición, la aproximación basada en las RNA parte de un conjunto de datos de entrada suficientemente significativo y el objetivo es conseguir que la red aprenda automáticamente las propiedades deseadas. En este sentido, el diseño de la red tiene menos que ver con cuestiones como los flujos de datos y la detección de condiciones, y más que ver con cuestiones tales como la selección del modelo de red, la de las variables a incorporar y el preprocesamiento de la información que formará el conjunto de entrenamiento. Asimismo, el proceso por el que los parámetros de la red se adecuan a la resolución de cada problema no se denomina genéricamente programación sino que se suele denominar entrenamiento neuronal.

Por ejemplo en una red que se va a aplicar al diagnóstico de imágenes médicas; durante la fase de entrenamiento el sistema recibe imágenes de tejidos que se sabe son cancerígenos y tejidos que se sabe son sanos, así como las respectivas clasificaciones de dichas imágenes. Si el entrenamiento es el adecuado, una vez concluido, el sistema podrá recibir imágenes de tejidos no clasificados y obtener su clasificación sano/no sano con un buen grado de seguridad. Las variables de entrada pueden ser desde los puntos individuales de cada imagen hasta un vector de características de las mismas que se puedan incorporar al sistema (por ejemplo, procedencia anatómica del tejido de la imagen o la edad del paciente al que se le extrajo la muestra).[2]

El estudio del paradigma del procesamiento distribuido en paralelo me otorgó un conocimiento nuevo y muy importante para continuar en mi afán de la creación de una herramienta para modelar todo tipo de sistemas, al igual que me ayudó a comprender la naturaleza de sistemas mismos. Pero inmediatamente detecté lo que consideré una falla significativa en ese paradigma.

Se continuará…

[1] http://es.wikipedia.org/wiki/Algoritmo

[2] http://es.wikipedia.org/wiki/Red_neuronal_artificial

ANOTACIÓN 2012 Serie 1 No 6 - 21 de febrero, 2012

ANOTACIÓN 2012 Serie 1 No 7: 21 de febrero, 2012

HACIA LA PRIMERA GENERACIÓN DE PROTOTIPOS DE VIPERS:

INTEGRANDO EL CAMPO MATEMÁTICO DE LA OPTIMIZACIÓN – INVESTIGACIÓN DE OPERACIONES – CON EL DISEÑO Y ANÁLISIS DE SISTEMAS:

¿Qué es la “investigación de operaciones” (IO)?

“La INVESTIGACIÓN DE OPERACIONES o INVESTIGACIÓN OPERATIVA es una rama de las matemáticas consistente en el uso de MODELOS MATEMÁTICOS, ESTADÍSTICA y ALGORITMOS con objeto de realizar un PROCESO DE TOMA DE DECISIONES. Frecuentemente trata del estudio de COMPLEJOS SISTEMAS REALES, con la finalidad de MEJORAR (u OPTIMIZAR) su FUNCIONAMIENTO. La investigación de operaciones permite el análisis de la toma de decisiones teniendo en cuenta la escasez de recursos, para determinar cómo se puede optimizar un objetivo definido, como la maximización de los beneficios o la minimización de costes.[1]

He decido tomar un camino concreto en la creación de VIPERS, un camino concreto y pragmático mediante la creación de sucesivos prototipos hacia la primera “generación” del producto. La idea aquí es de tomar ejemplos de sistemas optimizados por la aplicación de técnicas propias de la disciplina denominada “investigación de operaciones” con el triple fin de: 1) desarrollar la metodología diagramática al punto de poder representar sistemas reales; 2) lograr simulacros de esos mismo sistemas cuyos detalles operacionales sirvan de validación y verificación del sistema VIPERS; y 3) incorporar a la programación de VIPERS, a modo de Sistema Experto, la función o característica de la optimización en el diseño de nuevos sistemas y el análisis de sistemas existentes.

Comenzamos con la primera generación de “VIPERS Programación Lineal” – la programación lineal siendo una sub-disciplina dentro de la Investigación de Operaciones. Se trata para comenzar, de discernir numerosos ejemplos claves de problemas resueltos a través del método de la programación lineal para luego abordar la fase de creación de sucesivos prototipos. Introduzco de esta forma un primer problema conocido como el “Problema del Catering de Servilletas” en la siguiente anotación:

[1] Adaptado del artículo de wikipedia: http://es.wikipedia.org/wiki/Investigación_de_operaciones

ANOTACIÓN 2012 Serie 1 No 7: 22 de febrero, 2012

VIPERS: Especificaciones para la primera generación de prototipos.

El “Problema de Catering de Servilletas”

Fuente: “An Illustrated Guide to Linear Programming” de Saul I. Gass

El problema:

Un servicio de catering quiere determinar cuántas servilletas debe comprar y cuantas sucias debe mandar para lavar de forma que tenga suficientes servilletas para cumplir con un cliente que tiene un “tea party” los siete días de la semana. El servicio quiere lograr un equilibrio apropiado entre las compras de nuevas servilletas y el lavado de las usadas para minimizar el costo total de su gasto de servilletas.

El plan requiere que se adapte la técnica de investigación de operación conocida como “programación lineal” al problema del servicio de catering de forma que una vez que sea optimizado el flujo de servilletas, extender el análisis a otros elementos de las operaciones del servicio, como por ejemplo el flujo de comida, de bebidas, de invitados, etc.

Recolecta de datos respecto a una semana típica:

Se precisa de una fase inicial de recolecta de data para determinar lo que sería una semana típica en cuanto al número de personas atenderían el “tea party” cada día de la semana es:

1. lunes – 5.

2. martes – 6.

3. miércoles – 7.

4. jueves - 8.

5. viernes – 7.

6. sábado – 9.

7. domingo – 10.

Gastos:

La compra de una servilleta nueva puede lograrse el mismo día deseado y entregado a tiempo con un costo de 25 centavos de dólar por servilleta; la entrega es gratis. Hay dos lavanderías en el área que han sido puestas a prueba y aprobadas. La lavandería “Rey” puede lavar una servilleta en dos días y cobran 15 centavos de dólar por servilleta; mientras que la lavandería “Princesa” tarda tres días y cobra 10 centavos de dólar por servilleta. Suponiendo que hemos quemado todas servilletas viejas y no tenemos ninguna a mano, tenemos que construir un modelo de programación lineal para la data de forma que cada día para cada “tea party” de la semana se entreguen las servilletas adecuadas con un costo mínimo para la empresa.

Anotación:

Primero vamos a formular nuestra anotación. Dejemos que n₁, n₂, n₃, n₄, n₅, n₆, n₇ representen el número de servilletas nuevas que se vayan a comprar el lunes, el martes, el miércoles, etc., hasta el séptimo día de la semana, domingo. Las servilletas que se mandarán a la lavandería Rey cada día de la semana se denotarán por r₁, r₂, r₃, r₄, r₅, r₆, r₇ y las servilletas que se mandarán a la lavandería Princesa cada día de la semana se denotarán por p₁, p₂, p₃, p₄, p₅, p₆, p₇; finalmente representaremos por s₁, s₂, s₃, s₄, s₅, s₆, s₇ las servilletas usadas (sucias) que no se mandaron a lavar cada día de la semana. Queremos minimizar el costo total de mantener el inventario apropiado de servilletas limpias puesto que no es económico comprar más servilletas de las que se necesiten para el mismo día, o mandar a lavar una servilleta al menos que sea usada en un tiempo futuro.

Formulación:

Lunes:

Para el primer día de la operación, o sea para el lunes, debemos comprar exactamente el número de servilletas que precisamos. Puesto que esperamos cinco invitados, concluimos que

n₁ = 5.

Al final de la fiesta del lunes, podemos escoger mandar todas o algunas de las 5 servilletas sucias a la lavandería rápida Rey (y cara), a la lavandería lenta Princesa (y barata), o dejarlas que permanezcan sucias en el lavandero. Lo que sucede con estas cinco servilletas puede ser representada por la ecuación:

r₁ + p₁ + s₁ = 5

El costo total del primer día de operaciones (lunes) es de:

25n₁ + 15r₁ +10p₁

El problema consiste en determinar exactamente cuáles valores numéricos asignar a las variables del programa – hasta ahora tenemos r₁, p₁, s₁y n₁, con n₁= 5. Una vez que tengamos todas ecuaciones correspondientes a nuestro plan, los procedimientos computacionales de la programación lineal pueden aplicarse para encontrar la solución de mínimo costo. Después desarrollamos el resto de las restricciones del modelo, recordando que las servilletas lavadas estarán devueltas al sistema en dos o tres días dependiendo de cual servicio de lavandería se empleó: las servilletas del Rey del primer día (lunes) se enviarán el lunes y regresarán a tiempo para ser usadas el miércoles, mientras que las del la lavandería Princesa estarán listas para el jueves. También las servilletas que no se manden a lavar el lunes pueden ser enviadas al día siguiente.

Martes:

Ninguna de las servilletas que se manden a lavar estaría listas para el martes, por lo tanto para ese día, debemos comprar el número requisito de servilletas, o sea:

n₂ = 6.

Después de que estas servilletas hayan sido usadas (o sea, las servilletas del martes), las acciones tomadas de disponer de estas 6 servilletas, y el montón de servilletas sucias del lunes s₁, se describe con la siguiente ecuación:

r₂ + p₂ + s₂ = n₂ + s₁

Puesto que n₂ = 6, quedamos con:

r₂ + p₂ + s₂ = 6 + s₁

La última ecuación indica que ahora tenemos un stock de servilletas que incluye las sucias s₁ del lunes y seis más del martes que pueden o ser lavadas o apartadas en el montón de servilletas sucias. El costo de la operación del martes es:

(25n₂ + 15r₂ + 10p₂) centavos de dólar

Miércoles:

Para el evento del miércoles se precisan 7 servilletas. Este es el primer día en el cual las servilletas lavadas del lavado rápido de Rey pueden integrarse al servicio del cliente. Por lo tanto las 7 servilletas requeridas pueden obtenerse o por compra y/o mediante la cantidad enviada al servicio de lavado rápido de Rey el primer día (lunes). Por lo tanto tenemos:

n₃ + r₁ = 7

Igual que antes tenemos:

r₃ + p₃ + s₃ = n₃ + s₂

Puesto que n₃ = 7, quedamos con:

r₃ + p₃ + s₃ = 7 + s₂

Y el costo de la operación del miércoles es:

(25n₃ + 15r₃ + 10p₃) centavos de dólar

Jueves:

Las ocho servilletas que se precisan para el jueves pueden ser servilletas nuevas o servilletas lavadas que han sido devueltas del envío de servilletas sucias del martes a la lavandería del Rey o del envío de servilletas sucias del lunes enviada a la lavandería de la Princesa; esto se representa por:

n₄ + r₂ + p₁ = 8

Con

r₄ + p₄ + s₄ = 8 + s₃

y un costo los jueves de

(25n₄ + 15r₄ + 10p₄) centavos de dólar;

Ahora podemos continuar para escribir el resto de las ecuaciones de nuestro modelo de forma directa. Vamos a suponer para los propósitos de la discusión presente que estamos interesados en una forma eficiente de catering para solamente una semana de “tea parties”, y por lo tanto, ningún envío de lavandería será llevado a cabo si no puede ser devuelto para usar el domingo, el último día de la semana.

Viernes:

A continuación para el viernes tenemos las siguientes ecuaciones:

n₅ + r₃ + p₂ = 7

r₅+ s₅ = 7 + s₄

{Nota aclaratoria: la lavandería Princesa no se emplea a partir del jueves porque tarda 3 días en devolver el encargo, y no estaría sino para el lunes y por lo tanto fuera del dominio de nuestro modelo.}

Con un costo de:

(25n₅ + 15r₅) centavos de dólar;

Sábado:

Y para el sábado:

n₆ + r₄ + p₃ = 9

s₆ = 9 + s₅

Con un costo de:

(25n₆) centavos de dólar;

Domingo:

Y para el domingo:

n₇ + r₄ + p₄ = 10

s₆ = 10 + s₆

Con un costo de:

(25n₇) centavos de dólar.

Tabla de decisiones:

Cada día el servicio de catering tiene varias decisiones que tomar para abastecer a las necesidades de servilletas para su cliente en sus “tea parties”:

1) Comprar servilletas nuevas (n);

2) Enviar servilletas usadas a la lavandería Rey (r);

3) Enviar servilletas a la lavandería Princesa (p);

4) Dejar las servilletas para el montón de la ropa sucia (s).

Resumen de decisiones y eventos:

servilletas	lunes	martes	miércoles	jueves	viernes	sábado	domingo
Comprar nuevas	n₁=5	n₂=6	n₃	n₄	n₅	n₆	n₇
Enviar a Rey	r₁	r₂	r₃	r₄	r₅	r₆= 0	r₇= 0
Enviar a Princesa	p₁	p₂	p₃	p₄	p₅ = 0	p₆ = 0	p₇ = 0
Dejar sucias	s₁	s₂	s₃	s₄	s₅	s₆	s₇
Lavadas	0	0	r₁	r₂ + p₁	r₃+ p₂	r₄+ p₃	r₅+ p₄
Total	t₁=5	t₂= 6	t₃ = 7	t₄= 8	t₅ = 7	t₆ = 8	t₇ = 10

Resumiendo:

Juntando las anteriores ecuaciones, vemos que el problema consiste en encontrar los valores correspondientes a las variables n, r, p, y s (estos valores tienen que ser números enteros o cero, es decir, números no-negativos) las cuales minimicen el costo de la función:

25 (n₁+ n₂+ n₃+ n₄+ n₅+ n₆+ n₇) + 15 (r₁+ r₂+ r₃+ r₄+ r₅) + 10 (p₁+ p₂+ p₃+ p₄) y satisfaga las siguientes ecuaciones lineales:

TABLA DE ECUACIONES LINEALES PARA RESOLVER EL PROBLEMA DEL SERVICIO DEL CATERING
FACTORES	n	r	p	s		No de servilletas	s
1	n₁				=	5
2	n₂				=	6
3	n₃	+ r₁			=	7
4	n₄	+ r₂	+ p₁		=	8
5	n₅	+ r₃	+ p₂		=	7
6	n₆	+ r₄	+ p₃		=	9
7	n₇	+ r₅	+ p₄		=	10
8		r₁	+ p₁	+ s₁	=	5
9		r₂	+ p₂	+ s₂	=	6	+ s₁
10		r₃	+ p₃	+ s₃	=	7	+ s₂
11		r₄	+ p₄	+ s₄	=	8	+ s₃
12		r₅		+ s₅	=	7	+ s₄
13				s₆	=	9	+ s₅
14				s₇	=	10	+ s₆

Solución optima:

Resueltas las anteriores ecuaciones lineales se verifica que por un costo mínimo de $8.80, con solamente 21 servilletas nuevas compradas, se puede servir a un total de 52 huéspedes durante el periodo de la semana descrita.

COMPRAS Y ENCARGOS PARA UNA SEMANA TÍPICA DEL PROBLEMA DE CATERING PARA EL TEA PARTY
lunes	n₁ = 5			s₁ = 0
martes	n₂= 6			s₂ = 0
miércoles	n₃= 6	r₁ = 0		s₃ = 0
jueves	n₄= 3	r₂ = 0	p₁ = 5	s₄ = 0
viernes	n₅= 0	r₃ = 1	p₂ = 6	s₅ = 2
sábado	n₆= 0	r₄ = 3	p₃ = 6	s₆ = 9
domingo	n₇= 0	r₅ = 5	p₄ = 5	s₇ = 10
Totales	21	9	22	21

Costo total: 21 x 0.25 + 9 x 0.15 + 22 x 0.10 = $8.80

Los mecanismos algebraicos de la solución las dejamos aparte. Aún con las simplificaciones descritas (ej.: limite de una semana de operaciones) aquí el lector puede apreciar el valor pragmático de la disciplina de investigación operativa (en este caso empleando el método de “programación lineal”) en la toma de decisiones para minimizar costos y a la vez cumpliendo con los requisitos de un problema real.

CONCLUSIÓN:

La meta de VIPERS, con el estudio del campo de la Investigación Operativa, consiste precisamente en incorporar automáticamente 1) durante la fase del diseño de un sistema nuevo, o 2) del análisis y simulacro de un sistema existente, la optimización del empleo de recursos disponibles, incluyendo la minimización de costos.