Menu
▾
▴
[Mev-tm4-devel] Re: a hierarchy under the analysis menu
|
From: John Q. <jo...@ji...> - 2006-02-02 21:47:38
|
Sorry I missed these. GSH really does not work well since it is a memory hog, but I would still put it in clustering. Braisted, John C. wrote: > These partitions and category labels look pretty good. > No matter how it's done someone will find another partition but this > partition > makes sense to me. > > ST, CAST and QTC could go under clustering. GSH doesn't seem > to be practical to run. FOM is usually dropped into clustering by default > (lesser of several evils) but it doesn't quite fit. > > COA can go down in dimensional reduction. > > Is your suggestion to present the above algorithms only by selection > and not > in the initial default state? > > John > > ------------------------------------------------------------------------ > *From:* John Quackenbush [mailto:jo...@ji...] > *Sent:* Thursday, February 02, 2006 3:21 PM > *To:* Braisted, John C. > *Cc:* wendy wang; Howe, Eleanor; mev...@li... > *Subject:* Re: a hierarchy under the analysis menu > > OK, I have some problems with the classes. > > I would suggest: > > Clustering methods: > HCL > KMC > KMS > SOTA > SOM > > Statistical Tests and Pattern Finding: > TTEST > SAM > ANOVA > TFA > PTM > > Classification: > KNN > SVM > DAM > > Dimensional Reduction and Visualization > GDM > TRN > PCA > RN > > > Braisted, John C. wrote: >> I think there could be a select all option in the algorithm selection >> dialog and maybe the default state for the distribution could be that >> all algorithms are originally present. This default or starting state >> can be originally specified in tmev.cfg as the full list of algorithms. >> >> Oh, I guess I see your 'default' idea, I took that to mean starting >> state. I think if an algorithm doesn't have a class property it can >> go in a misc. bag of algorithms. In general any new algorithm should >> have the 'class' or 'category' property entered in the build.xml so >> this shouldn't be a problem. This depends on whether Wendy uses or >> will use the properties approach. >> >> >> You can carve up the algorithms in several ways but the crude separation >> that we had was: Tree and Network building, basic divisive methods, >> stat methods, classification methods, visualization methods, and >> post clustering methods (like EASE...) that analyze clusters. >> All algorithms seem to fall into one of these classes but the most >> diverse or generic are 'visualizations' and that includes >> GDM, PCA, and TRN. I think this category holds even though the >> process to create the data views is complex for PCA and TRN. >> >> This seems like a nice feature that is really important as the button >> count grows. >> >> John >> >> >> >> -----Original Message----- >> From: John Quackenbush [mailto:jo...@ji...] >> Sent: Thursday, February 02, 2006 2:50 PM >> To: Braisted, John C. >> Cc: wendy wang; Howe, Eleanor; mev...@li... >> Subject: Re: a hierarchy under the analysis menu >> >> John, >> >> Thanks for some very good suggestions. The only thing you would probably >> need is a default to just put things in the menu if there is no >> property. >> >> Braisted, John C. wrote: >> >>> Hi Wendy, >>> >>> (This got a bit long, a summary is at the bottom) >>> >>> Since algorithms have several properties that are designated in the >>> properties files that are constructed during the build, what about >>> adding a property to indicate algorithm class? >>> I think this could go into the properties file that contains >>> information like button gif, algorithm name, gui package name. >>> It probably means adding this to the 'gui' targets in build.xml. >>> >>> I'm not sure if or how you plan to segregate algorithms in the tool >>> bar. Previously this had been done by specifying order in the build >>> script and then 'hard coding' breaks or spaces between button groups >>> (JSeparators ?) to partition areas like stats and classification >>> algorithms. This process will now be under better control since each >>> algorithm 'knows' where it should go based on the properties. Its >>> been a while since I've worked with the code that specifies properties >>> >> >> >>> and can deliver them but I did use a bit of this when creating the >>> script algorithm selection dialog. I doubt that this will be of >>> direct use but it might be helpful to look at. >>> >>> Presentation ideas... you probably have this worked out... >>> >>> 1.) The dialog to select algorithms to put on the tool bar could be >>> segregated somehow into algorithm class. This could be a small tabbed >>> >> >> >>> pane dialog, one page per algorithm class. The reconstruction method >>> for the toolbar (or constructor) could take a set of algorithms and >>> corresponding classes. >>> >>> 2.) The other option is to provide single dialog page to present the >>> algorithms on one page. The menubar should be able to get the >>> property for each algorithm for the sake of segregation. >>> >>> The other thing to consider and maybe this is the main point. >>> The user designated algorithms should probably be kept as a list in >>> the tmev.cfg file in the config directory. This might be what you are >>> >> >> >>> doing but this provides the basis to know what to present when >>> re-starting mev. >>> >>> ===== >>> >>> Sorry this is so long... to summarize, I would >>> >>> -add the algorithm class (category) property to the build.xml. >>> (one for each algorithm, put it in the gui target) >>> >>> -read tmev.cfg on startup to indicate which to load. >>> This list of algorithms in tmev.cfg can change dynamically and stores >>> the state between sessions. >>> >>> -building the menubar is then taking the algorithms to present based >>> on tmev.cvf, segregating them based on class, then constructing and >>> formatting the menubar appropriately visually segregate the various >>> algorithm classes. >>> >>> Hope you can use some of these ideas... you might have this system >>> going already. >>> >>> John >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: wendy wang [mailto:ww...@ji...] >>> Sent: Thursday, February 02, 2006 12:15 PM >>> To: Quackenbush, John; Braisted, John C.; Howe, Eleanor >>> Subject: a hierarchy under the analysis menu >>> >>> Hi, JohnQ, JohnB and Eleanor, >>> >>> In last teleconference JohnQ suggested seletctabl menu-bar buttons and >>> >> >> >>> a hierarchy under the analysis menu.Recently I finished customized >>> menubar and showed to JohnQ. He thought it works fine. So I began to >>> work on the hiearchy of ananlysis menu. I met some problems. I have to >>> >> >> >>> ask your suggestion. >>> >>> In order to realize the flexibilty of adding or deleting analysis >>> >> >> >>> algorithm, Mev was oringinally designed to use factory to hold all >>> the algorithm. Whenever an algorithm needs to be added or deleted, we >>> just need to add the algorithm and change build file. So it is >>> flexible and easy to maintain. Each algorithm is treated the same. >>> >>> If we add a hierarchy for all algorithms, each algorith is treated >>> differently(when added on menubar). When we add event to each >>> algorithm, we have to add many selections to choose. The code will >>> become messy ,hard to maintain(including to add new algorithm) and >>> ruin the beauty of original design. >>> >>> So I am not sure if we need to add this function or if you >>> have suggetion how to solve this problem. >>> >>> Thanks, >>> >>> Wendy >>> >>> |