From kvddrift at earthlink.net Sat Oct 1 07:56:56 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 1 Oct 2005 07:56:56 -0400 Subject: [Biococoa-dev] whatsuuup? Message-ID: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> Hi all, I have been busy myself but now have some time again to work on BioCocoa. Some outstanding things are: - update current classes to use the new BCSequence structure - update the IO classes to use annotations and features - implement mutable sequences So, if anyone is still interested on working on BioCocoa, give a shout and we can talk a bit on the list to see where we stand and what a path forward could be. I really hope the project doesn't die out before we at least can release a usable version of the framework. cheers, - Koen. From mek at mekentosj.com Sun Oct 2 07:46:03 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 2 Oct 2005 13:46:03 +0200 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> Message-ID: That's great news Koen! Unfortunately I don't have much time for programming, wish I had... ;-( But shouting and talking a bit on the list is something I would love doing! It's nice to see you want to keep the project alive!! Thanks! cheers, Alex On 1-okt-2005, at 13:56, Koen van der Drift wrote: > Hi all, > > I have been busy myself but now have some time again to work on > BioCocoa. Some outstanding things are: > > - update current classes to use the new BCSequence structure > - update the IO classes to use annotations and features > - implement mutable sequences > > So, if anyone is still interested on working on BioCocoa, give a > shout and we can talk a bit on the list to see where we stand and > what a path forward could be. I really hope the project doesn't die > out before we at least can release a usable version of the framework. > > > cheers, > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.parnot at gmail.com Mon Oct 3 17:08:53 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Mon, 3 Oct 2005 14:08:53 -0700 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> Message-ID: <85BBEB06-9A64-4C8F-AF82-4465C95E4720@gmail.com> I have very little time to even do _some_ programming (on my xgrid project) and this is why I have not contributed much lately, and will not contribute much in the near future, unfortunately. My feeling is a usable framework would be one with a simple BCSequence object, as well as the IO, which is the most important part for any user of the framework. So that should be the focus... for now. Keep us informed of your progress, it might get me foolish enough to do some work too ;-) Charles On Oct 1, 2005, at 4:56 AM, Koen van der Drift wrote: > Hi all, > > I have been busy myself but now have some time again to work on > BioCocoa. Some outstanding things are: > > - update current classes to use the new BCSequence structure > - update the IO classes to use annotations and features > - implement mutable sequences > > So, if anyone is still interested on working on BioCocoa, give a > shout and we can talk a bit on the list to see where we stand and > what a path forward could be. I really hope the project doesn't die > out before we at least can release a usable version of the framework. > > > cheers, > > - Koen. -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From kvddrift at earthlink.net Mon Oct 3 18:09:44 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 3 Oct 2005 18:09:44 -0400 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> Message-ID: <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> On Oct 3, 2005, at 4:52 AM, Peter Schols wrote: > I'd really like to see a stable, usable BioCocoa framework and I'm > willing to do anything I can to help. > > I'm especially interested in helping with implementing the I/O > classes because I have code available to support much more formats. > The only thing I have been waiting for is a BCSequenceGroup/ > BCMatrix/BCWhateverWeWillCallIt class that represents a group of > sequences and can contain information that applies to one or more > sequences in this set. Of course I'm also willing to help with > writing such a class. > > I agree with Peter and Charles. Let's first make sure we have a usable I/O based framework. I think we are pretty close, so if we can get Peter's request in place we are 'almost there' ;-) So, could anyone refresh my memory on the BCSequenceGroup class? The way I understand it is that is a wrapper for an array or set of BCSequence objects? cheers, - Koen. From charles.parnot at gmail.com Mon Oct 3 23:40:22 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Mon, 3 Oct 2005 20:40:22 -0700 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> Message-ID: <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> >> I'd really like to see a stable, usable BioCocoa framework and I'm >> willing to do anything I can to help. >> >> I'm especially interested in helping with implementing the I/O >> classes because I have code available to support much more >> formats. The only thing I have been waiting for is a >> BCSequenceGroup/BCMatrix/BCWhateverWeWillCallIt class that >> represents a group of sequences and can contain information that >> applies to one or more sequences in this set. Of course I'm also >> willing to help with writing such a class. >> > > I agree with Peter and Charles. Let's first make sure we have a > usable I/O based framework. I think we are pretty close, so if we > can get Peter's request in place we are 'almost there' ;-) > > So, could anyone refresh my memory on the BCSequenceGroup class? > The way I understand it is that is a wrapper for an array or set of > BCSequence objects? > > cheers, > > - Koen. I suppose there would be some positional information, where the sequence are aligned in some specific ways, so an array of sequences + an array of offset should do. The best way to start is to agree on a good, simple but complete and consistent header and then the implementation almost does not matter and can always be modified in the future. charles -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From victor.jalencas at gmail.com Tue Oct 4 04:37:01 2005 From: victor.jalencas at gmail.com (victor jalencas) Date: Tue, 4 Oct 2005 10:37:01 +0200 Subject: [Biococoa-dev] Non genetic tools? Message-ID: Hi, I've been lurking in this list for a few weeks now. I'm a software developer married to a biologist, and I had a keen interest in biology in my high-school days as well, so that's why I'm interested in bioinformatics. I am wondering, though, whether the biococoa project is a genetics-only project, or are you interested in other disciplines as well. For example, I have developed some programs for my wife to measure distances between populations -she is an anthropologist specialised in demography and populations. I wonder if this kind of tools would fit in the project, or are better taken elsewhere. Thanks for your attention Victor -- Victor Jalencas From peter.schols at bio.kuleuven.be Tue Oct 4 05:26:26 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Tue, 4 Oct 2005 11:26:26 +0200 Subject: [Biococoa-dev] Non genetic tools? In-Reply-To: References: Message-ID: Hi Victor, Great to see some more interest in BioCocoa! BioCocoa is still in an early phase of development, we are trying to get the basics right. The framework is aimed at molecular biology. If you want to implement something to measure genetic distance between populations, I think it could fit into BC, or you could at least use BC as a tool to do file I/O and sequence manipulation. Best wishes, Peter On 04 Oct 2005, at 10:37, victor jalencas wrote: > Hi, > > I've been lurking in this list for a few weeks now. I'm a software > developer married to a biologist, and I had a keen interest in biology > in my high-school days as well, so that's why I'm interested in > bioinformatics. > > I am wondering, though, whether the biococoa project is a > genetics-only project, or are you interested in other disciplines as > well. For example, I have developed some programs for my wife to > measure distances between populations -she is an anthropologist > specialised in demography and populations. I wonder if this kind of > tools would fit in the project, or are better taken elsewhere. > > Thanks for your attention > > Victor > -- > Victor Jalencas > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Tue Oct 4 19:18:50 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 4 Oct 2005 19:18:50 -0400 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> Message-ID: <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> On Oct 3, 2005, at 11:40 PM, Charles Parnot wrote: > > I suppose there would be some positional information, where the > sequence are aligned in some specific ways, so an array of > sequences + an array of offset should do. The best way to start is > to agree on a good, simple but complete and consistent header and > then the implementation almost does not matter and can always be > modified in the future. > I am trying to figure out what you mean by the array of offset. I like to visualize things, so assume we have the following sequences that are related: 1. CCGTGGGTCCAGGATGA 2. ----GGGCCAGG---- 3. --GTGGGGCCAGGATGA Then the offset array would be like: 0, 4, 2 But it could also be: -4, 0, -2 Am I on the right track here? - Koen. From peter.schols at bio.kuleuven.be Wed Oct 5 04:31:59 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Wed, 5 Oct 2005 10:31:59 +0200 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> Message-ID: <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> I'm not sure if I get it right, but the offset could become quite complex because for sequences with many indels there will be many offsets and you not only need to store offset length but also offset position. For example: 1. CCGTGGGTCCAGGATGA 2. ----GGG---CCA--GG---- The offset array for 2. could be something like (0,4); (8,3); (14,2); (17,4) Maybe we could have an NSOffset (or NSInsertion) struct similar to NSPoint that has two integers: position and length. Charles, is this what you meant with offset information? Peter On 05 Oct 2005, at 01:18, Koen van der Drift wrote: > > On Oct 3, 2005, at 11:40 PM, Charles Parnot wrote: > > >> >> I suppose there would be some positional information, where the >> sequence are aligned in some specific ways, so an array of >> sequences + an array of offset should do. The best way to start is >> to agree on a good, simple but complete and consistent header and >> then the implementation almost does not matter and can always be >> modified in the future. >> >> > > I am trying to figure out what you mean by the array of offset. I > like to visualize things, so assume we have the following sequences > that are related: > > 1. CCGTGGGTCCAGGATGA > > 2. ----GGGCCAGG---- > > 3. --GTGGGGCCAGGATGA > > > Then the offset array would be like: > > 0, 4, 2 > > > But it could also be: > > -4, 0, -2 > > > Am I on the right track here? > > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Wed Oct 5 05:43:46 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 5 Oct 2005 05:43:46 -0400 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> Message-ID: On Oct 5, 2005, at 4:31 AM, Peter Schols wrote: > The offset array for 2. could be something like (0,4); (8,3); > (14,2); (17,4) > Maybe we could have an NSOffset (or NSInsertion) struct similar to > NSPoint that has two integers: position and length. > In that case I would use NSRange. - Koen. From peter.schols at bio.kuleuven.be Wed Oct 5 05:51:46 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Wed, 5 Oct 2005 11:51:46 +0200 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> Message-ID: <59085334-F3F4-47E2-BF89-7CCB31591E0B@bio.kuleuven.be> Oops, I overlooked that one! ;-) NSRange is a perfect fit indeed peter On 05 Oct 2005, at 11:43, Koen van der Drift wrote: > > On Oct 5, 2005, at 4:31 AM, Peter Schols wrote: > > >> The offset array for 2. could be something like (0,4); (8,3); >> (14,2); (17,4) >> Maybe we could have an NSOffset (or NSInsertion) struct similar to >> NSPoint that has two integers: position and length. >> >> > > In that case I would use NSRange. > > - Koen. > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Wed Oct 5 18:21:43 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 5 Oct 2005 18:21:43 -0400 Subject: [Biococoa-dev] BCSequenceCluster Message-ID: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> Hi, > I suppose there would be some positional information, where the > sequence are aligned in some specific ways, so an array of > sequences + an array of offset should do. The best way to start is > to agree on a good, simple but complete and consistent header and > then the implementation almost does not matter and can always be > modified in the future. Here's a first attempt for an interface for a BCSequenceCluster class : @interface BCSequenceCluster : NSObject { BCSequence *representativeSequence; // the sequence to which others are aligned, is 1st entry in sequenceArray NSMutableArray *sequenceArray; // array of the sequences NSMutableArray *offsetArray; // array of NSRanges that hold the offset information (position + length) of each sequence relative to the representativeSequence. The sequenceArray and offsetArray should be in sync, so the first entry in offsetArray is [0,0] NSString *description; // text to describe the cluster } -(BCSequence *)representativeSequence; -(NSMutableArray *)sequenceArray; -(NSMutableArray *)offsetArray; -(void) addSequence: (BCSequence *) aSequence; -(void) removeSequence: (BCSequence *) aSequence; -(void) alignSequencesUsingSelector:(SEL)alignment; // allows for the use of all kind of alignments if needed @end Let me know what you guys think. cheers, - Koen. From charles.parnot at gmail.com Wed Oct 5 19:47:08 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Wed, 5 Oct 2005 16:47:08 -0700 Subject: [Biococoa-dev] whatsuuup? In-Reply-To: <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> References: <29E0ACD8-AE9C-4329-B8E2-00B12BDE32B0@earthlink.net> <193720EB-B277-43A8-A933-3B2C19ECE1FB@bio.kuleuven.be> <49E8E8AC-65AC-41EB-8153-3FB826474214@earthlink.net> <6A6CE129-B7AB-49B4-AF2D-768136489973@gmail.com> <92CDCC8A-397E-41BB-84DB-09FF834799DC@earthlink.net> <912164E9-A1B1-4278-939D-5082F920235F@bio.kuleuven.be> Message-ID: > I'm not sure if I get it right, but the offset could become quite > complex because for sequences with many indels there will be many > offsets and you not only need to store offset length but also > offset position. For example: > > 1. CCGTGGGTCCAGGATGA > > 2. ----GGG---CCA--GG---- > > The offset array for 2. could be something like (0,4); (8,3); > (14,2); (17,4) > Maybe we could have an NSOffset (or NSInsertion) struct similar to > NSPoint that has two integers: position and length. > > Charles, is this what you meant with offset information? > > Peter You are going too fast for me, guys! NSRange is one possibility, as suggested by Koen. The other possibility is to remember that BCSymbol includes a gap symbol, that can be used for that, too, without the need for all the intermediate offsets. It does not matter too much in the end, though it might make our life easier to use the gap symbol to get the information back to the user of the framework, for instance when we need to return a string with the sequence, including the gaps. charles -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From charles.parnot at gmail.com Wed Oct 5 19:51:32 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Wed, 5 Oct 2005 16:51:32 -0700 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> Message-ID: <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> I think that returning the array of offset to the user is like giving the user the Bible not as a string, but as a list of positions of all the letters of the alphabet!! The offset array should remain private, I think. We should return sequences with gaps (either generate them using the offsetArray, or use gaps symbols from the start). what do you think? charles > Hi, > > >> I suppose there would be some positional information, where the >> sequence are aligned in some specific ways, so an array of >> sequences + an array of offset should do. The best way to start is >> to agree on a good, simple but complete and consistent header and >> then the implementation almost does not matter and can always be >> modified in the future. >> > > Here's a first attempt for an interface for a BCSequenceCluster > class : > > @interface BCSequenceCluster : NSObject > { > BCSequence *representativeSequence; // the sequence > to which others are aligned, is 1st entry in sequenceArray > > NSMutableArray *sequenceArray; // array of the > sequences > NSMutableArray *offsetArray; // array of NSRanges > that hold the offset information (position + length) of each > sequence relative to the representativeSequence. The sequenceArray > and offsetArray should be in sync, so the first entry in > offsetArray is [0,0] > > NSString *description; // text to describe > the cluster > } > > -(BCSequence *)representativeSequence; > > -(NSMutableArray *)sequenceArray; > -(NSMutableArray *)offsetArray; > > -(void) addSequence: (BCSequence *) aSequence; > -(void) removeSequence: (BCSequence *) aSequence; > > -(void) alignSequencesUsingSelector:(SEL)alignment; // allows > for the use of all kind of alignments if needed > > @end > > > Let me know what you guys think. > > cheers, > > - Koen. > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From kvddrift at earthlink.net Wed Oct 5 20:16:18 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 5 Oct 2005 20:16:18 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> Message-ID: <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> On Oct 5, 2005, at 7:51 PM, Charles Parnot wrote: > I think that returning the array of offset to the user is like > giving the user the Bible not as a string, but as a list of > positions of all the letters of the alphabet!! > > The offset array should remain private, I think. We should return > sequences with gaps (either generate them using the offsetArray, or > use gaps symbols from the start). > Making the offsetArray private sounds like a good idea. I also like the use of the gap symbol. However, what I am starting to sense now is that we are actually making a BCAlignment class in disguise and I am not sure if we should do that in this case. It's not clear to me from Peter's original request if that's what he meant. What type of alignment is used for instance for phylogenetic sequence clusters, I assume that's what he is talking about? - Koen. From peter.schols at bio.kuleuven.be Thu Oct 6 06:08:04 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Thu, 6 Oct 2005 12:08:04 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> Message-ID: <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> Dear Koen and Charles, I think we have two options: we could either use the gap symbol to represent gaps. In that case, there is no need for an offset at all, since we can simply use the gap symbol, both at the beginning of the sequence and in the middle. This is definitely the easiest way. We could then have a BCSequenceGroup that consists of BCSequences of equal length containing gaps. The only problem I see with this option is that this design does not correspond to the real world: individual sequences don't have gaps / indels. Indels only exist when comparing (aligning) sequences. So from a framework-design point of view, gaps should be a property of BCSequenceGroups not a property of individual sequences. That brings us to the second option: Use BCSequenceGroups to add an array of offsets for every sequence. This option would correspond with the interface Koen has written. However, I don't see why we would need the representativeSequence. Unless you want this class to actually align a set of sequences itself, I think this representativeSequence is not necessary. I suppose that the BCSequenceGroup class will receive its already aligned sequences either from the I/O class of from a BCAligner class (that could be just a wrapper for existing CLI alignment apps). In this case, removing any sequence from the BCSequenceGroup should not affect the alignment so there is no need for a representativeSequence. This is just my point of view, from a phylogenetics background. Maybe we could also have a look at how other Bio frameworks solve this problem. Cheers, Peter On 06 Oct 2005, at 02:16, Koen van der Drift wrote: > > On Oct 5, 2005, at 7:51 PM, Charles Parnot wrote: > > > >> I think that returning the array of offset to the user is like >> giving the user the Bible not as a string, but as a list of >> positions of all the letters of the alphabet!! >> >> The offset array should remain private, I think. We should return >> sequences with gaps (either generate them using the offsetArray, >> or use gaps symbols from the start). >> >> >> > > Making the offsetArray private sounds like a good idea. I also like > the use of the gap symbol. However, what I am starting to sense > now is that we are actually making a BCAlignment class in disguise > and I am not sure if we should do that in this case. It's not clear > to me from Peter's original request if that's what he meant. What > type of alignment is used for instance for phylogenetic sequence > clusters, I assume that's what he is talking about? > > - Koen. > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Thu Oct 6 06:38:44 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 6 Oct 2005 06:38:44 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> Message-ID: <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> On Oct 6, 2005, at 6:08 AM, Peter Schols wrote: > Dear Koen and Charles, > > I think we have two options: we could either use the gap symbol to > represent gaps. In that case, there is no need for an offset at > all, since we can simply use the gap symbol, both at the beginning > of the sequence and in the middle. This is definitely the easiest > way. We could then have a BCSequenceGroup that consists of > BCSequences of equal length containing gaps. > > The only problem I see with this option is that this design does > not correspond to the real world: individual sequences don't have > gaps / indels. Indels only exist when comparing (aligning) > sequences. So from a framework-design point of view, gaps should be > a property of BCSequenceGroups not a property of individual > sequences. That brings us to the second option: > > Use BCSequenceGroups to add an array of offsets for every sequence. > This option would correspond with the interface Koen has written. > However, I don't see why we would need the representativeSequence. > Unless you want this class to actually align a set of sequences > itself, I think this representativeSequence is not necessary. I > suppose that the BCSequenceGroup class will receive its already > aligned sequences either from the I/O class of from a BCAligner > class (that could be just a wrapper for existing CLI alignment > apps). In this case, removing any sequence from the BCSequenceGroup > should not affect the alignment so there is no need for a > representativeSequence. In the case where the input sequences are already aligned, we're ready to go, I guess. Also note we already have a BCAlignment class which we could use. However, I have not yet adapted that to use the NSData structure. I didn't write the alignment code, and I don't want to mess up someone elses work ;-) I added the representative sequence after looking up some info about sequence clusters (see eg http://en.wikipedia.org/wiki/ Sequence_clustering). But if you suggest it is not needed in this case, I'll be happy to remove it! - Koen. From peter.schols at bio.kuleuven.be Thu Oct 6 08:26:54 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Thu, 6 Oct 2005 14:26:54 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> Message-ID: <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> Hi Koen, > In the case where the input sequences are already aligned, we're > ready to go, I guess. Also note we already have a BCAlignment class > which we could use. However, I have not yet adapted that to use the > NSData structure. I didn't write the alignment code, and I don't > want to mess up someone elses work ;-) > > I added the representative sequence after looking up some info > about sequence clusters (see eg http://en.wikipedia.org/wiki/ > Sequence_clustering). But if you suggest it is not needed in this > case, I'll be happy to remove it! I don't think we need the sequence cluster functionality for the BCSequenceGroup class. We could reserve the name BCSequenceCluster for such a class we could eventually create in the future (if there is any need for this). The BCSequenceCluster class could then inherit from BCSequenceGroup. Peter Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From charles.parnot at gmail.com Thu Oct 6 17:45:58 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Thu, 6 Oct 2005 14:45:58 -0700 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> Message-ID: <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> At this point, given that I don't know that much about the fine details of sequence clusters and sequence groups, could you, Peter, take some time to explain exactly what the concept is, and also maybe come up with some examples of what it can be used for and how a user of the framework would want to use it. This way, we can define a header that does the job, and then worry about the implementation. In fact, I should have asked that question in the first place instead of pretending I understood what it was all about! Sorry maybe this is a quite wide question. We don't have to go too deep at this point, as we merely want some I/O to work. However, in 'I/O', there is 'O' for output, so the question is: after loading a sequence from disk, what information will the user want to retrieve? Or will she just want to perform some operations on the sequence group and then move on? cheers, charles On Oct 6, 2005, at 5:26 AM, Peter Schols wrote: > Hi Koen, > > >> In the case where the input sequences are already aligned, we're >> ready to go, I guess. Also note we already have a BCAlignment >> class which we could use. However, I have not yet adapted that to >> use the NSData structure. I didn't write the alignment code, and I >> don't want to mess up someone elses work ;-) >> >> I added the representative sequence after looking up some info >> about sequence clusters (see eg http://en.wikipedia.org/wiki/ >> Sequence_clustering). But if you suggest it is not needed in this >> case, I'll be happy to remove it! >> > > I don't think we need the sequence cluster functionality for the > BCSequenceGroup class. We could reserve the name BCSequenceCluster > for such a class we could eventually create in the future (if there > is any need for this). The BCSequenceCluster class could then > inherit from BCSequenceGroup. > > Peter > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From kvddrift at earthlink.net Thu Oct 6 20:07:42 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 6 Oct 2005 20:07:42 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> Message-ID: On Oct 6, 2005, at 5:45 PM, Charles Parnot wrote: > At this point, given that I don't know that much about the fine > details of sequence clusters and sequence groups, could you, Peter, > take some time to explain exactly what the concept is, and also > maybe come up with some examples of what it can be used for and how > a user of the framework would want to use it. This way, we can > define a header that does the job, and then worry about the > implementation. In fact, I should have asked that question in the > first place instead of pretending I understood what it was all about! > me too :) > Sorry maybe this is a quite wide question. We don't have to go too > deep at this point, as we merely want some I/O to work. However, in > 'I/O', there is 'O' for output, so the question is: after loading a > sequence from disk, what information will the user want to > retrieve? Or will she just want to perform some operations on the > sequence group and then move on? > I agree, lets go ahead with a very basic BCSequenceGroup class that only maintains an array of BCSequences. Actually, BCSequenceReader now already returns an NSArray to take care of this, it would be a slight modification of the code to have it return a BCSequenceGroup. I just realized that eg fasta file also can contain multiple sequences. However, when a file only contains one sequence (and the user knows that), the name BCSequenceGroup could be misleading. Once we have that in place, we can create subclasses of BCSequenceGroup that take care of additional info, and sequence relations. I just looked at bioperl, and they do something similar with their SeqIO class (see http://bioperl.org/HOWTOs/html/SeqIO.html). But they use a separate class to IO trees of sequences (for phylogenetics). Not sure if that is something we should do, unless that sequence format is completely different from all the others. cheers, - Koen. From peter.schols at bio.kuleuven.be Fri Oct 7 04:53:00 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Fri, 7 Oct 2005 10:53:00 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> Message-ID: <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> Hi Charles and Koen, First of all: I'm not a sequence cluster expert and I have never used it for my own research. As far as I know, sequence clustering is a way to align homologous sequences, detect regions of high sequence similarity and describe the differences between sequences. This is especially useful to create non-redundant datasets: for example, if you'd align hemoglobin genes for 5 mammals, you will end up with almost 5 times the same information. So if you'd just store one of the five sequences and store the differences between this sequence (the referenceSequence) and the other 4 sequences, you will save a lot of memory and disk space (maybe not for this example but on a genomic scale) without losing any information. It's highly comparable to JPEG compression. Back to BC: I don't think we need this cluster functionality in BioCocoa, at least for now. For the I/O methods we only need a good container class for BCSequences as you are pointing out. With this approach we would store the gaps directly inside the BCSequences (using the gap symbol). This is definitely the easiest way to implement it. The only thing we would need to do when going this route - to compensate for the fact that sequences don't have gaps in reality - is that we should add a method to BCSequence that returns the sequence without gaps (the 'real' sequence). To answer Charles' question: right now, the only purpose for the BCSequenceGroup would be to make I/O easier. But in the future, we could add extra methods to this class to enable alignment of the BCSequenceGroup (using BCAlignment) or to return a list of shared indels, for example. This BCSequenceGroup could also be the perfect class to pass as an argument to classes that do phylogenetic analysis. So in the future, we could do things like: BCSequenceGroup *group = [BCSequenceGroup groupWithFile:@"myFastaFile.fst"]; [group align]; BCPhylogeneticTree *tree = [group analyzeUsingHeuristicSearchWithReplicates: 1000]; Cheers, Peter On 06 Oct 2005, at 23:45, Charles Parnot wrote: > At this point, given that I don't know that much about the fine > details of sequence clusters and sequence groups, could you, Peter, > take some time to explain exactly what the concept is, and also > maybe come up with some examples of what it can be used for and how > a user of the framework would want to use it. This way, we can > define a header that does the job, and then worry about the > implementation. In fact, I should have asked that question in the > first place instead of pretending I understood what it was all about! > > Sorry maybe this is a quite wide question. We don't have to go too > deep at this point, as we merely want some I/O to work. However, in > 'I/O', there is 'O' for output, so the question is: after loading a > sequence from disk, what information will the user want to > retrieve? Or will she just want to perform some operations on the > sequence group and then move on? > > cheers, > > charles > > On Oct 6, 2005, at 5:26 AM, Peter Schols wrote: > > >> Hi Koen, >> >> >> >>> In the case where the input sequences are already aligned, we're >>> ready to go, I guess. Also note we already have a BCAlignment >>> class which we could use. However, I have not yet adapted that to >>> use the NSData structure. I didn't write the alignment code, and >>> I don't want to mess up someone elses work ;-) >>> >>> I added the representative sequence after looking up some info >>> about sequence clusters (see eg http://en.wikipedia.org/wiki/ >>> Sequence_clustering). But if you suggest it is not needed in this >>> case, I'll be happy to remove it! >>> >>> >> >> I don't think we need the sequence cluster functionality for the >> BCSequenceGroup class. We could reserve the name BCSequenceCluster >> for such a class we could eventually create in the future (if >> there is any need for this). The BCSequenceCluster class could >> then inherit from BCSequenceGroup. >> >> Peter >> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> > > -- > Xgrid-at-Stanford > Help science move fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford > > Charles Parnot > charles.parnot at gmail.com > > > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Fri Oct 7 18:12:54 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 7 Oct 2005 18:12:54 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> Message-ID: <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> On Oct 7, 2005, at 4:53 AM, Peter Schols wrote: > Hi Charles and Koen, > > First of all: I'm not a sequence cluster expert and I have never > used it for my own research. Neither am I :) > Back to BC: I don't think we need this cluster functionality in > BioCocoa, at least for now. For the I/O methods we only need a good > container class for BCSequences as you are pointing out. With this > approach we would store the gaps directly inside the BCSequences > (using the gap symbol). This is definitely the easiest way to > implement it. > The only thing we would need to do when going this route - to > compensate for the fact that sequences don't have gaps in reality - > is that we should add a method to BCSequence that returns the > sequence without gaps (the 'real' sequence). So this assumes that the input file already has the gaps in place? > > To answer Charles' question: right now, the only purpose for the > BCSequenceGroup would be to make I/O easier. But in the future, we > could add extra methods to this class to enable alignment of the > BCSequenceGroup (using BCAlignment) or to return a list of shared > indels, for example. This BCSequenceGroup could also be the perfect > class to pass as an argument to classes that do phylogenetic analysis. > > So in the future, we could do things like: > > BCSequenceGroup *group = [BCSequenceGroup > groupWithFile:@"myFastaFile.fst"]; > [group align]; > BCPhylogeneticTree *tree = [group > analyzeUsingHeuristicSearchWithReplicates: 1000]; That sounds like a good plan to me. The only thing that I now see what I don't like is the name BCSequenceGroup. Using this assumes that there is always a group of sequences that need to be imported, while often there is only one. But I cannot think of anything else right now :( cheers, - Koen. From charles.parnot at gmail.com Sat Oct 8 00:20:38 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Fri, 7 Oct 2005 21:20:38 -0700 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> Message-ID: <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> Thanks for the explanation about sequence clustering. This is actually more of a data compression trick, which would go on the implementation side. Again, I think we should worry about the implementation after we decide on the interface, and the needed classes. Thanks Peter, for the code example, this is the kind of stuff I was thinking about. For the sake of simplicity, should not we have a single class for such related concepts as "BCSequenceGroup", "BCSequenceCluster", and "BCSequenceAlignment", or even, let's throw one more, "BCSequenceContig"? For all of these, we are just talking about a bunch of sequences positioned a specific way with respect to each other. I just want to make sure I am not missing something. The conceptual differences are quite small, and I think to make the framework really taste like Cocoa, it has to have a simple interface. In fact, this is really the essence of what I was wondering about. How many classes do we need for all these related concepts? Is one enough? Regarding the implementation, I would tend to prefer using gaps, because we already have the BCSymbol, we can easily generate sequences without them (good suggestion, Peter), and it is easy to use for display, comparisons,... On the other hand, using offsets renders some task like "get the symbols at position 827 of all the sequences" a bit hard (basically trading off simplicity and speed for data compression). But in the end, I would be happy with any implementation, as long as it works, particularly because I am probably not going to be doing much of it!! so, just one class?? charles On Oct 7, 2005, at 1:53 AM, Peter Schols wrote: > Hi Charles and Koen, > > First of all: I'm not a sequence cluster expert and I have never > used it for my own research. > > As far as I know, sequence clustering is a way to align homologous > sequences, detect regions of high sequence similarity and describe > the differences between sequences. This is especially useful to > create non-redundant datasets: for example, if you'd align > hemoglobin genes for 5 mammals, you will end up with almost 5 times > the same information. So if you'd just store one of the five > sequences and store the differences between this sequence (the > referenceSequence) and the other 4 sequences, you will save a lot > of memory and disk space (maybe not for this example but on a > genomic scale) without losing any information. It's highly > comparable to JPEG compression. > > Back to BC: I don't think we need this cluster functionality in > BioCocoa, at least for now. For the I/O methods we only need a good > container class for BCSequences as you are pointing out. With this > approach we would store the gaps directly inside the BCSequences > (using the gap symbol). This is definitely the easiest way to > implement it. > The only thing we would need to do when going this route - to > compensate for the fact that sequences don't have gaps in reality - > is that we should add a method to BCSequence that returns the > sequence without gaps (the 'real' sequence). > > To answer Charles' question: right now, the only purpose for the > BCSequenceGroup would be to make I/O easier. But in the future, we > could add extra methods to this class to enable alignment of the > BCSequenceGroup (using BCAlignment) or to return a list of shared > indels, for example. This BCSequenceGroup could also be the perfect > class to pass as an argument to classes that do phylogenetic analysis. > > So in the future, we could do things like: > > BCSequenceGroup *group = [BCSequenceGroup > groupWithFile:@"myFastaFile.fst"]; > [group align]; > BCPhylogeneticTree *tree = [group > analyzeUsingHeuristicSearchWithReplicates: 1000]; > > Cheers, > > Peter > > > On 06 Oct 2005, at 23:45, Charles Parnot wrote: > > >> At this point, given that I don't know that much about the fine >> details of sequence clusters and sequence groups, could you, >> Peter, take some time to explain exactly what the concept is, and >> also maybe come up with some examples of what it can be used for >> and how a user of the framework would want to use it. This way, we >> can define a header that does the job, and then worry about the >> implementation. In fact, I should have asked that question in the >> first place instead of pretending I understood what it was all about! >> >> Sorry maybe this is a quite wide question. We don't have to go too >> deep at this point, as we merely want some I/O to work. However, >> in 'I/O', there is 'O' for output, so the question is: after >> loading a sequence from disk, what information will the user want >> to retrieve? Or will she just want to perform some operations on >> the sequence group and then move on? >> >> cheers, >> >> charles >> >> On Oct 6, 2005, at 5:26 AM, Peter Schols wrote: >> >> >> >>> Hi Koen, >>> >>> >>> >>> >>>> In the case where the input sequences are already aligned, we're >>>> ready to go, I guess. Also note we already have a BCAlignment >>>> class which we could use. However, I have not yet adapted that >>>> to use the NSData structure. I didn't write the alignment code, >>>> and I don't want to mess up someone elses work ;-) >>>> >>>> I added the representative sequence after looking up some info >>>> about sequence clusters (see eg http://en.wikipedia.org/wiki/ >>>> Sequence_clustering). But if you suggest it is not needed in >>>> this case, I'll be happy to remove it! >>>> >>>> >>>> >>> >>> I don't think we need the sequence cluster functionality for the >>> BCSequenceGroup class. We could reserve the name >>> BCSequenceCluster for such a class we could eventually create in >>> the future (if there is any need for this). The BCSequenceCluster >>> class could then inherit from BCSequenceGroup. >>> >>> Peter >>> >>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >>> >>> _______________________________________________ >>> Biococoa-dev mailing list >>> Biococoa-dev at bioinformatics.org >>> https://bioinformatics.org/mailman/listinfo/biococoa-dev >>> >>> >>> >> >> -- >> Xgrid-at-Stanford >> Help science move fast forward: >> http://cmgm.stanford.edu/~cparnot/xgrid-stanford >> >> Charles Parnot >> charles.parnot at gmail.com >> >> >> >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> >> > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > > -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From kvddrift at earthlink.net Sat Oct 8 09:14:35 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 8 Oct 2005 09:14:35 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> Message-ID: On Oct 8, 2005, at 12:20 AM, Charles Parnot wrote: > The conceptual differences are quite small, and I think to make the > framework really taste like Cocoa, it has to have a simple > interface. In fact, this is really the essence of what I was > wondering about. How many classes do we need for all these related > concepts? Is one enough? > > Regarding the implementation, I would tend to prefer using gaps, > because we already have the BCSymbol, we can easily generate > sequences without them (good suggestion, Peter), and it is easy to > use for display, comparisons,... On the other hand, using offsets > renders some task like "get the symbols at position 827 of all the > sequences" a bit hard (basically trading off simplicity and speed > for data compression). But in the end, I would be happy with any > implementation, as long as it works, particularly because I am > probably not going to be doing much of it!! > > so, just one class?? Let's at least start with one class. We could then either subclass them, or write categories for them to extend the various functionalities. One thing that occurred to me, are we concerned about the order of the sequences? Otherwise we could use a set instead of an array, and create a BCSequenceSet class (I also like that name :) It also fits nice in the framework: BCSymbol <-> BCSymbolSet, and BCSequence <-> BCSequenceSet. cheers, - Koen. From peter.schols at bio.kuleuven.be Sat Oct 8 09:18:41 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Sat, 8 Oct 2005 15:18:41 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> Message-ID: <9D2F50F3-2C04-49F2-A680-FC5E06D89163@bio.kuleuven.be> > So this assumes that the input file already has the gaps in place? > That's right. Most if not all of our I/O formats represent gaps as hyphens or dots. > That sounds like a good plan to me. The only thing that I now see > what I don't like is the name BCSequenceGroup. Using this assumes > that there is always a group of sequences that need to be imported, > while often there is only one. But I cannot think of anything else > right now :( > No problem, I don't particularly like BCSequenceGroup either. I was just using because it contrasts BCSequenceCluster. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From peter.schols at bio.kuleuven.be Sat Oct 8 09:32:16 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Sat, 8 Oct 2005 15:32:16 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> Message-ID: <9998B9DB-99FB-45F7-B0EB-D6B36CCF18DC@bio.kuleuven.be> > Thanks Peter, for the code example, this is the kind of stuff I was > thinking about. For the sake of simplicity, should not we have a > single class for such related concepts as "BCSequenceGroup", > "BCSequenceCluster", and "BCSequenceAlignment", or even, let's > throw one more, "BCSequenceContig"? For all of these, we are just > talking about a bunch of sequences positioned a specific way with > respect to each other. I just want to make sure I am not missing > something. > The conceptual differences are quite small, and I think to make the > framework really taste like Cocoa, it has to have a simple > interface. In fact, this is really the essence of what I was > wondering about. How many classes do we need for all these related > concepts? Is one enough? I think this is a very good suggestion, I totally agree. One class should fit them all. The only potential "problem" is that the overlap with contigs is quite small, so the BCSequences will contain plenty of gaps while with the other "formats", the sequences will be much more similar. In fact that's not really a problem at all... just a thought. For entire genomes, this might become a problem, though, as every sequence might become very long. This class could have a -(BOOL)isAligned method or something similar to easily test whether sequences are aligned (and thus have equal length) because I can imagine I/O formats that return a group of non- homologous sequences with different lengths. > Regarding the implementation, I would tend to prefer using gaps, > because we already have the BCSymbol, we can easily generate > sequences without them (good suggestion, Peter), and it is easy to > use for display, comparisons,... On the other hand, using offsets > renders some task like "get the symbols at position 827 of all the > sequences" a bit hard (basically trading off simplicity and speed > for data compression). But in the end, I would be happy with any > implementation, as long as it works, particularly because I am > probably not going to be doing much of it!! I'd also prefer the gap approach above the offset approach. It will keep things much simpler, it will make I/O much simpler and we can easily switch between a gapped and non-gapped sequence. Cheers, Peter Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From peter.schols at bio.kuleuven.be Sat Oct 8 09:34:40 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Sat, 8 Oct 2005 15:34:40 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> Message-ID: <95CFE3CC-B2A0-4370-B039-BE9C9B9EBD3C@bio.kuleuven.be> > One thing that occurred to me, are we concerned about the order of > the sequences? Otherwise we could use a set instead of an array, > and create a BCSequenceSet class (I also like that name :) It also > fits nice in the framework: BCSymbol <-> BCSymbolSet, and > BCSequence <-> BCSequenceSet. > BCSequenceSet sounds quite good and makes our naming scheme consistent indeed ;-) The only problem I see is that for some I/O formats of I/O conversions you want to do, preserving the order of sequences would be nice. Peter Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Sat Oct 8 09:57:16 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 8 Oct 2005 09:57:16 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <95CFE3CC-B2A0-4370-B039-BE9C9B9EBD3C@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> <95CFE3CC-B2A0-4370-B039-BE9C9B9EBD3C@bio.kuleuven.be> Message-ID: <2DD44FF6-3D0A-407A-A8D8-20DBE5B34E5B@earthlink.net> On Oct 8, 2005, at 9:34 AM, Peter Schols wrote: > BCSequenceSet sounds quite good and makes our naming scheme > consistent indeed ;-) > The only problem I see is that for some I/O formats of I/O > conversions you want to do, preserving the order of sequences would > be nice. > Yes, you're probably right. Although you could use NSSet's allObjects method, which returns an array of sequences. So maybe its actually better to have a BCSequenceArray class: @interface BCSequenceArray : NSObject { NSMutableArray *sequenceArray // array of the sequences NSString *description; // text to describe the sequences } -(void) sequenceAtIndex:(int)index; -(void) addSequence: (BCSequence *) aSequence; -(void) removeSequence (BCSequence *) aSequence; @end We could eg make use of NSArray's makeObjectsPerformSelector method to set up alignments etc. cheers, - Koen. From kvddrift at earthlink.net Sat Oct 8 12:27:33 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 8 Oct 2005 12:27:33 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <9D2F50F3-2C04-49F2-A680-FC5E06D89163@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> <9D2F50F3-2C04-49F2-A680-FC5E06D89163@bio.kuleuven.be> Message-ID: <74781191-2269-4E21-A932-758C1AF26616@earthlink.net> On Oct 8, 2005, at 9:18 AM, Peter Schols wrote: > No problem, I don't particularly like BCSequenceGroup either. Hmm, what about BCSequenceFamily ? - Koen. From peter.schols at bio.kuleuven.be Sun Oct 9 06:49:57 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Sun, 9 Oct 2005 12:49:57 +0200 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <74781191-2269-4E21-A932-758C1AF26616@earthlink.net> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> <9D2F50F3-2C04-49F2-A680-FC5E06D89163@bio.kuleuven.be> <74781191-2269-4E21-A932-758C1AF26616@earthlink.net> Message-ID: I thought we are going to use BCSequenceArray? peter On 08 Oct 2005, at 18:27, Koen van der Drift wrote: > > On Oct 8, 2005, at 9:18 AM, Peter Schols wrote: > > >> No problem, I don't particularly like BCSequenceGroup either. >> > > > Hmm, what about BCSequenceFamily ? > > - Koen. > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Sun Oct 9 08:30:41 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 9 Oct 2005 08:30:41 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <0684A143-7646-4C2B-BD10-AFE01B01AAE8@earthlink.net> <9D2F50F3-2C04-49F2-A680-FC5E06D89163@bio.kuleuven.be> <74781191-2269-4E21-A932-758C1AF26616@earthlink.net> Message-ID: <9EB765AD-01EF-4669-83BC-A706751D4D65@earthlink.net> BCSequenceArray is fine with me too. If I have some time I will add it today to cvs. I won't have much time for the rest of the week though. cheers, - Koen. On Oct 9, 2005, at 6:49 AM, Peter Schols wrote: > I thought we are going to use BCSequenceArray? > > peter > > > On 08 Oct 2005, at 18:27, Koen van der Drift wrote: > > >> >> On Oct 8, 2005, at 9:18 AM, Peter Schols wrote: >> >> >> >>> No problem, I don't particularly like BCSequenceGroup either. >>> >>> >> >> >> Hmm, what about BCSequenceFamily ? >> >> - Koen. >> > From kvddrift at earthlink.net Sun Oct 9 10:28:53 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 9 Oct 2005 10:28:53 -0400 Subject: [Biococoa-dev] BCSequenceArray Message-ID: Hi, I have added a very basic BCSequenceArray class, basically right now just a wrapper around a NSMutableArray. If we all agree on the format, we can update BCSequenceReader to return a BCSequenceArray object instead of a NSArray as it is right now. cheers, - Koen. From charles.parnot at gmail.com Mon Oct 10 02:04:30 2005 From: charles.parnot at gmail.com (Charles Parnot) Date: Sun, 9 Oct 2005 23:04:30 -0700 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <9998B9DB-99FB-45F7-B0EB-D6B36CCF18DC@bio.kuleuven.be> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> <9998B9DB-99FB-45F7-B0EB-D6B36CCF18DC@bio.kuleuven.be> Message-ID: <0BC9865D-C8E8-4946-B24A-B53DB2422925@gmail.com> > I think this is a very good suggestion, I totally agree. One class > should fit them all. The only potential "problem" is that the > overlap with contigs is quite small, so the BCSequences will > contain plenty of gaps while with the other "formats", the > sequences will be much more similar. In fact that's not really a > problem at all... just a thought. For entire genomes, this might > become a problem, though, as every sequence might become very long. I suppose we can at least use just one offset value, which is where each sequence is actually positioned, and then have gaps in between symbols as needed. So just one integer per sequence: instead of starting a sequence ith 400 gaps, store its position as being '400'. The position is relative to the leftmost sequence (and with circular sequence, well, euh, we don't do that!!). But this is an implementation detail. Whatever Koen prefers is fine with me if he writes the code ;-) charles -- Xgrid-at-Stanford Help science move fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford Charles Parnot charles.parnot at gmail.com From kvddrift at earthlink.net Wed Oct 12 08:13:19 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 12 Oct 2005 08:13:19 -0400 Subject: [Biococoa-dev] BCSequenceCluster In-Reply-To: <0BC9865D-C8E8-4946-B24A-B53DB2422925@gmail.com> References: <40C34035-95B6-4A20-BE01-F0CE53EFAC11@earthlink.net> <23EE0135-CE37-4543-95EA-8C440B70486B@gmail.com> <6A75357A-4B0D-454A-8725-EEDFB7ACF1BA@earthlink.net> <2AFCD5B2-7556-4442-9546-08A027B29FBE@bio.kuleuven.be> <711B087F-8B3D-4226-AB88-2549BC6FB8A1@earthlink.net> <95E7E0FC-45D2-4160-B9CA-D6FAB6ACAC69@bio.kuleuven.be> <3CF8137C-087E-4054-9854-6CED978F9B05@gmail.com> <5AF4BB59-05DE-4ABC-9731-C44AD18B8CF2@bio.kuleuven.be> <12633079-C769-4C4F-BE0A-6A0C90C65988@gmail.com> <9998B9DB-99FB-45F7-B0EB-D6B36CCF18DC@bio.kuleuven.be> <0BC9865D-C8E8-4946-B24A-B53DB2422925@gmail.com> Message-ID: <7EC39435-8F59-4331-AA56-3CF3AB7D8082@earthlink.net> On Oct 10, 2005, at 2:04 AM, Charles Parnot wrote: > I suppose we can at least use just one offset value, which is where > each sequence is actually positioned, and then have gaps in between > symbols as needed. So just one integer per sequence: instead of > starting a sequence ith 400 gaps, store its position as being > '400'. The position is relative to the leftmost sequence (and with > circular sequence, well, euh, we don't do that!!). > > But this is an implementation detail. Whatever Koen prefers is fine > with me if he writes the code ;-) I am ??? ;-) I will give it a shot, but I am looking for a input file to work with. Do you think test1 or test3 in the Translation demo code will work? Also, are we assuming that the input file is already aligned, correct. Otherwise we need to have a way to define a starting point without any alignment code. cheers, - Koen. From kvddrift at earthlink.net Thu Oct 13 21:25:19 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 13 Oct 2005 21:25:19 -0400 Subject: [Biococoa-dev] BCSequenceArray In-Reply-To: References: Message-ID: On Oct 9, 2005, at 10:28 AM, Koen van der Drift wrote: > Hi, > > I have added a very basic BCSequenceArray class, basically right > now just a wrapper around a NSMutableArray. If we all agree on the > format, we can update BCSequenceReader to return a BCSequenceArray > object instead of a NSArray as it is right now. > Since no-one objected I have changed the BCSequenceReader class, as well the code in the examples, They now all use the BCSequenceArray code. No alignment code because I am still not sure how to approach that. Feel free to implement it if you have a good idea about how to do that. - Koen. From peter.schols at bio.kuleuven.be Tue Oct 18 06:10:18 2005 From: peter.schols at bio.kuleuven.be (Peter Schols) Date: Tue, 18 Oct 2005 12:10:18 +0200 Subject: [Biococoa-dev] BCSequenceArray In-Reply-To: References: Message-ID: <4AC44FDD-4C84-48FE-BE59-F6F71E38271D@bio.kuleuven.be> Hi Koen Great! I'm just returning from a one-week vacation and I can't wait to have a look at the code and implement additional I/O methods using the BCSequenceArray class. cheers, peter On 14 Oct 2005, at 03:25, Koen van der Drift wrote: > > On Oct 9, 2005, at 10:28 AM, Koen van der Drift wrote: > > >> Hi, >> >> I have added a very basic BCSequenceArray class, basically right >> now just a wrapper around a NSMutableArray. If we all agree on the >> format, we can update BCSequenceReader to return a BCSequenceArray >> object instead of a NSArray as it is right now. >> >> > > > Since no-one objected I have changed the BCSequenceReader class, as > well the code in the examples, They now all use the BCSequenceArray > code. No alignment code because I am still not sure how to > approach that. Feel free to implement it if you have a good idea > about how to do that. > > - Koen. > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kvddrift at earthlink.net Tue Oct 18 18:01:56 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 18 Oct 2005 18:01:56 -0400 Subject: [Biococoa-dev] BCSequenceArray In-Reply-To: <4AC44FDD-4C84-48FE-BE59-F6F71E38271D@bio.kuleuven.be> References: <4AC44FDD-4C84-48FE-BE59-F6F71E38271D@bio.kuleuven.be> Message-ID: <17CF65ED-1C13-448E-AB4F-659F58F7269F@earthlink.net> On Oct 18, 2005, at 6:10 AM, Peter Schols wrote: > I can't wait to have a look at the code and implement additional I/ > O methods using the BCSequenceArray class. Excellent! I'm looking forward to your commits! - Koen. From johnvndn at textwise.com Tue Oct 25 10:18:14 2005 From: johnvndn at textwise.com (Louella) Date: Tue, 25 Oct 2005 10:18:14 -0400 Subject: [Biococoa-dev] XP Pro Products available for Download Message-ID: <2359816110.20051025101814@edsd> An HTML attachment was scrubbed... URL: