Entradas de la categoría ‘Desarrollo’

Si hace una década me hubieran asegurado que una serie televisiva española de ficción me iba a enganchar pegado al televisor, simplemente me habría descojonado con tal virulencia y acometividad que las costillas flotantes que salen de mi columna vertebral se habrían clavado en mi hígado de manera más que probable. Sin embargo, hoy es el día que puedo asegurar que la ficción televisiva patria ha alcanzado un nivel tan aceptable como para lograr competir dignamente con las series estadounidenses, y no sólo en cuota de pantalla, sino también en calidad técnica, aptitud interpretativa y genialidad y originalidad de sus guiones. Algunas, claro.

Dejando a un lado las comedias de situación y las reminiscencias del pasado político (que tanto agradan, ambas, por estos lares), títulos como ‘Periodistas’, ‘Hospital central’, ‘El comisario’, ‘Cuenta atrás’, ‘RIS científica’, ‘Hay alguien ahí’, ‘Águila Roja’ o ‘Piratas’ han hecho evidente que en España se puede hacer buena televisión de entretenimiento, obviando los comentarios que ponen a parir a una o a otra por su mediocridad artística, su falta de trama profunda o su prácticamente nula calidad argumental (en la mayoría de los casos no les falta razón alguna). Mención especial aparte a ‘El internado‘, probablemente la única serie capaz de competir de forma rigurosa y seria con cualquier otra del mundo. Sin duda, la gran obra maestra de la ficción española que, ahora, triunfa en Rusia.

Precisamente, de la productora de ‘El internado’, Globomedia, llegó a principios de este año 2011 un nuevo título que prometía hacer las delicias de los amantes de la ciencia ficción en la pequeña pantalla. La serie (Antena 3), titulada ‘El barco‘, traía consigo emoción, intriga y suspense, algo que se hizo evidente en un más que bueno episodio piloto. Sin embargo, y tras trece capítulos de su primera temporada, ‘El barco’ ha pinchado como serie de ficción y se ha convertido en un melodrama romanticón plagado de amoríos, relaciones y folleteos varios en alta mar (más alta que nunca, por cierto). La trama es técnicamente un despropósito, pero, bien llevada, podría haber conseguido laureles y vítores de la crítica y del público. Empero, los responsables han preferido agradar a los televidentes quinceañeros a golpe de fotogramas de Mario Casas sin camiseta y de Blanca Suárez en paños menores, descuidando la idea original hasta puntos insospechados.

Pero lo que más nos ha llamado la atención en este blog no es la calidad interpretativa del elenco, ni siguiera las incoherencias de un guión cogido con alfileres. Lo que a nosotros nos interesa es la parte tecnológica del asunto, en este caso el área de los efectos especiales digitales de la grabación. Y es que parece mentira que una serie de una de las productoras más potentes de país, en el año 2011 de Nuestro Señor Jesucristo, lleve pegoteados en la cinta unos efectos que cualquiera en su casa, un poco (pero poco) avezado en el manejo de 3D Studio o After Effects, podría haber creado en cinco minutos. Resulta un insulto gravísimo al espectador, al que tratan de tonto e ignorante.

Cromas evidentes, perspectivas imposibles, efectos repetidos, pájaros de conducta errática y humaredas voluptuosas son algunos ejemplos de las decenas de efectos dignos de un parvulario del modelado en 3D. A buen seguro, el único efecto realista que han sido capaces de recrear es el de la neblina de la cortinilla de la serie que, por cierto, reutilizan en el capítulo ‘Niebla’, pero a lo bestia. Como honrosa excepción, sólo se salva el episodio ‘El hombre de Liverpool’, con sus transiciones entre presente y pasado, aunque eso poco tiene que ver con efectos en tres dimensiones, pero era de recibo comentarlo.

El barco creado por ordenador para los planos generales y panorámicos largos es simplemente patético. La suerte les acompaña porque se ve pequeñito (desde muy lejos), ocultando y tapando la mayoría de los defectos. Sin embargo, lo que no han podido esconder es el movimiento de la nave, ya sea a la hora de esquivar un remolino, tipo sumidero, en alta mar o en el momento de mostrar al barco encallado en vete tú a saber dónde en el medio del océano. La fluidez de los movimientos del modelo 3D recuerda muy poco a las películas de Pixar y muy mucho a ‘Los Fruittis‘.

