commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (MATH-653) Rename "AbstractRealVector" to "RealVector"
Date Fri, 26 Aug 2011 22:25:29 GMT

    [ https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092083#comment-13092083
] 

Gilles edited comment on MATH-653 at 8/26/11 10:23 PM:
-------------------------------------------------------

>From S├ębastien, on the "dev" ML (in the thread with subject "RealMatrix.set(double)"):
{quote}
I personnaly have come to dislike the schizophrenia in the RealVector
interface between double[] and RealVector. As double[] is the simplest
representation of a vector, all methods which take a RealVector as an
argument in the RealVector interface are duplicated to also take a
double[] as an argument. While this is very flexible for end-users, it
is a bit of a pain when you want to extend this interface in a
consistent way (and it also make the classes implementing RealVector
quite cluttered). I'm just wondering what the real benefit is, since
the existing hierarchy allows (at virtually no cost) the creation of a
RealArrayVector from a double[] without taking first a (costly) deep
copy of the specified double[].
For example, for an end-user, it's not much of a hassle to write
v.add(new ArrayRealVector(w, false))
instead of v.add(w)
w being a double[].
{quote}

I agree.
Also for the reason that in "AbstractRealVector" many of the methods taking a "double[]" argument
actually delegate to the sibling method that taking an "ArrayRealVector" argument, which looks
fairly strange (a superclass relying on one of its subclasses). Even stranger, some methods
of the "RealVector" interface are not defined in "AbstractRealVector" e.g.
{code}
RealVector ebeDivide(RealVector)
{code}
although its equivalent with a "double[]" is defined and seems to call the non-existent one
above!
Of course, it works thanks to polymorphism and the fact that "AbstractRealVector" can never
be instantiated; however it makes the code quite unobvious.

Hence, I'd like to remove all the methods that take a "double[]" argument as part of this
issue.
Is there any objection?


      was (Author: erans):
    From S├ębastien, on the "dev" ML (in the thread with subject "RealMatrix.set(double)"):
{quote}
I personnaly have come to dislike the schizophrenia in the RealVector
interface between double[] and RealVector. As double[] is the simplest
representation of a vector, all methods which take a RealVector as an
argument in the RealVector interface are duplicated to also take a
double[] as an argument. While this is very flexible for end-users, it
is a bit of a pain when you want to extend this interface in a
consistent way (and it also make the classes implementing RealVector
quite cluttered). I'm just wondering what the real benefit is, since
the existing hierarchy allows (at virtually no cost) the creation of a
RealArrayVector from a double[] without taking first a (costly) deep
copy of the specified double[].
For example, for an end-user, it's not much of a hassle to write
v.add(new ArrayRealVector(w, false))
instead of v.add(w)
w being a double[].
{quote}

I agree.
Also because in "AbstractRealVector" many of the method that take a "double[]" argument actually
delegate to the sibling method that take an "ArrayRealVector" argument, which looks fairly
strange (a superclass relying on one of its subclasses). Even stranger, some methods of the
"RealVector" interface are not defined in "AbstractRealVector" e.g.
{code}
RealVector ebeDivide(RealVector)
{code}
although its equivalent with a "double[]" is defined and seems to call the non-existent one
above!
Of course, it works because of polymorphism and the fact that "AbstractRealVector" can never
be instantiated, but it makes the code quite unobvious.

Hence, I'd like to remove all the method that take a "double[]" argument as part of this issue.
Is there any objections?

  
> Rename "AbstractRealVector" to "RealVector"
> -------------------------------------------
>
>                 Key: MATH-653
>                 URL: https://issues.apache.org/jira/browse/MATH-653
>             Project: Commons Math
>          Issue Type: Task
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Trivial
>             Fix For: 3.0
>
>
> "AbstractRealVector" is the only implementation of the "RealVector" interface.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message