jueves, 24 de mayo de 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á.
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á…
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:
Suscribirse a:
Entradas (Atom)