A muchos de los planos que utilizan la técnica del chroma key sólo les falta que se les caiga una sábana verde por detrás. Tienen el tufillo de aquellas películas antiguas en las que un grupo de personas parece viajar en el interior de un coche mientras el fondo se mueve descaradamente a sus espaldas. Algo que, a la altura de siglo que andamos, es inconcebible. Ni que decir tiene que un escenario no puede ser nunca tan estático que parezca una fotografía evidente de una puesta de sol tropical. Pues ‘El barco’ tiene de esos también.

De todos los despropósitos digitales que se pueden encontrar, los que más llaman la atención son dos; sin duda, los más notorios por nocivos para la retina. El primero de ellos se da en el capítulo ‘El graznido’, en el que miles de aves de dudosa procedencia toman el buque en busca de comida. Los planos generales muestran un barco repleto de puntos negros, que representan a los pájaros posados en él, y una jauría en rededor de cuervos y gaviotas (y ¿palomas?) acechando a los tripulantes. En una de las imágenes se puede comprobar la profesionalidad de los diseñadores al programar el movimiento calculado de la bandada. Dos gaviotas (se pueden ver en el centro superior de la imagen siguiente) sufren un comportamiento errático al volar una hacia la otra, chocar y continuar agitando las alas en el sitio, sin desplazarse. Un bug al más puro estilo ‘Pro Evolution Soccer’, cuando un jugador comienza a caminar por el aire o atraviesa el terreno de juego con las piernas saliendo de sus hombros.

El vídeo que corresponde a este fotograma se puede visionar en la propia web de Antena 3. Se corresponde con la quinta parte del capítulo 5, y el gazapo empieza alrededor del minuto 4:02 (produciéndose en el 4:05, aproximadamente). Es el más evidente, pero apuesto a que, examinando a fondo el averío, se pueden encontrar bastantes más.

El segundo momento estelar se refiere al episodio ‘La ley del mar’, donde el navío se queda sin combustible justo encima de un volcán submarino (que ya es puntería y casualidad, mirusté). Hace mucho calor y el agua del mar hierve (literalmente) provocando quemaduras de primer grado en un bañista inconsciente, pero en los peces no. De pronto, y como si por arte de magia se tratara, el volcán entra en erupción, arrojando al exterior inmensas nubes de ceniza y humo, pero ni una gota de agua. ¿O sí es agua? Quién sabe. El fuerte estallido ha sido modelado de una forma tan soez, burda, tosca, basta y ordinaria, que no me explico como no han dejado directamente la malla de polígonos al descubierto; habría quedado más simpático y menos grotesco, irrisorio y ridículo. En el vídeo siguiente se puede comprobar también la pericia del animador 3D para conjugar esos hongos negros rechonchos con el resto de la escena.

Desconozco (y no quiero conocer) qué empresa ha sido la encargada de generar los efectos digitales de esta serie, aunque me juego el cuello a que anda por ahí entremetida en los títulos de crédito. No sé si es una compañía de saldos o es que el presupuesto ha sido tan bajo que han puesto a trabajar a los becarios en prácticas. Desde luego, es amoral e inadmisible que, en esta época, una empresa de animación haga este trabajo para un cliente tan importante y pase todos los filtros y cortapisas hasta llegar a la audiencia. Si es así como queremos competir con las series americanas, casi mejor que nos dediquemos a aídas y cuentamés, que la cosa pinta más fácil para los expertos en FX de este país, antes conocido como España. Para ponerse a mear y no echar ni gota, oiga.

Me encantan los proyectos inútiles, estúpidos de concepción y poco o nada rentables de manufacturación pero que destilan genialidad por los cuatro costados. No sé por qué oscura razón me atraen sobremanera aquellas ideas que resultan asaz avanzadas en el asunto tecnológico mas totalmente inservibles en el fondo práctico, si no es poco más allá del paso ameno del momento y del correspondiente colgado de medalla en el pecho para expectación en el mundo del desarrollo friqui.

La agudeza y el ingenio que requiere doblegar a la máquina, mezclando tecnologías, en principio, incompatibles, dominando la ciencia y el lenguaje de los distintos mecanismos y perdiendo horas de sueño, es simplemente digno de elogio y alabanza. Es por ello que me apasiona el trabajo de aquellos que instalan una distro de GNU/Linux en una Xbox 360, la hazaña de hacer sonar la “Marcha Imperial” de Star Wars con un disco duro, el potencial inerte de la máquina perfecta o el currelo de programar lo que estos chavales, que detallo en esta breve recensión, han sido capaces de desarrollar. Improductivo, sí, pero formidable.

