[Biojava-dev] Problems with RichLocations

Richard Holland holland at ebi.ac.uk
Thu Nov 2 16:35:10 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for pointing this out.

> In RichLocation.Tools.construct(Collection members) the merging is apparently missing. Biojavax always calls merging before construct but the javadoc indicates logically that merging should be done inside the body of the method.

The JavaDocs were wrong. There are instances (GenbankFormat etc.) where
we need to construct without merging. Therefore, merging is always left
to the caller. I have amended the JavaDocs to remove this ambiguity.

> In CompoundRichLocation, blocIterator should return an iterator over contiguous blocs sorted in ascending order according to Location javadoc. It does not seem that the list of members is sorted.

I've altered this now and it will return sorted blocks.

> In RichLocation.Tools.flatten(Collection members), members are checked for being instance of SimpleRichLocation. This does not sound correct. First, SimpleRichLocation is not an interface and therefore there is no contract with it and it should not be here; secondly compound members are probably instance of CompoundRichLocation which extends SimpleRichLocation and therefore these compound members are not flattened.

Oops! Fixed now.

> In RichLocation.Tools.modulateCircularLocation(int start, int end, int seqLength), end could be far up and we are probably missing something like  
> while (locationLength>=seqLength) locationLength-=seqLength;

This is deliberate, as circular locations are allowed to wrap round and
cover the entire sequence as many times as they like. Therefore
modulateCircularLocation is supposed to return a location of identical
length, just translated so that start is before end and that start is as
close to the actual start of the sequence as possible, in order to make
it easier for the subsequence methods to work out how to extract
circular sequence. (in the resulting coordinates, start will lie within
the sequence but end could be far far beyond the actual end of the
sequence, which will be interpreted as wrapping round and starting again
from the beginning).

> Hope this helps.

It did! :) All above fixes are in CVS.

cheers,
Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSh494C5LeMEKA/QRAixVAJ0a6rF+/sdG/8P+FfVBrF3i78OuagCePThK
nVT3GCpLl4AeHBnobZD9zDE=
=/CAn
-----END PGP SIGNATURE-----



More information about the biojava-dev mailing list