Two Dimensional Array Template

[Gianni Mariani]

Making this kind of surgery for a personal preference of (,) over [][]
is IMHO not a good enough reason.

Could you please stop saying "IMHO"? The H is silent.

I am not rigid, I will change...

 

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

A new abstraction is required because it is being created. The reason
for change exists. The question is if you want to continue
compatability with an abstraction that obviously isn't enough anymore
or do you want to do some minor editing and try for something a bit
better?

I don't think that the sintax change in question is a switch to another type
of abstraction. And the "a bit better" part is not a fact, is precisely
what you are supposedly trying to demonstrate.

 

[Daniel T.]

Daniel T. wrote:
...

What you successfully demonstrated, regardless of your intention, was
that in order for a class that uses [][] syntax to be as flexable as a
class that uses (,), the former must convert the [][] into (,).

I didn't demonstrate that you "must" do anything. How could you
possibly come to that conclusion ?

What I did demonstrate is that the technical arguments made for the use
of (,) over [][] are false and that using (,) over [][] is a simple
personal preference and there are good, not compelling but good reasons
to stick to [][].

[from the faq]

Here's what this FAQ is really all about: Some people build a
Matrix class that has an operator[] that returns a reference to
an Array object (or perhaps to a raw array, shudder), and that
Array object has an operator[] that returns an element of the
Matrix (e.g., a reference to a double). Thus they access
elements of the matrix using syntax like m[j] rather than
syntax like m(i,j).

The above is what I think we have both lost sight of. Peter initially
posted code that did exactly what the above paragraph talks about and I
agreed with the FAQ about the inappropriateness of it. When I asked you
to present an appropriate example that uses the [][] syntax, you
proceeded to present one that is specifically marked as acceptable by
the FAQ.

It is important to note that the FAQ is not comparing two syntaxes, but
two implementations. On the one hand having an op[] that returns a
reference to an array object or a raw array (something I think we can
both agree is a bad idea,) on the other hand not doing so.

 

[Noah Roberts]

I don't think that the sintax change in question is a switch to another type
of abstraction. And the "a bit better" part is not a fact, is precisely
what you are supposedly trying to demonstrate.

I'm not talking about the syntax change being a switch to another type
of abstraction. I'm talking about the need for the new abstraction
being created. What is the reason behind needing this 2d array
"class"?

The problem is that "legacy code" as an issue has been brought up in a
vaccuum. We start by saying we want a 2d array class and then someone
says we have to be aware of "legacy code" and thus are required to do
things a certain way. Legacy code doesn't exist nor change in a
vaccuum. If we where to add a 2d array class to legacy code then there
must have been a reason for it. Chances are high that a "2d array
class" would _never_ be added to legacy code in such a manner as has
been posited here. The requirement governing the change is more likely
to be leaning toward a better abstraction.

In other words, a "2d array class" doesn't do enough to warrant its
existance. A matrix abstraction should be at a higher level. If an
array of arrays is no longer adiquate to the task it should be dropped
as an interface. Does this mean that other points won't add up so that
you won't? No...it does mean though that the sytax issue in your
legacy code is not as important as it is being made out to be and
changing from raw arrays to a class is already a rather significant
change. Unless your reason for this change is very basic, localized,
and simple it is going to have wide reaching effects on the code base
already. If it's time for a change then let change happen.

 

[Gianni Mariani]

It is important to note that the FAQ is not comparing two syntaxes, but
two implementations. On the one hand having an op[] that returns a
reference to an array object or a raw array (something I think we can
both agree is a bad idea,) on the other hand not doing so.

The FAQ does state many false claims in support of the position of using
(,) over [][]. Read 13.11 more carefully.

 

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

The above is what I think we have both lost sight of. Peter initially
posted code that did exactly what the above paragraph talks about and I
agreed with the FAQ about the inappropriateness of it.

This clearly shows that this point in the FAQ leads to confusion.

 

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

In other words, a "2d array class" doesn't do enough to warrant its
existance. A matrix abstraction should be at a higher level. If an
array of arrays is no longer adiquate to the task it should be dropped
as an interface.

Don't see the correlation, the implementation and the interface are not
coupled. The use of ( , ) is no more or less abstract than [ ] [ ] just by
the fact that it looks this way to you. This line of argumentation has no
other content than personal preferences about syntax.

 

[Noah Roberts]

The use of ( , ) is no more or less abstract than [ ] [ ] just by
the fact that it looks this way to you.

Since [][] is a chaining of function calls, and not a single call, it
requires an additional object which (,) does not. [][] requires this
extra object while (,) simply does not preclude it. Since it requires
less and imposes no more it is the more abstract solution.

I'll leave it at that and ignore that you completely missed the point.

 

[Noah Roberts]

You still have not explained why array of array syntax is any less
expressive than matrix(,). They not only seem interchangeable in a
programming sense, but also in a theoretical sense. Metaphorically
speaking, instead of taking the horse to the straw, take the straw to
the horse.

Actually, since [][] is shown to be the more complex answer, no matter
how much or little, it is on you to show that (,) is less expressive.
I never said [][] was less expressive. What I said is that you can't
make [][] as expressive as (,) without additional complexity. Actually
I never said that, but it is what can be implied from what I did say.

I have no idea what horses and straw have to do with it.

So even from a notation/object design perspective [][] is just as
expressive as (,). In some ways, I may be those with the obsession with
(,) over [][] that express rigidity.

I can't parse that.

 

[Gianni Mariani]

Noah Roberts wrote:
....

I can't parse that.

It may be you that is rigid rather than the others you accuse of
rigidity.

 

[Sjouke Burry]

You still have not explained why array of array syntax is any less
expressive than matrix(,). They not only seem interchangeable in a
programming sense, but also in a theoretical sense. Metaphorically
speaking, instead of taking the horse to the straw, take the straw to
the horse.

Actually, since [][] is shown to be the more complex answer, no matter
how much or little, it is on you to show that (,) is less expressive.
I never said [][] was less expressive. What I said is that you can't
make [][] as expressive as (,) without additional complexity. Actually
I never said that, but it is what can be implied from what I did say.

I have no idea what horses and straw have to do with it.

??????????????????????

 

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

Since [][] is a chaining of function calls, and not a single call, it
requires an additional object which (,) does not. [][] requires this
extra object while (,) simply does not preclude it. Since it requires
less and imposes no more it is the more abstract solution.

This is a detail of the implementation that has no relation with the level
of abstraction.

 

[Gianni Mariani]

The use of ( , ) is no more or less abstract than [ ] [ ] just by
the fact that it looks this way to you.

Since [][] is a chaining of function calls, and not a single call, it
requires an additional object which (,) does not. [][] requires this
extra object while (,) simply does not preclude it. Since it requires
less and imposes no more it is the more abstract solution.

I'll leave it at that and ignore that you completely missed the point.

You might be missing the point as well. Who cares about extra objects
? That is the C++ paradigm, there is a very low threshold to creating
new classes. The cost of doing so is either negligible or in this case
zero. Getting hung up about trivial implementation detail does not
produce the best results.

 

[Noah Roberts]

Noah Roberts wrote:
...

It may be you that is rigid rather than the others you accuse of
rigidity.

I never accused anyone of anything.

Critical thinking not your strong suit I see. Oh well...bye then.

 

[Noah Roberts]

Since [][] is a chaining of function calls, and not a single call, it
requires an additional object which (,) does not. [][] requires this
extra object while (,) simply does not preclude it. Since it requires
less and imposes no more it is the more abstract solution.

This is a detail of the implementation that has no relation with the level
of abstraction.

The extra object is exposed in the interface. If it has no relation to
the abstraction it has no business in the interface and again (,) is
the better alternative.

 

[Kai-Uwe Bux]

Since [][] is a chaining of function calls, and not a single call, it
requires an additional object which (,) does not. [][] requires this
extra object while (,) simply does not preclude it. Since it requires
less and imposes no more it is the more abstract solution.

This is a detail of the implementation that has no relation with the
level of abstraction.

The extra object is exposed in the interface. If it has no relation to
the abstraction it has no business in the interface and again (,) is
the better alternative.

But of course row proxies have a relation to the matrix abstraction. What
makes a matrix a 2-dimensional array is that it has rows and columns. Any
interface that does not provide a way of addressing these important
sum-matrices as some type of vector is very low-level.