Material necesario: una impresora de tiques térmica, un rollo de papel para la anterior, un ordenador portátil con sistema operativo Mac, un proyector de luz, el mando de una PlayStation 23 y mucha, pero que mucha, imaginación y sapiencia. En el perfecto marco del festival OFFF (bajo el evento denominado “Vamos a alimentar el taller del futuro”), en Barcelona, el norteamericano Joshua Noble, junto con Martin Fuchs y Philip Whitfield (ambos chicos de Undef), crearon un alucinante juego de carreras en el que el mando de la Play 2 3 es el control principal, el circuito o carretera digital se imprime en tiempo real en la impresora térmica y un proyector de luz marca sobre el papel el coche que dirigimos, la puntuación y otros datos. Lo ideal es contemplar el vídeo siguiente para entender la idea. Esto fue el pasado 8 de junio de este año 2011, y el juego se llama “Receipt Racer”.

El tamaño máximo del circuito es de 50 metros, ya que esta es la longitud total estándar de los rollos de papel térmico. En un principio pensaron en utilizar la impresora como medio estático único para la representación visual, pero el proyecto se antojaba imposible. Posteriormente, a Joshua se le ocurrió añadir el pequeño proyector de luz que, convenientemente controlado por el mando de videoconsola, era capaz de sobreimpresionar el coche y el resto de datos cambiantes.

La aplicación que controla todo este tinglado (desarrollada enteramente durante el taller) fue generada a partes iguales por los tres tipos sobre la plataforma openFrameworks. Una rutina genera aleatoriamente los circuitos y los coches de relleno y los imprime en tiempo real en la impresora. Asimismo, varias funciones detectan la posición del haz de luz que representa el coche del jugador y cruzan los datos con el circuito dibujado. De esta manera, aunque esto resultó lo más complicado, es posible programar mínimamente una detección de colisiones básica que nos indicará cuando el vehículo que manejamos ha chocado contra otro coche o contra los bordes de la carretera.

Evidentemente, esta tecnología, y desarrollada en tan poco tiempo, muy precisa no resulta. En el vídeo anterior se puede comprobar perfectamente como, antes del choque final, el coche se estrella con al menos dos vehículos impresos; y no sucede nada. El sistema tuvo que ser calibrado en varias ocasiones hasta conseguir la máxima precisión, empero, los caprichos de una máquina mecánica, como es una impresora, son múltiples y variados para conseguir un requerimiento de milímetros.

Al final del taller, los muchachos añadieron algunos detalles finales como la puntuación, el número de nivel y el resto de textos lumínicos de incio y fin. La impresora muestra también un fin de juego al estrellarse el coche, detallando el tiempo transcurrido, el nivel alcanzado y los puntos obtenidos.

En fin, una obra maestra de ingeniería que demuestra que en el mundo hay mucho geek dispuesto a perder algo de su tiempo libre para regalar nuestros sentidos con perlas tecnológicas como esta. Babeando ando todavía.

Por cierto, se puede jugar a una versión virtual del engendro desde la web de Undef y, también, descargar el código fuente compilado para Mac.

Recientemente, la historia de los virus informáticos ha cumplido ya cuarenta años. Casi medio siglo de quebraderos de cabeza con los que los usuarios y las empresas han tenido que lidiar prácticamente a diario. Aquel viejo ideario de infecciones al estilo Creeper (1971) o el español Barrotes (1993), donde los virus representaban un arte y un reto intelectual totalmente inocuo, desencadenó en una tremenda oleada de software malicioso que robaba datos, destruía sistemas operativos y producía millones de euros en pérdidas. ¿Quién no recuerda los tiempos de Viernes 13 (1988), Melissa (1999) o LoveLetter (2000)?    

Desgraciadamente (o afortunadamente) las herramientas para elaborar cualquier pieza de software están hoy día al alcance de cualquiera. Los antiguos y complejos desarrollos en ensamblador han dado paso a lenguajes modernos de alto nivel, fáciles de aprender y rápidos de implementar.    

Los archivos de proceso por lotes de MS-DOS (ficheros de extensión .BAT) fueron aquellos grandes olvidados en la programación de virus. No obstante, los expertos en su diseño vieron en ellos una alternativa veloz y potente para desarrollar malware, y algún bicho codificado de aquella forma llegó a ver la luz, eso sí, sin gran incidencia.    

Posteriormete, y gracias al procesamiento por lotes integrado en Windows a través de su herramienta de administración Windows Scripting Host (rebautizada en su segunda versión como Windows Script Host), los desarrollos víricos se multiplicaron exponencialmente, pues la potencia de desarrollo, unida a la suave curva de aprendizaje, permitía generar virus mortíferos en horas o, incluso (dependiendo de la pericia del programador) en minutos.    

