Ponto de não progressão!

Pois é, desde que iniciei em termos efectivos o projecto desde já quase há um mês (5 de Fevereiro) atingi um ponto que se pode considerar como de não progressão, e isto porque, apesar do código do CGA já estar num nível que eu poderei considerar de certo modo aceitável -com uma nova classe MyRandom para gerar numeros aleatórios inspirado num código em C++ que me foi cedido pelo meu orientador e que se baseia em grande parte neste artigo da ACM - Random number generators: good ones are hard to find, da autoria de S. K. Park e K. W. Miller. O problema agora trata-se de experimentar pela primeira vez os Web Services, e o que eu quero fazer pela primeira é uma coisa mínima, fazer com que um cliente (worker, melhor dizendo) descarregue um vector-população a partir do manager, mas para conseguir fazer isso vou ter que mexer em classes de JAVA como a JAX-RPC, que, como de acordo com o que está no link anterior, se trata de uma biblioteca de JAVA que permite evitar ao programador o acesso directo ao protocolo SOAP. Como ainda não estudei a fundo a API do XML-RPC, não posso estar por aqui a dar detalhes. Tenho andado a tentar seguir este tutorial, que se baseia no TomCat, ao contrário do último, que usa ao invés um webserver qualquer da Sun, que já tive oportunidade de experimentar e que é muito pesado, por isso optei por não o seguir, não se fiz mal, mas as diferenças não são grandes. O problema é que os passos descritos são para ser usados para o caso em que se usa directamente o TomCat directamente para implementar os Web Services, e não por intermédio do Axis, como pretendia inicialmente. O problema é que ainda não encontrei um tutorial de Axis verdadeiramente condigno que me explicasse as coisas são assim, assim e assado, e tens que fazer estes passos para chegar lá. Só encontrei um que me explicava as coisas, mas tratava-se de usar ficheiros JWS, que são no entanto Web Services demasiado básicos para o meu gosto e que no fundo parecem mais receitas rápidas para demonstrar que o Axis funciona, do que bons exemplos que permitam Web Services mais complexos e aceitáveis. Por isso, que pelos vistos, vou ter que fazer um meio-termo entre o tutorial da Sun e o manual do Axis . O Axis permite simplificar a vida, permitindo gerar o código JAVA directamente a partir do WSDL, graças à ferramenta WSDL2Java, existindo também a recíproca, Java2WSDL . Para além de tudo isto, ainda por cima, chega finalmente a 3ª semana do 2º semestre, em que acho que o "2º semestre" vai começar a doer, em que as disciplinas de Inteligência Artificial e Progtamação Funcional e Lógica me vão dar água pela barba que chegue!!! De modo que acho, que se isto começar a dar problemas, o projecto vai ter que ficar em banho maria!!!

Mas que raio de WSDL...

Agora que já consegui realizar uma primeira implementação do CGA em JAVA, falta interligar com a outra parte do projecto e que tenho vindo a aprender por custo próprio aos poucos: fazer o algoritmo genético circular pela rede, ou seja, pôr clientes a trabalhar num vector população e criar um servidor que gira (de gerir) o trabalho de todos os clientes, distribuindo por todos os clientes o vector população que necessitam para por o CGA a trabalhar. Basicamente, trata-se de uma arquitectura "worker-manager" que é explicada neste artigo. Tenho, portanto, de pôr um manager (ou servidor) e workers (ou clientes) a comunicarem entre si através de Web Services. E para definir Web Services é necessario criar um ficheiro XML que descreva os Web Services atraves de um formato conhecido por WSDL. Atraves deste formato sao descritas coisas como o nome da API (função), como os seus parâmetros, o seu tipo assim como o tipo de retorno da função que o cliente necessita de invocar do motor de Web Services (eu chamo-lhe motor porque é um módulo que roda num servidor Web, ou seja, é um componente do servidor e não um servidor por si próprio, que neste caso concreto é o Apache Axis). Deste modo, é definida uma interface do Web Service (WS), que pode ser explorada por toda uma diversidade de clientes, escritos nas mais variadas linguagens. Pois é assim mesmo que deve ser: uma vez que na Internet coexistem a mais diversas plataformas e linguagens, um formato universal que permita descrever a interface do WS de modo que permita que qualquer cliente o possa utilizar. De modo que neste momento as dúvidas é que se põem estão relacionadas sobre quais devem ser as APIs a utilizar, eu pensei nas seguintes, não sei se serão as melhores, mas em minha opinião acho que não desagradam:

• DownloadPopulationVector - o worker pede ao manager um vector população com o qual possa começar a trabalhar. Este passo é feito no princípio por um novo worker disposto a iniciar um novo trabalho ou então na ocasião em que estando completo o trabalho depois de cumpridas m iterações do algoritmo - que é por outro lado, um parâmetro da resposta enviada pelo manager ao worker quando é descarregado o vector população para o worker - de modo que o worker possa saber quando a fase presente de trabalho terminou e pode enviar o resultado obtido para o manager.


• SendPopulationVector - o worker completou finalmente o seu trabalho e está disposto a enviar o vector população apenas com as diferenças entre o último vector população que recebeu do manager e o estado em que ficou o VP (vector população) depois de cumpridas as tais m iterações estabelecidas pelo manager. A esta solicitação o manager deve responder - depois de verificar se o VP já atingiu alguem critério que permita terminar o algoritmo - com uma resposta que informe a conclusão do trabalho ou então. No caso da resposta ser negativa, ou seja que o VP ainda não convergiu, então o cliente tem o dever de invocar a API anterior para que possa descarregar um novo VP e prosseguir o seu trabalho.
  

Até agora, é este o "estado do arte", que, no entanto, ainda nem comecei a implementar!!! É apenas, por enquanto, e ainda, uma declaração de intenções.

Numeros aleatorios muito pouco aleatorios

Nos algoritmos em que ando a trabalhar, é indispensável o uso de números aleatórios durante para gerar a população inicial, ou no caso concreto do CGA, para gerar os cromossomas dos indivíduos que se confrontam. A utilização de um gerador fidedigno é essencial para o bom funcionamento. E o que deve ser um gerador fidedigno ? Por poucas palavras, é um gerador em que, dado um determinado intervalo dentro do qual se pretenda obter os valores aleatórios, a probabilidade de sair um número é exactamente idêntica à de outro qualquer. Para melhor compreender estes assuntos, suponhamos um intervalo entre 0 e 1, dividido em 100 partes, assim em princípio, se pedirmos ao gerador para criar um número aleatório 100 vezes, a probabilidade de calhar um número em cada um desses intervalos é de 1%. Se forem 1000 vezes, a frequência absoluta é de 10 e 10000 de 100. Quanto maior for a amostragem, mais as probabilidades de cada intervalo se equilibram entre si.
Deste modo, decidi correr um programa para decidir se o gerador era o mais fiável possível baseado no exemplo que descrevi acima, isto apesar de acordo, com a teoria, geradores aleatórios perfeitos são coisas que não existem. Submeti então ao programa o gerador de números aleatórios baseados no código que o meu orientador me forneceu, assim como o gerador que vem com a biblioteca da Java.
Deixo aqui uma imagem que ilustra o resultado do programa para algoritmo extraído do SGA e baseado no livro do Goldberg:

Acho que se pode concluir que o gerador não é assim tão mau !!!

Qual o melhor IDE ?

Como nestes próximos tempos vou estar bastante ocupado no projecto programando em JAVA, ando à procura de um IDE (Integrated Development Environment) - ou Ambiente de Desenvolvimento Integrado, na língua de Camões - que me permita potenciar a produtividade, e para mim, os aspectos essenciais que me dão mais jeito são:

1. Em primeiro lugar, que me dê a capacidade de aceder à documentação de JAVA da forma mais rápida e eficiente possível sem ter que estar a perder tempo a perder tempo a fazer cliques para encontrar o documento referentre à classe da biblioteca de Java de que preciso.
2. Que seja initituitivo, isto é, que eu não ande perdido uma eternidade à procura como se faz uma "merdazinha" que se faz num instante num outro IDE a que eu já esteja acostumado
3. Permita detectar erros que normalmente não se detectam entquanto se está a escrever o código, isto que só são detectados em tempo de execução, ou seja.
4. Capacidade de auto-completar expressões bastante vulgares como por exemplo escrever automaticamente as duas expressões mais compridas e vulgares que existem em Java e que são:



public static void main(String[] args)
{
//...
}

e


System.out.println("blablabla");

5. Eu sou uma pessoa que se chateia com facilidade com repetições, nem as posso ver à frente, e um IDE que me permita evitar chatices é um passo decisivo para entrar nos meus gostos.

Tenho andado a experimentar três IDEs: o JCreator, o Netbeans e o Eclipse. De todos o que eu uso há mais tempo é o JCreator, pois é escrito em C++, tendo um tempo de arranque bem mais curto que os outros dois, é intuitivo e facilita imenso a navegação nos javadocs, mas não tem capacidade de detectar erros que normalmente só se encontram em tempo de execução, coisa que os outros dois IDEs - o Netbeans e o Eclipse - sabem fazer e bem. Por outro lado, estes dois últimos têm uma capacidade de integração com CVS bastante avançada (o JCreator só incluiu esta propriedade na última versão - a 3.5) e o NetBeans traz já integrado um editor ao estilo de Visual Basic para quem gosta de desenhar caixas, janelas e botões para o Swing (a biblioteca para criação de GUIs do Java), para não falar de trazer um servidor de JSP - o Tomcat. O Eclipse é que não traz de raíz um editor gráfico - mas essa falha pode-se corrigir, puxando o respectivo plug-in. Mas, falando a sério, o Eclipse não é editor exclusivo para JAVA, a sua extensibilidade é muito maior. Aliás o Eclipse, é de acordo com a IBM, que o criou e depois o libertou para o movimento open-source, um "meta-IDE", ou melhor, uma espécie de ambiente de criação de IDEs, uma vez que pode ser facilmente integrado com qualquer linguagem, havendo já plug-ins para C++, Perl, Python, Bash e PHP. É verdadeiramente um IDE "multi-plataforma". Apesar da grande sofisticação destes dois últimos IDE's, não estando em nada abaixo de IDEs mais profissionais e comerciais como o Visual Studio .NET da Microsoft, o preço a pagar por esse facto e por serem escritos em JAVA é o tempo de arranque e o gasto de recursos: tanto o NetBeans como o Eclipse são dois devoradores de memória e levam mais de um minuto a arrancar desde o momento que clico no icone até ser possível escrever alguma coisa. Quanto ao gasto de RAM, eles começam de mansinho nos 50 MB, mas dali a dez minutos já andam nos 100 MB. Não, recomendo, por isso, a utilização destes IDEs a quem tiver um computador mais lento que 1 GHz e menos de 256 MB de RAM (o meu tem 1800 GHz e 384 MB).
Apesar de tudo, os IDEs baseados em JAVA tem a vantagem que é o grande slogan da linguagem criada pela Sun: Compile one time, run everywhere, pode-se trabalhar em qualquer SO.

JGAP!

