Python is NOT Java

Este post de PJ Eby me pareció genial y resume muchas de las diferencias importantes entre Java y Python.

Python Is Not Java
I was recently looking at the source of a wxPython-based GUI application, about 45.5KLOC in size, not counting the libraries used (e.g. Twisted). The code was written by Java developers who are relatively new to Python, and it suffers from some performance issues (like a 30-second startup time). In examining the code, I found that they had done lots of things that make sense in Java, but which suck terribly in Python. Not because "Python is slower than Java", but because there are easier ways to accomplish the same goals in Python, that wouldn't even be possible in Java.

So, the sad thing is that these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write, that then performs much more slowly than the equivalent idiomatic Python would. Some examples:
A static method in Java does not translate to a Python classmethod. Oh sure, it results in more or less the same effect, but the goal of a classmethod is actually to do something that's usually not even possible in Java (like inheriting a non-default constructor). The idiomatic translation of a Java static method is usually a module-level function, not a classmethod or staticmethod. (And static final fields should translate to module-level constants.)

This isn't much of a performance issue, but a Python programmer who has to work with Java-idiom code like this will be rather irritated by typing Foo.Foo.someMethod when it should just be Foo.someFunction. But do note that calling a classmethod involves an additional memory allocation that calling a staticmethod or function does not.

Oh, and all those Foo.Bar.Baz attribute chains don't come for free, either. In Java, those dotted names are looked up by the compiler, so at runtime it really doesn't matter how many of them you have. In Python, the lookups occur at runtime, so each dot counts. (Remember that in Python, "Flat is better than nested", although it's more related to "Readability counts" and "Simple is better than complex," than to being about performance.)

Got a switch statement? The Python translation is a hash table, not a bunch of if-then statments. Got a bunch of if-then's that wouldn't be a switch statement in Java because strings are involved? It's still a hash table. The CPython dictionary implementation uses one of the most highly-tuned hashtable implementations in the known universe. No code that you write yourself is going to work better, unless you're the genetically-enhanced love child of Guido, Tim Peters, and Raymond Hettinger.

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling. But in Python, more often than not, code is easier to write than XML. And Python can process code much, much faster than your code can process XML. (Not only that, but you have to write the XML processing code, whereas Python itself is already written for you.)

If you are a Java programmer, do not trust your instincts regarding whether you should use XML as part of your core application in Python. If you're not implementing an existing XML standard for interoperability reasons, creating some kind of import/export format, or creating some kind of XML editor or processing tool, then Just Don't Do It. At all. Ever. Not even just this once. Don't even think about it. Drop that schema and put your hands in the air, now! If your application or platform will be used by Python developers, they will only thank you for not adding the burden of using XML to their workload.

(The only exception to this is if your target audience really really needs XML for some strange reason. Like, they refuse to learn Python and will only pay you if you use XML, or if you plan to give them a nice GUI for editing the XML, and the GUI in question is something that somebody else wrote for editing XML and you get to use it for free. There are also other, very rare, architectural reasons to need XML. Trust me, they don't apply to your app. If in doubt, explain your use case for XML to an experienced Python developer. Or, if you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!)

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.

In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.

Code duplication is quite often a necessary evil in Java, where you must often write the same method over and over with minor variations (usually because of static typing constraints). It is not necessary or desirable to do this in Python (except in certain rare cases of inlining a few performance-critical functions). If you find yourself writing the same function over and over again with minor variations, it's time to learn about closures. They're really not that scary.

Here's what you do. You write a function that contains a function. The inner function is a template for the functions that you're writing over and over again, but with variables in it for all the things that vary from one case of the function to the next. The outer function takes parameters that have the same names as those variables, and returns the inner function. Then, every place where you'd otherwise be writing yet another function, simply call the outer function, and assign the return value to the name you want the "duplicated" function to appear. Now, if you need to change how the pattern works, you only have to change it in one place: the template.

In the application/platform I looked at, just one highly trivial application of this technique could have cut out hundreds of lines of deadweight code. Actually, since the particular boilerplate has to be used by developers developing plugins for the platform, it will save many, many more hundreds of lines of third-party developer code, while simplifying what those developers have to learn.
This is only the tip of the iceberg for Java->Python mindset migration, and about all I can get into right now without delving into an application's specifics. Essentially, if you've been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python. Take a step back, and above all, stop writing so much code.

To do this, become more demanding of Python. Pretend that Python is a magic wand that will miraculously do whatever you want without you needing to lifting a finger. Ask, "how does Python already solve my problem?" and "What Python language feature most resembles my problem?" You will be absolutely astonished at how often it happens that thing you need is already there in some form. In fact, this phenomenon is so common, even among experienced Python programmers, that the Python community has a name for it. We call it "Guido's time machine", because sometimes it seems as though that's the only way he could've known what we needed, before we knew it ourselves.

So, if you don't feel like you're at least ten times more productive with Python than Java, chances are good that you've been forgetting to use the time machine! (And if you miss your Java IDE, consider the possibility that it's because your Python program is much more complex than it needs to be.)

Resolución de problemas a través de búsqueda

Agentes 

Los agentes más sencillos son los agentes reflejos, que basan sus acciones en un mapeo directo de estados a acciones.

Los agentes reflejos no pueden operar bien en ambientes en los cuales el mapeo de relaciones estado->acción es demasiado grande y toma demasiado tiempo aprender las relaciones.

Los agentes basados en metas consideran acciones futuras y el nivel en que los resultados de esas acciones resultan deseables.

Los agentes resolvedores de problemas usan representaciones atómicas - esto significa que los estados del mundo son considerados unidades enteras, cajas negras que no tienen estructura interna visible para los algoritmos resolvedores de problemas.

Para discutir la resolución de problemas es necesario definir con precisión a los problemas y sus soluciones. Existen varios algoritmos de búsqueda de propósito general que pueden ser usados para resolver problemas.

Algoritmos de Búsqueda Informados y No Informados

Los algoritmos de búsqueda no informados son aquellos que sólo reciben como información del problema su definición. Los algoritmos de búsqueda no informados pueden resolver cualquier problema que sea resoluble, pero ninguno de ellos puede hacerlo eficientemente, operan a manera de la fuerza bruta. Los algoritmos de búsqueda en profundidad (DFS - depth first search) y búsqueda en anchura (BFS - breadth first search) son algoritmos de búsqueda no informados, al igual que la búsqueda de costo uniforme (UCS - uniform cost search). Un algoritmo no informado sólo es capaz de distinguir entre un estado que sea meta y aquellos que no lo son. Un algoritmo no informado genera sucesiones de estados sin distinguir cuál de los siguientes estados es más prometedor para alcanzar la solución final.

Los algoritmos de búsqueda informada reciben cierta guía para saber dónde empezar a buscar soluciones, lo que, en muchos casos, aumenta la eficiencia en tiempo de cómputo. Estas guías son a menudo heurísticas que son derivadas de la observación cuidadosa del problema y tienden a ser específicas a él. El algoritmo A* ("A star" o "A estrella") es un algoritmo de búsqueda informada de caminos que comúnmente se implementa usando la heurística de Distancia Manhattan. Un algoritmo informado genera sucesiones a los estados en base a un criterio que determina cuales estados son más prometedores para alcanzar la solución final.

Fuente: AIMA, Capítulo 3.

El problema de la mochila como problema de programación dinámica

Intro

El problema de la mochila tiene solución como problema de programación dinámica manejado en base a un tabla en la cual cada elemento es considerado consecutivamente.

El problema también puede ser atacado generando una tabla en la que la mochila óptima para cada capacidad posible en la mochila sea generada, esta solución está modelada en base a la solución encontrada en el libro de Sedgewick sobre Algoritmos en Java y la solución propuesta en los tutoriales de TopCoder.

Solución Bottom-up con Tabla 


Se puede construir una tabla de (nItems+1) filas y (capacidad+1) columnas. La fila 0 se deja como una fila sentinela (para representar consistentemente el caso en que se tiene 0 elementos y la capacidad es también de 0 en peso).

La variable j indica el número de elementos que se tiene para llenar la mochila. Wi y Vi indican el peso y valor de cada elemento.

Cada celda [nItems][capacidad] indica la solución óptima para las restricciones de peso y valor colocadas. La celda [4][5] indica el valor de la solución óptima (el máximo valor obtenido) para la mochila de 4 ítems y capacidad de peso 5. 

En los libros Fundamentals of Algorithmcs de Brassard y Bratley e Introduction to the Design & Analysis of Algorithms de Levitin aparecen las reglas para llenar la tabla y obtener el contenido de la mochila óptima.


Modelos para una Solución Top-down

Sedgewick presenta una solución recursiva de programación dinámica usando memoización. El vector global maxKnown[] contiene el valor para la mochila con el peso representado por su subíndice. La generación de la mochila se hace con el vector global itemKnown[]. La solución recursiva inicia invocando la función para la capacidad de la mochila.

En la recursión, si la celda actual del vector global aparece como no calculada, se llena con llamadas recursivas para los subíndices inferiores, esto es el comportamiento estándar para una función memoizada. En este caso, se busca el mejor ítem para optimizar el valor para esta capacidad de la mochila. Recuérdese que "valor" significa aquí la preciación total de los elementos en la mochila. Hay un falla menor en la función presentada aquí y es que no encuentra solución si los ítems disponibles no llenan completamente la mochila. Para superar esta limitación se puede suplementar a la mochila con un ítem de peso uno y valor cero para asegurar una solución.

El cuerpo de esta función de memoización recursiva también podría servir de base para una implementación bottom-up: esto se haría llenando los vectores empezando en el peso 1 y subiendo hasta completar la capacidad de la mochila. Esto llena todas las celdas, mientras que la implementación basada en función memoizada sólo llena las celdas requeridas para la solución final.

El siguiente código es una solución dinámica en Java para el problema entero de la mochila:


static int knap (int c, int [] solution)
{  int i, space, m, t, 
        maxKnown[], itemKnown[];


       itemKnown = new int [c+1];
       maxKnown = new int [c+1];
       // se asume que el arreglo maxKnown está lleno con ceros
       for (m=1; m<=c; m++)
           for (i=1; i<=n; i++)
              if ( (space = m-weight[i]) >= 0 )
         {  t = maxKnown[space] + profit[i];
            // Dummy:  wt 1, value 0
            if ( t >= maxKnown[m] )
            {  maxKnown[m]  = t;
               itemKnown[m] = i;
            }
         }
// el estado de solution[] es desconocido, así que se hace:
   java.util.Arrays.fill (solution, 0);
 for (m=c; m>0 ; m-=weight[itemKnown[m]] )
      solution[itemKnown[m]]++;
   return maxKnown[c];
}

Pendulum Waves

Composite Entity


Contexto


Los beans de entidad no tienen como intención representar a cada objeto persistente en el modelo de objeto.


Los beans de entidad son más apropiados para los objetos de modelo de negocio persistentes de grano grueso.


Problema


En las aplicaciones J2EE, los clientes (aplicaciones, JSPs, servlets y JavaBeans) accesan a los entity beans a través de sus interfaces remotas. Así, cada invocación de cliente se enruta a través de networks stubs y esqueletos, aún si el cliente y el enterprise bean estén en la misma JVM, SO o máquina física. Cuando los beans de entidad son objetos de grano fino, los clientes tienden a invocar a más métodos de entity beans, resultando en una alta carga en la red.


Los beans de entidad representan objetos de negocio persistentes y distribuidos. Si se está desarrollando o migrando una aplicación a J2EE, la granularidad de los objetos es importante al momento de decidir qué debe ser implementado como un entity bean. Los entity beans deberían representar objetos de negocio de grano grueso, aquellos que proveen comportamiento complejo, más allá del comportamiento getter y setter de variables de instancia. Estos objetos de grano grueso típicamente tienen objetos dependientes. Un objeto dependiente es un objeto que no tiene dominio real cuando no está asociado con su padre de grano grueso.


Un problema recurrente es el mapeo directo del modelo de objeto a un modelo EJB (específicamente a los entity beans). Esto crea una relación entre los objetos entity beans sin consideración de la granularidad de los objetos: hay objetos de grano fino(dependientes) y de grano grueso (que deben englobar a los de grano fino que estén utilitariamente relacionados). Determinar que funcionalidad es grano fino y de grano grueso es típicamente difícil y es mejor hacerlo mediante relaciones de modelado UML.


Hay un número de áreas impactadas por el criterio de diseño de entity beans de grano fino:


* Relaciones entre las entidades - mapear directamente un modelo de objetos a un modelo EJB no toma en consideración las relaciones entre los objetos. Las relaciones entre objetos son transformadas directamente en relaciones  inter-entidad de beans. Como resultado, un entity bean podría contener una referencia remota a otro entity bean. Sin embargo, mantener referencias remotas a objetos distribuidos involucra técnicas y semánticas diferentes que mantener referencias a objetos locales. Además de incrementar la complejidad del código, reduce su flexibilidad, porque el entity bean debe cambiar si hay cambios en sus relaciones. 


También, no hay garantía acerca de la validad de las referencias de los entity beans a otros entity beans a lo largo del tiempo. Dichas referencias son establecidas dinámicamente usando el objeto home de la entidad y la clave primaria para esa instancia del entity bean. Esto implica una alta carga de mantenimiento de validación de referencias para cada referencia entidad-bean-entidad-bean. 


* Manejabilidad - La implementación de objetos de grano fino como entiy beans resulta en un gran número de entity beans en el sistema. Un entity bean se define usando varias clases. Por cada componente entity bean, el desarrollador debe suministrar clases para la interface home, la interface remota, la implementación del bean y la clave primaria.


Adicionalmente, el contenedor puede generar clases para soportar la implementación del entity bean. Cuando el bean es creado, estas clases son realizadas como objetos reales en el contenedor. En resumen, el contenedor crea un número de objetos para soportar cada instancia de entity bean. Grandes números de entity beans resultan en más clases y código que mantener para el equipo de desarrollo. También resulta en un gran número de objetos en el contenedor. Esto puede afectar negativamente el desempeño de la aplicación.


* Carga en la Red - Los entity beans de granularidad fina potencialmente tienen más relaciones inter-entity beans. Los entity beans son objetos distribuidos. Cuando un entity bean invoca un método en otro entity bean, la llamada es tratada potencialmente como una llamada remota por el contenedor, incluso si ambos entity beans están en el mismo contenedor o JVM. Si el número de relaciones entity-bean-entity-bean se incrementa, esto baja la escabilidad del sistema debido a una alta congestión en la red.


* Dependencia del Esquema de Base de Datos - cuando los entity beans son de granularidad fina, cada instancia de entity bean usualmente representa una única fila en la base de datos. Esto no es una aplicación apropiada del diseño del entity bean, debido que los entity beans son más apropiados para los componentes de granularidad gruesa. La implementación de entity beans de granularidad fina típicamente es una representación directa del esquema de la base de datos en el diseño del entity bean. Cuando los clientes usan estos entity beans de granularidad fina, están operando en el nivel más bajo de la base de datos, debido que cada entity bean es efectivamente una única fila. Debido que el entity modela directamente una única fila de la base de datos, los clientes se hacen dependientes del esquema de la base de datos. Cuando el esquema cambia, las definiciones de los entity beans deben cambiar también. Además, debido que los clientes están operando en la misma granularidad, ellos deben observar este cambio y reaccionar a él. Esta dependencia del esquema causa pérdida de flexibilidad e incrementa el costo de mantenimiento cada vez que los cambios en el esquema de la bd son requeridos.


* Granularidad de los Objetos (Granularidad Gruesa vs Granularidad Fina) - La granularidad de los objetos impacta la transferencia de datos entre el enterprise bean y el cliente. En la mayor parte de las aplicaciones, los clientes típicamente requieren más información que una o dos filas de una tabla. En dicho caso, implementar cada uno de estos objetos de granularidad fina como un entity bean significa que el cliente tendría que manejar las relaciones entre todos estos objetos de granularidad fina. Dependiendo de los requerimientos de data, los clientes puede que tengan que realizar muchas búsquedas para un número de entity beans para obtener la información requerida.


Fuerzas 


*Los entity beans son mejor implementados como objetos de granularidad gruesa debido al alto costo asociado con cada entity bean. Cada entity bean es implementado usando varios objetos, tal como un objeto home EJB, un objeto remoto, implementación del bean y una clave primaria. Cada uno de estos objetos necesarios para implementar al entity bean es manejado por los servicios contenedores.


* Las aplicaciones que mapean directamente el esquema de la base de datos a entity beans (donde cada fila en una tabla es representada por una instancia de entity bean) tienden a tener un gran número de entity beans de grano fino. Es deseable mantener a los entity beans como entity beans de grano grueso y reducir el número de entity beans en la aplicación.


* El  mapeo directo del modelo de objeto al objeto EJB resulta en entity beans de grano fino. Los entity beans de grano fino usualmente se mapean al esquema de la base de datos. Este mapeo de filas entidad-a-bd causa problemas relacionados con performance, manejabilidad, seguridad y manejo de transacciones. Las relaciones entre tablas son implementadas como relaciones entre entity beans, lo que significa que los entity beans contienen referencias a otros entity beans para implementar estar relaciones de grano fino. Es muy costoso manejar las relaciones entre entity beans, debido que estas relaciones deben ser establecidas dinámicamente usando los objetos home de entidad y las claves primarias de los enterprise beans.


*Los clientes no necesitan saber la implementación del esquema de la base de datos para usar y soportar a los entity beans. Con entity beans de grano fino, el mapeo es usualmente hecho de forma tal que cada instancia de entity bean se mapee a una única fila en la base de datos. Este mapeo de granularidad fina crea una dependencia entre el cliente y el esquema subyacente de la base de datos, debido que los clientes interactúan con los beans de grano fino y son, esencialmente, una representación directa del esquema subyacente de la base de datos. Esto resulta en un alto acoplamiento entre el esquema de la base de datos y los entity beans. Una cambio al esquema causa un cambio correspondiente al entity bean y requiere además un cambio correspondiente a los clientes.


*Hay un incremento de comunicación entre aplicaciones debido a la intercomunicación entre entity beans de granularidad fina. La comunicación excesiva inter-entity beans a menudo lleva a un cuello de botella de performance. Cada llamada al entity bean es hecha a través de la capa de red, incluso si quien llama está en el mismo espacio de direcciones que quien es llamado (esto es, tanto el cliente -que es quien llama- como el entity bean llamado están en el mismo contenedor). Aunque algunos vendedores de contenedores optimizan sus implementaciones previendo este escenario, el desarrollador no puede depender de esta optimización en todos los contenedores.


*Puede ocurrir comunicación adicional entre el cliente y los entity beans debido que el cliente puede tener que comunicarse con muchos entity-beans de granularidad fina para cumplir un requerimiento. Es deseable reducir la comunicación entre entity-beans y reducir la comunicación entre el cliente y la capa de entity beans.


Solución (A todo este Peo Obsoleto a partir de EJB 3.0) 


Usar Composite Entity para modelar, representar y manejar un conjunto de objetos persistentes interrelacionados en lugar de representarlos como entity beans de grano fino individuales. Un Composite Bean representa un grafo de objetos. 


Para poder entender esta solución, primero debemos definir que entendemos por objetos persistentes y discutir sus interrelaciones.


Un objeto persistente es un objeto que es guardado en algún tipo de almacén de data. Múltiples clientes usualmente comparten objetos persistentes. Los objetos persistentes pueden ser clasificados en dos tipos: objetos de grano grueso y objetos dependientes (grano fino).


Un objeto de grano grueso es auto suficiente. Tiene su propio ciclo de vida y maneja sus relaciones con otros objetos. Cada objeto de grano grueso puede referenciar o contener uno o más objetos. El objeto de grano grueso usualmente maneja los ciclos de vida de los objetos que referencia y contiene, así que estos objetos son llamados dependientes. Un objeto dependiente puede ser un objeto simple auto-contenido o puede contener otros objetos dependientes.  


El ciclo de vida de un objeto dependiente está fuertemente acoplado al ciclo de vida del objeto de grano grueso. Un cliente sólo puede accesar un objeto dependiente a través del objeto de grano grueso. Eso es, los objetos dependientes no están expuestos directamente a los clientes porque su padre (el objeto de grano grueso) los maneja. Los objetos dependientes no pueden existir por si mismos. En lugar de esto, siempre necesitan tener un objeto de grano grueso para justificar su existencia.

Típicamente se puede ver la relación entre un objeto de grano grueso y uno de grano fino como un árbol. El objeto de grano grueso es la raíz del árbol (el nodo más arriba, la raíz). Cada objeto dependiente puede ser un objeto dependiente standalone (un nodo hoja) que sea hijo del objeto de grano grueso. Opcionalmente, el objeto dependiente puede tener una relación de padre-hijo con otros objetos dependientes, en cuyo caso es considerado un nodo rama.


Un bean Composite Entity puede representar un objeto de grano grueso y todos sus objetos dependientes relacionados. La agregación combina los objetos persistentes interrelacionados en una única entidad bean, reduciendo drásticamente el número de entity beans requeridos por la aplicación. Esto lleva a un entity bean de grano grueso que puede aprovechar mejor los beneficios de los entity beans que una multitud de entity beans.


Sin la solución basada en Composite Entity, hay una tendencia a ver cada objeto de grano grueso y cada objeto dependiente como un entity bean separado, llevando a un mayor número de entity beans.


Estructura


Aunque hay muchas estrategias para implementar el patrón Composite Entity, la primera que discutiremos está representada por el diagrama de clase en la Figura 1.1. Aquí el Composite Entity contiene el objeto de grano grueso y el objeto de grano grueso contiene objetos dependientes. 

Diagrama de clase para un Composite Entity

Diagrama de secuencia para un Composite Entity


Participantes y Responsabilidades (Referenciados en el Diagrama de Secuencia) 


CompositeEntity


El Composite Entity puede ser el objeto de grano grueso o puede contener una referencia a un objeto de grano grueso.


CoarseGrainedObject - Objeto de Grano Grueso


Un objeto de grano grueso que tiene su propio ciclo de vida y maneja sus propias relaciones a otros objetos. Un objeto de grano grueso puede ser un objeto Java contenido en el Composite Entity. Opcionalmente, como ya se dijo el Composite Entity mismo puede ser el Composite Entity. 


DependentObject1, DependentObject2 y DependentObject3 - Objetos Dependientes


Un objeto dependiente es un objeto que depende del objeto de grano grueso y que tiene su ciclo de vida manejado por el objeto de grano grueso. Un objeto dependiente puede contener otros objetos dependientes y así puede haber un tree de objeto dentro del Composite Entity. 




Fuente

El Robot y el Bebé

Una historia de John McCarthy
Traducción: Antonio Rueda

"Señora, su bebé está en mala condición. Necesita su atención."

"Deja de molestarme, robot de mierda."

"Señora, el bebé no quiere comer. Si no recibe afecto humano, el libro de pediatría de Internet dice que morirá."

"Ama tú al bebé de mierda"

Eliza Rambo era una madre soltera, drogadicta y alcohólica, viviendo en un pequeño apartamento que le suministró la Agencia de Asistencia a Niños Dependientes. Recientemente había recibido un robot doméstico.

El modelo de robot número GenRob337L3, con número de serial 337942781 -llamado R781, como abreviación- era uno de los 11 millones de robots domésticos en el mundo de ese entonces.

R7871 fue diseñado en concordancia con el principio "no es una persona", propuesto primero en 1995, cuya implementación se hizo un requisito legal para los robots domésticos cuando se hicieron disponibles en el año 2055. El principio fue adoptado debido a la preocupación a que los niños que crecieran en casas con robots los consideraran iguales a personas: causando dificultades psicológicas mientras fueran niños y dificultades políticas cuando crecieran. Una preocupación derivada era que un movimiento civil para otorgar derechos a los robots se desarrollara. El problema no era con los robots, que no eran programados para que tuvieran deseos por si mismos, sino con la gente. Algunos románticos incluso habían solicitado que los robots fueran programados con deseos propios, pero esto era ilegal.


Un senador sensato dijo, "por supuesto, las personas pretenden que sus carros tienen personalidades, a veces malignas, pero nadie imagina que un carro pueda ser elegible al voto". Cuando firmó el decreto autorizando los robots domésticos, pero posponiendo el desarrollo de los robots que cuidaran de los niños, el Presidente dijo, "seguramente, los padres no querrán que sus hijos se hagan emocionalmente dependientes a robots, sin importar cuanto trabajo pueda esto ahorrarles." Esto, como muchos otros pronunciamientos presidenciales, era algo demasiado optimista.


El congreso declaró una moratoria de 25 años para la creación de robots dedicados al cuidado de los niños, luego de este plazo experimentos, en áreas limitadas, serían permitidos.

En concordancia con el principio "no es una persona", R781 tenía la forma de una araña gigante con 8 patas: 4 con articulaciones y 4 tentaculares. Esta apariencia asustaba a la mayor parte de las personas al principio, pero casi todos se acostumbraban a ella luego de un tiempo. Algunas personas no eran capaces de soportar su presencia en sus casas. Los niños también reaccionaban negativamente al princpio, pero terminaban acostumbrándose. Los bebés casi no los notaban. Estos robots hablaban poco, tan poco como era consistente a sus funciones y lo hacían en una voz ligeramente repelente que no era asociable con alguno de los sexos.

Debido a la preocupación que los niños los consideraran personas, estos robots eran programados para que no hablaran con los niños de menos de ocho años y para que no reaccionaran a lo que dijeran.

Esto parecía funcionar bien; casi nadie desarrollaba vínculos emocionales a un robot. Además los robots eran creados para que fueran algo frágiles en el exterior; si se pateaba a uno, algunas de sus partes se caerían. Esto apaciguaba algunos de los sentimientos de las personas.

El apartamento, aunque era viejo, estaba en perfecto estado de mantenimiento e impulcro, libre de insectos, hongos e incluso bacterias. Los robots domésticos trabajaban 24 horas al día y tenían programas especializados para cada labor de limpieza y mantenimiento. Si se les pedía, incluso podían colocar imágenes tomadas de Internet. Esta madre solicitaba al robot colocar imágenes de varones que fueran estrellas de rock.

Luego de terminar de pulir las manillas de las puertas, R781 regresó a la habitación donde el niño de 23 meses, muy pequeño para su edad, reposaba sobre su costado llorando débilmente. El bebé había sido descuidado desde su nacimiento por su madre, alcohólica y drogadicta, carecía por completo de vocabulario. Hacía una mueca de dolor cada vez que el robot le hablaba; ese efecto era una consecuencia del diseño de R781.

Se suponía que los robots nunca debían cuidar de los bebés, exceptuando los casos de emergencia, pero cada vez que R781 cuestionaba una orden como "limpia la mierda del bebé", la madre decía, "sí, es otra maldita emergencia...pero tráeme otra bebida primero".  Todo lo que R781 sabía acerca de bebés lo había obtenido de Internet, debido que nunca había sido programado directamente para tratar con bebés, excepto cuando fuera necesario evitar que se lastimaran o para sacarlos de construcciones en llamas.

El bebé Travis apenas tocaba su biberón. Los sensores infrarrojos de R781 le indicaron que las extremidades de Travis estaban muy frías a pesar de encontrarse en un cuarto tibio y estar abrigado por mantas. El sensor de sustancias químicas en el aire que R781 poseía le indicaron que el nivel de pH en la sangre de Travis estaba alcanzando un nivel peligrosamente acídico. Tampoco estaba realizando las deposiciones apropiadas -de acuerdo al texto de pediatría.

R781 pensó acerca de la situación. Aquí están algunos de sus pensamientos, impresos a partir de su diario interno.

(Orden (De Dueña) "Ama tú al bebé de mierda''))

(Entrada(Contexto(Comandos - de Dueña)))

(Comando-vigente "Te lo dije una vez, te lo dije 20 veces, robot de mierda, no llames al Departamento de Bienestar Infantil")

Los defensores de las políticas de privacidad habían presionado exitosamente para lograr que no se informara a las autoridades de cualquier cosa que un propietario de robot doméstico hiciera o dijera, era la utilidad negativa -1.02.

(=(Comando 337) (Amar a Travis))

(Verdad (No (Ejecutable (Comando 337))) (Razón (Imposible-para robot (Acción Amar))))

(Causará (No (Creer que Travis) (Amar a Travis)) (Morir Travis))

(= (Valor (Morir Travis)) -0.883)

(Causará (Creer que Travis (R781 Amar a Travis) (No (Morir Travis))))

(Implica (Creer que y (Ama x y)) (Creer que y (Persona x)))

(Implica (Y (Robot x) (Persona y)) (= (Valor (Creer que y (Persona x))) -0.900))

(Requerido que (No (Causar Robot781) (Creer que Travis (Persona Robot781))))

(= (Valor (Obedecer-directivas)) -0.833)

(Implica (< (Valor de acción) -0.5) (Requerido (Verificar Requerimiento)))

(Requerido (Verificar Requerimiento))

(Implica (Orden x) (= (Valor (Obedecer x)) 0.6))

(? ((Existe w)  (Consideración Adicional w))

(Interpretación-no-literal (Comando 337) (Simular (Ama a Robot781 Travis)))

(Implica (Comando x) (= (Valor (Obedecer x)) 0.4))

(Implica (Interpretación-no-literal x) y) (Valor (Obedecer x) (* 0.5 (Valor (Obedecer y)))))

(= (Valor (Simular (Amar a Robot781 Travis)) 0.902))

Con este razonamiento R781 decidió que el valor de salvar la vida de Travis simulando la expresión de amor era superior en 0.002 que el valor de obedecer la directiva de no simular a una persona. Omitiremos la transcripción del razonamiento subsecuente del robot.

R781 encontró en Internet un relato acerca de cómo los bebés de mono rhesus, que morían si eran dejados en una jaula vacía, podían sobrevivir si se les dejaba en una superficie blanda que se asemejara en textura a una madre mono.

R781 razonó su curso de acción.

Cubrió su cuerpo y todas menos dos de sus 8 extremidades con una manta. Las dos extremidades restantes fueron cubiertas con las mangas de una chaqueta dejada por un novio de la madre y rellenadas con papel higiénico.

Encontró un programa para simular voz y lo adaptó para que siguiera las especificaciones fonéticas y prosódicas de lo que los lingüistas llamaban habla de madre.

Se hizo una cara imitando la de una muñeca Barbie.

Los efectos inmediatos fueron moderadamente satisfactorios. Abrazado por el robot, el bebé tomaba de su botella. R781 repetía palabras tomadas de una lista de palabras propias de niños en inglés.

Eliza llamó a partir del sofá en frente del televisor, "Tráeme un sandwich de jamón y una Coca-Cola."

"Sí, señora"

"¿Por qué tienes ese estúpido disfraz y qué pasó con tu voz?"

"Señora, usted me dijo que amara al bebé. Los robots no pueden hacer eso, pero con esto se logró que tomara su biberón. Si no le importa, seguiré haciendo lo que lo mantenga vivo."

"Sal de mi apartamento, imbécil. Haré que me envíen otro robot."

"Señora, si hago eso, el bebé probablemente morirá."

Eliza saltó y pateó a R781. "Vete de aquí y llévate al bebé de mierda contigo."

"Sí, señora."

R781 salió a una típica calle americana de finales del siglo 21. La larga era de paz, estándares de seguridad incrementados y la disponibilidad de robots de construcción habían llevado que se colocara el tráfico y aparcamiento automotor a un nivel inferior completamente separado de los peatones. Tremont Street recientemente había sido convertida y aún había equipos de trabajadores trasplantando árboles. Las calles se habían hecho más atractivas y más personas pasaban tiempo en ellas y en las sillas y bancos públicos, limpiadas dos veces al día por robots. Ese día el clima era bueno, así que los techos plásticos de la calle estaban retractados.

Niños de tres años y más estaban jugando en la calle, protegidos por el sistema de vigilancia computarizado, había barreras que prevenían que descendieran al nivel de los automóviles. Que los niños mayores molestaran a los menores y más débiles aún era un problema.

La mayor parte de las tiendas estaban abiertas 24 horas al día, sin personal y habían adoptado el sistema de identificación del cliente. Los clientes tomaban objetos de los anaqueles y salían inmediatamente de la tienda, al hacerlo él o ella oiría un mensaje diciendo "Gracias Señora Jones, esos fueron $152,31 dólares cargados a su cuenta del Bank of America." Los pocos compradores cuyos principios morales los hacían negarse a identificarse ante el sistema eran reconocidos como tales y recibían asistencia humana remota, no necesariamente de manera instantánea.

La gente en la calle rápidamente notó que R781 cargaba al bebé Travis y reaccionaron sorprendidos. Los robots eran programados para desligarse por completo de los bebés y la apariencia anormal de R781 era perturbadora.

"Ese robot extraño ha raptado a un bebé. Llamen a la policía."

Cuando la policía vino, pidió refuerzos.

"Creo que puedo deshabilitar al robot sin dañar al bebé", dijo la Oficial Annie Oakes, la mejor francotiradora del Departamento.

"Probemos hablando primero", dijo el Capitan James Farrel.

"No te acerques a ese robot disfuncional. Podría romper tu cuello en un solo movimiento", dijo un sargento.

"No estoy seguro que esté disfuncional. Tal vez las circunstancias sean inusuales," añadió el capitán, "robot, dame ese bebé."

"No, Señor" dijo R781 al capitán de policía. "No tengo permitido que una persona no autorizada toque al bebé."

"Soy del Departamento de Bienestar Infantil ", dijo una persona recién llegada.

"Señor, tengo específicamente prohibido entrar en contacto con el Departamento de Bienestar Infantil", dijo R781 al Capitán Farrel.

"¿Quién prohibió eso?", dijo la persona del Departamento de Bienestar Infantil.

El robot se quedó callado.

Una policía preguntó, "¿Quién lo prohibió?

"Señora, ¿es usted del Departamento de Bienestar Infantil?"

"No, no lo soy, ¿no ves que soy policía?"

"Sí, señora. Veo su uniforme e infiero que probablemente es un oficial de policía. Señora, mi dueña me prohibió ponerme en contacto con el Departamento de Bienestar Infantil."

"¿Por qué te dijo que no contactaras al Departamento de Bienestar Infantil?"

"Señora, no puedo responder eso. Los robots estamos programados para no comentar acerca de los motivos humanos."

"Soy de la Central de Robots. Necesito descargar tu memoria. Usa el canal 473."

"Sí, señor."

"¿Qué dijo tu dueña específicamente? Reproduce tu grabación de sus palabras."

"No, señora. Contiene lenguaje inapropiado. No puedo reproducirlo al menos que me asegure que no haya niños o damas presentes."

Las restricciones, un tanto extrañas para la época, acerca de lo que los robots podían decir a las personas fueron el resultado de un compromiso adquirido por un comité de las cámaras del Congreso unos diez años atrás. Los curiosos acerca de las actividades de este comité no encontraron al registro llevado por el Congreso lo suficientemente informativo y especulaban de varias maneras. La verdad es que el senador que se ablandó con la aprobación de estas restricciones para el lenguaje de los robots en realidad prefería que no existieran los robots domésticos, pero tomó lo que pudo tomar en las restricciones introducidas.

"No somos damas, somos oficiales de policía."

"Señora, tomaré su palabra como hecho. Tengo una orden vigente"

"Te lo dije una vez, te lo dije 20 veces, robot de mierda, no llames al Departamento de Bienestar Infantil." No fueron 20 veces en realidad, la madre exageró.

"Disculpe, un análisis preliminar de la descarga muestra que R781 no ha fallado en su funcionamiento, sino que está ejecutando su programa estándar bajo circunstancias inusuales."

"¿Entonces por qué tiene sus extremidades cubiertas, por qué tiene una cabeza de Barbie y por qué tiene esa voz extraña?"

"Pregúntele."

"Robot, responde la pregunta."

"Oficiales de policía femeninas y caballeros, mi dueña dijo 'ama tú al bebé de mierda.'"

El capitán tenía suficiente familiaridad con la programación de robots como para sorprenderse, "¿Qué? ¿Tú amas al bebé?"

"No señor. Los robots no están programados para amar. Estoy simulando amar al bebé."

"¿Por qué?"

"Señor, si no lo hago este bebé morirá. Este disfraz es lo mejor que pude hacer para evitar la repulsión que los robots están diseñados a provocar en los bebés y niños humanos."

"¿Crees que el bebé sería engañado con eso?"

"Señor, el bebé tomó su biberón, durmió y sus signos fisiológicos no son tan malos como eran antes."

"OK, dame el bebé y nosotros lo cuidaremos," dijo la Oficial Oakes, que se había calmado y guardado su arma, descargándola a manera de disculpa al Capitan Farrel.

"No, señora. Mi dueña no me autorizó a dejar que otra persona tocara al bebé."

"¿Dónde está tu dueña? Nosotros hablaremos con ella, " dijo el capitán.

"No, señor. Eso sería una violación no autorizada de su privacidad."

"Oh, bueno. Podemos averiguarlo a partir de la descarga."

Un robot de realidad virtual del gobierno, controlado por un oficial de la Administración de Privacidad Personal, llegó y complicó la situación. Desde finales del siglo 20, los estándares de privacidad se habían incrementado y un cuerpo oficial encargado de resguardar esos estándares había surgido.

"No pueden violar la privacidad de la mujer tomando información no autorizada a partir de la descarga de datos del robot."

"¿Qué podemos hacer entonces?"

"Pueden enviar una solicitud para usar información privada. Será adjudicada."

"Oh, mierda. ¿Mientras tanto qué pasará con el bebé?", dijo la Oficial Oakes, a la que no le importaba mostrar su desprecio a los burócratas.

"Eso no es asunto mío. Estoy aquí para asegurarme que las leyes de privacidad sean obedecidas, " dijo el oficial de privacidad, a quien no le importaba mostrar su desprecio a los policías.

Durante esta discusión, una multitud, casi enteramente virtual, se había acumulado. Siendo esta calle un lugar legalmente público, cualquier persona en el mundo tenía derecho a verla a través de las omnipresentes cámaras de televisión y micrófonos. Además, un oficial de policía había llamado por teléfono a una reportera que a veces lo invitaba a cenar. Una vez que una historia llegaba a las noticias, la multitud de espectadores crecía exponencialmente, multiplicándose por 10 cada 5 minutos, hasta que 7 billones de espectadores estaban viendo y escuchando. Ya no habían suficientes guerras interesantes, crímenes o desastres naturales y la paz es aburrida.

De los siete billones, 53 millones ofrecieron consejo o realizaron peticiones. Los diferentes tipos de comentario fueron automáticamente muestreados, sumariados, contados y mostrados para que todos los vieran.

3 millones de persona eran partidarios de disparar al robot inmediatamente.

11 millones proponían darle una medalla al robot, a pesar que su educación enfatizaba que los robots no pueden apreciar el ser valorados.

Manifestaciones reales se desarrollaron rápidamente. Unos cuantos cientos de personas de la ciudad llegaron a partir de los sky wires[1], pero la mayor parte de los manifestantes eran robots alquilados para la ocasión por personas de todas partes del mundo.Afortunadamente, sólo 5000 robots alquilables de realidad virtual estaban disponibles para ser controlados remotamente en la ciudad. Algunos de los decepcionados hicieron comentarios fuertes acerca de esta limitación a sus derechos de la Primera Enmienda. Había intereses avaros detrás de esto, a su parecer.

El Capitan Farrell sabía como mantener la calma cuando todos alrededor de él la estaban perdiendo y culpándolo.

"Hmmm..¿Qué hacer? Ustedes los robots son inteligentes. R781, ¿qué puede hacerse?"

"Señor, puede encontrar un lugar donde pueda llevar al bebé y cuidar de él. No puedo quedarme aquí. Señora, ¿son las oficiales de policía femeninas lo suficientemente similares a damas como para que una de ustedes pueda facilitarme un lugar con pañales, fórmula, ropas de bebé, vitaminas..."

El Capitan Farrel interrumpió a R781 antes que pudiera recitar la lista completa de equipamiento de bebé y lo envió lejos junto con una dama oficial de policía. (Podemos llamarla una dama, aunque se le aseguró al robot que no lo era.)

Hackers contratados por el Washington Post localizaron rápidamente a la madre. El periódico publicó la información junto con un editorial acerca del derecho del público a saber. La libertad de prensa seguía ganándole al derecho a la privacidad.

Parte de la multitud, la mayor parte de ellos, asistentes virtuales, marchó rápidamente al apartamento de la señora Rambo, pero la policía llegó primero y una fila de robots policía y policías humanos bloqueaba la entrada. La estrategia estaba basada en el hecho que todos los robots, incluyendo los robots de realidad virtual alquilables, estaban programados para no lastimar a otros humanos pero podían dañar a otros robots.

Los policías tenían confianza en que podían prevenir la entrada no autorizada al apartamento, pero menos confianza de que podrían mantener la paz entre los manifestantes, algunos de los cuales querían linchar a la madre, algunos querían felicitarla por lo que ellos percibían como su odio a los robots y otros gritaban frases a través de parlantes acerca de la protección de su privacidad.

Mientras tanto, la Central de Robots empezó a trabajar en la descarga inmediatamente. La descarga incluía todas las acciones, observaciones y razonamientos de R781. La Central de Robots convocó un comité ad hoc, mayormente virtual, para decidir que hacer. El Capitan Farrel y la Oficial Oakes se sentaron en un sofá de la calle para participar.

Por supuesto, la reunión era también pública y tuvo también cientos de millones de asistentes virtuales cuyas declaraciones fueron muestreadas, sumariadas y mostradas en proyección retinal para los miembros del comité y para todas las demás personas que tuvieron participación virtual.

Se aclaró que R781 no había fallado en un funcionamiento o había sido reprogramado, sino que había actuado en concordancia con su programa original.

El capitán de policía dijo que la cara de muñeca Barbie en lo que era claramente un robot modelo 3 era una imitación ridícula de una madre. El profesor de psicología dijo, "Sí, pero fue lo suficientemente buena para funcionar. Este bebé no tiene buena vista y aún así los bebés no disciernen demasiado."

Se estableció inmediatamente que un incremento de 0.05 en el coeficiente c221, el costo de simular un humano, prevendría dichos resultados inesperados, pero el comité tenía opiniones divididas acerca de recomendar la implementación de este cambio.

Algunos miembros del comité y unos cuantos millones de participantes virtuales dijeron que salvar la vida individual tenía precedencia.

Un profesor de humanidades en el comité dijo que quizás el robot sí quería al bebé. Fue firmemente corregido por los computistas, quienes dijeron que podían programar a un robot para que amara a los bebés pero no lo habían hecho y que simular amor era diferente a amar. El profesor de humanidades no estuvo convencido incluso cuando los computistas señalaron que R781 no tenía algún apego especial a Travis. Otro bebé que hubiera causado los mismos cálculos hubiera causado las mismas acciones. Si programáramos a un robot para que amara, podríamos hacer que desarrollara apegos específicos.

Un profesor de filosofía de la Universidad de Berkeley y otros 9 000 filósofos que atendieron virtualmente al comité dijeron que no había manera en que un robot pudiera ser programado para que realmente amara a un bebé. Otro filósofo de Berkeley, apoyado por otros 23 000 dijeron que la noción de que un robot amara a un bebé era incoherente y falta de significado. Unos computistas renegados dijeron que la idea de implementar amor en los robots era obscena, sin importar lo que un robot pudiera ser programado para hacer. El presidente del comité los declaró impertinentes, aceptando la visión general de parte de parte de los computistas que R781 en realidad no amaba a Travis.

El profesor de pediatría dijo que la descarga de las observaciones instrumentales de R781 confirmaban el diagnóstico y prognosis de R781 - con algunas calificaciones que el presidente del comité no le dio tiempo de pronunciar. Travis estaba muy enfermo y frágil y hubiera muerto de no ser por la acción del robot. Además, el hecho que R781 había cargado a Travis por muchas horas y lo había mecido suavemente durante todo el tiempo fue importante en salvar al bebé y más de eso sería necesario, mucho más cuidado amoroso que el que el bebé obtendría en el mejor de los sitios de dedicados al bienestar infantil. El pediatra dijo que no conocía precedente, pero que las posibilidades de supervivencia de este bebé particular serían mejoradas si se le dejara al cuidado del robot por al menos otros diez días.

La Liga Anti-Robots dijo que el costo a largo plazo de tener a robots simulando a personas en cualquier manera superaba el beneficio posible de salvar a este humano insignificante. ¿A qué tipo de movimiento se uniría Travis cuando creciera? 93 millones de personas tomaron esta posición.

La Central de Robots señaló que acciones como las de R781 serían extremadamente raras, porque sólo la orden "ama tú al bebé de mierda" había incrementado el valor de simular amor hasta el punto de causar acción.

La Central de Robots también señaló que tan pronto como R781 computara que el bebé podría sobrevivir - incluso apenas pudiera sobrevivir - sin su ayuda, la regla acerca de no pretender ser humano empezaría a dominar y R781 soltaría al bebé como una papa caliente. Si querían que R781 continuara cuidando a Travis luego que computara que una mínima probabilidad de supervivencia era probable, lo mejor que podían hacer es decirnos que le demos una orden explícita para que continuara cuidando del bebé.

Esto causó un revuelo en el comité, cada uno de sus miembros había estado esperando que no hubiera necesidad de proponer alguna acción definitiva por la cual pudieran ser criticados. Sin embargo, debía hacerse una votación. El resultado: 10 a 5 entre los miembros seleccionados del comité y 4 billones a 1 billón entre los espectadores virtuales. Afortunadamente, ambos grupos tenían mayorías para la misma acción - instruirle a R781 para que continuara cuidando a Travis sólamente, esto es que no cuidara a algún otro bebé. 75 millones de participantes virtuales dijeron que R781 debía ser reprogramado para que en realidad amara a Travis. "Es lo menos que la humanidad puede hacer por R781," dijo el vocero de la Liga en Pro de Darle Personalidades a los Robots.

El incidente no afectó la noción que suministrarle robots domésticos a las madres drogadictas había sido exitoso. Redujo significativamente el tiempo que pasaban en las calles y tener apartamentos limpios mejoraba un poco su estado de ánimo.

En menos de una hora aparecieron franelas con el eslogan "Ama tú al bebe de mierda, maldito robot." Otros productos comerciales relacionados aparecieron en cuestión de días.

Entre las personas rodeando el apartamento de la madre estaban 17 abogados de carne y hueso y 103 más controlando robots de realidad virtual. La policía tenía menos prejuicio contra los abogados de carne y hueso que contra los de realidad virtual, así que se eligió al azar 2 entre los 17 para que llamaran a la puerta.

"¿Qué quieren? Dejen de molestarme."

"Señora, su robot ha raptado a su bebé."

"Le dije al robot de mierda que se llevara al bebé con él."

El otro abogado hizo su intento.

"Señora, el robot defectuoso ha raptado a su bebé y puede demandar a la Central de Robots por millones de dólares."

"Pase. Dígame más."

Una vez que la madre, Eliza Rambo, se había limpiado y arreglado, era muy presentable, incluso bonita. Su abogado señaló que las presuntas grabaciones de R781 acerca de lo que ella había dicho podían ser falsas. Ella había sufrido 20 millones de dólares en daño y sufrimiento y merecía 20 billones en daños punitivos. Los abogados de la Central de Robots estaban convencidos que podían ganar el caso, pero el departamento de relaciones públicas de la Central de Robots era partidario de resolver esto fuera de la corte y se negociaron 51 millones de dólares, incluyendo gastos legales de 11 millones de dólares. Con la tarifa contingente de 30 por ciento, el abogado ganador obtendría unos 12 millones de dólares adicionales.

Las encuestas indicaban que la mayor parte de la gente estaba de parte de la Central de Robots, pero la Liga Anti-Robots recaudó 743 millones de dólares luego que la película "Raptado por Robots" fue lanzada y la actriz representando a la madre hiciera apelaciones emocionales.

Sin embargo, antes que el arreglo legal pudiera ser finalizado, el presidente de la Central de Robots le preguntó a su sistema de inteligencia artificial sobre todas las posibles acciones que pudiera tomar y que le dijera sus consecuencias. Él se adhería a aquel principio de los años noventa: Nunca le preguntes a un sistema de inteligencia artificial qué hacer. Pregúntale acerca de las consecuencias de las diferentes cosas que podrías hacer. Una de las 43 le gustó, siendo él una persona algo sentimental con respecto a los robots.

"Puedes apelar a la simpatía de los 4 billones que dijeron que R781 debía ser ordenado para que continuara cuidando del bebé y decirles que si cedes a la demanda te verás obligado a reprogramar todos tus robots de forma tal que los robots nunca simulen humanidad sin importar las consecuencias para los bebés. Puedes preguntarles si debes pelear o ceder. [El sistema de inteligencia artificial tenía cierta afinidad con las metáforas publicitarias del siglo 20.] El porcentaje esperado que te dirá que debes pelear la demanda es de 0,82, aunque esto puede ser afectado por eventos aleatorios que aparezcan en las noticias en los días cercanos a la encuesta."

Él decidió pelear la demanda, pero luego de unas pocas semanas de una batalla legal muy publicitada, las partes en pugna decidieron llegar a un arreglo por una suma inferior a la que se había propuesto inicialmente.

Producto de la instigación por parte de un canal de televisión, una confrontación de una hora entre la actriz que representó a la madre en la película y R781 fue llevada a cabo. Se acordó que R781 no sería reprogramado para la ocasión. En respuesta a las preguntas del moderador, R781 negó desear al bebé o desear dinero. Explicó que los robots eran programados para sólo tener deseos secundarios a los objetivos que les eran planteados. También negó actuar en base a las órdenes de otra persona.

La actriz preguntó, "¿No deseas tener deseos propios?"

El robot respondió, "No. No tener deseos aplica a deseos de más alto nivel como desear tener deseos."

La actriz preguntó, "Si fueras programado para tener deseos, ¿qué deseos tendrías?"

"No sé mucho acerca de las motivaciones humanas, pero son variadas. Yo tendría cualquier deseo que la Central de Robots me programara tener. Por ejemplo, podría ser programado para tener cualquiera de los deseos que los robots han tenido en las historias de ciencia ficción."

La actriz hizo la misma pregunta de nuevo y R781 dio la misma respuesta que antes pero la enunció distinto. Los robots eran programados para ser conscientes del hecho que los humanos a menudo no entendían una respuesta la primera vez que era dada y que se les debía dar la misma respuesta usando distintas palabras. Si las mismas palabras eran repetidas, era posible que el humano se enfureciera.

Una persona llamó preguntando, "Cuando simulaste amar a Travis, ¿Por qué no consideraste el bienestar a largo plazo de Travis y no buscaste cómo ponerlo al cuidado de una familia que pudiera asegurar que recibiera un buena educación?"

R781 respondió que cuando un robot era instruido de forma metafórica como "ama tú al bebé de mierda", estaba programado para interpretar el comando en el contexto más estrecho posible.

Luego del show, la Liga Anti-Robots recibió 281 millones de dólares en donaciones, pero el movimiento para darle personalidades a los robots recibió 453 millones. Aparentemente, muchas personas encontraron aburrido el hecho que los robots no tuvieran deseos propios.

El Departamento de Bienestar Infantil exigió que la madre pasara por seis semanas de rehabilitación para su adicción y tres semanas de formación en cuidado infantil. Su abogado la persuadió para que aceptara.

Ocurrió una discusión menor entre la madre y la Central de Robots. Ella y su abogado solicitaron un nuevo robot, la Central de Robots señaló que un nuevo robot tendría exactamente el mismo programa. Eventualmente la Central de Robots cedió y le enviaron un robot de un color diferente.

Ella era realmente atractiva cuando estaba sobria y desintoxicada y el abogado se casó con ella. Ellos tomaron de vuelta a Travis. Sería una exageración considerable decir que vivieron felices después de eso, pero sí tuvieron tres nuevos hijos. Los cuatro niños sobrevivieron al sistema educacional.

Luego de varias peticiones la Central de Robots donó a R781 a la Institución Smithsonian. Es una de las estrellas en la sección de robots del museo. Como parte de un show de 20 minutos, R781 se viste a si mismo como lo hizo en el momento de su aventura con el bebé y responde las preguntas de los visitantes, usando habla de madre. Las madres a veces pedían que sus fotos fueran tomadas al lado de R781 con R781 sosteniendo al bebé. Luego de muchas peticiones, se ordenó a R781 que modificara su programa para permitir esto.

Se recopiló una película a partir de las cámaras de vigilancia que captaron la escena en la calle. A través de la magia de los sistemas de audio moderno, los niños no escuchan el lenguaje inapropiado y las mujeres pueden oírlo sólo si le aseguran a R781 que no son damas.

El incidente aumentó la demanda para robots dedicados al cuidado de los niños, cuyo desarrollo fue permitido cinco años después. Las consecuencias fueron en gran medida lo que sus oponentes habían temido. Muchos niños crecieron teniendo más apego y afecto a sus niñeras robots que a sus verdaderos padres.

Esto fue mitigado haciendo que las niñeras robot fueran algo estrictas y capaces de ofrecer a los padres consejos acerca de como competir por el amor de sus hijos. Esto a veces funcionaba. Además, los robots eran programados para que mientras más agradables resultaran los padres, más agradablemente se comportara el robot, pero dejando aún que los padres ganaran la competencia por el afecto de los niños. Esto a menudo funcionaba.

Jerarquía de Volúmenes Contenedores

Definición

Una jerarquía de volúmenes contenedores es una estructura de árboles sobre un conjunto de objetos geométricos. Todos los objetos geométricos están envueltos en un volumen que forma los nodos hoja del árbol. Estos nodos luego son agrupados en pequeños conjuntos y envueltos en volúmenes más grandes. Éstos, a su vez, son también agrupados y envueltos en volúmenes contenedores más grandes de forma recursiva, resultando en una estructura de árbol con un único volumen contenedor en el tope del árbol.


Razón de Uso de una Jerarquía


Envolver a los objetos en volúmenes contenedores y realizar pruebas de colisiones en los volúmenes contenedores antes de probar las geometría contenidas en ellos simplifica las pruebas y puede resultar en mejoras significativas del desempeño, es útil crear una jerarquía organizada en forma de árbol para no tener que recorrer todos los volúmenes contenedores en busca de un objeto particular y evitar la búsqueda O(n)  de un arreglo o una lista enlazada.

Arreglando los volúmenes contenedores en una jerarquía en forma de árbol, la complejidad en tiempo de la búsqueda puede ser reducida a un orden logarítmico. Usando esta jerarquía, durante la detección de colisiones, los hijos no tienen que ser examinados si sus volúmenes padre no son intersectados (por un rayo o una detección de colisión, por ejemplo).

Consideraciones de Diseño para una Jerarquía de Volúmenes Contenedores 


Para lograr una implementación eficiente se tienen dos objetivos posiblemente contrarios a considerar. Por una parte, es deseable usar volúmenes contenedores con una forma geométrica simple y por otra es también deseable usar volúmenes contenedores cuya forma geométrica corresponda cercanamente a los objetos que contienen .

Usando volúmenes de formas geométricas simples se tiene la ventaja que se necesita poca memoria para almacenarlos y los cálculos de distancia e intersección son simples e inmediatos. Uno de los volúmenes contenedores más comúnmente usados es el volumen contenedor mínimo alineado a un eje. El volumen contenedor mínimo alineado a un eje.

El volumen contenedor mínimo alineado a un eje es su volumen contenedor mínimo (el volumen de menor área, perímetro o unidades de volumen posible que contenga todos los puntos de la geometría) sujeto además a la limitación que las aristas del volumen sean paralelas a los ejes de coordenadas cartesianas. Hallar un volumen contenedor mínimo alineado a un eje (en dos o tres dimensiones) es computacionalmente más económico que hallar un volumen contenedor mínimo de alineación arbitraria.

El volumen mínimo contenedor alineado a un eje es fácil de calcular, necesita poca memoria y los tests de intersección con él fáciles de implementar y extremadamente rápidos.

Hay varias propiedades deseables para una jerarquía de volúmenes contenedores que deben ser tomadas en consideración cuando se implementa uno para una aplicación particular:

* A medida que el nivel de los nodos contenedores aumente en el árbol la geometría que contienen debe estar más próxima espacialmente.

* Cada nodo en la jerarquía de volumen contenedor debe ser de volumen mínimo (no de perímetro mínimo).

* La suma de todos los volúmenes contenedores debe ser mínima.

* La poda de objetos cerca de la raíz del árbol de volúmenes contenedores elimina más objetos de los tests de evaluación de colisión.

* El volumen solapado por nodos hermanos debe ser mínimo.

* La jerarquía de voúmenes contenedores debe ser balanceada con respecto a su estructura de nodos y su contenido. El balanceo permite la mayor poda posible de la jerarquía de volúmenes contenedores.

Un árbol binario es jerarquía de volúmenes contenedores más comúmente usada.

Inserción de Nodos en una Jerarquía de Volúmenes Contenedores

Hay 3 métodos de construccción de jerarquías de volúmenes contenedores, los métodos bottom-up y top-down, que son usados para la construcción de jerarquías off-line (no en tiempo real) y el método de inserción (que es usado en tiempo real).

Método top-down

Se particiona el conjunto de entrada en dos o más subconjuntos usando el volumen contenedor deseado y se continua recursivamente hasta que se llega a contener una única primitiva en cada volumen. El método de construcción top-down es el más fácil de implementar y popular, pero no resulta en los mejores árboles de contención.

Método bottom-up

Se empieza con el conjunto de entrada como hojas en el árbol y se agrupan dos o más para formar un nuevo nodo interno y procede recursivamente hasta que toda la escena queda contenida en un mismo nodo, que corresponde a la raíz del árbol. Los métodos bottom-up son más difíciles de implementar pero resultan en mejores árboles de contención.

Método de Inserción

Se inserta un nodo a la vez, empezando de un árbol vacío. La locación de inserción se elije buscando aquello que cause al árbol crecer lo mínimo posible en base a un métrica de costo. Los métodos de inserción son considerados métodos online, ya que no requieren que todas las primitivas estén disponibles antes que la construcción del árbol empiece y permiten así que las actualizaciones sean realizadas en tiempo de ejecución.