[Bioperl-l] Bio::Location::Split question
hlapp at gmx.net
Thu Sep 21 23:29:39 EDT 2006
The idea is that those sub-locations are 'owned' by the container
location unless they are remote.
The motivation for Location::Split was not to have an arbitrary
container which could have first-class locations added to it, but
rather its purpose is to represent the location of a dis-contiguous
feature transparently in a way that's compatible with Bio::LocationI.
So if you call $loc->strand(-$loc->strand) and $loc happens to be a
split location but doesn't propagate the location change to the sub-
locations, you have a situation which is ambiguous and inconsistent.
Obviously, if you assume that the sub-locations are first-class
locations and you permit those to zig-zag between strands then
propagating a new strand value would clearly lead to an incorrect
result (namely the same strand for all sublocs when they did not have
the same strand before).
You could change that to only propagate the direction of the change,
not the new value itself.
On Sep 21, 2006, at 4:43 PM, Chris Fields wrote:
> Here's a question which I can't quite find the answer for. The
> behavior of Bio::Location::Split is to propagate strand information
> $loc->strand()) for a Split location object to the various
> sublocations it
> contains. In other words, it isn't just a get/set, but has a
> direct effect
> on the sublocation objects and assumes that all sublocations have
> the same
> strand as the Split location container object. Would you know of any
> rationale for this?
> Christopher Fields
> Postdoctoral Researcher - Switzer Lab
> Dept. of Biochemistry
> University of Illinois Urbana-Champaign
>> -----Original Message-----
>> From: bioperl-l-bounces at lists.open-bio.org [mailto:bioperl-l-
>> bounces at lists.open-bio.org] On Behalf Of Hilmar Lapp
>> Sent: Monday, September 18, 2006 5:27 PM
>> To: Chris Fields
>> Cc: Bioperl-l at lists.open-bio.org
>> Subject: Re: [Bioperl-l] Bio::Location::Split question
>> On Sep 18, 2006, at 5:55 PM, Chris Fields wrote:
>>> However, if I take the two examples above, run them through
>>> FTLocationFactory, then use to_FTstring() to get the feature
>>> string, this is
>>> what I get:
>> So this looks like a bug, right? The correct result would be if both
>> yielded the same strings, or syntactically equivalent strings. The
>> two above are neither identical nor syntactically equivalent.
>> Another test is if you set a feature location from either string and
>> then request the sub-sequence, the resulting sequence should be
>> identical given syntactically equivalent location specifications.
>> Do you want to file (and possibly address?) this?
>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net :
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
: Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net :
More information about the Bioperl-l