Quando andei na net à procura de possíveis problemas que possam ser resolvidos por meio de algoritmos genéticos, deparei-me com este projecto hospedado no Sourceforge que dá pelo nome de JGAP (ou JAVA Genetic Algorithms Package), uma biblioteca em JAVA que dá para ser utilizado livremente em qualquer outro projecto, desde que cumpra os requisitos da licença estipulada no Web Site. Tive a experimentar como funcionava, experimentando com a mais simples das funções de Algortimos Genéticos, o One-Max (que devolve o número de uns existentes num cromossoma) e funcionava. Engraçado é que aquilo, pelo menos porque tive oportunidade de ver a documentação ainda um tanto superficialmente não tem um critério de convergência para paragem do algoritmo quando for atingida a "melhor solução". Mas deve andar para lá. Aqui fica uma lista de trabalhos científicos que citam o JGAP. Deixo também um link para uma página que apresenta a equipa por trás do projecto.

CVS = Concurrent Versions System

Pois é ! Tenho andado a aproveitar estas férias que estão quase terminadas da melhor maneira ! Ando a aplicar-me e decidi finalmente embalar-me e tentar perceber que raio é isso que provavelmente alguns de vocês já terão tropeçado e que dá pelo nome de CVS. Provavelmente alguns de vocês já depararam nisso enquanto estiveram a explorar algum IDE (Ambiente de Desenvolvmento) numa opção chamada "CVS". Pois bem: o CVS serve para que em empresas com equipas de vários programadores possam desenvolver em grupo diferentes porções do projecto comum em que estão envolvidos. Deste modo enquanto um colega edita um ficheiro A, outro programador pode estar a trabalhar no mesmo ficheiro e é usado um repositório onde são guardadas todas as versões passadas e conhecidas de todos os ficheiros que alguma vez fizeram parte desse projecto. É possível também recuperar versões antigas de determinado ficheiro, se for caso disso. A mim isto interessa-me para o projecto porque assim posso estar a trabalhar nisso em qualquer lugar. Através de um repositório guardado no computador do laboratório 2.56 que me foi adjudicado, posso importar os ficheiros e trabalhar em qualquer outro computador da universidade, basta apenas ter um cliente de CVS instalado na máquina para onde desejo ir trabalhar. Por outro lado, é bom, porque dá um aspecto profissional a toda a cena. O CVS é praticamente universal, sendo praticamente o software "standard" usado em todo o mundo por grupos de programação dedicadas a produção de software "a sério". O Sourceforge.net suporta CVS para todos os membros de um projecto, deixo aqui o link para um dos projectos (o TightVNC) de maior saída e que são um bom exemplo daquilo que o Open Source é capaz. Deixo também aqui um link para o repositório do PHP

Java server pages, SAAJ, JAX-RPC, tudo uma grande confusão...

Pois é, nestes últimos tenho-me aventurado pelo grande mundo das Java Server Pages (JSP). Para alguém, como eu, que vinha do PHP e, pensava que todos os geradores dinâmicos de páginas fossem todos do género da simplicidade do PHP para configurar e começar a programar vaiam tirando o cavalinho da chuva. Para correr JSP é necessário um web server próprio, para além, de é claro, uma máquina virtual java com compilador instalada na mesma máquina onde esteja a correr o servidor de JSP, que, no meu caso, é o Apache Tomcat , e, uma vez por aquilo que li é, de entre todos os servidores de JSP, o mais chato de configurar porque é tudo feito via ficheiros do configuração, como o seu irmão mais velho, o servidor Web Apache propriamente dito. Acontece que o Tomcat é standalone, quer dizer, não depende da existência de outro servidor HTTP na mesma máquina, e corre numa porta própria: por defeito a 8080. É no entanto, possível interligar os dois através de dois módulos do Apache: um é o mod_proxy, outro é o mod_jk. Um ou outro, como tive oportunidade de testar funcionam bem: o melhor é o segundo, porque foi especialmente desenvolvido para esse efeito.
O problema é com Apache e Tomcat na mesma máquina o consumo na mesma máquina (eu testei em Windows) vai para cima dos 50 MB e o Tomcat como é escrito em JAVA, demora meio-minuto a arrancar completamente, mas depois, já de pé, não fica em nada atrás do Apache. O problema é que para depois tar a configurar aquilo tudo como deve de ser, não é nada simples para quem, como eu, está habituado ao "velho" Apache. As JSP é um mundo muito próprio que fala a sua própria língua.
Assim, por exemplo, em JSP, e ao contrário do PHP em que só existe dois tipos de tags : <? ?> e <?= ?> no PHP existem até quatro, parecidas com ASP: <% %>, <%= %>, <%! %>, e <%@ %>. Enquanto as duas primeiras têm practicamente a mesma finalidade das que lhe são idênticas em PHP, as duas últimas são específicas, a terceira é para declarar código Java de forma livre e a última é para declarar directiva, do estilo de import's, ao que parece, ainda não naveguei nisto a fundo para perceber isto ? Mas para que raio eu preciso de saber isto tudo ? Acontece que estou pensando em escrever Web Services usando JAVA, daí que precise de usar JSP. O Axis, motor que eu pretendo usar sobre o Tomcat, é escrito em JSP, e posso vir a precisar de saber JSP para saber como escrever os Web Services. Ainda não sei como isso se faz, mas espero vir a saber.

Entretanto, a implementação do CGA em JAVA vai "nos eixos": tem passado em quase todos os testes. Nem era de surpreender, dada a sua simplicidade, depois de usar o One-Max, a mais simples das funções em Algoritmos Genéticos, tentei experimentar com a Trap Function, mas acho que não sei muito bem como aquilo se define. Para determinar o máximo de funções reais de variável real é que tem funcionado perfeitamente !!! Agora espero conseguir resolver outros problemas com o meu CGA em Java. Net aí vou eu....

Primeira implementação concluída

Consegui terminar a primeira implementação do CGA em Java. Comecei por fazer tudo numa única classe e no método main, seguindo a passo a descrição existente no artigo original do meu orientador. Já com o algoritmo e tudo a funcionar comecei por experimentar pela função mais básica quando se trata deste campo dos algoritmos genéticos - a one-max, que consiste em simplesmente contar o número de uns presentes no cromossoma. Até aqui tudo bem, mas quando fui usar com a função trap, é que as coisas já não correram tão bem de feição. Provavelmente eu não me recordo é perfeitamente de como se constrói a função trap.
Após ter tudo a funcionar comecei a modulizar e a organizar o código: o algoritmo genético compacto passou a classe abstracta, de modo que para ser implementado é necessário fazer uma subclasse descendente que implemente a função fitness. Deste modo é possível fazer a reeutilização de código de acordo com o tipo de problema. E estou já em querer imaginar um tipo de problema concreto que eu possa utilizar para utilizar o algoritmo. É bom ver o meu trabalho começar já a dar os seus frutos.
A outra parte vai ser como aprender a desenvolver os Web Services. Esta parte vou ter eu que aprender inteiramente sozinho, mas a minha intenção é usar o motor Apache Axis, baseado em JAVA, que para funcionar precisa do suporte do Tomcat, que é um servidor Web baseado em JAVA desenvolvido pela Apache Foundation que serve para albergar JSP (Java Server Pages). Eu neste momento ignoro quase a 95% o que eu vou ter que fazer para por os Web Services a funcionar, quanto mais interligar o algoritmo genético compacto com os Web Services. Até agora só vi a parte emersa do iceberg, agoro vou querer ver os restantes 95% que estão debaixo da superfície!

Primeiro post

Este é o primeiro post neste blog, que temporariamente irá receber o nome de WebServCGA, contracção de Web Services for Compact Genetic Algorithm. Enquanto não encontrar nada de melhor, vou usar precisamente este nome. Diaria ou semanalmente, espero eu, vou dando aqui as impressões da forma como o trabalho vai decorrendo. Espero que, quando chegar ao fim deste projecto, eu possa, ao rever todo este blog do princí­pio, os sacrifícios que fiz até ter conseguido alcançar um resultado que espero que seja o mais frutuoso possível.