[Mev-tm4-devel] RE: a hierarchy under the analysis menu

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
=20
-----Original Message-----
From: John Quackenbush [mailto:johnq@...]=20
Sent: Thursday, February 02, 2006 2:50 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor; mev-tm4-devel@...
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=20
> properties files that are constructed during the build, what about=20
> adding a property to indicate algorithm class?
> I think this could go into the properties file that contains=20
> 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=20
> bar. Previously this had been done by specifying order in the build=20
> script and then 'hard coding' breaks or spaces between button groups=20
> (JSeparators ?) to partition areas like stats and classification=20
> algorithms. This process will now be under better control since each=20
> algorithm 'knows' where it should go based on the properties. Its=20
> 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=20
> script algorithm selection dialog. I doubt that this will be of=20
> 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=20
> segregated somehow into algorithm class. This could be a small tabbed
> pane dialog, one page per algorithm class. The reconstruction method=20
> for the toolbar (or constructor) could take a set of algorithms and=20
> corresponding classes.
>
> 2.) The other option is to provide single dialog page to present the=20
> algorithms on one page. The menubar should be able to get the=20
> 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=20
> 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=20
> re-starting mev.
>
> =3D=3D=3D=3D=3D
>
> 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=20
> the state between sessions.
>
> -building the menubar is then taking the algorithms to present based=20
> on tmev.cvf, segregating them based on class, then constructing and=20
> formatting the menubar appropriately visually segregate the various=20
> algorithm classes.
>
> Hope you can use some of these ideas... you might have this system=20
> going already.
>
> John
>
>
>
>
>
> -----Original Message-----
> From: wendy wang [mailto:wwang67@...]
> 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=20
> menubar and showed to JohnQ. He thought it works fine. So I began to=20
> 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=20
> the algorithm. Whenever an algorithm needs to be added or deleted, we=20
> just need to add the algorithm and change build file. So it is=20
> flexible and easy to maintain. Each algorithm is treated the same.
>
> If we add a hierarchy for all algorithms, each algorith is treated=20
> differently(when added on menubar). When we add event to each=20
> algorithm, we have to add many selections to choose. The code will=20
> become messy ,hard to maintain(including to add new algorithm) and=20
> ruin the beauty of original design.
>
> So I am not sure if we need to add this function or if you=20
> have suggetion how to solve this problem.
>
> Thanks,
>
> Wendy
> =20

Thread view

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=20
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=20
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=20
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.
=3D=3D=3D=3D=3D
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:wwang67@...]=20
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

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
=20
-----Original Message-----
From: John Quackenbush [mailto:johnq@...]=20
Sent: Thursday, February 02, 2006 2:50 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor; mev-tm4-devel@...
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=20
> properties files that are constructed during the build, what about=20
> adding a property to indicate algorithm class?
> I think this could go into the properties file that contains=20
> 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=20
> bar. Previously this had been done by specifying order in the build=20
> script and then 'hard coding' breaks or spaces between button groups=20
> (JSeparators ?) to partition areas like stats and classification=20
> algorithms. This process will now be under better control since each=20
> algorithm 'knows' where it should go based on the properties. Its=20
> 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=20
> script algorithm selection dialog. I doubt that this will be of=20
> 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=20
> segregated somehow into algorithm class. This could be a small tabbed
> pane dialog, one page per algorithm class. The reconstruction method=20
> for the toolbar (or constructor) could take a set of algorithms and=20
> corresponding classes.
>
> 2.) The other option is to provide single dialog page to present the=20
> algorithms on one page. The menubar should be able to get the=20
> 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=20
> 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=20
> re-starting mev.
>
> =3D=3D=3D=3D=3D
>
> 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=20
> the state between sessions.
>
> -building the menubar is then taking the algorithms to present based=20
> on tmev.cvf, segregating them based on class, then constructing and=20
> formatting the menubar appropriately visually segregate the various=20
> algorithm classes.
>
> Hope you can use some of these ideas... you might have this system=20
> going already.
>
> John
>
>
>
>
>
> -----Original Message-----
> From: wendy wang [mailto:wwang67@...]
> 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=20
> menubar and showed to JohnQ. He thought it works fine. So I began to=20
> 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=20
> the algorithm. Whenever an algorithm needs to be added or deleted, we=20
> just need to add the algorithm and change build file. So it is=20
> flexible and easy to maintain. Each algorithm is treated the same.
>
> If we add a hierarchy for all algorithms, each algorith is treated=20
> differently(when added on menubar). When we add event to each=20
> algorithm, we have to add many selections to choose. The code will=20
> become messy ,hard to maintain(including to add new algorithm) and=20
> ruin the beauty of original design.
>
> So I am not sure if we need to add this function or if you=20
> have suggetion how to solve this problem.
>
> Thanks,
>
> Wendy
> =20

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:johnq@...]
> Sent: Thursday, February 02, 2006 2:50 PM
> To: Braisted, John C.
> Cc: wendy wang; Howe, Eleanor; mev-tm4-devel@...
> 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:wwang67@...]
>> 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
>>
>>

