[Bioperl-l] Bio::Location::Split question
cjfields at uiuc.edu
Fri Sep 22 05:27:00 UTC 2006
On Sep 21, 2006, at 10:29 PM, Hilmar Lapp wrote:
> 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.
There are two relatively serious problems that I have found, which
are outlined in bugzilla (and which we have talked about):
Data::Dumper output shows that the objects are different in order and
strand. I'm running more tests when I have time to check out the
subsequences but they seem out-of-order, so using each_sub_Location
will likely get the subsequences out of order as well. I'll see what
I can work out. I know that, if we treat remote locations similarly
to regular locations in strand(), then one bug is fixed.
The reason I ask about the use of strand() is I found it much easier
to fix some of these bugs when assuming the split location has a
strand, if using it as nothing more than a point of reference for the
sublocations (i.e. the strand doesn't mean anything except
internally). I noticed that is done somewhat, but only with
> 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 :
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign
More information about the Bioperl-l