Hi Francisco,

I have some observations but no definitive = diagnosis or=20 solution...

I think the problem in COA does come down the = condition of=20 your matrix.
Changing the Jama version did not resolve the = issue. =20 The computation still stalled in
finding the SVD (Singular Value = Decomposition). =20 The Jama package seems to hang up
inside a loop.  I'm not sure why this = happens=20 specifically in SVD since this shouldn't
have a problem with a row of = zeros.

I tried SVD and corresp in R and it complains = up front=20 about an empty row or column
and doesn't attempt to continue.  I then = noticed that=20 line 2 in your matrix is all zeros.
I'm not sure if this is strictly disallowed but = removal of=20 that row allows COA to run in R and MeV.
Passing the Jama implementation of SVD and = corresp in R=20 depends on this row being out of the matrix.
Just=20 to complicate things, we have a sample TDMS file with a row of zeros but = it runs=20 through
COA in=20 MeV but R complains.  Our matrix is not made up of discrete = values (0=20 or 1) as is yours.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Others=20 on our development team are receiving this and might have some = additional=20 ideas.
I'm=20 attaching your problem matrix in case others are interested or have=20 insight.

Sorry=20 I don't have better news or an easy solution.

John

From: Francisco J. Ossand=F3n C.=20 [mailto:fossandon@vtr.net]
Sent: Wednesday, September 27, = 2006 4:47=20 PM
To: Braisted, John C.
Subject: Re: COA=20 module

Hi John:
Thanks for the quick reply. Yes I = noticed that the=20 PCA module works correctly, but PCA gives a weird result, placing all = data=20 points of the table at only 1 side of the X-axis instead of around the = center,=20 maybe because all data used is of positive sign. Instead COA places them = around=20 the center as expected, with a resulting logical and coherent = interpretation of=20 the associations. Thus I currently only use COA for plotting the data = from the=20 SVD analysis.

I hope you can fix the error so that = the data can=20 be analysed through COA, because earlier results of COA on older data = gave=20 interesting results that were also consistent with a Support = Tree.

I visited the JAMA website you wrote = and I wonder=20 if they are still active, since the last change on the changelog and the = webpage=20 in general is from more than a year ago (July 2005).

Hopefully something can be done. Thanks = again, I'll=20 be checking my e-mail and MeV website in case an update appear on the=20 issue.

Regards.

Francisco Ossandon
----- Original Message -----
From:=20 Braisted, John=20 C.
Cc: mev-tm4-devel@lists.s= ourceforge.net=20 ; tm4
Sent: Wednesday, September 27, = 2006 12:38=20 PM
Subject: RE: COA module

Hi Francisco,

I ran COA with the same result.  PCA = which uses the=20 same imputation code ran fine which is
expected since you don't need to = impute.  The=20 problem comes after possible imputation.

I ran some more tests and found that it = starts the=20 Singular Value Decomposition of the matrix which = is
performed by a package called JAMA that we = use for matrix=20 operations.  This method never returns.
I don't have access to the code to find out = exactly where=20 it fails but this decomposition can fail
based on the nature of your = matrix.  JAMA and=20 others found that it should be robust
but I've now seen some other reports that it=20 hangs.

I wish that JAMA would produce some sort of = feedback or=20 an escape.

*I might try to update our Jama jar file that = contains=20 the svd code.  This page:

http://math.nis= t.gov/javanumerics/jama/ChangeLog

points to some changes that might address = this specific=20 issue.

I'll let you know if a new Jama version fixes = this.

John Braisted

John Braisted
The = Institute for=20 Genomic Research (TIGR)
9712 Medical Center Drive
Rockville, MD=20 20850

From: Francisco J. Ossand=F3n C.=20 [mailto:fossandon@vtr.net]
Sent: Wednesday, September 27, = 2006=20 11:33 AM
To: mev
Subject: COA = module

Hello MeV team:
There is something weird with the COA = module and=20 I hope you can help me. In the past I have successfully used this = module to=20 analyze relations between the presence of variables and samples = using=20 binary data (0/1). Usually I pre-filter them with a percentage cutoff = value of=20 80% and, since the data is not big, the results are = available seconds=20 later. But the last table I tried to analyze (of a small size too, for = the=20 standards of the program) caused the CPU to reach 100% usage without = coming to=20 a result even after some hours of process, stalled in the = dialog:
Starting SVD = calculation
Imputing missing=20 values.
If I press the cancel button or even = close the=20 active Multiple Array Viewer, Java continue using the whole CPU untill = I close=20 completely MeV. Im guessing that for some reason the program = entered into=20 an infinite loop. Thinking that the missing data may have been causing = it, I=20 generated a new table with 100% of data; but the result was the same, = CPU=20 usage jumps to 100% and stay there for a long time.

I have tested the = table in two=20 different computers with the same results, an Athlon XP Barton 2600+ = and a=20 Pentium 4 Dual core 3.2 GHz, both with WinXP SP2 and with the program = staying=20 inside the limits of RAM capacity when monitored (512MB and 1GB = capacity=20 respectively). Java Runtime Environment version is 1.5.0_07 for the = first=20 computer and 1.5.0_08 for the second computer. COA module was used = with=20 default parameters in all cases (Number of neighbors: 10). No unusual = message=20 appear in the MeV console.

To illustrate the problem, Im also = attaching 2=20 files. Table 1 works fine and give the results within a couple of = seconds, but=20 the problematic Table 2 (just a little bigger and that is actually an = update=20 of the 1st table) causes 100% CPU usage and no results after = considerable time (I have to just close the program).