[Biojava-dev] Vecmath in biojava

Fri Nov 29 00:13:53 UTC 2013

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