Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

fca [2010/02/01 10:22]
suitable
fca [2010/02/01 10:46] (Version actuelle)
suitable
Ligne 27: Ligne 27:
       * [[fca:formats#cxt|ConImp context data]] *.cxt: It is possible to work with contexts, that were created using ConImp. The disadvantage is, only the context can be encoded in this format.       * [[fca:formats#cxt|ConImp context data]] *.cxt: It is possible to work with contexts, that were created using ConImp. The disadvantage is, only the context can be encoded in this format.
       * Comma Separated Values *.csv: So far ConExp supports only the import of contexts in this format. Actual separator is semicolon (;). It is assumed, that the first line of the file contains attributes names and the first cell is empty. (I.e, if one has a context with attributes attr1 and attr2, then first line will be the following: ;attr1;attr2.) Each of the succeeding lines should start with an object name followed by a sequence of 0s and 1s. A cross will appearer in all cells of the imported context, where a 1 has been set.       * Comma Separated Values *.csv: So far ConExp supports only the import of contexts in this format. Actual separator is semicolon (;). It is assumed, that the first line of the file contains attributes names and the first cell is empty. (I.e, if one has a context with attributes attr1 and attr2, then first line will be the following: ;attr1;attr2.) Each of the succeeding lines should start with an object name followed by a sequence of 0s and 1s. A cross will appearer in all cells of the imported context, where a 1 has been set.
-      * [[fca|formats#oal|Object Attribute List]] *.oal: So far ConExp supports only the import of contexts in this format. Each line contains information on one object starting with the name and followed-up by the possessed attributes. If object obj1 has the attributes attr2 and attr3, the line representing obj1 should look as follows: obj1:attr2;attr3+      * [[fca|formats#oal|Object Attribute List]] *.oal: So far ConExp supports only the import of contexts in this format.  
-  * [[http://fcalgs.sourceforge.net/|fcalgs]] by by Petr Krajca, Jan Outrata, and [[vilem.vychodil@upol.cz|Vilem Vychodil]]. ; [[pcbo|parallel recursive implementation]] of Kuznetsov's CbO ([[fca:cbo|Close by One]]) algorithm. //The INPUT-FILE is in the usual FIMI format.// ((According to the FIMI rules at [[http://fimi.cs.helsinki.fi/fimi03/submission.html]] "The dataset input must use the following ascii format only! \\ Each transaction is stored on a separate line as a list of items separated by white space and ending with a newlineEach item is a non-negative integer. \\ The items in the test datasets will be consecutively numbered starting from 0, and each transaction will be sorted ascending. (Note that this is not yet the case for the provided test datasets.) ))  The code is C and "parallel" is an option; it can be run as the sequential algorithm.  In fact, the parallelism only kicks in after the sequential algorithm has built a good foundation for the threads to complete. Whereas CbO as originally described adds objects to the extent one by one, intersecting their intents with the previous intent (as long as the intersection is not empty), pcbo processes the dual problem: it adds attributes to the intent and intersects the extent of the new attribute with the extent of the previous concept. It appears to be about 100 times faster than any other algorithm for binary attributes.  More recently, Simon Andrews published an algorithm called [[InClose]] similar in concept, but with different choices of pre-calculation and memory usage, which seems to be about 40 times faster than the sequential version of pcbo! +  * [[http://fcalgs.sourceforge.net/|fcalgs]] by by Petr Krajca, Jan Outrata, and [[vilem.vychodil@upol.cz|Vilem Vychodil]]. ; [[pcbo|parallel recursive implementation]] of Kuznetsov's CbO ([[fca:cbo|Close by One]]) algorithm. The INPUT-FILE is in the //usual// [[fca:formats#fimi|FIMI]] format.  The code is C and "parallel" is an option; it can be run as the sequential algorithm.  In fact, the parallelism only kicks in after the sequential algorithm has built a good foundation for the threads to complete. Whereas CbO as originally described adds objects to the extent one by one, intersecting their intents with the previous intent (as long as the intersection is not empty), pcbo processes the dual problem: it adds attributes to the intent and intersects the extent of the new attribute with the extent of the previous concept. It appears to be about 100 times faster than any other algorithm for binary attributes.  More recently, Simon Andrews published an algorithm called [[In-Close]] similar in concept, but with different choices of pre-calculation and memory usage, which seems to be about 40 times faster than the sequential version of pcbo! 
   * [[http://fcastone.sourceforge.net/|FcaStone]]    * [[http://fcastone.sourceforge.net/|FcaStone]] 
     * FcaStone (named in analogy to "Rosetta Stone") is a command-line utility that converts between the file formats of commonly-used FCA tools (such as ToscanaJ, ConExp, Galicia and Colibri) and between FCA formats and other graphics formats. The main purpose of FcaStone is to improve the interoperability between FCA, graph editing and vector graphics software.     * FcaStone (named in analogy to "Rosetta Stone") is a command-line utility that converts between the file formats of commonly-used FCA tools (such as ToscanaJ, ConExp, Galicia and Colibri) and between FCA formats and other graphics formats. The main purpose of FcaStone is to improve the interoperability between FCA, graph editing and vector graphics software.
 
fca.txt · Dernière modification: 2010/02/01 10:46 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki