commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
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 
> 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.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 
>>>> 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 "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
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message