# commons-dev mailing list archives

##### Site index · List index
Message view
Top
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [MATH] Matrix indices
Date Sat, 28 Aug 2004 15:09:56 GMT
```

Phil Steitz wrote:

> Mark R. Diggory wrote:
>
>> I can give a couple other examples of matrices in java using 0 to n-1.
>>
>> 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 d-dimensional array A of elemental type T have extent nj
>>> along its j-th axis, j = 0,...,d-1. Then, a valid index ij along the
>>> j-th axis must be greater than or equal to zero and less than nj. An
>>> attempt to reference an element A[i0,i1,...,id-1] 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 0-based
> indexing is troubling, however.  I would prefer to stick to the standard
> 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.0-RC1 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?

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 "0-based" 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
>>>> 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 "0-based" 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, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>  For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org