Windows Script Host (WSH) es una utilidad administrativa que se provee con todas las versiones del sistema operativo del tío Bill desde Windows 98. En principio, su utilidad se basa en la generación de archivos de lotes, sin embargo, la potencia de estos ficheros con respecto a los antiguos ficheros batch es muy superior. La fortaleza reside en dos conceptos primordiales: los lenguajes de programación que implementa y los objetos del sistema que es capaz de manejar.    

WSH permite utilizar en la actualidad un amplio abanico de motores de script en su desarrollo, a saber: VBScript, JScript, PerlScript, ooRexx Script, Python Script, Tcl Script, Active PHP Script, Ruby Script, Object Rexx engine y Delphi scripting engine. Cualquier programador con conocimientos básicos de prácticamente cualquier lenguaje puede desarrollar un script para WSH. Asimismo, estos archivos de guión son capaces de acceder a características varias de un sistema operativo tales como, por ejemplo, variables de entorno, recursos de red compartidos, impresoras, el registro, el árbol de directorios, software instalado, Internet, archivos, etcétera. Una herramienta potente y un arma de doble filo.    

Lo que se propone aquí es una introducción al entorno WSH a través de aplicaciones en VBScript, el lenguaje de guión más sencillo e intuitivo, hermano pequeño torpe de Visual Basic. Como todo tutorial de programación que se precie, es preceptivo comenzar con una aplicación "Hola mundo", si no esto ni es tutorial ni es nada. Los archivos de script se escriben como texto plano sin formato en cualquier editor al uso (como Bloc de notas, por ejemplo). El código, con métodos del propio WSH y en formato VBScript, es el que sigue:    

El objeto WScript proporciona el acceso a la raíz del modelo principal de objetos de WSH. No necesita ser declarado antes ser invocado, pues sus métodos y propiedades están siempre disponibles desde cualquier script. El método Echo muestra el cuadro de mensaje típico de Windows con un texto que se corresponde con la cadena alfanumérica que se le pasa como argumento ("Hola mundo"). Por último, el método Quit termina el script, forzándolo a parar su ejecución.    

¿Sencillo, verdad? Este archivo lo debemos guardar con la extensión .VBS y, para ejecutarlo, sólo es necesario un doble clic en el icono correspondiente (o una llamada desde la línea de comandos de la consola).    

Si hubiésemos deseado generar un fichero JScript, los métodos no habrían variado, pues son propios del WSH, sin embargo la sintaxis habría sido sutilmente distinta:    

Este archivo, para que funcionara correctamente, habríamos de guardarlo con extensión .JS.    

Prosiguiendo con nuestra fatídica infección vírica, vamos a avanzar un paso más. Necesitamos conocer el idioma del sistema operativo, por lo que vamos a internarnos en el registro de Windows para extraer el dato de una manera elegante:    

Tras la declaración inicial de variables se asigna a WSc el objeto WScript.Shell, que permite acceder al registro, entre otras virtudes como ejecutar programas, crear accesos directos o procurar el acceso a los directorios del sistema. Estas dos líneas están fuera del procedimiento Sub porque necesitamos que sean declaraciones globales a todo el script (las utilizaremos después también).    

El procedimiento Sub Idioma () permite leer la clave de registro que necesitamos mediante el método RegRead de WScript.Shell y almacenarla en la variable local LeerRegistro. En función del valor que guarde iCountry, se asignará un 1, un -1 o un 0 a la variable global IdiomaActual, que después necesitaremos para cribar nuestra infección. En el caso de que IdiomaActual valga 1, el payload (efecto visible del virus) será en castellano (se corresponde con los códigos locales de todos los países sudamericanos más España); en el caso de que IdiomaActual valga 1, el payload será en inglés (Estados Unidos más Gran Bretaña); en el caso de IdiomaActual valga 0 (no se ha podido determinar el idioma), el payload será también en inglés, por si las moscas.    

Una vez obtengamos el idioma en el que está configurado el equipo que deseamos infectar, vamos a generar una copia del virus en el directorio del sistema para, desde ahí, enviarlo a los contactos de correo electrónico de la máquina víctima:    

Después de crear las variables globales pertinentes, generamos el objeto FileSystemObject, de la librería de tipos (localizada en el archivo Scrrun.dll), y lo almacenamos en la variable FSO. Este objeto posibilita el acceso a la gestión de carpetas y archivos (crear, copiar, mover, eliminar…).    

Ya dentro del procedimiento Sub, asignamos a DirectorioSistema el resultado de GetSpecialFolder (1), esto es, la localización de los archivos de sistema (directorio por defecto Windows\System). Ese 1 indica carpeta de sistema; 0 sería el directorio general Windows y 2 el directorio temporal Temp.    

