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 |
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]> |
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. |
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]> |
Free forum by Nabble | Edit this page |