The matrix class I use has row and column proxies. You can get a row by the
row() method and a column by the column() method. It happens that
operator[] returns a row proxy. The main advantage of the proxy classes is
not that they allow [][] notation but lies in the way they enrich the
interface. For instance, I can say

swap( A.row(i), A.row(j) );

to do a row swap. An elementary row operation can be written as

A.row(i) += factor * A.row(j);

which is much more readable than

row_op( A, i, j, factor );

and it also chains better:

A.row(i) += f*A.row(j) + g*A.row(k);


Best

Kai-Uwe Bux

 

[Z.Meson]

Let's see if we disagree on any of these statements:

a) in C and in C++ matricies have been traditionally supported using
[][] (array of array) syntax. Hence there is a non-trivial body of
code and knowledge that is using [][] as opposed to (,).

No. In C, matrices have been traditionally supported using something
other than [][] -- at least for 'serious' numerical linear algebra
applications. Take a look at CLAPACK, the C interface for BLAS, or any
C implementation for sparse matrices.

I have seen *alot* of gl and OpenGL code that uses [][].

The OpenGL C code that I'm familliar with more often deals with
coordinates of point to define shapes, and here it uses uses (,).
Here's some code from a search on Google:

http://www.eecs.tulane.edu/Terry/OpenGL/Examples/Polygons.c
http://www.eecs.tulane.edu/Terry/OpenGL/Primitives.html#OpenGL Primitives
http://gpwiki.org/index.php/OpenGL:Codes:Simple_GLSL_example

But there are OpenGL matrix operations too (of which I am not very
familiar). But even here, the tutorials I see don't use two sets of
brackets -- they only use one:

http://www.opengl.org/resources/faq/technical/transformations.htm (see
9.130)
http://lists.apple.com/archives/mac-opengl/2000/Dec/msg00036.html (the
4x4 matrix 'm' is specified as a 16-element array)

This link is especially interesting:

http://72.14.253.104/search?q=cache...tures/lecture03.ppt+&hl=en&gl=us&ct=clnk&cd=8

A snippet says:
"Warning about declaring matrices in C
matrix m[4][4] can be accesses as m[ i ] [ j ], but this accesses
the ith column and the jth row of the OpenGL transformation matrix

Because C convention is opposite the OpenGL convention, m[16]
is recommended declaration"

Sure, you can cast an array of arrays of floats to a pointer to float,
but that requires a cast and isn't really what is specified in the
OpenGL interface. Does it work? Well sort of -- opposite to the C
convention. Is it an example that demonstrates the syntactical
superiority of [][] over (,)? Not really. A quick Google search shows
much more code and many more libraries that use the (,) syntax over
[][] for C and C++.

As mentioned, already, for things like sparse matrices in C, it's
impossible to use [][] (it's only possible in C++ and that with proxy
classes and operator overloading). But there are lots and lots of
scientific libraries for both C and C++ that use (,). There's probably
very good reason for it -- like those pointed out in the C++ FAQ Lite.

- Kevin

 

[Gianni Mariani]

Gianni Mariani wrote:
Let's see if we disagree on any of these statements:

a) in C and in C++ matricies have been traditionally supported using
[][] (array of array) syntax. Hence there is a non-trivial body of
code and knowledge that is using [][] as opposed to (,).
No. In C, matrices have been traditionally supported using something
other than [][] -- at least for 'serious' numerical linear algebra
applications. Take a look at CLAPACK, the C interface for BLAS, or any
C implementation for sparse matrices.

I have seen *alot* of gl and OpenGL code that uses [][].

The OpenGL C code that I'm familliar with more often deals with
coordinates of point to define shapes, and here it uses uses (,).
Here's some code from a search on Google:

http://www.eecs.tulane.edu/Terry/OpenGL/Examples/Polygons.c
http://www.eecs.tulane.edu/Terry/OpenGL/Primitives.html#OpenGL Primitives
http://gpwiki.org/index.php/OpenGL:Codes:Simple_GLSL_example

None of those example show any matrix manipulation, also they don't show
any use of 1D vectors other than ones created by passing discrete values
as function parameters. Nice try, wrong examples.

This one is shows examples of using matix
http://www.google.com/codesearch?hl...gz&cs_f=glut-3.4/progs/examples/glpuzzle.c#a0

here is another...
http://www.google.com/codesearch?hl...0203/Code/Moebius6.zip&cs_f=vcg/matrix44.h#a0