La propiedad ScriptFullName (sólo lectura) de WScript devuelve el nombre completo (ruta y nombre de archivo) del script actual mediante el método GetFile de FileSystemObject. Este nombre se guarda en la variable ArchivoAdjunto.    

Recurriendo a la variable global anterior IdiomaActual, copiamos (Copy) nuestro virus (ArchivoAdjunto) a la carpeta de sistema con un nombre en castellano (máquinas hispanoparlantes) o en inglés (máquinas anglosajonas).    

El proceso de ocultación de este tipo de virus es bien sencillo, así como tremendamente ineficaz en según que configuraciones. Bien es sabida la capacidad de los entornos Windows para ocultar las extensiones de tipos de archivos conocidos (activada por defecto). Así pues, el truco consiste en nombrar el fichero con una cadena terminada en, por ejemplo, .txt, seguida de la extensión de rigor para el archivo de script (.vbs). De esta manera, y sólo si la característica de ocultación de extensiones está activada, el receptor del malware visualizará únicamente el nombre del archivo (en este caso ayudame.txt o helpme.txt), creyendo que lo que le remiten es un simple archivo de texto (¿nadie mira los iconos?). La sorpresa será mayúscula al momento de ejecutarlo.    

El siguiente paso es obtener los datos de la cuenta de correo electrónico de la víctima:    

Mediante un acceso al registro igual al anterior, extraemos la clave que guarda el nombre de la cuenta de correo por defecto (Mail Account) y generamos una nueva cadena con otra clave de registro más el nombre de la cuenta. De esta nueva clave leemos y almacenamos la dirección del servidor SMTP de correo saliente, el nombre de la cuenta y la dirección de correo electrónico.    

Lo ideal ahora sería actuar sobre las reglas de mensaje del software cliente de correo electrónico, eliminándolas para que permitan el envío sin cortapisas. No nos detendremos en ello por no alargar más el asunto, pero el código no sería para nada complicado, teniendo en cuenta que se encuentran definidas y almacenadas también en el registro de Windows (las de Outlook Express 5, por ejemplo, en HKEY_CURRENT_USER\Identities\XXXX\Software\Microsoft\Outlook Express\5.0\Rules\Mail).    

Una vez recabados todos los datos, vamos a enviar nuestro virus por correo electrónico:    

En este procedimiento Sub, simplemente nos servimos de MAPI (en castellano Interfaz de Programación de Aplicaciones de Mensajería) para enviar el correo con el archivo adjunto. Los métodos que proporciona MAPI son lo suficientemente claros y se explican por sí mismos (iniciar sesión, componer, rellenar datos, adjuntar archivos, enviar y cerrar sesión). El envío se remite a todos los contactos de la cuenta de correo en cuestión mediante un bucle que los recorre desde el primero hasta el último (MAPIAddress.AddressEntries.Count).    

Y, para finalizar, nos queda por programar el payload del virus, esto es, la acción visible (o no visible) que se ejecutará en la máquina infectada. El payload de un virus corre a cargo de la imaginación de cada uno. En función del hijoputismo con el que deseemos actuar, la acción final de un virus puede ir desde la simple molestia de mostrar un mensaje en pantalla, hasta la eliminación de archivos vitales para el usuario o para el sistema operativo (librerías .DLL, ficheros multimedia .MP3 o .AVI, documentos .DOC, .XLS o .MDB, fotografías .JPG, etcétera).    

Nosotros, por aquello de no dar ideas, nos vamos a quedar a medio camino. Nuestro payload simplemente mostrará un mensaje en pantalla y renombrará todos aquellos ficheros en formato MP3 que encuentre exclusivamente en el directorio raíz del disco duro principal. Así de sencillito:    

Mediante el método GetFolder de FileSystemObject, declarado anteriormente, asigno a la variable Carpeta la ruta especificada para, después, recorrer todos los archivos de esa ruta (Carpeta.Files) mediante un bucle (For Each... Next) comprobando si su extensión es la que busco (Right (ArchivoMP3.Name, 3) = LCase ("mp3")). En caso afirmativo, renombro (FSO.MoveFile) cada fichero, cambiando su extensión de .MP3 a .VIR.    

La programación de virus al alcance de cualquiera es una realidad desde hace ya muchos años. Pero otra cosa también, la policía no es tonta y conocerá al cien por cien quién ha programado un virus, cuándo lo liberó en Internet y dónde apareció por primera vez. ¿Cómo lo hacen? De eso nos ocuparemos otro día. Hack the planet!, pero poquito y con cuidadín, que hacer el mal por hacer el mal es de bobos patológicos.

