 "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> Phil Steitz wrote:
>
> > Mark R. Diggory wrote:
> >
> >> I can give a couple other examples of matrices in java using 0 to n1.
> >>
> >> Colt:
> >> http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/DoubleMatrix2D.html
> >>
> >>> A matrix has a number of rows and columns, which are assigned upon
> >>> instance construction  The matrix's size is then rows()*columns().
> >>> Elements are accessed via [row,column] coordinates. Legal coordinates
> >>> range from [0,0] to [rows()1,columns()1]. Any attempt to access an
> >>> element at a coordinate column<0  column>=columns()  row<0

> >>> row>=rows() will throw an IndexOutOfBoundsException.
> >>
> >>
> >>
> >> Ninja:
> >>
> >>> 0 <= index[i] < size(i)
> >>
> >>
> >>
> >> Most importantly, the JSR 83 for Multiarray is indexed in this manner:
> >>
> >> JSR 83:
> >> http://jcp.org/en/jsr/detail?id=83
> >>
> >>> Elements of a multiarray are identified by their indices along each
> >>> axis. Let a ddimensional array A of elemental type T have extent nj
> >>> along its jth axis, j = 0,...,d1. Then, a valid index ij along the
> >>> jth axis must be greater than or equal to zero and less than nj. An
> >>> attempt to reference an element A[i0,i1,...,id1] with any invalid
> >>> index ij causes an ArrayIndexOutOfBoundsException to be thrown.
> >>
> >>
> >>
> >> I would agree with Kim because I feel that the implementation language
> >> should dictate the indexing strategy, not mathematical notation. It
> >> makes integrating the package other API's more consistent and easier for
> >> the user to implement.
> >
> >
> > I disagree, precisely for the reason that a matrix is NOT a MultiArray.
>
> True, its an interface which may one day exist on a multiarray
> implementation.
>
> > I also disagree strongly that implementation details should determine
> > API definition.
>
> This is a grey area for me because I do agree with your point about
> Interfaces/Implementations, but, this is a java Interface in a java
> environment, where users are encouraged to reference arrays using 0 <= i
> < n, So I guess from my perspective, its an issue that is actually
> outside the whole Interface/Implementation subject.
>
> > The fact that Colt, Jama, and JADE all use 0based
> > indexing is troubling, however. I would prefer to stick to the standard
> > math notation, but if other [math] committers feel strongly about this,
> > I could be talked into making this change. Since it is an interface
> > change, this would need to be done before 1.0. I was about to close the
> > 1.0RC1 vote and send an annnouncment. I will hold off until I hear
> > others weigh in on this.
> >
> > Phil
> >
>
> True, Lets give it a little room for discussion, will others in the
> group please verbalize their opinion on this issue?
My personal preference would originally have been to use 1based indexing
(actually, I really prefer Fortran's ability to let the user define the lower
bound index value in each array dimension if they so choose, even though that
facility is not that often used), but that was based on my assumption that
commonsmath is a library for enabling people who know some math to more easily
do math in Java. However, the few use cases we've heard about seem to be split
between that kind of user and Java programmers who have some need for math
capabilities. The former class of user would more likely want/expect 1based
indexing, the latter would expect 0based indexing. Quoting from our own home
page:
"Guiding principles:
1. Realworld application use cases will determine development priority.
...
4. In situations where multiple standard algorithms exist, a Strategy pattern
will be used to support multiple implementations."
Unfortunately, nowhere in our charter do I know of a statement that would help
us decide the priority between the two classes of users I described above (I
would be happy if someone pointed out some passage of our charter that I don't
know about that would resolve this decision).
I think ideally we would provide facilities to handle both 0 and 1based
indexing (and even arbitrary lowerboundbased indexing, given that I'm
pipedreaming here).
The _Numerical Recipes_ solution to this problem is to stick to 1based
indexing throughout, as all algorithms are described in standard mathematical
notation where the first index in each dimension is 1 (probably also because it
made for easier [possibly at least partially automated] translation from the
original 1based Fortran source code into other languages). For 0based
languages (viz., C and presumably C++) they provided array data types that
automatically translated between the mathematical 1based notation and the
underlying 0based array data structure, at the expense of having one extra
element in each dimension of each array, I believe. Perhaps we could do
something similar and even provide a user setting that would choose between
0based and 1based behavior  probably a global setting, to prevent the kind
of confusion that would result from mixing the two representations
unintentionally.
Al
> thnx,
> Mark
>
> >>
> >> Mark
> >>
> >> Kim van der Linde wrote:
> >>
> >>> Hi Phil,
> >>>
> >>> With the 1 base system, I keep casting back and forth between the 0
> >>> based underlying java system and the 1 based matrix system. But only
> >>> in selected cases, not as a general rule. It also requires me to make
> >>> specific methods just to increase the row number by one, as the
> >>> method returns them at the 0 based system. This happens always as
> >>> soon as you use a matrix or array by itsself and with matrcies
> >>> combined, as I do. The fact that java uses the "0based" notation
> >>> anyways conflicts with the mathematical notation.... Why not stay
> >>> with that....???
> >>>
> >>> As most methods in the RealMatrixImpl return a RealMatrix and NOT a
> >>> RealMatrixImpl, the methods need to be in the RealMAtrix itself also.
> >>> There is no option to create a RealMatrixImpl directly from a
> >>> RealMatrix, and requires casting around with new
> >>> RealMatrixImpl(RealMAtrix.getArray()); MatrixUtil depends on how...
> >>> But results in a lot of cating around also unless implemented as
> >>> static's....
> >>>
> >>> Kim
> >>>
> >>> Phil Steitz wrote:
> >>>
> >>>> I need to understand better exactly what the problem is with the
> >>>> indexing. I don't see anything wrong with the current
> >>>> implementation. The element accessor methods use standard matrix
> >>>> notation, which starts with index = 1 in each case. The methods
> >>>> that provide access to copies of the underlying double[][] arrays
> >>>> are for efficiency and return arrays which are correctly sized to
> >>>> hold the matrix data. I would be 1 to changing the matrix accessor
> >>>> methods (getEntry, setEntry, getRow, getColumn) to be "0based" as
> >>>> this conflicts with standard mathematical notation.
> >>>>
> >>>> I am OK with adding the additional methods above to (post 1.0)
> >>>> RealMatrixImpl or a MatrixUtils class.
> >>>>
> >>>> Phil

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
