Treillis

[marminthibaut]

Alors voilà, j'en ai déjà parlé à Nam et William, mais autant mettre tout ça à l'écrit ici.

Pour l'instant, j'ai implémenté une partie de la mémoire sémantique et donc du treillis. J'arrive à stocker un ensemble d'attributs (RelevantPartialBoardState) et un ensemble d'objets (CompleteBoardState), avec la matrice d'appartenance ou non.

Pour construire le treillis, je convertit le contexte en une string respectant le format standard FIMI utilisé pour les FCA (comme les ctx de conexp), et je fait tourner un programme performant en code natif (cad en c++) qui me retourne une liste de concepts, avec pour chaque concept une liste d'attributs.

Placer les objets dans les concepts est très simple (il suffit de matcher), mais la question est la suivante :

Est t-il nécessaire de construire le treillis (sous forme de graphe), ou une simple modélisation en liste de liste suffirait à naviguer dedans ?

Comme je l'ai dis à Nam toute à l'heure j'ai un peu de mal à réfléchir la... Je me pencherai sur la question demain, mais j'aimerai avoir vos avis :)

[marminthibaut]

Ahh non !! Gros pb. J'ai fait une classe de test de volumétrie en taille d'attributs et d'objets pour générer les concepts.

Attributs = 100 Objets = 1000 Couverture = 10% (proba qu'un attribut appartienne à un objet) => instantanné (0,5Mo de concepts)

Attributs = 100 Objets = 1000 Couverture = 20% (proba qu'un attribut appartienne à un objet) => quelques secondes (15Mo de concepts)

Attributs = 100 Objets = 1000 Couverture = 30% (proba qu'un attribut appartienne à un objet) => Trop relou d'attendre, fichier de plusieurs centaines de Mo, et a 50% on atteind même les Go de concepts xD

Ensuite juste pour essayer j'ai tenté :

Attributs = 1000 Objets = 10000 Couverture = 5% => Rien que la génération du code FIMI c'est trop long (au bout d1/2h toujours pas fini...)

Je pense tenter une autre implémentation du contexte demain pour améliorer les perfs..

[marminthibaut]

Bon alors avec l'implémentation du lattice context avec Neo4j la génération est bcp plus longue (normal ça stock les données c'est plus seulement en ram ^^). Pour les tests de génération FIMI je vais voir ça maintenant..

[marminthibaut]

Re-SPAM Il faudrait savoir au moins le nombre moyen d'attributs qui checkerons par object, et dans l'idéal avoir un ordre de grandeur sur le nombre d'attributs / object serait cool (c'est à toi de me dire ça clément, pour le nombre d'attributs :p)

Le must serait aussi de trouver une fonction qui permet de purger la le context des trucs inutiles, ou quasi inutiles..

[marminthibaut]

Help please : qu'est ce qui peut prendre du temps dans cette fonction ?

  /**
   * Generate a string sequence in FIMI format
   * 
   * @param context
   *          the context
   * @return the FIMI String sequence
   * @throws LatticeContextException 
   */
  public static String toFimi(LatticeContext context) throws LatticeContextException
  {
    String ret = "";

    if (logger.isDebugEnabled()) logger.debug("Génération du FIMI");
    boolean hasattribute;
    for (CompleteBoardState object : context.getObjects().values())
      {
        hasattribute = false;
        for (Iterator<RelevantPartialBoardState> iterator = context
            .getAttributesByObject(object).values().iterator(); iterator
            .hasNext();)
          {
            ret += ((RelevantPartialBoardState) iterator.next()).getId() + " ";
            hasattribute = true;

          }
        if (hasattribute)
          ret += "\n";
      }
    if (logger.isDebugEnabled()) logger.debug("Génération du FIMI terminée");
    return ret;
  }

A part context.getObjects() et context.getAttributesByObject(object)

[sipi]

Je crois que tu devras recourir à un profiler... Eclipse Test & Performance Tools Platform Project http://www.eclipse.org/tptp/

[marminthibaut]

Ouep je tersterai ça demain à la fac :p