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?

From: John Quackenbush []
Sent: Thursday, February 02, 2006 3:21 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor;
Subject: Re: a hierarchy under the analysis menu

OK, I have some problems with the classes.

I would suggest:

Clustering methods:

Statistical Tests and Pattern Finding:


Dimensional Reduction and Visualization

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.



-----Original Message-----
From: John Quackenbush [] 
Sent: Thursday, February 02, 2006 2:50 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor;
Subject: Re: a hierarchy under the analysis menu


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

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.


-----Original Message-----
From: wendy wang []
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.