[math] Proposed resolution for MATH-1284

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[math] Proposed resolution for MATH-1284

Raymond DeCampo
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
Reply | Threaded
Open this post in threaded view
|

Re: [math] Proposed resolution for MATH-1284

Matt Sicker
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 <[hidden email]> 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [math] Proposed resolution for MATH-1284

Raymond DeCampo
On Sun, May 7, 2017 at 5:22 PM, Matt Sicker <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [math] Proposed resolution for MATH-1284

Matt Sicker
Oh, nevermind then. :)

On 8 May 2017 at 09:21, Raymond DeCampo <[hidden email]> wrote:

> On Sun, May 7, 2017 at 5:22 PM, Matt Sicker <[hidden email]> 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 <[hidden email]>