Xnoccio

Un desconcertante comportamiento de Java con el autoboxing de los tipos boolean,Si tenemos las siguientes linea, funciona correctamente.

Boolean repetible=null;if(!( repetible==null))

Sin embargo, si sustituimos == por != nos encontramos con un misterioso error que provoca un “java.lang.NullPointerException at booleanValue()“.

Boolean repetible=null;if(repetible!=null)

Analizando un poco el tratamiento que le da java al autoboxing, podemos ver que el comportamiento tiene su sentido, aunque no deja de ser un tanto curioso.En el primer caso, la comparación funciona correctamente ya que el operador == aplicado a Objetos comprueba si los dos objetos son iguales, sin hacer una llamada al booleanValue() para generar el tipo primitivo.En el segundo caso al ser ambos operadores booleanos, una de las optimizaciones de la Máquina Virtual nos juega una mala pasada. En esta caso, el operador != se comporta diferente, ya que el operador de negación trabaja con el valor primitivo del Boolean, invocando a booleanValue().

Actualización

A raíz del comentario de Pablo Moretti, me he dado cuenta que estaba en un error, no es Java 5 el que tiene el problema, si no el JDT de Eclipse 3.3. Para reproducir el poblema:

    public static void main(String[] args) {
	Boolean b=null;;
	// Este código falla en Eclipse 3.3 al ejecutar en modo debug
	// un inspect sobre la condición
	if(b!=null){
	    System.out.println("B no es null");
	}
    }

Iniciamos la ejecución en modo depuración, seleccionamos con el cursor (b!=null) e inspeccionamos su valor.

Jboss Seam es un magnífico framework para el desarrollo de aplicaciones Web, pero plantea algunos problemas, cuando deseamos reutilizar nuestro código Seam  desde una aplicación que no se esta ejecutando dentro de un servidor de aplicaciones o desde un Thread independiente. Esto es debido a que sin la envoltura del servidor de aplicaciones, ninguno de los contextos Seam estarán disponibles.

El error típico con el que nos vamos a encontrar es:

java.lang.IllegalStateException: No application context active
at org.jboss.seam.Component.forName(Component.java:1807)

Código para inicializar Seam antes de utilizarlo:

     /**
     * Inicializa el contexto Seam.
     * Necesario para ejecutar código cuando el contexto Seam no esta inicializado y necesitamos acceder a elementos del contexto.
     * Con esto evitamos la excepción "No application context active"
     * @author Félix García Borrego
     */
    public static void initContextApplication(){
        if(!Contexts.isApplicationContextActive()){
        // Si el contexto no esta inicializado lo creamos
       if(!Lifecycle.isApplicationInitialized()){
            // La aplicación no esta activa, la activamos
            MockServletContext servletcontextMock = new MockServletContext();
            ServletLifecycle.beginApplication(servletcontextMock);
            new Initialization(servletcontextMock).create().init();
     }
     // Inicializamos el contexto
     ServletLifecycle.beginInitialization();
 }

Puede parecer una tontería, pero yo he tenido este problema. Haciendo el maven eclipse:eclipse de un nuevo proyecto se me queja de esta dependencia:

com.sun:tools:jar:1.5.0

Y claro, esa dependencia no existe en ningún repositorio. ¿Cuál es el problema? El problema es que Eclipse estaba usando para compilar la JRE, no la JDK. Para resolverlo nada más simple que decirle que use el JDK:

Windows -> Preferences -> Java -> Installed JRE’s -> Add

Y añadimos una con nombre JDK que apunte a la ruta del JDK y la marcamos para que la use por defecto. Cuando añadamos cualquier servidor Tomcat con usar el “default workbench JRE” tenemos suficiente.

Las redes neuronales son una de las herramientas más potentes en el campo de la IA, y en particular suelen dar muy buenos resultados en la detección y reconocimiento de figuras. Recientemente hemos realizado pruebas para valorar si incluíamos esta posibilidad en la detección de figuras en uno de nuestros proyectos. Y aunque en este caso, se ha descartado esta opción, me hace pensar que es sólo cuestión de potencia que algún día las máquinas puedan ser capaces de “ver flores”.

Y para demostrarlo, vamos a detectar en la siguiente foto quiénes son “un poco Flower”:

El primer paso es aplicar a la imagen original un algoritmo de detección de bordes para simplificar la imagen:

Ya que la potencia de calculo es finita y escasa, nuestra red neuronal contendrá sólo 10×10 neuronas, para poder distinguir y procesar una zona muy pequeña, pero suficientemente representativa de la flor.

El siguiente paso es entrenar a nuestra red neuronal, para ello, proporcionamos a la red neuronal ejemplos correctos e incorrectos de regiones de la imagen y lanzamos el proceso de entrenamiento sobre este conjunto reducido.

KernelIA ia = KernelIA.buildKernel(imagen, rectangulos);

Internamente este método itera sobre todas las zonas de ejemplo que tenemos, las transforma a una matriz entendible por la red neuronal e inicia el proceso de entrenamiento para cada patrón.

Una vez que el proceso de entrenamiento ha terminado, ya esta disponible la red neuronal para ser interrogada. Recorremos la imagen, e interrogamos a la red neuronal, en busca de zonas que cumplan con el patrón buscado.

Resultado tras 10 minutos de entrenamiento y 15 patrones sobre los que aprender:

Resultado tras 6 horas de entrenamiento y 40 patrones sobre los que aprender:

Como vemos, en este último caso, el sistema prácticamente ha sabido detectar todos los “Flowers de la oficina”, aunque incluso con 6 horas de entrenamiento, ha cometido algunos extraños errores. Probablemente con algo más de tiempo, paciencia y potencia de cálculo podremos llegar al objetivo deseado en el futuro.