Two Dimensional Array Template

[Michael DOUBEZ]

Julián Albo a écrit :

What I mean is that a well designed Matrix interface (in legacy code or
C or whatever you think might have used it) would have used a
function/define call and not a direct access to memory in the [][] (snip)
The consensus is not built on what a few people might say but on what is
effectively used in real life.

Interesting point. You say that everyone that uses [ ] [ ] would have used
another way. Then the consensus will not be based in this, because is just
what you say.

It is not saying something it is seeing what the well known libraries
do(blitz,newmat,GSL...). Though I concede after reading Noah Robert's
reply that there are some legacy code issue in the case of representing
2D array (not matrices). I stand corrected in this case.

In essence, all you say is that your position is right because your opinions
are more importants that any other.

?
You puting some intentions behind what I say ?

And the point is not about which syntax can give faster results or about
what is more used in certain libraries, is about not discarding one as
always bad without good reasons to prove such strong claim.

And another point to think about: the [ ] [ ] can not be implemented
directly as a function just because composite operators ("The Design an
Evolution of C++", 11.6.3) were not included in the language because lack
of time to evaluate his real usefulness. Given that in all this years
nothing has provided a solid evidence in favor of the reevaluation of that
feature, we must assume that the proxy classes approach is good enough.

I don't pretend it is not good enough if it is what you want.
"Do what you must" overrides any FAQ or general design.

I don't pretend to see all cases and the FAQ doesn't either (from my
reading and my opinion again).

 

[Michael DOUBEZ]

Gianni Mariani a écrit :

Michael DOUBEZ wrote:
...

If legacy code must be updated, there is a reason for it. Otherwise,
you just let it be.

There had better be a very good reason. Personal preference of (,) over
[][] is decidedly not a good reason.

I don't see the point in saying there is a change to make but one will
take a sub-optimal approach to the required change because there are
other more important change to perform.

Is your claim of being sub-optimal supported in some way ? So far I
have seen only suggestions and no clear proof that the difference (if
any) is something to worry about.

By sub-optimal I don't mean compiler-easy but maintainable, extensible
and understandable. In the Matrix case, not the 2D array case.

I don't believe you. I think there are far more cons using (,).

I don't deal in faith; belief has nothing to do here.
I see a simple approach (,) compared to a confusing cosmetic one [][].

Confusing to whom ? You ? I personally find [][] less confusing.
Again, this is a personal preference, not a well argued position on a
technical basis.

Technicality is not the end and all of design. If I call a function
(matrix) with two parameters [][] is confusing. If I represent a 2D
arrray, it is understandable but I would also expect to be able to use [].

Matrices are not memory areas, they are functions, graphs and other
mathematical concept; the [][] notation is only a engineer artifact.

So ? Who cares. [][] has been the way many matrix types have been
modelled in C and C++ for a long time. I don't see the impetus to
change to (,) and break a chunk of re-usability because of someone's
personal preference.

This is how 2D arrays may be represented.
This is false for matrices.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

What I mean is that a well designed Matrix interface (in legacy code or
C or whatever you think might have used it) would have used a
function/define call and not a direct access to memory in the [][] (snip)
The consensus is not built on what a few people might say but on what is
effectively used in real life.

Interesting point. You say that everyone that uses [ ] [ ] would have
used another way. Then the consensus will not be based in this, because
is just what you say.

It is not saying something it is seeing what the well known libraries
do(blitz,newmat,GSL...). Though I concede after reading Noah Robert's
reply that there are some legacy code issue in the case of representing
2D array (not matrices). I stand corrected in this case.

But the discussion is not against the (,) usage, so the mention of several
libraries that uses it does not prove nothing.

?
You puting some intentions behind what I say ?

Just an inference derived from the lack of good arguments from your part and
the lack of refutations of other people arguments.

I don't pretend to see all cases and the FAQ doesn't either (from my
reading and my opinion again).

Quoting FAQ again: "[13.10] How do I create a subscript operator for a
Matrix class? - Use operator() rather than operator[]."

 

[Noah Roberts]

Quoting FAQ again: "[13.10] How do I create a subscript operator for a
Matrix class? - Use operator() rather than operator[]."

If you insist on being operator happy why **** around...do it all the
way

http://tinyurl.com/yzptkn

There's your standard syntax.

 

[Gianni Mariani]

Quoting FAQ again: "[13.10] How do I create a subscript operator for a
Matrix class? - Use operator() rather than operator[]."

If you insist on being operator happy why **** around...do it all the
way

http://tinyurl.com/yzptkn

There's your standard syntax.

I suppose you think that was a joke but I'll take it seriously.

[][] is better than [,] because is mimics the syntax of an array of
array and so from a generic programming perspective is ideal.

So, if you gave me (,) vs [,] I would not care either way because there
really is no benefit to "[" or "]" in this case. However [][] does !

 

[Gianni Mariani]

Gianni Mariani a écrit :

Michael DOUBEZ wrote:
...

If legacy code must be updated, there is a reason for it. Otherwise,
you just let it be.

There had better be a very good reason. Personal preference of (,)
over [][] is decidedly not a good reason.

I don't see the point in saying there is a change to make but one
will take a sub-optimal approach to the required change because there
are other more important change to perform.

Is your claim of being sub-optimal supported in some way ? So far I
have seen only suggestions and no clear proof that the difference (if
any) is something to worry about.

By sub-optimal I don't mean compiler-easy but maintainable, extensible
and understandable. In the Matrix case, not the 2D array case.

[][] is far more extensible and reusable than (,) (because of the
generic programming argument).

I don't believe you. I think there are far more cons using (,).

I don't deal in faith; belief has nothing to do here.
I see a simple approach (,) compared to a confusing cosmetic one [][].

Confusing to whom ? You ? I personally find [][] less confusing.
Again, this is a personal preference, not a well argued position on a
technical basis.

Technicality is not the end and all of design. If I call a function
(matrix) with two parameters [][] is confusing. If I represent a 2D
arrray, it is understandable but I would also expect to be able to use [].

There is nothing in that paragraph that is anything but personal
preference. Just because you prefer somthing (because it is less
confusing to you) does not make it less confusing to someone else.

Also, there is nothing stopping you from using just the first [] of [][]
for decomposing a matrix.

Matrices are not memory areas, they are functions, graphs and other
mathematical concept; the [][] notation is only a engineer artifact.

So ? Who cares. [][] has been the way many matrix types have been
modelled in C and C++ for a long time. I don't see the impetus to
change to (,) and break a chunk of re-usability because of someone's
personal preference.

This is how 2D arrays may be represented.
This is false for matrices.

Why is it false? A 2D matrix is exactly an array of arrays. Many
linear algebra problems I remember to be based on decomposing or
recomposing a matrix from vectors.

I make modelled a matrix like:

float matrix[4][4];

many times. I have never had a problem with that model.

 

[Michael DOUBEZ]

Julián Albo a écrit :

What I mean is that a well designed Matrix interface (in legacy code or
C or whatever you think might have used it) would have used a
function/define call and not a direct access to memory in the [][]
(snip)
The consensus is not built on what a few people might say but on what is
effectively used in real life.
Interesting point. You say that everyone that uses [ ] [ ] would have
used another way. Then the consensus will not be based in this, because
is just what you say.

It is not saying something it is seeing what the well known libraries
do(blitz,newmat,GSL...). Though I concede after reading Noah Robert's
reply that there are some legacy code issue in the case of representing
2D array (not matrices). I stand corrected in this case.

But the discussion is not against the (,) usage, so the mention of several
libraries that uses it does not prove nothing.

?
You puting some intentions behind what I say ?

Just an inference derived from the lack of good arguments from your part and
the lack of refutations of other people arguments.

I think I have been clear concerning your arguments (_considering we
speak of Matrix, not 2D array_):
Pros [][]
* very fast/simple
If you use array of array (ie limit yourself to dense representation)
and proxy classes fall in the general case.
In all cases, (,) is just as fast/simple.

* uses the native/standard/general interface
2D arrays are not matrices and long standing Matrix libraries don't use
[][] for the very good reason it is not practical for general purpose.
(see Blitz, GSL, newmat ...)

* The rule is that [][] is far more common than (,) for writing
matrix code.
This is false except in the internal of the library, for dense matrices
and in local implementation. Here we speak of best practice thus general
design.

Cons (,)
* learning curve cost
Since matrices have always been addressed through (,), there is no
learning cost.

* backwards compatibility/legacy code
Same as previous for backward compatibility.
Even if a legacy code uses [][], switching to (,) seems not a big deal
to me (or otherwise a necessary step). But I can understand it can be.

It would be basing a general design on supporting legacy code (uness it
is a requierement).

* typing error rate
Same as "learning curve". And compilers are good at finding typping
error. If this is really an issue, declaring operator[] private could help.

Misc
* [][] syntax is directly equivalent to the (,) syntax
At the cost of an intermediary object hopefully optimized out (expected
to be now or in the future).
This means maintaining an additional object and if not (generic
intermediary object), [][] is only a wrapping around (,).

Making an abstract class accessing elements with [][] is far from trivial.

- this is a question about syntax preference ; [][] is just as
expressive as (,)
In truth, this may be misleading, making believe the underlying
data is a dense matrice.
And it is not expressive for people of the field (i.e. mathlab, ...)

- Both (,) and [][] can be implemented
In order to keep the interface minimal, there can be only one.
Choosing [][] is really taking the difficult and risky path.

- FAQ is misleading.
The FAQ speak about matrices, not array and I think this is the root of
all this mess. Thanks to Noah Roberts for pointing this to me.

Now, if the goal is to implement a 2D (or even a xD) array. The use of
[][] is legitimate from my point of view. But arrays *are not* matrices.

I don't pretend to see all cases and the FAQ doesn't either (from my
reading and my opinion again).

Quoting FAQ again: "[13.10] How do I create a subscript operator for a
Matrix class? - Use operator() rather than operator[]."

Yes but the FAQ is not a valid answer to the original post which
concerns only 2D array..

Peter Olcott asked.

I think that the operator[]() member function does not work correctly, does
anyone else know how to make a template for making two dimensional arrays from
std::vectors ??? I want to use normal Array[ROW][COL] Syntax.

 

[Michael DOUBEZ]

Gianni Mariani a écrit :

Michael DOUBEZ wrote:
> [snip]

By sub-optimal I don't mean compiler-easy but maintainable, extensible
and understandable. In the Matrix case, not the 2D array case.

[][] is far more extensible and reusable than (,) (because of the
generic programming argument).

Let's say you need an abstraction of the matrix.
It is easy to declare operator() virtual.

In the [][] case you have the following solutions I see:
1. declare virtual operator[] returning a refernce to the Array
which is himself .
virtual Array& operator[](size_t i);
class Array { virtual Array& operator[](size_t j); };
2. implement protected operator()-like solution and use this
reference in Array (i.e. wrapping)
3. Use [][] in template class and give it up in abstact class to the
profit of virtual call (i.e. implementing both interfaces).

The only extensibility I recognize to [][] is the possibility to have
any number of dimension you want.

I don't believe you. I think there are far more cons using (,).

I don't deal in faith; belief has nothing to do here.
I see a simple approach (,) compared to a confusing cosmetic one [][].

Confusing to whom ? You ? I personally find [][] less confusing.
Again, this is a personal preference, not a well argued position on a
technical basis.

Technicality is not the end and all of design. If I call a function
(matrix) with two parameters [][] is confusing. If I represent a 2D
arrray, it is understandable but I would also expect to be able to use
[].

There is nothing in that paragraph that is anything but personal
preference. Just because you prefer somthing (because it is less
confusing to you) does not make it less confusing to someone else.

It is confusing because [][] is a container layout, not a functionnal
layout. [][] makes sense if I consider may matrix as a container.

Also, there is nothing stopping you from using just the first [] of [][]
for decomposing a matrix.

Matrices are not memory areas, they are functions, graphs and other
mathematical concept; the [][] notation is only a engineer artifact.

So ? Who cares. [][] has been the way many matrix types have been
modelled in C and C++ for a long time. I don't see the impetus to
change to (,) and break a chunk of re-usability because of someone's
personal preference.

This is how 2D arrays may be represented.
This is false for matrices.

Why is it false? A 2D matrix is exactly an array of arrays. Many
linear algebra problems I remember to be based on decomposing or
recomposing a matrix from vectors.

I make modelled a matrix like:

float matrix[4][4];

many times. I have never had a problem with that model.

Replace 4 by 10000 and float by double then you have a problem.
T matrix[N][M] is not a general design of matrix though is is a
potential representation.
The only time I had to use a dense matrix this big, I had to map memory
in a file using OS dependant features; clearly not a general design.

I used float DiagMatrix[1000] for a diagonal matrix and I never had any
problem (using appropriate access function).
I also used float TriMatrix[(N+1)*N/2]; for triangular square matrix
without problem either.

That doesn't make them matrices.

 

[Noah Roberts]

Michael DOUBEZ wrote:

By sub-optimal I don't mean compiler-easy but maintainable, extensible
and understandable. In the Matrix case, not the 2D array case.

[][] is far more extensible and reusable than (,) (because of the
generic programming argument).

That's nothing but an unfounded assertion. Show it to be true.

Confusing to whom ? You ? I personally find [][] less confusing.
Again, this is a personal preference, not a well argued position on a
technical basis.

Technicality is not the end and all of design. If I call a function
(matrix) with two parameters [][] is confusing. If I represent a 2D
arrray, it is understandable but I would also expect to be able to use [].

There is nothing in that paragraph that is anything but personal
preference. Just because you prefer somthing (because it is less
confusing to you) does not make it less confusing to someone else.

As I recall, you're the one that originally brought this issue up
saying that [][] is less confusing because that is how arrays work in
C++.

Actually what Michael is bringing up is very important. Keeping code
in line with the domain of the problem it is answering is an important
issue when wishing that code to be readable and maintainable. See
Spirit and the MPL book. When code matches the domain it also matches
the requirements documentation. In cases involving matrices this also
applies to the equations involved. It isn't just a matter of
preference then but a matter of practice and discipline.

This is how 2D arrays may be represented.
This is false for matrices.

Why is it false? A 2D matrix is exactly an array of arrays. Many
linear algebra problems I remember to be based on decomposing or
recomposing a matrix from vectors.

I make modelled a matrix like:

float matrix[4][4];

many times. I have never had a problem with that model.

Well then, I guess since you've always found that model adiquate it
invariably must always be so for everyone.

At any rate, since, as you say, you've never had a problem with that
model then you have no reason to create a matrix class....no reason at
all.

 

[Daniel T.]

I have seen nothing in the FAQ that says "that the only reason someone
would have for wanting []s in the interface is to say '[j]' instead
of '(i, j)'"

The assumption is not explicit, but it is there. It's not hard to see.

I don't see it. What I see is an attempt to help those people who
routinely come into this group asking how to overload [][] for their
two-dimensional array so they can access individual elements. As the FAQ
says, you can't do it without either (a) writing a class that locks you
into a particular implementation [FAQ 13.11] or (b) writing proxy
classes that refer back to a more appropriate interface that must also
exist in the primary class. [FAQ 13.12].

 

[Noah Roberts]

It is confusing because [][] is a container layout, not a functionnal
layout. [][] makes sense if I consider may matrix as a container.

I think this whole issue boils down to that question. What is a
matrix? Gianni obviously views a matrix as a subtype of array. To
find out if he is correct we can ask two questions (via the Liskov
Substitution Principle [1]):

Does the matrix concept require preconditions that the array concept
does not?

Does the array concept have post conditions that are not met by the
matrix concept?

If the answer to both of these questions is, "No," then there is
nothing inherently incorrect with viewing a matrix as a subtype of
array and thus no reason, beyond such things as simplicity or
expressiveness (which are too objective to quantify), to discount the
[][] as a viable design.

I think if we are talking about vector< vector<> > as the array type
then indeed the matrix concept has preconditions that are not met by
that concept....the columns and rows in a matrix must be the same size
as other columns or rows. A matrix also does not meet the
post-conditions of a vector of vectors since if you resize one vector
the rest must not change. So a matrix and a vector of vectors are not
related concepts (a vector of vectors also is not a matrix for similar
reasons).

If we narrow the discussion down to array types that contain arrays
that are of equal length then maybe things are different.

The question I have though...if a matrix is an array of arrays, is it
an array of rows or an array of columns? If it is both then IMHO that
it a precondition of array that is not met by matrix and so matrix
cannot be a subtype of array...since array can only be one. I think
this is in fact the case since returning row vs. column from [] has
come up several times.

Second, removing the previous assumption, since C++ allows arrays of
arrays to be several things, including arrays of arrays of different
sizes (vectors of vectors or arrays of pointers to arrays), the concept
of matrix has yet another precondition that is not required by the
array of array concept.

Assuming the above, a matrix is not an array of arrays but is a
different concept entirely. This means that treating it as such is not
optimal in view of "correct" design - design governed by certain
principles that have shown to be valid and highly useful in evaluating
designs.

Gianni also brought up the fact that you can decompose a matrix into
vectors. Vectors seem to be equivelant to arrays and I can't think of
any reason why they couldn't be treated as such - if you resize it then
the matrix could no longer accept it... I don't think this means that
a matrix is simply an array of equal sized vectors though since it can
be decomposed into both vertical and horizontal vectors. I also don't
think the fact that an concept can be decomposed into a set of objects
means that the original should be considered "a set of objects". It
may be that it makes sense in some cases, but not all. Such an
argument boils down to P->Q...Q is true so P must be too....which is
not valid.

1 - http://en.wikipedia.org/wiki/Liskov_Substitution_Principle

 

[Peter Olcott]

http://groups.google.com/group/comp.lang.c++/msg/a9092f0f6c9bf13a

I think that the operator[]() member function does not work
correctly, does anyone else know how to make a template for making
two dimensional arrays from std::vectors ?
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.10

I want to use normal Array[ROW][COL] Syntax.

Why?

You win !!! I switched to operator() for my matrix implementation because it
has greater flexibility in specifying the physical layout. I tried and tried to
get the same thing from operator[], and it does not seem to be possible without
performance hits of one kind or another. Thanks again for your excellent advice.