Hello,
It's entirely possible that the OSGi headers are incorrect. I've created a new
issue (GEOMETRY-116 [1]) for it. We can continue that part of this discussion
there.
The "internal" package in commons-geometry-core is intended to be internal from
the standpoint of the library. Classes under this package (and "internal"
packages in other modules) are not considered part of the public API and are
not guaranteed to be binary compatible with previous releases. From a practical
standpoint, however, these packages do need to be exported and available for
use by the other modules in the library.
In regard to the new method you mentioned, I am hesitant to add that to the
API. The main reason is that there are a large number of possible ways to
represent 2D vectors as arrays. For example, the xy components could be in two
parallel arrays (as in your example), a single array with interleaved xy
components (eg, [x1,y1,x2,y2,...]), a multidimensional array (eg,
[[x1,y1],[x2,y2]...]), etc. Adding this method could open up a can of worms as
to which formats are accepted by the API. It would keep the API cleaner by
leaving this functionality to consuming applications. You could, for example,
use AffineTransformMatrix2D as-is for matrix creation and manipulation and
create a utility method in your application that performs the required
transformations using the target format.
public static void applyTransform(AffineTransformMatrix2D m, double[] x,
double[] y) {
// input checking, etc
double[] mArr = m.toArray();
for (int i = 0; i < x.length; ++i {
x[i] = LinearCombination.value(mArr[0], x[i], mArr[1], y[i]) + mArr[2];
y[i] = LinearCombination.value(mArr[3], x[i], mArr[4], y[i]) + mArr[5];
}
}
I would also be interested in seeing if there is an actual performance
improvement when skipping the Vector2D instantiations. In my experience,
optimizations such as this sometimes don't really make a difference.
Regards,
Matt J
[1] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-116
From: Christoph Läubrich
Sent: Sunday, March 21, 2021 8:40 AM
To: user@commons.apache.org
Subject: Re: [math] 2D Line getOffset and natural orientation
Hi Matt,
just some feedback on the AffineTransformMatrix2D in general I think it
would be good to have methods that accept a plain array. for example I
have an array of x and y values and like to transform them.
Currently I need to first construct a Vector of each x/y pair, then
apply the transform (what create another Vector), and copy the data back
to the array.
so a method apply [double[] x, double[] y) that simply performs the
transform in-place would prevent a lot of instantiation overhead.
Am 20.03.21 um 13:25 schrieb Matt Juntunen:
> It's available on maven central [1]. You can find the code on the Apache git
> repo [2] or on Github [3]. The user guide [4] gives an overview of the
> library along with code examples so you can get a feel for how it works.
> Don't hesitate to ask if you have any questions.
>
> -Matt
>
>
> [1]
> https://mvnrepository.com/artifact/org.apache.commons/commons-geometry-euclidean
> [2] https://gitbox.apache.org/repos/asf?p=commons-geometry.git
> [3] https://github.com/apache/commons-geometry
> [4] https://commons.apache.org/proper/commons-geometry/userguide/index.html
>
>
>
> From: Patrik Karlström
> Sent: Saturday, March 20, 2021 4:30 AM
> To: Commons Users List
> Subject: Re: [math] 2D Line getOffset and natural orientation
>
> Thanks for the clarification, I would be happy to try out beta1 of
> commons-geometry, is there a staging repo for it?
>
> /Patrik
>
> Den fre 19 mars 2021 kl 00:29 skrev Matt Juntunen > :
>
>> Hello.
>>
>> I agree that the docs are not really clear on the "natural orientation"
>> part there. Basically, the possible results are as follows:
>>
>>* positive - The argument lies on the right side of the calling line,
>> with the "right side" defined as the side on the right when looking along
>> the calling line in its defined direction. (This is what I believe is meant
>> by "natural orientation".)
>>* negative - The argument lies on the left side of the calling line.
>>* zero - The lines have points in common, meaning they intersect or
>> are coincident.
>>
>> On a side note, if you're writing geometric code, I would suggest trying
>> out the new(-ish) commons-geometry library [1]. It is a rewrite and
>> extension of the commons-math geometry code and, IMHO, the API is more
>> user-friendly. (Disclaimer: I wrote the majority of it so I am completely
>> biased 🙂
>>
>> Regards,
>> Matt J
>>
>> [1] https://commons.apache.org/proper/commons-geometry/
>> [https://avatars.githubusercontent.com/u/47359?s=400&v=4]<
>> https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/Line.java#L370
>>>
>> apache
