Interesting list, one nice thing coming out of that is that the dimension
of our matrices tends to be small.
I did a quick search, as I am worried about the performance of JScience
(just bias as I am sure it is a general purpose solution).
Got a lit of alternatives:
- JAMA: http://math.nist.gov/javanumerics/jama/
- COLT: http://acs.lbl.gov/~hoschek/colt/
- Apache commons math: http://commons.apache.org/math/
And a nice recommendation to "role your own" from:
-
http://stackoverflow.com/questions/6312329/fast-java-matrix-library-suitable-for-jogl-generic-matrix-math
(This by the author of
http://code.google.com/p/efficient-java-matrix-library/ which focuses on
small matrices)
So yeah I am going to think about this, but would expect a performance
shootout is needed before considering any of the above.
Jody
On Fri, Aug 23, 2013 at 6:36 PM, Andrea Aime
<[email protected]>wrote:
> On Fri, Aug 23, 2013 at 10:26 AM, Jody Garnett <[email protected]>wrote:
>
>> Note a few of our dependencies are rather stale:
>>>> - vecmath - has gone GPL on us for later releases, and the exsisting
>>>> JDL / JRL make it not open source.
>>>> - JSR-275 - is dead
>>>>
>>>> I wonder if we can replace both of the above with JScience?
>>>>
>>>
>>> Don't know. Have you looked into it? Is it a drop-in replacement, a
>>> search/replace imports replacement,
>>> or a rewrite client code type replacement?
>>>
>>
>> *Units*
>> Basically drop-in search/replace as JScience donated code to JSR-275
>>
>> There actually has been a useful development on the unit side of things
>> after JSR-275 did not make it. They have defined a common set of interfaces
>> (http://www.unitsofmeasurement.org) and several "unit" projects are
>> implementing <http://www.unitsofmeasurement.org/implementations.html>,
>> including JScience. If it was a green field choice I would go with UOMo
>> (backed by the health industry by the looks of it).
>>
>
> Never spent time looking into the matter, so don't have an opinion....
> given the experience with EMF/XSD, seems that UOMo is a
> Eclipse foundation project makes me nervous about it.
>
>
>>
>> *Vecmath*
>> No such luck on this one - rewrite our code type replacement. Not sure if
>> client code would be effected?
>>
>> I am also not sure how much we use vecmath, I know it is used in
>> referencing. If our needs are modest and fixed dimension it may be look for
>> something more light weight.
>>
>> (The reason I am interested is I do not want to have to ask end-users to
>> install Java3D in order to run uDig)
>>
>
> It may not be too hard, grepped our source files for vecmath imports, it
> seems we don't have too many usages.
> See results in attachment
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
