Menu
▾
▴
databionic-esom-devel — Discussion of Databionic ESOM Tools development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(11) |
May
(9) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
(5) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian S. <st...@Ma...> - 2005-05-10 19:21:35
|
Hello Fabien, I'll try to make a GUI-Tool out of it till the weekend. Unfortunately the Tools are in the middle of some sort of refactoring at the moment (see also mail 'No Subject' [sic!] from this list), which makes this a little tricky. We'll need a development branch in cvs before starting to fix this. As I have not reached the peak in cvs' learning curve yet, any hint on this i= s appreciated. regards Christian Stamm Fabien Moutarde said: > Hello. > > First of all, it seems that U*-matrix are not yet implemented in the > current version > of the package, so I can only make a version working on U-matrix... > > Also, another problem is that the current version of U*F clustering is > still not *fully* > automated: it is rather conceived as an interactive system where you > display > the U*-matrix (or U-matrix), and then click with the mouse on one point > "inside" > each of what "looks to be a separate region on the map" (with even > sometimes > the need for manual tuning of the threshold parameter, when the > semi-automated > version chooses too big a threshold so that 2 "would-be regions" get > flooded together > as only one region). > > Anyway, I nevertheless worked out a version fitted to the Cluster.java > skeleton > you sent me, but it is not very convenient : > one has to run the program several times to iteratively add segmented > regions into the classmask file ; also, the (x,y) starting point of > region-growing has > to be set manually (through options -x and -y), which is *definitely* > NOT convenient ; > the category ID also has to be specified this way (with the -g option), > but is less a hassle > than for x,y. > > The ideal would thus be if there was some way to integrate the > segmentation > tool in the GUI displaying the U-matrix (and U*-matrix when you shall h= ave > added it), so that clicking on the matrix display is possible, as well > as having > some buttons (such as "new category", "erase category", ...), plus a > slider > and textfield (for cases when manual tuning of threshold has to be > done)... > > Also, I am currently doing some experiments on an approach for automati= ng > the choice of starting points (and when to stop trying to grow new > regions) which > could allow a fully automated segmentation of the U*-matrix (or > U-matrix), that > would be more adapted to your Cluster.java skeleton. But it is still to= o > preliminary, > and not really operational... > > > Regards, > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Fabien MOUTARDE > Ecole Nationale Superieure des Mines de Paris (ENSMP) > 60 Bd Saint-Michel, 75272 PARIS Cedex 06, FRANCE > Tel : 33 - (0) 1.40.51.92.92 Fax : 33 - (0) 1.40.51.93.01 > E-mail : Fab...@en... Web : http://www.ensmp.fr/~moutarde > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Fabian M=F6rchen wrote: > >> Dear Fabien Moutarde, >> >> i have implemented an interface for automatic clustering algorithms in >> the ESOM tools to aid your plans of implementing U*F. >> >> as a start you should check out the latest sources from sourceforge >> [1] and follow the description for compiling [2]. >> >> the file src/java/databionics/esom/Cluster.java is a simple >> demonstration for clustering the neurons of a trained ESOM. the >> weights (*.wts) and U-Matrix and P-Matrix (both *.umx) as well as the >> training data (*.lrn) are loaded according to the command line >> parameters given. the clustering simply creates four clusters >> according to the quadrants of the coordinates on the map. this way you >> can already see how to access the map with spatial coordinates. >> >> the skript to start the program is called esomclust[.bat], "esomclust >> -h" will list the syntax. the saved class mask (*.cls with one entry >> per neuron) can be loaded from within the GUI and displayed on top of >> the ESOM. later we will provide a mechanism to call the cluster tool >> via the menu and have the result automatically loaded. >> >> you can plug in your algorithm in the Cluster.java file, if you wish. >> later we can put it in a different class and offer several algorithms >> from within the Cluster class. >> >> if you have any problems getting this to work or further questions on >> how to access certain data structres needed in your algorithm, don't >> hesitate to ask. the developer mailing [3] list would be a good place >> for this, since your questions and my (of my student's) answers will >> be available to future contributors as well. >> >> Regards, >> Fabian M=F6rchen >> >> [1] http://databionic-esom.sourceforge.net/cvs-usage.html >> [2] http://databionic-esom.sourceforge.net/devel.html >> [3] http://databionic-esom.sourceforge.net/mail-lists.html > > > |
|
From: Thanassis S. <th...@no...> - 2005-05-10 09:15:14
|
Hello, I noticed that this object returns the 'standard' Euclidean distance (squared-root) when asked for distance type 'euc' and assigns this to the SOM grid. But the corresponding thresholded function that is returned is the squared euclidean (without square root). As the second is used in bestmatch search, won't there be potentially be differences? Is it something by design, or is it a bug? Regards, Thanassis |
|
From: Fabien M. <Fab...@en...> - 2005-05-09 12:36:55
|
Hello. First of all, it seems that U*-matrix are not yet implemented in the=20 current version of the package, so I can only make a version working on U-matrix... Also, another problem is that the current version of U*F clustering is=20 still not *fully* automated: it is rather conceived as an interactive system where you disp= lay the U*-matrix (or U-matrix), and then click with the mouse on one point=20 "inside" each of what "looks to be a separate region on the map" (with even someti= mes the need for manual tuning of the threshold parameter, when the=20 semi-automated version chooses too big a threshold so that 2 "would-be regions" get=20 flooded together as only one region). Anyway, I nevertheless worked out a version fitted to the Cluster.java=20 skeleton you sent me, but it is not very convenient : one has to run the program several times to iteratively add segmented regions into the classmask file ; also, the (x,y) starting point of=20 region-growing has to be set manually (through options -x and -y), which is *definitely*=20 NOT convenient ; the category ID also has to be specified this way (with the -g option),=20 but is less a hassle than for x,y. The ideal would thus be if there was some way to integrate the segmentati= on tool in the GUI displaying the U-matrix (and U*-matrix when you shall hav= e added it), so that clicking on the matrix display is possible, as well=20 as having some buttons (such as "new category", "erase category", ...), plus a=20 slider and textfield (for cases when manual tuning of threshold has to be done).= .. Also, I am currently doing some experiments on an approach for automating the choice of starting points (and when to stop trying to grow new=20 regions) which could allow a fully automated segmentation of the U*-matrix (or=20 U-matrix), that would be more adapted to your Cluster.java skeleton. But it is still too=20 preliminary, and not really operational... Regards, +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Fabien MOUTARDE Ecole Nationale Superieure des Mines de Paris (ENSMP) 60 Bd Saint-Michel, 75272 PARIS Cedex 06, FRANCE Tel : 33 - (0) 1.40.51.92.92 Fax : 33 - (0) 1.40.51.93.01 =20 E-mail : Fab...@en... Web : http://www.ensmp.fr/~moutarde ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Fabian M=F6rchen wrote: > Dear Fabien Moutarde, > > i have implemented an interface for automatic clustering algorithms in=20 > the ESOM tools to aid your plans of implementing U*F. > > as a start you should check out the latest sources from sourceforge=20 > [1] and follow the description for compiling [2]. > > the file src/java/databionics/esom/Cluster.java is a simple=20 > demonstration for clustering the neurons of a trained ESOM. the=20 > weights (*.wts) and U-Matrix and P-Matrix (both *.umx) as well as the=20 > training data (*.lrn) are loaded according to the command line=20 > parameters given. the clustering simply creates four clusters=20 > according to the quadrants of the coordinates on the map. this way you=20 > can already see how to access the map with spatial coordinates. > > the skript to start the program is called esomclust[.bat], "esomclust=20 > -h" will list the syntax. the saved class mask (*.cls with one entry=20 > per neuron) can be loaded from within the GUI and displayed on top of=20 > the ESOM. later we will provide a mechanism to call the cluster tool=20 > via the menu and have the result automatically loaded. > > you can plug in your algorithm in the Cluster.java file, if you wish.=20 > later we can put it in a different class and offer several algorithms=20 > from within the Cluster class. > > if you have any problems getting this to work or further questions on=20 > how to access certain data structres needed in your algorithm, don't=20 > hesitate to ask. the developer mailing [3] list would be a good place=20 > for this, since your questions and my (of my student's) answers will=20 > be available to future contributors as well. > > Regards, > Fabian M=F6rchen > > [1] http://databionic-esom.sourceforge.net/cvs-usage.html > [2] http://databionic-esom.sourceforge.net/devel.html > [3] http://databionic-esom.sourceforge.net/mail-lists.html |
|
From: Thanassis S. <th...@no...> - 2005-04-28 08:33:01
|
Thanks for the feedback guys. I will be factoring out the relevant code from Weka so an inclusion in ESOM is possible. Thanassis |
|
From:
<fa...@in...> - 2005-04-28 07:51:16
|
Hi Thanassis, just adding my 5 (euro) cents. of course your code is welcome. i suggest you send patches to christian, for a start. maybe this is already a good point to start a new cvs branch. especially since we need to make some changes to the tool architecture for the upcoming musicminer program, that relies on the esom tools. @niko: can you start a dev branch, please? you idea of option panels provided by the background renderers in particular is something we have also discussed before. the RunDialog class, that is responsible for running the 'external' tools like training and projection, contains a mechanism to create render gui elements from an xml description. iirc weka has a similar mechanism, that came to my attention too late. maybe one of them or a combination thereof could be used for the bg renderers. as for the dynamic class discovery: it should work if you run "maven jar install" once, before continuing development with eclipse. but a more sophisticated mechanisme would'n hurt, i guess. bye fabian Christian Stamm wrote: > sorry for the repost, wrong reply address chosen... > > Christian Stamm said: > >>Hi Thanassis, >> >>nice to hear from you. Taking synergy from the Weka project surely sounds >>like a good idea, your code will be welcome. Can you give me a hint where >>I can learn more about the mechanism used in Weka? >> >>The foregroundrenderers had an auto load mechanism, which i removed, to >>make the software stable enough for a release. One of quite a few >>workarounds. >> >>Regarding the foregroundrenderers I had a different architecture in mind: >>As most foregroundrenderers require additional data like bestmatch >>classification, I moved most of them into the 'tool' and subpackages. >>The idea is to make the tools the automatically loaded plugins. The tool >>should know about how the data in question is created, modified, loaded, >>saved and displayed. (When talking about tools I mean classes derived from >>class AbstractTool.) >> >>The ToolLoader is at this time in the middle of a refactoring and uses two >>strategies to administer the tools. The old strategy is to know every tool >>explicitely the new is having them inside a toolhash. An automated loading >>mechanism is the goal. As the actual a state is of course no good, it is >>stable and therefore remained unchanged for the release. >> >>Regarding the backgroundrenderers, the actual solution is surely non >>optimal. I've been thinking about refactoring them in the way you >>suggested for quite a while, but there was always something more >>important. The main Renderer has lost and has to loose much more special >>knowledge than only this. >> >>Following picture gives you a hint on how the esomtools should ideally >>work: >>http://www.mathematik.uni-marburg.de/~stammi/esom/SomanaArchitecture.png >>where >>- 'external tasks' are training, projection etc. >>- 'core tools' are foregroundtool, renderertool and backgroundtool. >>- 'optional tools' are all other tools. >>- 'central data managment' is rather a TODO at this time, Project.java is >>used besides local solutions. Sadly the main renderer is still involved. A >>hash based datamanager is in the making. >> >>Hope this made things a little clearer. Please keep asking. >> >>mfg Christian >> >> >>Thanassis Stathopoulos said: >> >>>Hello everybody, >>> >>>I've been examining how the application discovers renderers (after >>>having >>>trouble running it in my Eclipse workbench) and noticed that it hits the >>>jar >>>file it was loaded from. >>>Examining the jar file for classes assumes that the jar is built already >>>there, which is not always the case. >>> >>>I would suggest adapting the run-time class discovery mechanism of the >>>latest Weka, which dynamically searches the classpath. >>>Then both renderer types could use automatic class discovery. >>> >>>Would the team be interested in integrating the proposed automatic class >>>discovery, if I code it? >>> >>>Another (architectural) point regarding renderers that require user >>>interaction, like Pmatrix and SmoothedHistogram - The renderers >>>themselves >>>could be providing custom panels to plug in to the appropriate frames, >>>instead of having the main renderer know about their names and the types >>>of >>>UI controls they use. Of course this is a bigger refactoring... >>> >>>Thanks, >>>Thanassis >>> >>> >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide >>>Read honest & candid reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start reading now. >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>_______________________________________________ >>>Databionic-esom-devel mailing list >>>Dat...@li... >>>https://lists.sourceforge.net/lists/listinfo/databionic-esom-devel >>> >> >> > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Databionic-esom-devel mailing list > Dat...@li... > https://lists.sourceforge.net/lists/listinfo/databionic-esom-devel |
|
From: Christian S. <st...@Ma...> - 2005-04-26 12:38:07
|
sorry for the repost, wrong reply address chosen... Christian Stamm said: > Hi Thanassis, > > nice to hear from you. Taking synergy from the Weka project surely sounds > like a good idea, your code will be welcome. Can you give me a hint where > I can learn more about the mechanism used in Weka? > > The foregroundrenderers had an auto load mechanism, which i removed, to > make the software stable enough for a release. One of quite a few > workarounds. > > Regarding the foregroundrenderers I had a different architecture in mind: > As most foregroundrenderers require additional data like bestmatch > classification, I moved most of them into the 'tool' and subpackages. > The idea is to make the tools the automatically loaded plugins. The tool > should know about how the data in question is created, modified, loaded, > saved and displayed. (When talking about tools I mean classes derived from > class AbstractTool.) > > The ToolLoader is at this time in the middle of a refactoring and uses two > strategies to administer the tools. The old strategy is to know every tool > explicitely the new is having them inside a toolhash. An automated loading > mechanism is the goal. As the actual a state is of course no good, it is > stable and therefore remained unchanged for the release. > > Regarding the backgroundrenderers, the actual solution is surely non > optimal. I've been thinking about refactoring them in the way you > suggested for quite a while, but there was always something more > important. The main Renderer has lost and has to loose much more special > knowledge than only this. > > Following picture gives you a hint on how the esomtools should ideally > work: > http://www.mathematik.uni-marburg.de/~stammi/esom/SomanaArchitecture.png > where > - 'external tasks' are training, projection etc. > - 'core tools' are foregroundtool, renderertool and backgroundtool. > - 'optional tools' are all other tools. > - 'central data managment' is rather a TODO at this time, Project.java is > used besides local solutions. Sadly the main renderer is still involved. A > hash based datamanager is in the making. > > Hope this made things a little clearer. Please keep asking. > > mfg Christian > > > Thanassis Stathopoulos said: >> Hello everybody, >> >> I've been examining how the application discovers renderers (after >> having >> trouble running it in my Eclipse workbench) and noticed that it hits the >> jar >> file it was loaded from. >> Examining the jar file for classes assumes that the jar is built already >> there, which is not always the case. >> >> I would suggest adapting the run-time class discovery mechanism of the >> latest Weka, which dynamically searches the classpath. >> Then both renderer types could use automatic class discovery. >> >> Would the team be interested in integrating the proposed automatic class >> discovery, if I code it? >> >> Another (architectural) point regarding renderers that require user >> interaction, like Pmatrix and SmoothedHistogram - The renderers >> themselves >> could be providing custom panels to plug in to the appropriate frames, >> instead of having the main renderer know about their names and the types >> of >> UI controls they use. Of course this is a bigger refactoring... >> >> Thanks, >> Thanassis >> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Databionic-esom-devel mailing list >> Dat...@li... >> https://lists.sourceforge.net/lists/listinfo/databionic-esom-devel >> > > |
|
From: Thanassis S. <th...@no...> - 2005-04-25 16:02:38
|
Hello everybody, I've been examining how the application discovers renderers (after having trouble running it in my Eclipse workbench) and noticed that it hits the jar file it was loaded from. Examining the jar file for classes assumes that the jar is built already there, which is not always the case. I would suggest adapting the run-time class discovery mechanism of the latest Weka, which dynamically searches the classpath. Then both renderer types could use automatic class discovery. Would the team be interested in integrating the proposed automatic class discovery, if I code it? Another (architectural) point regarding renderers that require user interaction, like Pmatrix and SmoothedHistogram - The renderers themselves could be providing custom panels to plug in to the appropriate frames, instead of having the main renderer know about their names and the types of UI controls they use. Of course this is a bigger refactoring... Thanks, Thanassis |
|
From: Christian S. <st...@Ma...> - 2005-04-22 08:24:58
|
> - bestmatch size gets bigger (to 5) if you toggle the display of class > letters. it's not a bug it's a feature (: unfortunately it doesn'make sense,=20 drawing those letters with a too small bmSize. The user toggles to letter= s and wont see anything if bmSize is 1 or 2 or so. To avoid the user considers it a bug, i just put up the size. mfg Christian Fabian M=F6rchen said: > changes: > > http://databionic-esom.sourceforge.net/changes-report.html > > known bugs: > > - bold display of classes doesn't make all bestmatches of the classbold. > - class "0" (=3D no class) doesn't always contain the complement of the > classified bestmatches. workaround: press the clear button once before > starting to classify. > - autoload is sometimes active even if the checkbox is turned on > > feature request: > > - colored letter bestmatches. > > bye > fabian > |
|
From:
<fa...@in...> - 2005-04-22 08:15:45
|
changes: http://databionic-esom.sourceforge.net/changes-report.html known bugs: - bestmatch size gets bigger (to 5) if you toggle the display of class letters. - bold display of classes doesn't make all bestmatches of the classbold. - class "0" (= no class) doesn't always contain the complement of the classified bestmatches. workaround: press the clear button once before starting to classify. - autoload is sometimes active even if the checkbox is turned on feature request: - colored letter bestmatches. bye fabian |
|
From: Christian S. <st...@Ma...> - 2005-04-21 18:24:33
|
Hi all, I just fixed a bug spottet by Katrin. Bestmatch classification wasn't possible with no initial *.cls file loaded. As this bug is critical, version 0.9.1 will be released after someone has done a little testing. Furthermore you will find a new checkbox in the classes tab, telling wether or not the ClassBestmatchRenderer should draw letters instead of colored boxes. This feature uses the first letter of the classname. For that reason you may want to keep/make this letters distinct. The classname is visible and editable in the classes tab and stored in the *.cls file. TODO: - investigate why 'load *.wts' causes multiple image renderings. mfg Christian |
|
From: Niko E. <ne...@Ma...> - 2005-04-17 22:24:39
|
Fabian M=C3=B6rchen wrote: > @niko: the patch is placed in cvs in src/colt, so you would have had > write access. your patch was much too large, however, you must have > generated a complete copy. I used diff -urN src.org src.db. I thinks thats the thing you do in the ant script. --=20 Niko Efthymiou Tel: 06421/898565 Geschw.-Scholl-Str.11a www: www.mathematik.uni-marburg.de/~nefthy 35039 Marburg pgp-key: 976A9363 @ www.keyserver.net |
|
From: <fa...@in...> - 2005-04-17 18:40:39
|
hi my bad. the colt patch was generated with an older version. i fixed the cvs, but have not made a new release, yet. i want to collect some more changes and test them first. the maven build as described on the web page should work and is much more comfortable than applying the patch yourself. minor correction to niko's answer: upstream is 1.2.0 of course, not 1.0.2 @niko: the patch is placed in cvs in src/colt, so you would have had write access. your patch was much too large, however, you must have generated a complete copy. bye fabian Efthymiou Niko wrote: > I have to get used to repling to the list, instead of just hitting reply... > > Hello Thanassis, > > Thanassis Stathopoulos wrote: > > > >>Trying to rebuild the toolkit from source (release 0.9), there is an >>unresolved method coming up on DoubleMatrix2D, method zTrans. >> >>The 1.2.0 Colt source release off LBL does not contain such a method, > > and it > >>is also not contained in the Colt patch within ESOM (neither the >>distribution nor anonymous cvs). > > > > ztrans() is missing in the databionics-colt.patch. I have uploaded an > updated patch to [1] (854K) as a temporary solution. > > Using maven to build from source works correctly, since the ztrans() > function is included in the prebuild colt jar file. > > @fabian: please rebuild the patch and update sourceforge cvs and files > section. (or tell me how to do it :) > > >>I notice that the Colt version (jar) is 1.2.0.3. Is this a point > > release of > >>Colt *above* 1.2.0, or was the method somehow omitted? > > > > 1.2.0.3 is our internal version used to track the modified version and > 1.0.2 is the upstream version. The method got ommited somewhow from the > patch... > > [1] http://www.mathematik.uni-marburg/~nefthy/colt.patch.zip > > Greetings, > > Niko |
|
From: Efthymiou N. <ne...@Ma...> - 2005-04-16 15:59:04
|
I have to get used to repling to the list, instead of just hitting reply... Hello Thanassis, Thanassis Stathopoulos wrote: > Trying to rebuild the toolkit from source (release 0.9), there is an > unresolved method coming up on DoubleMatrix2D, method zTrans. > > The 1.2.0 Colt source release off LBL does not contain such a method, and it > is also not contained in the Colt patch within ESOM (neither the > distribution nor anonymous cvs). ztrans() is missing in the databionics-colt.patch. I have uploaded an updated patch to [1] (854K) as a temporary solution. Using maven to build from source works correctly, since the ztrans() function is included in the prebuild colt jar file. @fabian: please rebuild the patch and update sourceforge cvs and files section. (or tell me how to do it :) > I notice that the Colt version (jar) is 1.2.0.3. Is this a point release of > Colt *above* 1.2.0, or was the method somehow omitted? 1.2.0.3 is our internal version used to track the modified version and 1.0.2 is the upstream version. The method got ommited somewhow from the patch... [1] http://www.mathematik.uni-marburg/~nefthy/colt.patch.zip Greetings, Niko -- Niko Efthymiou Tel: 06421/898565 Geschw.-Scholl-Str.11a www: www.mathematik.uni-marburg.de/~nefthy 35039 Marburg pgp-key: 976A9363 @ www.keyserver.net |
|
From: Thanassis S. <th...@no...> - 2005-04-16 13:50:55
|
Hello everybody, Trying to rebuild the toolkit from source (release 0.9), there is an unresolved method coming up on DoubleMatrix2D, method zTrans. The 1.2.0 Colt source release off LBL does not contain such a method, and it is also not contained in the Colt patch within ESOM (neither the distribution nor anonymous cvs). I notice that the Colt version (jar) is 1.2.0.3. Is this a point release of Colt *above* 1.2.0, or was the method somehow omitted? Small problem, as it only binds to the UI z-transform button, but thought I'd ask. Thanks for any and all pointers, Thanassis |
