henryzord / ednel Goto Github PK

Atualmente a versão na branch with_null tem um algoritmo que impede ciclos de serem formados. Remover essa restrição e re-testar o algoritmo para ver seu desempenho.

Atualmente as probabilidades, após atualizadas, são deixadas sem normalização, e só são re-normalizadas durante a amostragem.

Talvez seja interessante re-normalizá-las tão logo elas sejam atualizadas no graphical model.

Atualmente a informação mútua não é ajustada para contabilizar variáveis com muitos valores.

Ela deve ser ajustada para reduzir essa interferência, copiando a implementação do scikit-learn: https://scikit-learn.org/stable/modules/generated/sklearn.metrics.adjusted_mutual_info_score.html#sklearn.metrics.adjusted_mutual_info_score

As probabilidades não estão somando 100%. Verificar código em AbstractVariable, incluindo método addResidualProbabilities.

É apenas necessário anotar a performance no conjunto de validação do melhor indivíduo desta geração.

Desativar o código que faz este processamento para todos os indivíduos.

Criar método que permite fazer esse cálculo posteriormente.

Contar número de indivíduos inválidos gerados. Se 5 indivíduos inválidos forem gerados em sequência, resetar busca para último indivíduo válido gerado.

Se mesmo assim nenhum indivíduo válido for gerado... não sei!

Variáveis do J48 e PART podem ser mescladas, para diminuir o número de variáveis do sistema. Basta que se acrescente qual é o pai da variável quando se está amostrando (e.g. ou J48, ou PART).

Agora que não é possível mais utilizar learning rate, implementar elitismo (como um hiper-parâmetro) para a população, de forma que a atualização de probabilidades não seja tão radical.

Fazer com que a chamada do EDNEL seja não-bloqueante entre as execuções do 10-fold cross validation.

Adicionar ao documento markdown de cada um desses indivíduos

Ponderar o precision e recall de cada uma das regras dos classificadores ordenados, com base no training set.

Utilizar isso para verificar o peso de voto delas.

Utilizar datasets melhores para otimização de hiper-parâmetros (i.e. datasets para treino): os datasets atuais são desbalanceados.

Adicionar setas às variáveis para saber a relação entre elas.

For example:
if J48_pruning is set to confidenceFactor, then only J48_confidenceFactorValue should be updated. Leave the values from variables children of ReducedErrorPruning unset (i.e. set to null).

utilizar mutual information modificada (do EDNA) para mensurar correlação entre varoáveis

Implementar dot para SimpleCart, de forma que seja possível ver a árvore de decisão, e exportá-la para markdown.

A parte do código que chama o método dot é esta:
https://github.com/henryzord/ednel/blob/master/src/main/java/utils/PBILLogger.java#L225

Atualmente, o algoritmo não trata balanceamento de datasets. Será que seria interessante utilizar o módulo pronto do Weka para realizar esta tarefa?

Fazer a atribuição de hiper-parâmetros ser determinística no código

Precisamos de mais datasets para validação da performance preditiva!

A escala de cores está muito "aguada" no projetor de indivíduos. Isso é piorado pelo fato de que os indivíduos last e overall possuem um valor muito diferente do resto (-1, quando o range de valores é [0, 1]), e porque a escala de cores é consistente em todas as gerações.

Talvez utilizar uma escala de cores para cada geração, e projetar os melhores indivíduos em outra camada, resolva o problema.

O método ThreadPoolExecutor.shutdown não espera que as threads terminem de executar. Por isso, é necessário implementar o método ThreadPoolExecutor.awaitTermination, passando como parâmetro o número de segundos restantes, e notificar as threads que elas precisam terminar imediatamente quando o tempo for encerrado.

Atualmente, colunas que possuem valores true, false estão sendo convertidas para one-hot (e.g. usePrune_true, usePrune_false), o que é um processamento desnecessário (a coluna já é numérica, embora binária).

Fazer essa adaptação no script characteristics_to_pca, mais especificamente na função to_all_numeric_columns

Pegar as regras individuais de cada um dos classificadores e fundi-los em um classificador não-ordenado.

