[Biojava-dev] Vecmath in biojava

[Spencer Bliven]

There's a fair bit of vector math that currently operates on Atom[] arrays
(the whole Calc class, for instance). I would expect at least some of those
operations would be quite a bit faster using vecmath instead of accessing
object members for the xyz coordinates at every step.

-Spencer


On Mon, Dec 2, 2013 at 3:40 AM, Jose Duarte <jose.duarte at psi.ch> wrote:

> Thanks for the reply Andreas. Some comments below:
>
>
>
>  Fewer dependencies is better. However since Jama is used extensively at
>> the internals, probably a dual dependency on both vecmath and jama is the
>> way to go for now.
>>
>>
> Yes I agree it is the way to go for now. In any case it would be good to
> keep in mind that JAMA would be redundant if vecmath was introduced.
>
>
>
>  We can provide utility methods such as Atom.getPoint3D(), StructureTools.getPoint3dCAArray(structure)
>> , etc. if people think that would be helpful.
>>
>>
> Alright, that sounds like a reasonable thing to do. I can add some of
> those already if I need them for the ASA implementation.
>
>
>
>> Yes you can and need to. In prob. 85% of all situations that will go
>> perfectly as expected. However if the Java VM has vecmath bundled with it,
>> it will load the JVM's vecmath.jar instead of your application's and then
>> there is a high chance that there will be conflicts due to API changes.
>> Since we try to run on a wide variety of systems and setups, we should
>> therefore assume an older vecmath version when writing biojava code.
>>
>
> Ok, thanks for explaining that. I think now I understand the problem. It
> never occurred to me in practice because I work 95% of the time in Linux
> and the JREs don't come bundled with java3d. In fact it is actually quite
> difficult to convince your Linux to point vecmath to the system's one ;)
> Anyway now I see that conflicts can happen with the system's vecmath, in
> fact I've just read that it seems to be bundled by default in Mac (
> https://forums.oracle.com/thread/1274789).
>
> So in my opinion the solution to the problem would be:
>
> 1) bundle-in the vecmath library with biojava, if I understand it
> correctly that's compatible with the vecmath licensing
>
> 2) take care of the maven classpath order and make sure that the vecmath
> import comes from biojava's provided jar and not from the system's one,
> thus making sure that the system's vecmath is always overridden by
> biojava's. From what I've been reading around, it seems that from maven
> 2.0.9 the ordering of dependencies in the pom will be respected. Not sure
> how that applies to system libraries though. Does anyone have experience
> with this?
>
>
>
>> Yes. Having said that, the goal is always to keep dependencies to a
>> minimum and only add new ones when we really need them. As such I just
>> committed a cleanup that removes the log4j dependency (it was only used in
>> a few files). The structure module now only depends on other biojava
>> modules (with the exception of the unit tests, but those are not part of a
>> release).
>>
>
> Alright thanks for that! I agree that it is a good idea to keep
> dependencies to a minimum. But it is also true that some basic things are
> unavoidable. So vecmath could be an example but also something like a
> logging framework if logging was to be done extensively throughout the code
>
> Cheers
>
> Jose
>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>