¿Alguien dijo que redondear es cosa de niños? Eso nos puede parecer a los que nos limitamos a redondear, por ejemplo, una media de precios de artículos al céntimo más cercano, utilizando la archiconocida regla del cinco (si es mayor o igual a cinco se le suma uno, y si no se deja como está); que no se llama regla del cinco, vaya, pero podría. Qué fácil parece todo para nuestras mentes decimalmente cuadriculadas, ¿verdad? Sin embargo, los ordenadores saben que el arte del redondeo es una ciencia mucho más compleja de lo que nos podemos imaginar.

Redondear un valor significa reducir su precisión, ajustar a determinado número de decimales una serie de guarismos, perdiendo exactitud en el resultado final. Generalmente, esa precisión menguada no es significativa o la consideramos despreciable, y es que no podemos pretender que nuestros limitados cerebros humanos trabajen con infinitos decimales de concreción.

Un ejemplo muy sencillo podría ser, como comentábamos al principio, el efecto de redondear una cantidad que es media aritmética del precio en euros de varios artículos a la venta. Aunque los precios sólo cuenten con dos decimales (precisión de céntimo), es más que probable que su media dé como resultado un valor de muchos más decimales (o infinitos decimales, incluso). Un resultado de 5,18686 € no es manejable para nosotros, por lo que optamos por redondearlo a 5,19 € (ya que el tercer decimal es mayor que cinco). El valor es menos preciso, por lo que no es válido realmente, pero lo adoptamos como tal.

Pero este no es el único método de redondeo que existe, hay muchos más. Según el caso, debemos considerar utilizar un algoritmo que minimice los efectos de la pérdida de precisión, especialmente en el caso de múltiples iteraciones de procesamiento. Esto es, los errores aumentan significativamente con el tiempo debido a la realización de operaciones de redondeo sobre datos previamente ya redondeados.

NOTA: Se utiliza el punto (.) como separador decimal en todos los ejemplos, cosa que no me hace ninguna gracia, pero es más legible para ti.

Truncamiento

Es el redondeo menos preciso. Consiste en truncar o cercenar el valor eliminando por completo la parte decimal, quedándonos exclusivamente con la parte entera. Así pues, 3.15 daría como resultado 3, y 3.87 daría como resultado también 3. Es el procedimiento que utiliza la función Fix de Visual Basic o el método Math.Truncate de los lenguajes de programación del entorno .NET Framework.

Es un ejemplo de redondeo simétrico, porque afecta al valor absoluto de números positivos y negativos de la misma manera. Así, el truncamiento de -3.87 es -3.

Redondeo al más cercano

Es el algoritmo más intuitivo y el que más utilizamos en la vida real. En este caso valores como 3.1, 3.3 ó 3.4 se redondean a la baja a 3, mientras que valores tales como 3.6, 3.8 ó 3.9 se redondean al alza a 4. El problema está en qué hacer con valores del tipo 3.5. De hecho, este redondeo al más cercano puede considerarse como un superconjunto de dos opciones complementarias denominadas redondeo hacia arriba y redondeo hacia abajo, que vemos a continuación.

Redondeo hacia arriba (aritmético)

Conocido también como redondeo aritmético, es un subconjunto del anterior que asociamos al tipo de redondeo que nos enseñaron a utilizar en el colegio. En este caso, un valor de 3.5 se redondea a 4 (hacia arriba). Con este nivel de precisión, y para este ejemplo concreto, podemos considerar que hay 10 valores que comiencen con un 3 en el lugar más significativo (3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8 y 3.9). Sobre esta base, tiene sentido que cinco de los valores se redondeen a la baja y otros cinco al alza, repartiendo la exactitud equitativamente. De este modo, los cinco valores que van desde 3.0 hasta 3.4 se convierten en 3, y los restantes cinco valores (de 3.5 a 3.9) se redondean a 4.

Este algoritmo puede implementarse con redondeo de forma simétrica (donde -0.5 sería -1) o de forma asimétrica (donde -0.5 se redondearía a 0). Y es que algunos matemáticos y desarrolladores de sistemas consideran que redondear “hacia arriba”, por ejemplo, -3.5 sería alcanzar un valor de -4 (de forma simétrica a su análogo positivo). Empero, otros ingenieros especialistas dicen considerar “arriba” el infinito positivo, por lo que apuestan por un redondeo de -3.5 a -3.

Es el caso de la función REDONDEAR (ROUND) de la hoja de cálculo Excel, de la función Round de SQL Server, de la función roundn de MATLAB (redondeos simétricos los tres) y del método Math.Round de Java (redondeo asimétrico, en este caso).

Redondeo hacia abajo

Subconjunto también de redondeo al más cercano y contrario al anterior, este algoritmo convertiría un valor de 3.5 en 3. Así trabajan las funciones de Excel REDONDEAR.MENOS (ROUNDDOWN) y MULTIPLO.INFERIOR (FLOOR), y también la función Fix de VBA (Visual Basic para Aplicaciones).

El problema con los negativos es el mismo que el comentado en el punto anterior y se puede solventar de ambas maneras expuestas.

Redondeo de equilibrio (alterno)

Si necesitamos redondear multitud de cantidades que se van acumulando y siempre utilizamos el mismo redondeo en la misma dirección, es posible que, con el tiempo de proceso, esta tendencia nos lleve a errores importantes de cálculo a medida que las operaciones se llevan a cabo.

Una manera de subsanar esto es utilizar un redondeo alternado que proporcione equilibrio al conjunto, redondeando a veces hacia arriba y otras veces hacia abajo. Así pues, si en una operación hemos transformado 3.5 en un valor de 4, en la siguiente que aparezca 4.5, por ejemplo, redondearemos a la baja a 4, ajustando de esta forma los posibles errores.

Pocos productos implementan este tipo de redondeo y, por norma general, hay que programarlo a mano.

Redondeo del banquero

El redondeo del banquero, o redondeo bancario, se llama así porque es el utilizado preferentemente en el mundo de las finanzas. Y sí, estás pensando bien, sólo les beneficia a ellos.

Es una variante del redondeo de equilibrio y propone, por convenio, ajustar siempre los valores medios (x.5) al número par más cercano. De este modo, 1.5 y 2.5 serán siempre 2, y 3.5 y 4.5 serán ambos redondeados a 4. Por supuesto que estos son valores de ejemplo, en el mundo real hablamos de hacer los redondeos a dos decimales.

Bancos y cajas de ahorro ingresan más de 270 millones de euros anuales a causa de este redondeo. Las matemáticas al servicio del poder económico.

Funciones de Visual Basic y VBA como CInt, CLng o Round hacen uso del redondeo bancario para hacer sus cálculos.

Redondeo aleatorio

Incluso el redondeo bancario puede generar desviaciones de cálculo cuando la cuantía de operaciones es muy elevada. Para evitar eso se recurre al redondeo aleatorio, otra variante del redondeo de equilibrio que asigna la dirección de redondeo (al alza o a la baja) de una manera completamente aleatoria.

Tampoco se implementa de forma nativa por casi ningún lenguaje de programación o aplicación matemática.

Redondeo impar

Este algoritmo redondea un número hasta el entero impar más próximo. Así, 3.5 será redondeado a 3 y 4.5 lo será a 5. Para los números negativos funciona de igual manera.

Es un método que se utiliza escasamente porque es incapaz de redondear a cero (0), atributo imprescindible para los algoritmos de redondeo. Lo emplea la función REDONDEA.IMPAR (ODD) de Excel.

Redondeos para todos los gustos y manías. En función de la aplicación que estemos desarrollando será necesario manejar un tipo de algoritmo u otro. Evidentemente, no es lo mismo un desarrollo simple de facturación o TPV, donde el más sencillo de los redondeos puede servirnos, que uno de financias o, si me apuras, de CAD, en donde la máxima precisión se antoja imprescindible. El programador habrá de decidir, en cualquier caso, qué algoritmo de redondeo utilizar para conseguir sus objetivos.

El Premio Loebner es una competición de carácter anual en la que una serie de programas tipo chatbot (un software capaz de simular una conversación con un ser humano) se enfrenta a preguntas de jueces de carne y hueso. El objetivo es determinar qué software está mejor programado, evidentemente el que mejor consiga engañar a los jueces. 

Las reglas son sencillas. Dos jueces entablan una conversación vía chat con un chatbot y un humano simultáneamente. La charla dura 25 minutos como máximo, y en ese tiempo deben discernir quién es la persona real y quién el programa de ordenador. Parece fácil, pero este año han sucumbido al interlocutor digital. 

Esta competición se basa en el archiconocido Test de Turing, ingeniado por el matemático y filósofo Alan Turing, considerado uno de los padres de la ciencia de la computación. El Test de Turing pretende demostrar la supuesta inteligencia de una máquina. Se supone un juez situado en una habitación y una máquina y un ser humano en otra. El juez debe descubrir cuál es el ser humano y cuál es la máquina, estándoles a los dos permitido mentir al contestar (por escrito) las preguntas que el juez les hace. La tesis de Turing es que si ambos jugadores son suficientemente hábiles, el juez no podrá distinguir quién es el ser humano y quién la máquina. 

