[Biojava-dev] Vecmath in biojava

Fri Nov 29 16:12:55 UTC 2013

Thanks everyone for the replies. So I think there is enough consensus 
that vecmath is needed. It's also good that Andreas brought to attention 
the JAMA package issue. As far as I can see the JAMA package is only 
needed for SVD or EVD in a couple of places.

It should be quite straight forward then to replace JAMA stuff by 
vecmath. Vecmath can do everything that JAMA can do, I could not find 
EVD in vecmath but if I understand, it simply is a subcase of SVD 
(available in vecmath.GMatrix). I'd say that solves the JAMA problem in 
a better way by simply eliminating the need for another library. As 
Peter says, anyway the vecmath library has a very nice interface and has 
been optimised to perform efficiently.

With regards to how to actually include vecmath, I'm a bit lost there. I 
only know that it is somehow part of the java core library but it 
doesn't come with the normal JDK. When I've had to use it in the past, I 
always needed to add a vecmath.jar to the classpath. Can't vecmath be 
added as a maven dependency?

How is it done at the moment for other dependencies? For instance 
there's a dependency in log4j in biojava3-structure. If I were to use 
biojava by simply downloading the jar, how would log4j be resolved? 
would I need to download it myself manually?

Jose

On 11/29/2013 01:13 AM, Amr AL-Hossary wrote:
> I also needed VecMath for my M.Sc. Project, and am intending to use it in my
> PhD research; especially as it is already incorporated in JMol.
> So I support depending on it.
>
> Regarding forcing a specific version of vecmath, I have two quick ideas:
> 1) we can call a specific function that is present only in a base version
> that we want. If it is not there, then an exception is thrown and refuse to
> run.
> 2) If we can wait  until java 8 is released, it includes this feature
> already. But that option has Several bad consequences (not suitable for
> everybody).
>
> Regards
>
> Amr
>
> -----Original Message-----
> From: biojava-dev-bounces at lists.open-bio.org
> [mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Prlic
> Sent: Friday, 29 November, 2013 5:53 AM
> To: Rose, Peter
> Cc: biojava-dev at biojava.org
> Subject: Re: [Biojava-dev] Vecmath in biojava
>
> Hi Jose,
>
> Great that you want to join! Let's try to make this as easy as possible for
> you.
>
> The reason why we have not been using vecmath for the structure module so
> far is that some Java VMs come with (usually an ancient version of) vecmath
> bundled with the VM. As such it is hard to control for an application what
> version gets executed. I definitely had bugs related to that when moving
> code from the desktop into the server room and also when shipping code to
> users via webstart.
>
> Having said that, both your and Peter's use case are showing that we need to
> add support for vecmath to BioJava.  We probably want to be a bit
> conservative regarding what version of vecmath we are going to depend on,
> though.
>
> How can we make this most useful and where shall we add support for this?
>
> Since we are discussing libraries, the other odd thing is that a long time
> ago I integrated the Jama package. This was done at a time when it was not
> easily accessible, and the whole fate of the library was unclear. Since this
> is not original BioJava code, and it can get pulled via Maven nowadays, I
> propose that for the next major release, we take this out again. This means
> that a lot of package-imports will need to get changed, but that should be
> fairly easy with some global search-and-replace. Any thoughts on that?
>
> Andreas
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 28, 2013 at 12:35 PM, Rose, Peter <pwrose at ucsd.edu> wrote:
>
>> Jose,
>>
>> I'm in a similar situation. I've also developed a significant amount
>> of code for quaternary structure analysis based on BioJava that uses
>> Vecmath extensively, which I'll contribute to the project in the near
> future.
>> I frequently inter-convert between Matrix, AxisVector, and Quaternion
>> representations. All of this works very naturally in Vecmath.
>>
>> There are a number of reasons I use Vecmath:
>>
>> * Why reinvent the wheel. Using Vecmath allows you to interface with
>> other APIs that are also based on Vecmath. For example I can use the
>> same classes in some our  BioJava application and our RCSB PDB
>> viewers. So for example a surface area calculation that only needs
>> Points and radii would be generally useful, even for developers that do
> otherwise not use BioJava.
>> Vecmath removes the dependency on specific BioJava classes.
>>
>> * The entire library is well designed, very flexible, and highly
>> efficient. It avoids allocation of  new objects and has hardcoded
>> methods for transforming coordinates that are more efficient that
>> using general purpose matrix operations, such as JAMA, that is used in
> BioJava.
>> The only problem we've encountered with Vecmath is the question of
>> distribution and versioning. We had problems with old Vecmath versions
>> distributed on Mac and Linux, which are missing some methods, plus we
>> found a bug in an old Vecmath implementation. We haven't figured out
>> how to overwrite the class path. Have you had similar problem? How
>> could Vecmath be distributed with BioJava so that we can ensure that
>> the latest version of Vecmath is used, and not some old incompatible
>> version that happens to be installed on a machine.
>>
>> -Peter
>>
>>
>> ________________________________________
>> From: biojava-dev-bounces at lists.open-bio.org [
>> biojava-dev-bounces at lists.open-bio.org] on behalf of Jose Duarte [
>> jose.duarte at psi.ch]
>> Sent: Thursday, November 28, 2013 9:13 AM
>> To: biojava-dev at biojava.org
>> Subject: [Biojava-dev] Vecmath in biojava
>>
>> Hi biojava-ers
>>
>> I am a long-time follower of the biojava project but never wrote to
>> the list or contributed to the project, so here is my official
> presentation.
>> I work mainly in protein structure analysis and develop in java.
>> Together with some colleagues we took the decision quite some time ago
>> to go our way and developed our own library for structural
>> bioinformatics ( http://www.bioinformatics.org/owl/). Which in general
>> was a good idea and allowed for a lot of flexibility. Of course we
>> knew that at some point joining a bigger project like biojava would
>> always be a better option in the long term.
>>
>> After talking to Andreas at the PDBx workshop I think that this is the
>> right moment to try joining in. For us that would mean a lot of code
>> rewriting but surely it will be beneficial for us and hopefully also
>> for the biojava project as we could contribute quite a lot of code back.
>>
>> The main project I am working on at the moment is protein interface
>> classification in crystal structures (see our website
>> http://www.eppic-web.org <http://www.eppic-web.org/>). It involves
>> mainly structural calculations so it should be possible to do with the
>> structural modules of biojava. For instance some things we do are
>> reconstruction of the crystal lattice from the asymmetric unit or
>> accessible surface areas (ASA) calculations.
>>
>> So for now I will try to do my first contribution into biojava by
>> contributing the ASA code (an implementation of Shrake and Rupley's
>> algorithm). So there I have my first question already:
>>
>> I see that the javax.vecmath library is not used in biojava. I find
>> that strange since it is natural thing to use in dealing with 3D
>> objects. For instance in our OWL framework we have used it extensively
>> and it was very useful indeed. Our atom coordinates were represented
>> as Point3d objects, which for instance allows for usage of built-in
>> methods for transformations (represented as Matrix4d objects) and in
>> general any kind of vector maths, necessary in almost any structural
> analysis.
>> For instance in the context of ASA calculations I need to sample 3D
>> points on the atoms' spherical surfaces (so these points are not atoms).
>> There I used Point3d again and it seemed very natural. Of course one
>> can instead use arrays or create a vecmath library ourselves but that
>> seems overkill when a vecmath library exists already and is "almost"
>> part of the core java libraries.
>>
>> So what is the opinion about using the vecmath library? could atom
>> coordinates be represented as Point3ds? would it be a major issue to
>> change that implementation? are there alternatives to that within the
>> existing framework? I have only read some parts of the code and I'm
>> not yet very familiar with it, so apologies in advance if I ask too
>> obvious questions!
>>
>> Cheers
>>
>> Jose
>>
>>
>> ---
>> Jose Duarte
>> Laboratory of Biomolecular Research
>> 5232 Villigen PSI
>> Switzerland
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev