You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Raymond DeCampo <ra...@decampo.org> on 2017/05/07 12:26:43 UTC

[math] Proposed resolution for MATH-1284

I have prepared a resolution for issue MATH-1284 (
https://issues.apache.org/jira/browse/MATH-1284) in the feature-MATH-1284
branch.

I'd appreciate a review by any interested parties.  I am particularly
concerned to know if the changes represent to much of an API change, even
given the target is 4.0.  Boring details about the reasoning behind the
approach follow.

I originally started out intending to keep the Vector?D classes pretty much
as-is, dropping the implementation of the Point interface and introducing
concrete Point?D classes.  In the process of implementing this I learned
that the existing code switches between using Vector?D as a Vector and a
Point fairly frequently.  I started by adding conversion methods but I felt
this introduced potential inefficiencies.

So I decided to try a different approach.  Leveraging the fact that a point
and a vector in finite dimensional Euclidean space can both be represented
by n-tuples, I created a class for the n-tuples, Cartesian?D (h/t Gilles
for the name) which can represent a vector or a point.

This approach was much more easily propagated to the remainder of the code
and in many places allowed the removal of casts.  I also kept the Vector?D
classes as an intermediary abstract class in the hope of reducing the
burden on a user upgrading from 3.x.

Thanks,
Ray

Re: [math] Proposed resolution for MATH-1284

Posted by Matt Sicker <bo...@gmail.com>.
Oh, nevermind then. :)

On 8 May 2017 at 09:21, Raymond DeCampo <ra...@decampo.org> wrote:

> On Sun, May 7, 2017 at 5:22 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> > I find using "tuples" here confusing since a tuple can have multiple
> types,
> > while a vector or point are all the same type (given the space it's in,
> so
> > reals -> doubles for example).
> >
> >
> There is no mention of tuples in the code, only in my explanation of the
> code on the ML.
>



-- 
Matt Sicker <bo...@gmail.com>

Re: [math] Proposed resolution for MATH-1284

Posted by Raymond DeCampo <ra...@decampo.org>.
On Sun, May 7, 2017 at 5:22 PM, Matt Sicker <bo...@gmail.com> wrote:

> I find using "tuples" here confusing since a tuple can have multiple types,
> while a vector or point are all the same type (given the space it's in, so
> reals -> doubles for example).
>
>
There is no mention of tuples in the code, only in my explanation of the
code on the ML.

Re: [math] Proposed resolution for MATH-1284

Posted by Matt Sicker <bo...@gmail.com>.
I find using "tuples" here confusing since a tuple can have multiple types,
while a vector or point are all the same type (given the space it's in, so
reals -> doubles for example).

On 7 May 2017 at 07:26, Raymond DeCampo <ra...@decampo.org> wrote:

> I have prepared a resolution for issue MATH-1284 (
> https://issues.apache.org/jira/browse/MATH-1284) in the feature-MATH-1284
> branch.
>
> I'd appreciate a review by any interested parties.  I am particularly
> concerned to know if the changes represent to much of an API change, even
> given the target is 4.0.  Boring details about the reasoning behind the
> approach follow.
>
> I originally started out intending to keep the Vector?D classes pretty much
> as-is, dropping the implementation of the Point interface and introducing
> concrete Point?D classes.  In the process of implementing this I learned
> that the existing code switches between using Vector?D as a Vector and a
> Point fairly frequently.  I started by adding conversion methods but I felt
> this introduced potential inefficiencies.
>
> So I decided to try a different approach.  Leveraging the fact that a point
> and a vector in finite dimensional Euclidean space can both be represented
> by n-tuples, I created a class for the n-tuples, Cartesian?D (h/t Gilles
> for the name) which can represent a vector or a point.
>
> This approach was much more easily propagated to the remainder of the code
> and in many places allowed the removal of casts.  I also kept the Vector?D
> classes as an intermediary abstract class in the hope of reducing the
> burden on a user upgrading from 3.x.
>
> Thanks,
> Ray
>



-- 
Matt Sicker <bo...@gmail.com>