¿por qué un OPS (Official Production System) no soporta el tipo vector además del tipo escalar en las ranuras de las plantillas?
Mi inteligencia viene a decir que tener una memoria de hechos de tamaños variables es simulada de I.A. mejor que con una de hechos de tamaños fijos.
Un ejemplo típico a simular en OPS podría ser el Block World del brazo de robot, en donde se apilan bloques en determinadas columnas.
Tales apilamientos necesitan el uso de vectores en las ranuras de los hechos mejor que hacer malabarismos con una expansión en horizontal de hechos con identificadores de posición de cada bloque.
Mi recomendación sería que un OPS soportase tipos vectores en las ranuras de las plantillas, sin importar las críticas de la ineficiencia del algoritmo de matching cuando se usa esta característica faltante.
Es decir, el tipo vector obliga a cambiar la implementación del algoritmo de matching, y no al revés, nunca hacer que el algoritmo de matching impida añadir esta característica muy funcional de I.A. de soportar tipos vectores además de tipos escalares.
En principio, irá a ser una versión muy simple, vector de escalares. Las complicaciones de las implementaciones de la característica de vectores de vectores se tendrán que esperar hacia más adelante según la necesidad pronta del ingeniero de conocimiento en determinadas áreas de I.A.
Para el procesador ecológico, un ejemplo de intérprete o compilador de un lenguaje de programación de muy altísimo nivel podría ser:
ResponderEliminar* Prototype Oriented Programming + Rules Engine.
Así podré programar aplicaciones tanto en sentencias de POP como en reglas de RE de una forma integrada.
Es paradoja de que a mayor nivel de lenguaje de programación, menor será las KLocs de aplicaciones, o mayor grado será la reusabilidad de las componentes de sus librerías.
La búsqueda exhaustiva no es una característica obligatoria de la RE. La RE da algunos consejos lógicamente válidos si puede, o en otro caso solicitará más ciclos de CPU o el aborto de su ejecución. Una vez encontrada sus cadenas de producciones de soluciones, podrían ser cacheadas en la base de datos o en los ficheros para evitar un despilfarro de ciclos de CPU en las siguientes re-ejecuciones de procesos.