billybiset / fud

Automatically exported from code.google.com/p/fud
GNU General Public License v3.0
1 stars 0 forks source link

The order in which antivirals are selected and grouped is wrong. #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Now, in the aplication RNAFFE, antivirals are selected and then gouped by type 
(NRTI, NNRTI, PI). It should be in the opposite way. First, antivirals should 
be gropued by type, and then, they should be selected according as their 
genetic distance.

EXAMPLE:
Suppose we have 4 antivirals: A, B, C, D. Also suppose we have its distances 
and types:

Name   Type    Distance
(A,    NRTI,      1)
(B,    NRTI,      1)
(C,    NNRTI,     2)
(D,    NNRTI,     2)

Then, the result of running the antiviral_selector is: {A,B}, since they have 
minimal genetic distance. Then, we have only one type in the selection (NRTI), 
since antivirals C and D discarded because their genetic distance is higher 
than 1 (the distance of A and b).

Now, suppose the current combination policy requires antivirals of types NRTI 
and NNRTI. It is clear that the cmbination policy will fail (only we have one 
type, NRTI).

Now, let see what happen if antivirals are first grouped and then selected.
In first place, we get 2 gropus of antivirals:  X = {A, B}
                                                Y = {C, D}
If we run the antiviral_selector over each group (X and Y), any antiviral is 
discarded. So, we get that the cmbination policy doesn't fail.

Original issue reported on code.google.com by favio.bettiol@gmail.com on 23 Dec 2011 at 5:54

GoogleCodeExporter commented 9 years ago
Is this fixed in LAV?

Original comment by daniel.g...@fudepan.org.ar on 5 Mar 2012 at 9:05

GoogleCodeExporter commented 9 years ago
This issue doesn't belong to LAV. LAV provides the features to group and to 
rank, but the order in wich that features are used in the applications doesn't 
depend on LAV. Anyway, the issue is fixed on the application RNAFFE, but is not 
committed yet.

Original comment by favio.bettiol@gmail.com on 7 Mar 2012 at 2:19

GoogleCodeExporter commented 9 years ago
If not committed, it's not fixed.

If this doesn't belong here, close it. Open up a ticket in RNAFFE and close 
when the fix is committed.

Original comment by billybiset on 7 Mar 2012 at 2:25

GoogleCodeExporter commented 9 years ago
The issue belongs here because RNAFFE is an application stored in the FUD 
repository. So, if I want to add an issue, I have to add here... right?

Original comment by favio.bettiol@gmail.com on 7 Mar 2012 at 2:32

GoogleCodeExporter commented 9 years ago
It's OK to add test applications here, but when the project picks up speed, it 
should be stored in a different repo. No problem on it being here now, but it 
really should be placed elsewhere.

This is one of the problems, issues of RNAFFE are not necessarily FuD related :)

Original comment by billybiset on 7 Mar 2012 at 2:58