Re: [Geotools-devel] Replacing Vecmath

[Tyler B. <tb...@bo...>]

Sounds good to me.

On 13 March 2015 at 12:35, Jody Garnett <jod...@gm...> wrote:

> For reference this is issue https://jira.codehaus.org/browse/GEOT-22
>
> --
> Jody Garnett
>
> On 13 March 2015 at 11:57, Jody Garnett <jod...@gm...> wrote:
>
>> At the foss4gna code sprint, here is a proposal to make this change:
>> http://docs.codehaus.org/display/GEOTOOLS/Change+from+vecmath+to+EJML
>>
>> Looking at this with Jim, the library has DenseMatrix64F (which does the
>> work) and an example of wrapping this up for normal use called SimpleMatrix.
>>
>> Each operation in SimpleMatrix makes a copy, an overhead we could avoid
>> by using DenseMatrix64F ourself. So the proposal is to delegate to
>> DenseMatrix64F, using SimpleMatrix (and its friend BaseMatrix) as a guide.
>>
>> Alternatively we could kill our GeneralMatrix class and use SimpleMatrix
>> directly in the rest of the GeoTools codebase, it would be more an an API
>> change - which is okay if people only see this stuff inside MathTransforms.
>> Anyone got an idea on how visible GeneralMatrix is?
>>
>>
>>
>> --
>> Jody Garnett
>>
>> On 14 February 2015 at 10:37, Jody Garnett <jod...@gm...>
>> wrote:
>>
>>> Details.
>>> https://code.google.com/p/efficient-java-matrix-library/
>>>
>>> Apache license.
>>>
>>> Looks like it is available in maven central.
>>>
>>> On Fri, Feb 13, 2015 at 12:24 PM Eric Engle <ee...@go...> wrote:
>>>
>>>> I think you'll be happy with EJML, for all of that.  They have a
>>>> high-handed but easy-to-use API, a low-level and tweakable API, and an
>>>> implementation mindset that questions what L2 cache does with each
>>>> algorithm.  It's... significantly faster than some of the alternatives like
>>>> JAMA.
>>>>
>>>> On Sat, Feb 7, 2015 at 9:35 AM, Jody Garnett <jod...@gm...>
>>>> wrote:
>>>>
>>>>> So Eric is the above breakdown useful? Our priorities are are accuracy
>>>>> and speed :)
>>>>>
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> On 4 February 2015 at 19:55, Jody Garnett <jod...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Let me try:
>>>>>>
>>>>>> *gt-metadata: *looks to just be data structure (Point3d and
>>>>>> MismatchedSizeException)
>>>>>>
>>>>>> org.geotools.math.Line
>>>>>> org.geotools.math.Plane
>>>>>>
>>>>>> *gt-referencing: *uses assorted exceptions, extends GMatrix, and
>>>>>> Matrix3d/Matrix4d multiply
>>>>>>
>>>>>> org.geotools.referencing.operation.DefaultCoordinateOperationFactory
>>>>>>
>>>>>> org.geotools.referencing.operation.builder.AdvancedAffineBuilder
>>>>>> org.geotools.referencing.operation.builder.AffineTransformBuilder
>>>>>> org.geotools.referencing.operation.builder.BursaWolfTransformBuilder
>>>>>> - Imports GMatrix but does not use it
>>>>>> org.geotools.referencing.operation.builder.MathTransformBuilder
>>>>>> org.geotools.referencing.operation.builder.ProjectiveTransformBuilder
>>>>>> org.geotools.referencing.operation.builder.RubberSheetBuilder
>>>>>> org.geotools.referencing.operation.builder.SimilarTransformBuilder
>>>>>>
>>>>>> org.geotools.referencing.operation.matrix.GeneralMatrix
>>>>>> - extends GMatrix (this is the key integration point with vecmath)
>>>>>> org.geotools.referencing.operation.matrix.Matrix1.java
>>>>>> org.geotools.referencing.operation.matrix.Matrix2.java
>>>>>> org.geotools.referencing.operation.matrix.Matrix3.java
>>>>>> - uses Matrix3d.multiply
>>>>>> org.geotools.referencing.operation.matrix.Matrix4.java
>>>>>> - uses Matrix4d.multiply
>>>>>> org.geotools.referencing.operation.matrix.XMatrix.java
>>>>>>
>>>>>> org.geotools.referencing.operation.transform.AbstractMathTransform
>>>>>> org.geotools.referencing.operation.transform.ProjectiveTransform
>>>>>>
>>>>>> So it comes down to:
>>>>>>
>>>>>> * Extending GMatrix
>>>>>> * delegating to Matricx3d multiply and Matrix4d.muiltiply
>>>>>>
>>>>>> So we are stuck going through the GMatrix methods and seeing which
>>>>>> ones are called. Going to ignore things like constructors/equals/set/get
>>>>>> (so we can focus on where the math is used)
>>>>>> - GMatrix.add(GMatrix,GMatrix) - used by cglib-nodep-2.1_3.jar (not
>>>>>> sure what this is)
>>>>>> - GMatrix.invert() - called by AdvancedAffineBuilder,
>>>>>> BursaWolfTransformBuilderm ProjectiveTransformBuilder
>>>>>> - GMatrix.mul(GMatrix) called by BursaWolfTransformBuilder,
>>>>>> GeneralMatrix
>>>>>> - GMatrix.mul(GMatrix,GMatrix) called by AdvancedAffineBuilder,
>>>>>> BursaWolfTransformBuilder, ProjectiveTransformBuilder, ConcatenatedTransform
>>>>>> - GMatrix.negate() called by AdvancedAffineBuilder,
>>>>>> BursaWolfTransformBuilder
>>>>>> - GMatrix.sub(GMatrix) called by MathTransformBuilderTest
>>>>>> - GMatrix.sub(GMatrix,GMatrix) called by AdvancedAffineBuilder,
>>>>>> BursaWolfTransformBuilder
>>>>>> - GMatrix.transform() called by AdvancedAffineBuilder,
>>>>>> BursaWolfTransformBuilder, ProjectiveTransformBuilder
>>>>>>
>>>>>>
>>>>>> Not quite sure what to make of that .. looks like multiply, invert,
>>>>>> negate, transform are our actual requirements.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jody Garnett
>>>>>>
>>>>>> On 4 February 2015 at 18:58, Eric Engle <ee...@go...> wrote:
>>>>>>
>>>>>>> I've used almost all of those options at one time or another, but is
>>>>>>> there a synopsis of the vecmath features that are actually used within
>>>>>>> Geotools?
>>>>>>>
>>>>>>> On Wed, Feb 4, 2015 at 1:20 PM, Tyler Battle <
>>>>>>> tb...@bo...> wrote:
>>>>>>>
>>>>>>>> Thanks to Jody, for pointing me at http://docs.codehaus.org/
>>>>>>>> display/GEOTOOLS/Replace+Vecmath
>>>>>>>>
>>>>>>>> Has anyone worked with any of these (or similar) libraries?
>>>>>>>>
>>>>>>>> When I have some free time, I'm going to try some of the drop-in
>>>>>>>> (fingers crossed) replacements. If there isn't a loss in performance, this
>>>>>>>> would be an easy short/medium term solution. Does anyone have any
>>>>>>>> suggestions for testing the performance of these libs?
>>>>>>>>
>>>>>>>> Switching to a more specialized library or rolling our own is also
>>>>>>>> an option. My expertise is very limited in this respect, so I'd need a lot
>>>>>>>> of help if we want to consider this option.
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Tyler Battle
>>>>>>>>
>>>>>>>> Software Engineer| Boundless
>>>>>>>>
>>>>>>>> tb...@bo... <ca...@bo...>
>>>>>>>>
>>>>>>>> Victoria, BC, Canada
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://twitter.com/boundlessgeo>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ------------------
>>>>>>>> Dive into the World of Parallel Programming. The Go Parallel
>>>>>>>> Website,
>>>>>>>> sponsored by Intel and developed in partnership with Slashdot
>>>>>>>> Media, is your
>>>>>>>> hub for all things parallel software development, from weekly
>>>>>>>> thought
>>>>>>>> leadership blogs to news, videos, case studies, tutorials and more.
>>>>>>>> Take a
>>>>>>>> look and join the conversation now. http://goparallel.sourceforge.
>>>>>>>> net/
>>>>>>>> _______________________________________________
>>>>>>>> GeoTools-Devel mailing list
>>>>>>>> Geo...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------
>>>>>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>>>>>> sponsored by Intel and developed in partnership with Slashdot Media,
>>>>>>> is your
>>>>>>> hub for all things parallel software development, from weekly thought
>>>>>>> leadership blogs to news, videos, case studies, tutorials and more.
>>>>>>> Take a
>>>>>>> look and join the conversation now. http://goparallel.sourceforge.
>>>>>>> net/
>>>>>>> _______________________________________________
>>>>>>> GeoTools-Devel mailing list
>>>>>>> Geo...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


-- 

Tyler Battle

Software Engineer| Boundless

tb...@bo... <ca...@bo...>

Victoria, BC, Canada


<https://twitter.com/boundlessgeo>