Two Dimensional Array Template

[Simon G Best]

Again, the second [] need not immediately follow the first.

And there is no reason that can't be done with the (,) interface and an
external binder. However, such comments have nothing to do with the
veracity of the FAQ.

The FAQ erroneously assumes that the only reason someone would have for
wanting []s is so as to say "[j]" instead of "(i, j)". That
assumption is wrong, so this /is/ relevant to the correctness of the FAQ.

 

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

As has been said before, [][] can be used with regular POD array of
array as well as matrix classes and a matrix function template could
easily provide the basis for both regular POD types as well as matrix
classes if the class supported the [][] syntax. That's a big bonus.

Except that it's better to avoid C-style POD arrays in the first place.
Even when we have to deal with them, it's better to wrap them up in
proper interfaces and then go through the interfaces. That means we're
only dealing directly with the POD arrays in one place, which is
preferable.

You can have an array of arrays perfectly encapsulated in a class that does
not expose any sign of his presence to the outer world, and want to use a
templated function with that array as argument. As have been said several
times in the thread, there is no direct relation between the usage of the
[ ] [ ] operation and the details of the implementation or his exposure.

 

[Daniel T.]

Those expressions, however, make my life much easier. My main
issue with the FAQ entry on matrices is that it creates the
misguided impression that element access (although of course an
important primitive) is the main issue in interface design for a
matrix class.

...

Similarly, the main problem I've got with those FAQs is the
assumption that the only reason someone would have for wanting []s
in the interface is to say "[j]" instead of "(i, j)". But, of
course, that assumption is incorrect.

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)'"

While there are some people who would simply rather say "[j]"
than "(i, j)", and while there is old code that has "[j]", there
is, as you rightly say, a lot more to it than that. Put simply, the
application of the first [] may well be in a different place to the
application of the second (such when they're in different functions).

The same thing can be done with op() and external binders. No need for
[][] to handle that. This however, has nothing to do with the FAQs in
question.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
As an aside, my vacation is over and I'm back to work writing real code.
My posting volume will probably go down considerably until my next
break but hopefully, I will be able to continue talking with new friends
and old. I have especially enjoyed talking with my new friends Simon and
Julián, Kai-Uwe Bux is always fun to butt heads with. Peter and Gianni,
you opened my eyes. I never knew such a heated controversy existed over
those particular FAQs. I've been recommending them to new people
struggling with trying to set-up multi-dimensional arrays for years. To
everyone, thanks for the hours of entertainment and pearls of wisdom!

 

[Kai-Uwe Bux]

Daniel T. wrote:
(a) does not talk about [][] versus (,).

So it is irrelevant to the discussion at hand.

That depends on how narrowly you define the topic of the discussion.
If you consider the veracity of the FAQ as the topic at hand, and if
you consider the rationales provided by the FAQ as claims of the
FAQ, then (a) is relevant as the FAQ creates the impression that
your life would be simpler without the proxy classes.

I think the implication of the FAQ is different. But this thread is more
about what the FAQ says, rather than what it implies. Is there anything
that it says that you disagree with?

a) Yes, e.g., the recommendation against [][].

b) Arguments for recommendations differ from truth preserving inferences in
important ways, e.g., a truth preserving inference cannot be invalidated by
additions to the set of hypotheses whereas a recommendation for a car based
upon the information that it has a really good transmission can be
invalidated by added information about the crapy engine and lousy seats.
The problem with the FAQ is not so much misinformation it may or may not
contain. But:

* The FAQ presents a highly selected and incomplete account of row and
column proxies.

* It only talks about the ease for the programmer of the matrix class not
about the ease for client code using the matrix class (which is where one
can see good reasons to have row and column proxies anyway).

Thus, the recommendation is ill-argued because the discussion leaves out
relevant information that can off-set the reasons put forth by the FAQ.

Why/how is [][] more "useful" syntacticly than (,)?

It's not---well: asside from generic algorithms templates that could
work with, e.g., double[m][n] as well as any matrix class offering
[][].

And the FAQ does make an exception for legacy code. To assert that *new
code* should use arrays of arrays is to deny FAQ 34.1.

I fail to see how this is only related to legacy code.
vector<vector<float> > is a perfect example of a 2D-array that offers
[][] but not (,). If you program generic matrix algorithms, why
would you want to exclude this data structure?

The construct in question is exactly what 13.11 argues against.
Although, I think that is a viable construct to use as a possible
implementation of a Matrix class, I wouldn't use it raw, nor advocate
its use. (Again, I accept that it may be used extensively in some legacy
code and in that case, one may be forced to support it

This is a simple misunderstanding. You seem to think, I was proposing

vector< vector< T > >

as an implementation for a matrix class. That is not the case. Reread what I
wrote and you will find that I was talking about genering algorithms.
Consider, for example:


#include <cstddef>
#include <cassert>

template < typename MatrixType >
struct MatrixValueType {

typedef typename MatrixType::value_type value;

};

template < typename MatrixType >
struct MatrixSizeType {

typedef typename MatrixType::size_type value;

};

template < typename MatrixType >
MatrixSizeType<MatrixType>::value
RowSize ( MatrixType const & M ) {
return ( M.row_size() );
}

template < typename MatrixType >
MatrixSizeType<MatrixType>::value
ColSize ( MatrixType const & M ) {
return ( M.col_size() );
}


template < typename MatrixType >
typename MatrixValueType<MatrixType>::value
trace_n ( MatrixType const & M,
typename MatrixSizeType<MatrixType>::type row_size,
typename MatrixSizeType<MatrixType>::type col_size ) {
assert( row_size == col_size );
typename MatrixValueType<MatrixType>::value result =
typename MatrixValueType<MatrixType>::value();
for ( typename MatrixSizeType<MatrixType>::value i = 0;
i < row_size;
++i ) {
result += M; // should this be M(i,i) ?
}
return ( result );
}


This algorithm can be used with any matrix class that supports [][] and it
can be used with vector< vector< T >. All you need to add is partial
specializations for MatrixValueType and MatrixSizeType.

The FAQ does not address the issue of using [][] or (,) in algorithms like
the above (it never talks about the use of the matrix class in client
code!). Yet another shortcoming of the FAQ account on this issue.

Also note that this is not an issue of legacy code. This is an issue of
separating algorithms from containers. One question is whether (,) or [][]
is better suited to support such separation. Since native containers like
vector< vector< T > > already support [][] but not (,), a point can be made
that [][] might be a more natural choice for generic programming.

It isn't meant to cover a "good discussion of interface design for a
matrix class."

Well, that is part of the problem with these 3 FAQ items. Should it turn out
that row and column proxies are a good idea anyway, much of the rational
for why you should use (,) disappears.

IMO, the class would be better for it, but let's try to stick to what
the FAQ actually says rather than your impression (or mine) of what a
good matrix interface design should look like.

As explained above, the problem lies more with what the FAQ fails to tell.

IMO, yet another inappropriate design.


IMO, embedded proxies have no place in a full-fledged matrix class. I
believe that the design should be complete and minimal. Embedding
classes and function calls that could easily be written outside of the
Matrix proper (with no loss in performance or express-ability) makes for
a fat interface. If you care to go further down this road, we should
probably start a new thread though because it has nothing to do with
what the FAQ actually says.

Where in my posts did I say something about *embedded* proxies. The proxy
classes can be independent. In my own implementation they are part of the
expression template machinery used to cut down temporaries arising from
matrix expressions. It turns out that that is a natural place for the
proxies. Whether you have a row() method as part of the matrix class, or
just a Row( Matrix, Index ) freestanding function, is a minor issue.
Important is, that operators like + are generic: it should be possible to
add matrices with different storage layouts, etc. Thus, those are more or
less forced to be freestanding. Anyway, I agree that this is a digression.

The FAQ doesn't ask what a well designed, full-fledged matrix class
looks like. It only compares two methods of single element access.

Again: that narrow view is part of the problem since it means that the
recommendation is based upon incomplete information that leaves out
important aspects of the problem.

The main thrust of the FAQ is how to implement single element
access (How do I create a subscript operator for a Matrix class?),
what we learn is that performance wise, "the operator() approach
is never worse than, and sometimes better than, the [][]
approach." That is something that simply cannot be said the other
way around, at least not for all possible standards conforming
compilers.

The relevance of a statement about all possible (as opposed to all
actual) compilers when it comes to performance considerations is
highly doubtfull. What matters is whether people can be expected to
run into performance problems. The optimization techniques that
prevent this are well known and widely implemented.

IMO, the relevance of such micro-optimizations in general is highly
doubtful. I'm willing to completely drop the speed issue. The FAQs in
question make reference to "performance" in a few places but are all
sufficiently equivocal as to be pointless (not incorrect, just not worth
arguing about.) It was a blind ally I should have never gone down.

Agreed.


Best

Kai-Uwe

 

[Kai-Uwe Bux]

Those expressions, however, make my life much easier. My main issue with
the FAQ entry on matrices is that it creates the misguided impression
that element access (although of course an important primitive) is the
main issue in interface design for a matrix class.

...

Similarly, the main problem I've got with those FAQs is the assumption
that the only reason someone would have for wanting []s in the interface
is to say "[j]" instead of "(i, j)". But, of course, that assumption
is incorrect. While there are some people who would simply rather say
"[j]" than "(i, j)", and while there is old code that has "[j]",
there is, as you rightly say, a lot more to it than that. Put simply,
the application of the first [] may well be in a different place to the
application of the second (such when they're in different functions).

I wholeheartly agree. It's not so much what the FAQ says, it's more what it
fails to consider.


Best

Kai-Uwe Bux

 

[Michael DOUBEZ]

Daniel T. a écrit :

Daniel T. a écrit :

- The FAQ says: "The array-of-array solution obviously works,
but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in
the [][] approach, and therefore the [][] approach is more
likely to lead to bad performance, at least in some cases."
Keep in mind Michael, that quote is about a particular
implementation of [][]. Read the paragraph before and after it.

Concerning the particular implementation, I read in the paragraph
before: "[...]Some people build a Matrix class that has an
operator[] that returns a reference to an Array object [...] and
that Array object has an operator[] that returns an element of the
Matrix.[...]"

This seems pretty general for me and since there is no operator[][],
I don't see the alternative. Which particular implementation are you
talking about ?

I think the FAQ, in showing the proxy solution, is making a distinction
between that solution and others like the one that Peter presented that
started off this thread and the vector of vectors solution.

Yes but those you presented are not flexible.

And you fall into the general case:
typdedef vector<int> Array;
typedef vector<Array> Matrix;
Matrixis an Array and you use Array[j] to access Matrix[j].
It is the case [][} yields the same performances (perhaps even better
but I doubt it otherwise there is no point in the STL) as (,).

If the whole point is to have a simple Matrix, it is the solution and
you don't really care about the interface but if the point is to have a
reusable, flexible and extendable design (which is the whole point of
c++ compared to c) then you care about the practicality of the interface.
I don't see why the FAQ should be clearer it is part of why c++ has been
created; no reason to recall it.

Michael

 

[Michael DOUBEZ]

Peter Olcott a écrit :

Daniel T. a écrit :
- The FAQ says: "The array-of-array solution obviously works,
but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in
the [][] approach, and therefore the [][] approach is more
likely to lead to bad performance, at least in some cases."
Keep in mind Michael, that quote is about a particular
implementation of [][]. Read the paragraph before and after it.
Concerning the particular implementation, I read in the paragraph
before: "[...]Some people build a Matrix class that has an
operator[] that returns a reference to an Array object [...] and
that Array object has an operator[] that returns an element of the
Matrix.[...]"

This seems pretty general for me and since there is no operator[][],
I don't see the alternative. Which particular implementation are you
talking about ?

I think the FAQ, in showing the proxy solution, is making a distinction
between that solution and others like the one that Peter presented that
started off this thread and the vector of vectors solution.

I like Gianni Mariani's solution the best for several reasons:
(1) It is very machine efficient. In my case this is utterly crucial.

But (,) is expected to be as efficient.

(2) It is very simple, thus its reliability can be reliably validated.

operator[] has the same flaw as POD[] in vector (i.e. out of bound access).
If you want reliability you have to use vector::at which break the [][]
usage and preforms 2 if() operation that may cut optimisations.

I don't undersand your point.

(3) It uses the same standard convention for multiple dimension array access as
is native to its language, thus minimizing the learning curve and typing error
rate

The learning curve is very small especially for science engineer who
*expect* a (,) interface.
Even though, if the learning curve were a major factor, we would all
certainly be using C (or fortran).

Typing error rate isn't a factor since it is caught by the compiler.

Michael

 

[Michael DOUBEZ]

Sorry, I messed up the Subject.

Michael DOUBEZ a écrit :

Daniel T. a écrit :

Daniel T. a écrit :
Michael DOUBEZ <[email protected]> wrote:

- The FAQ says: "The array-of-array solution obviously works,
but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in
the [][] approach, and therefore the [][] approach is more
likely to lead to bad performance, at least in some cases."
Keep in mind Michael, that quote is about a particular
implementation of [][]. Read the paragraph before and after it.
Concerning the particular implementation, I read in the paragraph
before: "[...]Some people build a Matrix class that has an
operator[] that returns a reference to an Array object [...] and
that Array object has an operator[] that returns an element of the
Matrix.[...]"

This seems pretty general for me and since there is no operator[][],
I don't see the alternative. Which particular implementation are you
talking about ?

I think the FAQ, in showing the proxy solution, is making a
distinction between that solution and others like the one that Peter
presented that started off this thread and the vector of vectors
solution.

Yes but those you presented are not flexible.

And you fall into the general case:
typdedef vector<int> Array;
typedef vector<Array> Matrix;
Matrixis an Array and you use Array[j] to access Matrix[j].
It is the case [][} yields the same performances (perhaps even better
but I doubt it otherwise there is no point in the STL) as (,).

If the whole point is to have a simple Matrix, it is the solution and
you don't really care about the interface but if the point is to have a
reusable, flexible and extendable design (which is the whole point of
c++ compared to c) then you care about the practicality of the interface.
I don't see why the FAQ should be clearer it is part of why c++ has been
created; no reason to recall it.

Michael

 

[Gianni Mariani]

Michael DOUBEZ wrote:
....

But (,) is expected to be as efficient.

Very possibly you're right on this one. However if his code is using
rows, then that code will have exactly the same performance
characteristics as before without needing to test anything. Maybe he
should say "no need to check performance" instead of "is very machine
efficient".

(2) It is very simple, thus its reliability can be reliably validated.

operator[] has the same flaw as POD[] in vector (i.e. out of bound access).
If you want reliability you have to use vector::at which break the [][]
usage and preforms 2 if() operation that may cut optimisations.

He probably has old code that he can test it on - no changes to his
older code.

I don't undersand your point.

The learning curve is very small especially for science engineer who
*expect* a (,) interface.
Even though, if the learning curve were a major factor, we would all
certainly be using C (or fortran).

Yes but the reason to prefer (,) over [][] is also marginal so you can't
really argue against having a marginal claim.

Typing error rate isn't a factor since it is caught by the compiler.

Not all typos are caught by the compiler.

 

[Michael DOUBEZ]

Gianni Mariani a écrit :

Michael DOUBEZ wrote:
...

Very possibly you're right on this one. However if his code is using
rows, then that code will have exactly the same performance
characteristics as before without needing to test anything. Maybe he
should say "no need to check performance" instead of "is very machine
efficient".

At the cost of flexibility. Meaning further evolution of your class will
certainly have to giveup the vector<vector<> > internal and then you
need to test.
What you do is replace legacy code with immutable code or with code
whose performance test will have to be done later (upon change) hoping

(2) It is very simple, thus its reliability can be reliably validated.

operator[] has the same flaw as POD[] in vector (i.e. out of bound
access).
If you want reliability you have to use vector::at which break the
[][] usage and preforms 2 if() operation that may cut optimisations.

He probably has old code that he can test it on - no changes to his
older code.

The same can be said of (,). Once he has make the modifications, the old
tests should still pass.
If he is lazy with changing is test code, he can always use a wrapper
(since performances in functionnal tests are not an issue, or if it is,
it is test in the test of (,) usage).

I don't undersand your point.

The learning curve is very small especially for science engineer who
*expect* a (,) interface.
Even though, if the learning curve were a major factor, we would all
certainly be using C (or fortran).

Yes but the reason to prefer (,) over [][] is also marginal so you can't
really argue against having a marginal claim.

I think there are enough cons again [][] (in previous post) to justify
the use of (,).
And if it was not enough, I see no pros in using [][] except some
illusion of backward compatibility for some poor designed code that use
[][] as general API instead of a proper interface.

Not all typos are caught by the compiler.

In this case, this would be a poor compiler.
An the typos error still suppose the [][] was widely used that way.


Michael

 

[Gianni Mariani]

Michael DOUBEZ wrote:
...

(2) It is very simple, thus its reliability can be reliably validated.
operator[] has the same flaw as POD[] in vector (i.e. out of bound
access).
If you want reliability you have to use vector::at which break the
[][] usage and preforms 2 if() operation that may cut optimisations.

He probably has old code that he can test it on - no changes to his
older code.

The same can be said of (,). Once he has make the modifications, the old
tests should still pass.
If he is lazy with changing is test code, he can always use a wrapper
(since performances in functionnal tests are not an issue, or if it is,
it is test in the test of (,) usage).

Why would you consider making this change ? I am sure there are far
more important changes to make than bothering with changing [][] to (,).

I don't undersand your point.

(3) It uses the same standard convention for multiple dimension
array access as is native to its language, thus minimizing the
learning curve and typing error rate
The learning curve is very small especially for science engineer who
*expect* a (,) interface.
Even though, if the learning curve were a major factor, we would all
certainly be using C (or fortran).

Yes but the reason to prefer (,) over [][] is also marginal so you
can't really argue against having a marginal claim.

I think there are enough cons again [][] (in previous post) to justify
the use of (,).

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

And if it was not enough, I see no pros in using [][] except some
illusion of backward compatibility for some poor designed code that use
[][] as general API instead of a proper interface.

A matter of personal opinion for you and a matter of clear fallacy for
me. If you do not see it, it does not mean it's not there.

Not all typos are caught by the compiler.

In this case, this would be a poor compiler.
An the typos error still suppose the [][] was widely used that way.

I have no idea what you're talking about.

 

[Simon G Best]

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.

 

[Michael DOUBEZ]

Gianni Mariani a écrit :

Michael DOUBEZ wrote:
..

(2) It is very simple, thus its reliability can be reliably validated.
operator[] has the same flaw as POD[] in vector (i.e. out of bound
access).
If you want reliability you have to use vector::at which break the
[][] usage and preforms 2 if() operation that may cut optimisations.

He probably has old code that he can test it on - no changes to his
older code.

The same can be said of (,). Once he has make the modifications, the
old tests should still pass.
If he is lazy with changing is test code, he can always use a wrapper
(since performances in functionnal tests are not an issue, or if it
is, it is test in the test of (,) usage).

Why would you consider making this change ? I am sure there are far
more important changes to make than bothering with changing [][] to (,).

If legacy code must be updated, there is a reason for it. Otherwise, you
just let it be.
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.

I don't undersand your point.

(3) It uses the same standard convention for multiple dimension
array access as is native to its language, thus minimizing the
learning curve and typing error rate
The learning curve is very small especially for science engineer who
*expect* a (,) interface.
Even though, if the learning curve were a major factor, we would all
certainly be using C (or fortran).

Yes but the reason to prefer (,) over [][] is also marginal so you
can't really argue against having a marginal claim.

I think there are enough cons again [][] (in previous post) to justify
the use of (,).

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 [][].

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

And if it was not enough, I see no pros in using [][] except some
illusion of backward compatibility for some poor designed code that
use [][] as general API instead of a proper interface.

A matter of personal opinion for you and a matter of clear fallacy for
me. If you do not see it, it does not mean it's not there.

If you see it, it doesn't mean it is there either.
So what is the point ?

Typing error rate isn't a factor since it is caught by the compiler.

Not all typos are caught by the compiler.

In this case, this would be a poor compiler.
An the typos error still suppose the [][] was widely used that way.

I have no idea what you're talking about.

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 [][]
fashion; that would have been a cut to any numerical optimization (such
as choosing the matrix form carefully).

Therefore, legacy code matrix user would have used the (,) notation
anyway such as in the GNU Scientific Library
http://www.gnu.org/software/gsl/man...atrix-elements.html#Accessing-matrix-elements

And (,) is kept in libraries that have very good performances such as
Blitz++.

The consensus is not built on what a few people might say but on what is
effectively used in real life.

Michael

 

[=?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.

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

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.

 

[Gianni Mariani]

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.

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.

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.

And if it was not enough, I see no pros in using [][] except some
illusion of backward compatibility for some poor designed code that
use [][] as general API instead of a proper interface.

A matter of personal opinion for you and a matter of clear fallacy for
me. If you do not see it, it does not mean it's not there.

If you see it, it doesn't mean it is there either.
So what is the point ?

I have listed at least 3 times on this thread the reasons to use [][]
over (,). Please go read them. It's not just I who has stated them.

....

The consensus is not built on what a few people might say but on what is
effectively used in real life.

Excellent. You have your reasons to use (,), knock yourself out. The
issue here is that the FAQ wrongly makes a case against [][]. These are
a matter of personal opinion and does not belong in the FAQ.

 

[Noah Roberts]

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.

It happens.

This discussion goes off the path every time legacy code comes up. The
FAQ and I both agree that there can be issues that might govern one to
use a less optimal design. Legacy code is a distraction when
attempting to answer the real question: which is the better method?

Gianni Mariani has brought up code reuse. This is an important topic
but is it better answered by which interface?

If we use the Dependency Inversion Principle [1] (DIP) to analyze the
problem we might come up with an answer. Using this principle we could
think of the situation in two ways:

1) We have operations that work on arrays of arrays. Anything that
these operations work on must implement the array of array interface -
they must be arrays of arrays.

2) We have operations that work on matrices (or some other
abstraction). Anything that these operations work on must implement
the matrix interface - they must be matrices.

Basically we have two "concepts" [2], the array concept and the matrix
concept. How do we pick which is correct? Well one question that
could bring us closer is: Is a matrix a form of array or is an array a
form of matrix? Or, are they conceptually distinct?

1 - If a matrix is a form of array then Mariani is likely correct.
2 - If an array is a form of Matrix then Mariani's design is
questionable.
3 - If they are conceptually different then again his design is
questionable.

Now we have something to discuss...

This leaves asside the issue of a 2d array class. A 2d array is
obviously, conceptually, an arary. I've already argued though that
such a class really has no business being around so I don't feel it is
of much importance here.

references:

1 - http://www.objectmentor.com/resources/articles/dip.pdf
2 - http://boost.org/libs/concept_check/concept_check.htm

 

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

use a less optimal design. Legacy code is a distraction when
attempting to answer the real question: which is the better method?

This is not the real question, as have been said enough times. It can be an
interesting question, but is not the matter of this thread, unless you
provide a proof that the method better in general must be the only one
used.

 

[Noah Roberts]

This is not the real question, as have been said enough times. It can be an
interesting question, but is not the matter of this thread, unless you
provide a proof that the method better in general must be the only one
used.

Well, the matter of this thread is how to implement [][]....but that
was answered last week.

The matter at hand is whether it is appropriate to do so. In general
it is a bad idea to have two interfaces that do the same thing. This
means you should pick one or the other, not do both. Which means my
question is very much to the point...more so than any other side
discussion that has taken place.

Why, did you have a more to the point question to answer or did you
want to just continue babbling around in an argument that has no issue
to resolve?

 

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

This is not the real question, as have been said enough times. It can be
an interesting question, but is not the matter of this thread, unless you
provide a proof that the method better in general must be the only one
used.

Well, the matter of this thread is how to implement [][]....but that
was answered last week.

That is the subject, not the matter of the majority of the messages.

Why, did you have a more to the point question to answer or did you
want to just continue babbling around in an argument that has no issue
to resolve?

I just don't see a reason to keep this thread living forever.

 

[Gianni Mariani]

This is not the real question, as have been said enough times. It can be an
interesting question, but is not the matter of this thread, unless you
provide a proof that the method better in general must be the only one
used.

Well, the matter of this thread is how to implement [][]....but that
was answered last week.

The matter at hand is whether it is appropriate to do so. In general
it is a bad idea to have two interfaces that do the same thing. This
means you should pick one or the other, not do both. Which means my
question is very much to the point...more so than any other side
discussion that has taken place.

Why, did you have a more to the point question to answer or did you
want to just continue babbling around in an argument that has no issue
to resolve?

That's about as content-free as the post you're accusing of being
content-free.

One of the issues of this thread is that [][] is dissed by the FAQ for
what can be best described a "personal preference" and in so doing does
not belong in the FAQ whatsoever.

Secondly, there is likely no good reason in general to avoid using [][]
and whatever reasons you may have are situational or personal preference
at best.

Thirdly, there has been a huge misunderstanding (because of the FAQ) as
to the issues surrounding this topic that I think it needed a good
thrashing and which has been thrashed to death here.

It appears to me that there are so many experienced programmers that
never questioned the merits in the FAQ and blindly went down the path
and now they find themselves trying to defend their choice and have no
strong argument to support it other than personal preference to which I
say, "knock yourself out", but stop spreading erroneous information as fact.

Here again you state "use a less optimal design" to which the response
is - "not the real question". There is nothing inherently "less
optimal" with [][] over (,) as has been shown while the inverse is not
true. Even if in your particular implementation, it is less optimal,
then you have other options - get the compiler fixed (by filing a bug)
and live with the suboptimal result in the meantime or apply a second
interface to your code or whatever - this is your call.

So far, I have lost the war betting against the compiler. It's far more
important to write code that is readable and maintainable as well as
works and limit your optimizations to things that a compiler will never
be able to optimize (like using a list vs a vector vs a map etc) or
minimizing network round trip times in your protocol etc. For the very
small amount of code that needs a micro level optimization, do it on a
as needed basis. Certainly choosing (,) based on a fallacy of being
hard to optimize [][] is bad practice - in general.