These partitions and category labels look pretty good. =20
No matter how it's done someone will find another partition but this
partition
makes sense to me.
=20
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.
=20
COA can go down in dimensional reduction.
=20
Is your suggestion to present the above algorithms only by selection and
not
in the initial default state?
=20
John
________________________________
From: John Quackenbush [mailto:johnq@...]=20
Sent: Thursday, February 02, 2006 3:21 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor; mev-tm4-devel@...
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:=20
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.
=09
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.
=09
=09
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.
=09
This seems like a nice feature that is really important as the
button
count grows.
=09
John
=09
=20
=09
-----Original Message-----
From: John Quackenbush [mailto:johnq@...]=20
Sent: Thursday, February 02, 2006 2:50 PM
To: Braisted, John C.
Cc: wendy wang; Howe, Eleanor;
mev-tm4-devel@...
Subject: Re: a hierarchy under the analysis menu
=09
John,
=09
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.
=09
Braisted, John C. wrote:
=20
Hi Wendy,
=09
(This got a bit long, a summary is at the bottom)
=09
Since algorithms have several properties that are
designated in the=20
properties files that are constructed during the build,
what about=20
adding a property to indicate algorithm class?
I think this could go into the properties file that
contains=20
information like button gif, algorithm name, gui package
name.
It probably means adding this to the 'gui' targets in
build.xml.
=09
I'm not sure if or how you plan to segregate algorithms
in the tool=20
bar. Previously this had been done by specifying order
in the build=20
script and then 'hard coding' breaks or spaces between
button groups=20
(JSeparators ?) to partition areas like stats and
classification=20
algorithms. This process will now be under better
control since each=20
algorithm 'knows' where it should go based on the
properties. Its=20
been a while since I've worked with the code that
specifies properties
=20
=09
=20
and can deliver them but I did use a bit of this when
creating the=20
script algorithm selection dialog. I doubt that this
will be of=20
direct use but it might be helpful to look at.
=09
Presentation ideas... you probably have this worked
out...
=09
1.) The dialog to select algorithms to put on the tool
bar could be=20
segregated somehow into algorithm class. This could be
a small tabbed
=20
=09
=20
pane dialog, one page per algorithm class. The
reconstruction method=20
for the toolbar (or constructor) could take a set of
algorithms and=20
corresponding classes.
=09
2.) The other option is to provide single dialog page to
present the=20
algorithms on one page. The menubar should be able to
get the=20
property for each algorithm for the sake of segregation.
=09
The other thing to consider and maybe this is the main
point.
The user designated algorithms should probably be kept
as a list in=20
the tmev.cfg file in the config directory. This might
be what you are
=20
=09
=20
doing but this provides the basis to know what to
present when=20
re-starting mev.
=09
=3D=3D=3D=3D=3D
=09
Sorry this is so long... to summarize, I would
=09
-add the algorithm class (category) property to the
build.xml.
(one for each algorithm, put it in the gui target)
=09
-read tmev.cfg on startup to indicate which to load.
This list of algorithms in tmev.cfg can change
dynamically and stores=20
the state between sessions.
=09
-building the menubar is then taking the algorithms to
present based=20
on tmev.cvf, segregating them based on class, then
constructing and=20
formatting the menubar appropriately visually segregate
the various=20
algorithm classes.
=09
Hope you can use some of these ideas... you might have
this system=20
going already.
=09
John
=09
=09
=09
=09
=09
-----Original Message-----
From: wendy wang [mailto:wwang67@...]
Sent: Thursday, February 02, 2006 12:15 PM
To: Quackenbush, John; Braisted, John C.; Howe, Eleanor
Subject: a hierarchy under the analysis menu
=09
Hi, JohnQ, JohnB and Eleanor,
=09
In last teleconference JohnQ suggested seletctabl
menu-bar buttons and
=20
=09
=20
a hierarchy under the analysis menu.Recently I finished
customized=20
menubar and showed to JohnQ. He thought it works fine.
So I began to=20
work on the hiearchy of ananlysis menu. I met some
problems. I have to
=20
=09
=20
ask your suggestion.
=09
In order to realize the flexibilty of adding or
deleting analysis
=20
=09
=20
algorithm, Mev was oringinally designed to use factory
to hold all=20
the algorithm. Whenever an algorithm needs to be added
or deleted, we=20
just need to add the algorithm and change build file. So
it is=20
flexible and easy to maintain. Each algorithm is treated
the same.
=09
If we add a hierarchy for all algorithms, each algorith
is treated=20
differently(when added on menubar). When we add event to
each=20
algorithm, we have to add many selections to choose. The
code will=20
become messy ,hard to maintain(including to add new
algorithm) and=20
ruin the beauty of original design.
=09
So I am not sure if we need to add this function
or if you=20
have suggetion how to solve this problem.
=09
Thanks,
=09
Wendy
=20
=20

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:johnq@...]
> *Sent:* Thursday, February 02, 2006 3:21 PM
> *To:* Braisted, John C.
> *Cc:* wendy wang; Howe, Eleanor; mev-tm4-devel@...
> *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:johnq@...]
>> Sent: Thursday, February 02, 2006 2:50 PM
>> To: Braisted, John C.
>> Cc: wendy wang; Howe, Eleanor; mev-tm4-devel@...
>> 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:wwang67@...]
>>> 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
>>>
>>>

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:wwang67@...]
> 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
>