....

http://72.14.253.104/search?q=cache...tures/lecture03.ppt+&hl=en&gl=us&ct=clnk&cd=8

A snippet says:
"Warning about declaring matrices in C
matrix m[4][4] can be accesses as m[ i ] [ j ], but this accesses
the ith column and the jth row of the OpenGL transformation matrix

Because C convention is opposite the OpenGL convention, m[16]
is recommended declaration"

Yes - openGL matrices are transposed depending on how you look at it.

Sure, you can cast an array of arrays of floats to a pointer to float,
but that requires a cast and isn't really what is specified in the
OpenGL interface. Does it work?
Yup.

....

As mentioned, already, for things like sparse matrices in C, it's
impossible to use [][] (it's only possible in C++ and that with proxy
classes and operator overloading). But there are lots and lots of
scientific libraries for both C and C++ that use (,). There's probably
very good reason for it -- like those pointed out in the C++ FAQ Lite.

a) This is comp.lang.c++ where C++ is topical, if it's impossible in C
it really does not matter as far as this discussion is concerned. (,)
is just as impossible as [][] is in C anyway.

b) most of the opengl code I have seen uses float matrix[4][4]

c) if you read the FAQ, it is sparse on reason and the reasons mentioned
in FAQ 13.11 are debunked in FAQ 13.12. There are no technical reasons
to use (,) over [][].

Sure, if you like (,), knock yourself out but don't spread
misinformation about technical superiority of (,) over [][] because
there simply isn't any. The only cogent arguments of any weight go in
favour of [][] instead of (,).

 

[Simon G Best]

I am not rigid, I will change...

Thanks

Simon

 

[Simon G Best]

I'm not talking about the syntax change being a switch to another type
of abstraction. I'm talking about the need for the new abstraction
being created. What is the reason behind needing this 2d array
"class"?

How about two-dimensional digital images? (I think that's what the
original poster has in mind. It's certainly something that I need
two-dimensional arrays for.)

There are all sorts of uses for two-dimensional arrays, as matrices
themselves demonstrate. And there are all sorts of useful things we can
do with and do to two-dimensional arrays. (Of course, we could
generalize to N-dimensional arrays, and it might be preferable to do
two-dimensional arrays as N-dimensional arrays where N happens to be
two. But anyway.)

The problem is that "legacy code" as an issue has been brought up in a
vaccuum. We start by saying we want a 2d array class and then someone
says we have to be aware of "legacy code" and thus are required to do
things a certain way. Legacy code doesn't exist nor change in a
vaccuum. If we where to add a 2d array class to legacy code then there
must have been a reason for it. Chances are high that a "2d array
class" would _never_ be added to legacy code in such a manner as has
been posited here. The requirement governing the change is more likely
to be leaning toward a better abstraction.

It wouldn't necessarily be a matter of adding a two-dimensional array
class /to/ old code. It could be that we want to reuse old code with
our new code. Our new code might need a new implementation of
two-dimensional arrays, but we might still want to apply some of that
old code to our new arrays. If that old code assumes [][]-style
interfaces, then there's really no great loss in including such an
interface in our new array class - especially as it doesn't preclude
using a (,)-style interface as well!

As I understand it, one of the strengths of C++ was supposed to be that
old code could be applied to new stuff without having to be changed (as
long as the old code was written appropriately for such reuse). Runtime
polymorphism and templates are both ways of allowing old code to use new
code. If we're taking advantage of such reusability, we may well find
ourselves wanting to apply that old code to our new arrays.

Of course, we /could/ edit the old code, to have it use the interface we
think it ought to use. But what about other code that uses, or is used
by, that old code? Should we really be editing modules B, C and D just
because we think module A ought to use the interface we want for our new
module E? I don't think so.

And, of course, our new code may eventually be old code that someone
else wants to reuse in the future. For all we know, they might want to
use it with other old code that operates on one-dimensional arrays,
using []-style subscripting. They might want to treat our
two-dimensional arrays as one-dimensional arrays of rows. They might
want to treat individual rows as one-dimensional arrays. If we haven't
provided suitable []-style interfaces, it's not going to be quite so
simple (but they can always wrap our two-dimensional array in a suitable
wrapper class with the right interface).

Simon