As regras devem ser avaliadas com base em sua precision e recall: precision * recall

Remover as instâncias corretamente classificadas pela regra inclusa no sistema.
Depois, re-computar precision * recall e ver a regra com a melhor métrica.

Fazer com que o seletor seja colocado em cima da tabela de probabilidades, oposto a como é hoje, embaixo (pois tabelas com muitas entradas empurram o seletor muito para baixo).

Adicionalmente, corrigir o label de cada geração no slider também seria bom (vide figura).

Agora com as regras extraídas dos classificadores, utilizá-las em um novo classificador, baseado em regras (que calcula cobertura das regras e etc), para gerar um meta-classificador.

Passo-a-passo:

1. Podar as regras; utilizar Jaccard para remover regras redundantes
2. Utilizar um algoritmo de cobertura de regras greedy para classificar novas instâncias não vistas

Recomputar precision * recall das regras do sistema de regras não-ordenado em todo o training set (uma vez que essas regras foram adicionadas ao rule set) e utilizar como peso de voto.

Atualmente a amostragem de variáveis segue uma ordem pré-definida. Mudar esta ordem para randômica, e fazer tratamento dos indivíduos gerados inválidos.

Provavelmente os indivíduos inválidos poderiam entrar dentro do thinning factor.

É óbvio, pela análise prévia do código, que algumas variáveis são correlacionadas com outras, mesmo que o resultado do mutual information diga o contrário.

Por exemplo, subtreeRaising depende ou de reducedErrorPruning, ou de confidenceFactor (como métodos de pruning) para ser ativado. Essa correlação jamais mudará (por características do J48), então não há sentido nem em calculá-la, nem em atualizá-la.

Permitir que base classifiers possam ou não estar presentes nos ensembles dos indivíduos.

Garantir que pelo menos um classificador sempre esteja presente.

Investigar por que no arquivo gerado para cada execução, todos os classificadores tem os mesmos valores na matriz.

Exemplo:

Se os pais de uma variável não mudarem de uma geração para outra, utilizar fórmula com descrita no artigo, mas incluindo pais mutáveis; se os pais mudarem, utilizar fórmula sem a primeira parte, como quem atualiza as probabilidades com lr = 1

Nosso ensemble utiliza dois classificadores baseados em listas de regras: PART e JRip.

As regras desses classificadores dependem que todas as regras anteriores à regra atual sejam falsas para que a regra atual possa disparar. Tome como exemplo o dataset play_tennis:

O classificador JRip gera as seguintes regras:

Em uma investigação mais minuciosa do dataset, fica evidente que a segunda regra depende diretamente que a primeira seja falsa. Se escrevêssemos todas as regras por extenso, ficaria assim:

Quando for processar as regras, fazer a concatenação usando a lista antiga; não fazer recursivamente este processamento, senão uma política de resolução (i.e. inverter os inúmeros ! que apareceriam) teria que ser utilizada.

Atualmente, as probabilidades da dependency network não são anotadas, a fim de serem examinadas ao fim do processo evolutivo.

Fazer um registro dessas probabilidades.

Fazer um teste de mesa com o método de ajustedMutualInformation e visualizar se os valores retornados estão corretos.

Logar características de toda a população durante a evolução. Projetar esses dados posteriormente com PCA.

Utilizar matrizes esparsas do scipy para construir uma matriz que denota a estrutura da GM no decorrer do processo evolutivo. Depois, utilizar plotly para projetar essa matriz.

Garantir que nem todos os indivíduos de uma população estão tendo suas variáveis amostradas e setadas para o mesmo valor.

Sobre dependency networks para classification.

Not sure how to use on discrete variables, though.

A ordem de amostragem das variáveis importa. Podemos utilizar clusters de variáveis, onde o valor semântico delas importa dentro do cluster, mas não importa fora do cluster, para evitar a geração de indivíduos inválidos.

Fazer versão com probabilidades uniformes.

Limitar a, no máximo, 5 o número de pais que uma variável pode ter.

Começar testes em 2 pais, e ver se justifica adicionar mais pais.