[Bioperl-l] Bio::Location::Split question

[Hilmar Lapp]

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.

	-hilmar

On Sep 21, 2006, at 4:43 PM, Chris Fields wrote:

> Hilmar,
>
> Here's a question which I can't quite find the answer for.  The  
> current
> behavior of Bio::Location::Split is to propagate strand information  
> (using
> $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:
>>>
>>> complement(join(2691..4571,4918..5163))
>>>
>>> complement(join(4918..5163,2691..4571))
>>
>> 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
>> --
>> ===========================================================
>> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>> ===========================================================
>>
>>
>>
>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================