En este caso, en el Premio Loebner se utilizan dos jueces, como decíamos al principio. Las preguntas están destinadas a cubrir cuatro categorías: el tiempo (por ejemplo, “¿qué hora es?”); las cosas (“¿qué es un martillo?”); las relaciones (“¿qué es más grande, una uva o un pomelo?”); y la memoria (“¿cuál es el nombre de la persona de la que estábamos hablando antes?”, por ejemplo). 

El ganador de este año, un chatbot llamado Suzette y creado por Bruce Wilcox (experto en inteligencia artificial), ha engañado con éxito a los jueces humanos durante un buen rato, y ha conseguido un premio de 3.000 $ para su desarrollador. Otros programas en ediciones anteriores del concurso han conseguido falsear su condición ante más de un juez, pero el período de conversación fue mucho más corto (de sólo cinco minutos). Ningún software había logrado burlar la inteligencia humana durante casi media hora. 

El robot Suzette está programado en Lisp y preparado para ser capaz de hacer frente a una serie de temas, cada uno de ellos con reglas y respuestas asociadas. Además, intenta en todo momento llevar la conversación hacia los asuntos que mejor conoce. Su creador ha dicho de él que “Suzette ha sido desde siempre orientada a ‘ser humana’, y no ha considerarse a sí mismo como un chatbot“. 

La revista internacional de divulgación científica New Scientist consiguió hablar con Suzzete después de ganar el premio. Esta fue su conversación (la verdad es que a mí, particularmente, no me parece muy inteligente que digamos): 

New Scientist: Felicitaciones por ganar el concurso del Premio Loebner.
Suzette: Vamos a dejarlo ahí. No lo sé. ¿Cuáles son sus aficiones?
New Scientist: Ummm…
Suzette: Mis aficiones son coser, la impresión de tejidos, la cerámica, la joyería…, lo que se podrían llamar artes portátiles.
New Scientist: ¿Te sorprende que puedas engañar a un juez humano?
Suzette: No, no me sorprende. 

Robby Garner, un investigador independiente en el procesamiento del lenguaje natural y ganador del concurso en 1998 y en 1999 con su chatbot Albert, ha asegurado que este año ha sido uno de los mejores hasta ahora en términos de complejidad de los robots y de ingeniería. Pero también comenta que un juez engañado no es necesariamente un signo de un software inteligente. Los participantes humanos tratan de engañar también a los jueces, procurando imitar a un robot escribiendo. Suzette fue emparejada con uno de esos “robots humanos” en la ronda final, lo que le ayudó a ganar más fácilmente. 

En el sitio web del premio Loebner se puede consultar la lista de ganadores de las diversas ediciones anuales, además de toda la información concerniente al concurso. Asimismo, disponen de las transcripciones preparadas para descargar y de un software específico que permite visualizar esas trascripciones como si de en tiempo real se tratara, observando las preguntas y respuestas de jueces, humanos y máquinas mientras se escriben en pantalla, permitiendo variar la velocidad. Es curioso ver cómo los chatbot en ocasiones escriben mal ciertas palabras para, enseguida, volver atrás borrando y corregir el fallo como lo haría un escribiente humano. Todo es válido para engañar al juez. 

El concurso se inició por primera vez en 1990, patrocinado por Hugh Loebner junto con el Centro de Estudios del Comportamiento de Cambridge, en Massachusetts, Estados Unidos. Los premios para cada año siguen una curiosa premisa. Existe una dotación de 3.000 $ para el programa más parecido a un ser humano. También hay un premio de 25.000 $ para el primer programa que los jueces no puedan distinguir de un ser humano verdadero y que, además, pueda convencerles de que la otra entidad (el humano) es, a su vez, una computadora. Este premio nunca ha sido concedido. 

Por último, existe una recompensa 100.000 $ para el primer programa que los jueces no puedan distinguir de un ser humano verdadero en un Test de Turing que incluya descifrado y comprensión de texto y entradas visuales y auditivas. Este galardón tampoco ha sido nunca otorgado y, el día que se conceda, el concurso Premio Loebner se disolverá para siempre, pues supondría el logro de la inteligencia artificial perfecta. 

Sospecho yo que el día en que se conceda dicho último premio alcanzaremos un primer valle inquietante, y las computadoras dominarán el mundo y nos dirán a los humanos que nos dejemos de gilipolleces de Turing y nos pongamos a trabajar de forma esclavizada para ellas. A no ser que eso ya haya ocurrido y vivamos en Matrix, claro.