I would introduce getArrayRef(), which makes clear what exactly happen.
It is after all the same like spares/dense discussion ...
Arne
Am Mittwoch, den 07.09.2011, 08:11 +0200 schrieb Sébastien Brisard:
> In fact, getArrayRef does not belong to the RealVector class. It is
> only defined in Array
Le 07/09/2011 08:27, Sébastien Brisard a écrit :
True enough.
Maybe the use of one those two could be strongly discouraged.
I personally was puzzled the first time I saw those two methods. I was
even wondering wether one of them would not return a shallow copy
(when possible), while the other wou
True enough.
Maybe the use of one those two could be strongly discouraged.
I personally was puzzled the first time I saw those two methods. I was
even wondering wether one of them would not return a shallow copy
(when possible), while the other would return a deep copy. Had to look
at the source to
2011/9/7 Sébastien Brisard :
> Hi,
> as noted in MATH-653, these two methods are redundant, and one should
> go. Pros and cons are
> * toArray() is fairly classical in the Java world
> * but getData() is consistent with ArrayRealVector.getDataRef().
> Personnaly, my preference goes to keeping toArr
In fact, getArrayRef does not belong to the RealVector class. It is
only defined in ArrayRealVector (which is backed by a double[]).
Sébastien
2011/9/7 Arne Ploese :
> If toArray() returns always a copy and if getArrayRef() throws an
> exception if there is no backing array, it would be much clear
If toArray() returns always a copy and if getArrayRef() throws an
exception if there is no backing array, it would be much clearer. A
property isArray() is needed in this case.
Arne
Am Mittwoch, den 07.09.2011, 04:19 +0200 schrieb Sébastien Brisard:
> Hi,
> as noted in MATH-653, these two method
