These partitions and category labels look pretty
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
to be practical to run. FOM is usually dropped
into clustering by default
(lesser of several evils) but it doesn't quite
COA can go down in dimensional
your suggestion to present the above algorithms only by selection and
the initial default state?
OK, I have some problems with the classes.
Statistical Tests and
Reduction and Visualization
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
From: John Quackenbush [mailto:firstname.lastname@example.org]
Sent: Thursday, February 02, 2006 2:50 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor; email@example.com
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:
(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
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
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
Hope you can use some of these ideas... you might have this system
From: wendy wang [mailto:firstname.lastname@example.org]
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.