Two Dimensional Array Template

[Simon G Best]

Not if the interface also has operator().

And once again, the whole proxy interface becomes something added to
placate those who like to use [][] and legacy code.

Is there any class that supports the [][] interface that is as flexible
as one that supports the (,) interface, but doesn't simply convert the
former to the latter?

So what if [][] converts to (,)? [][] is part of the interface. How
it's implemented internally should be unimportant to what the interface
is. So, really, the issue of whether or not [][] internally converts to
(,) should be irrelevant to the issue of whether or not it's appropriate
to provide [][] in the interface.

Anyway, we could always implement [][] more directly, and then define
(,) in terms of [][]. Would that mean we should not use (,)? Of course
not!

If we're going to have row() and col() with proxies (and there are good
uses for them), then adding [][] is very cheap indeed (the first [] just
inlines to row(), which would provide an operator[] anyway).

Simon

 

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

But I don't think it does just come down to personal preference. When
it comes to what the interface should provide, we've got various issues
to consider, and I'm sure some of it's rather political. But it is a
good thing that we've got to the point where we no longer need to
consider the internal implementation when considering what the interface
should be.

I completely agree with that.

But, of course, just because something's provided in an interface (be it
operator() or operator[]), it doesn't mean it has to be used if there
are better alternatives. And what counts as better may well depend on
the context of use. I think it makes sense to provide an interface
which provides a number of options, including operator(), operator[]
with proxies, row() and col() with proxies, and so on. Oh, and
iterators of a few kinds could also be useful.

The iterators are a good example. The set of operators provided allow the
use of templates that expects iterators with pointers. Use of [ ] [ ]
operator in templates that expects a type that represent some type of
two-dimensional arrays can allow his usage with native arrays of arrays. I
don't see a reason to say that those two things are so different that one
is an acceptable practice even for the standard library and the other must
be blamed and completely avoided.

Well, as this and other messages shows, both syntax can have advantages and
cab be preferred in certain situations or by some users. Then there is no
point to have a FAQ entry that discourages one in favor or the other, even
if is just an artifact of the redaction what makes it to look that way.

Do you mean in favour of operator() /and not having alternatives in the
interface?/ Or just in favour of including operator() in the interface
(along with alternatives)?

In favor of anything the argument poster tries to demonstrate is better.

 

[Daniel T.]

Daniel T. wrote:

If I want to access just one element in the array, must I
create a row or column proxy?

Not if the interface also has operator().

And once again, the whole proxy interface becomes something added
to placate those who like to use [][] and legacy code.

Is there any class that supports the [][] interface that is as
flexible as one that supports the (,) interface, but doesn't
simply convert the former to the latter?

So what if [][] converts to (,)? [][] is part of the interface.
How it's implemented internally should be unimportant to what the
interface is. So, really, the issue of whether or not [][]
internally converts to (,) should be irrelevant to the issue of
whether or not it's appropriate to provide [][] in the interface.

If all you are doing is adapting an interface, then one needs to wonder
why you are bothering to do so when the initial interface (the (,)
interface) is fine to work with directly.

Adaptors are fine in legacy code situations, but otherwise why bother?
Why not just use the (,) interface initially?

Anyway, we could always implement [][] more directly, and then
define (,) in terms of [][].

Could you? That is the exact question I'm asking. Can you come up with
an [][] interface that is the same for row major, column major and
sparse arrays that works "more directly"?

 

[Gianni Mariani]

Rather than answer each and every response to my post I'd like to
refocus on the argument. I won't be going back and answering each and
every response to my posts unless anyone responds to this post.

The assertion is that:

The decision to employ (,) vs [][] or both in a matrix class is usually
a personal matter or at most a situational decision (looking at
pre-existing code). As such FAQ items 13.10/13.11/13.12 need to be
revised as many false statements are made.

The claim supporting this assertion is that depending on implementation,
anything done using (,) can also be done using [][].

I don't see any unanswered posters to this thread that refute the claim.

So rather than waste any more time on many of the sideline issues, can
we refocus on this assertion.

Does anyone want to take a crack and rewriting the FAQ items ?

 

[Daniel T.]

Is there any class that supports the [][] interface that is as flexible
as one that supports the (,) interface, but doesn't simply convert the
former to the latter?

[snip]

By the way, I don't see any flexibility (or lack of it) in the ( , ) syntax.

The (,) interface works with row major, column major and sparse
implementations of 2D arrays without any interface changes. The [][]
interface doesn't (AFAIK), unless it is doing nothing more than
converting to the (,) interface.

If that is all [][] is doing, (adapting one interface to another) then
how does one justify using it in other than legacy code?

 

[Gianni Mariani]

Daniel T. wrote:
....

Could you? That is the exact question I'm asking. Can you come up with
an [][] interface that is the same for row major, column major and
sparse arrays that works "more directly"?

Why would you think that it can't ?

 

[Daniel T.]

And once again, the op[] becomes merely a notational convenience for
those who like the syntax or to accommodate legacy code.

And the ( , ) is another notation for those who like that syntax... Can
someone provide solid evidence and rational arguments in favor of his
preferred style instead of trying to blame the others? If not, better end
the discussion and rewrote the faq entry, or delete it, given that there
are no consensus in the point.

In some contexts, the best (i.e., fastest, etc.) implementation is a row
major array, in other contexts a column major array would be better, in
yet others, we would be better with a sparse array. (I expect there are
yet other ways to implement a 2D array, for example row major ragged and
column major ragged.)

As good programmers, we don't worry too much about optimization up
front, we want to just get the stuff working, then change out
implementations to see which one would be better for the particular
situation we find ourselves in. This is where interfaces come in.

We want each of our 2DArray implementations to use the same interface so
that we can easily switch out implementations then profile to see which
implementation is best for us. As the FAQ points out, this can easily be
done with the (,) interface, but it can only be done with the [][]
interface if the latter does nothing more than adapt to the (,)
interface. Assuming this is correct, there is no reason to use the [][]
interface when the (,) interface is available. (Unless, as pointed out
in the FAQ, one must adapt the interface for legacy code.)

If something in the above is not correct, then please let me know.

 

[Kevin Hall]

Rather than answer each and every response to my post I'd like to
refocus on the argument. I won't be going back and answering each and
every response to my posts unless anyone responds to this post.

The assertion is that:

The decision to employ (,) vs [][] or both in a matrix class is usually
a personal matter or at most a situational decision (looking at
pre-existing code). As such FAQ items 13.10/13.11/13.12 need to be
revised as many false statements are made.

The claim supporting this assertion is that depending on implementation,
anything done using (,) can also be done using [][].

I don't see any unanswered posters to this thread that refute the claim.

The FAQ mentions in 13.12 that it is possible to do exactly the same
thing with [][] and proxy classes as can be done with (,).

The FAQ comes across awefully strong and I can see why someone would
want those points re-worded to be a little less strong. But, remember
that this is an *unofficial FAQ Lite* -- not an official C++ FAQ. As
such, the author has taken some liberty in expressing how he feels
about a particular subject. Take a look at how he describes macros:
they're EVIL. Are they really evil? No -- of course not! When was
the last time, you saw a macro actively do something morally wrong --
like sexually molest a child? It can't of course, a macro is just a set
of characters / bytes and can't physically perform acts of evil.

Now, how do I personally feel about the following assertion?
"anything done using (,) can also be done using [][]."

Well, sure, it can be done, *BUT* I feel that people need to also
understand:
- Proxy classes cannot always be optimized away. (Embedded C++
compilers are notorius for not optimizing well.)
- Proxy classes take time to write and maintain and open up the
possiblity for additional bugs. (I've got other things to do like
writing tests, writing documentation, posting to clc++ ;-) )

So rather than waste any more time on many of the sideline issues, can
we refocus on this assertion.

Does anyone want to take a crack and rewriting the FAQ items ?

Again, since this is an *unofficial FAQ Lite* and not an official C++
FAQ, I don't even know that if someone re-wrote the FAQ items in
question that the author would accept them.

- Kevin Hall

 

[Daniel T.]

Daniel T. wrote:
...

Could you? That is the exact question I'm asking. Can you come up with
an [][] interface that is the same for row major, column major and
sparse arrays that works "more directly"?

Why would you think that it can't ?

I don't know if you can or not, I'm asking if you can. The question
wasn't rhetorical, just like last time when you showed me the proxy
solution, I genuinely want to know if it can be done, and if so, what
such a solution would look like.

 

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

By the way, I don't see any flexibility (or lack of it) in the ( , )
syntax.

The (,) interface works with row major, column major and sparse
implementations of 2D arrays without any interface changes. The [][]
interface doesn't (AFAIK), unless it is doing nothing more than converting
to the (,) interface.

And the meaning of that sentence is? What is the essence of "the (,)
interface" that IYO makes his syntax "real" and any other nothing more than
conversions?

If that is all [][] is doing, (adapting one interface to another)

Is an interface. What it does is adapt the external usage to the
implementation. The notion that the (,) has some type of precedence or is
more natural in some sense, is in your mind, is not a fact. Or at least, I
don't have seen in this thread any proof of it.

Other can say that the "natural" way is use a named member function, and
that [ ] [ ] and (,) are both adaptations to him. It can ever write code
that implements it that way.

then how does one justify using it in other than legacy code?

Nothing needs to justify nothing to choose an interface over other when
there are no clear arguments nor experimental data to support the opinion
that the other is better.

 

[Kevin Hall]

In some contexts, the best (i.e., fastest, etc.) implementation is a row
major array, in other contexts a column major array would be better, in
yet others, we would be better with a sparse array. (I expect there are
yet other ways to implement a 2D array, for example row major ragged and
column major ragged.)

As good programmers, we don't worry too much about optimization up
front, we want to just get the stuff working, then change out
implementations to see which one would be better for the particular
situation we find ourselves in. This is where interfaces come in.

We want each of our 2DArray implementations to use the same interface so
that we can easily switch out implementations then profile to see which
implementation is best for us. As the FAQ points out, this can easily be
done with the (,) interface, but it can only be done with the [][]
interface if the latter does nothing more than adapt to the (,)
interface. Assuming this is correct, there is no reason to use the [][]
interface when the (,) interface is available. (Unless, as pointed out
in the FAQ, one must adapt the interface for legacy code.)

I agree. The funny thing is that when you need to refactor in order to
optimize code, writing proxy classes is counter-productive. Sure, very
good compilers like Visual Studio 8.0 and GCC 3.4 and 4.0 can most
likely optimize the proxy classes away, but many other embedded
compilers do not. And embedded applications are very popular for
matrices and linear algebra applications.

 

[Daniel T.]

Rather than answer each and every response to my post I'd like to
refocus on the argument. I won't be going back and answering each and
every response to my posts unless anyone responds to this post.

The assertion is that:

The decision to employ (,) vs [][] or both in a matrix class is usually
a personal matter or at most a situational decision (looking at
pre-existing code). As such FAQ items 13.10/13.11/13.12 need to be
revised as many false statements are made.

The claim supporting this assertion is that depending on implementation,
anything done using (,) can also be done using [][].

My rebuttal:

In some contexts, the best (however one chooses to define best)
implementation is a row major array, in other contexts a column major
array would be better, in yet others, we would be better off with a
sparse array. (I expect there are yet other ways to implement a 2D
array, for example row major ragged and column major ragged, broken up
into blocks like std::deque does...)

As good programmers, we don't worry too much about optimization up
front, we want to just get the stuff working, then change out
implementations to see which one would be better for the particular
situation we find ourselves in. This is where interfaces come in.

We want each of our 2DArray implementations to use the same interface so
that we can easily switch out implementations then profile to see which
implementation is best in our particular context.

The FAQ says this can easily be done with the (,) interface, but it can
only be done with the [][] interface if the latter adapts to the (,)
interface.

Assuming this is correct, there is no reason to use the [][] interface
when the (,) interface is available. (Unless, as pointed out in the FAQ,
one must adapt the interface for legacy code.)

Are you asserting that the FAQ is wrong in its claim as outlined above?
(The assertion I'm replying to does not deny the above claim.)

 

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

Could you? That is the exact question I'm asking. Can you come up with
an [][] interface that is the same for row major, column major and
sparse arrays that works "more directly"?

Please define "is the same". To me [ ] [ ] is the same interface as [ ] [ ],
no matter what are the internals of the class, operators, functions,
proxies or whatever.

And a quoted "more directly" is not exactly an exact question. Please
elaborate.

Or at least provide an implementation of ( , ) in all cases you demand, that
is the same and works as directly as you want, to be able to compare.

 

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

The assertion is that:

The decision to employ (,) vs [][] or both in a matrix class is usually
a personal matter or at most a situational decision (looking at
pre-existing code). As such FAQ items 13.10/13.11/13.12 need to be
revised as many false statements are made.

Completely agree, except that the mention of pre-existing code is too
narrow, they can be other factors. Be able to write template functions that
works with both the matrix class and with arrays of arrays, or vectors of
vectors, for example.

I don't see any unanswered posters to this thread that refute the claim.

Same.

 

[Noah Roberts]

Daniel T. wrote:
...

Could you? That is the exact question I'm asking. Can you come up with
an [][] interface that is the same for row major, column major and
sparse arrays that works "more directly"?

Why would you think that it can't ?

I don't know if you can or not, I'm asking if you can. The question
wasn't rhetorical, just like last time when you showed me the proxy
solution, I genuinely want to know if it can be done, and if so, what
such a solution would look like.

I already answered your question. You can do so by authoring a maze of
highly coupled classes that access the matrix internals directly....one
set per different way of implenting your matrix.

 

[Daniel T.]

Nothing needs to justify nothing to choose an interface over other when
there are no clear arguments nor experimental data to support the opinion
that the other is better.

Let me try to make my argument more clear... I'm replying here in case
you don't read my reply to Gianni. If you want to reply to this, it
would be easer on me if you replied to that message.

----------------------------------------------------------------------
In some contexts, the best (however one chooses to define best)
implementation is a row major array, in other contexts a column major
array would be better, in yet others, we would be better off with a
sparse array. (I expect there are yet other ways to implement a 2D
array, for example row major ragged and column major ragged, broken up
into blocks like std::deque does...)

As good programmers, we don't worry too much about optimization up
front, we want to just get the stuff working, then change out
implementations to see which one would be better for the particular
situation we find ourselves in. This is where interfaces come in.

We want each of our 2DArray implementations to use the same interface so
that we can easily switch out implementations then profile to see which
implementation is best in our particular context.

The FAQ says this can easily be done with the (,) interface, but it can
only be done with the [][] interface if the latter adapts to the (,)
interface.

Assuming this is correct, there is no reason to use the [][] interface
when the (,) interface is available. (Unless, as pointed out in the FAQ,
one must adapt the interface for legacy code.)

 

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

implementation is best for us. As the FAQ points out, this can easily be
done with the (,) interface, but it can only be done with the [][]
interface if the latter does nothing more than adapt to the (,)
interface.

Please stop repeating the same non-argument.

 

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

The FAQ comes across awefully strong and I can see why someone would
want those points re-worded to be a little less strong. But, remember
that this is an *unofficial FAQ Lite* -- not an official C++ FAQ. As
such, the author has taken some liberty in expressing how he feels
about a particular subject.

This is completely reasonable. However, it is also reasonable that if a
point of him is far away of the consensus of the group, it must be changed,
or people must stop to quote him. The latter will be a shame.

A FAQ, official or not, has not the purpose of generate endlessly
discussions about his points.

 

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

The FAQ says this can easily be done with the (,) interface, but it can
only be done with the [][] interface if the latter adapts to the (,)
interface.
Assuming this is correct, there is no reason to use the [][] interface

The point seems to be: assuming my opinion is correct, then I'm right,
q.e.d.

And even assuming the first sentence is valid, the conclusion is incorrect.
The -> operator for pointers is an adaptation of * and . , but I don't see
nothing proposing to ban his usage for that reason. You can say that -> is
less problematic with precedence... other can say that [ ] [ ] is less
problematic than ( , ) with the comma operator... another endlessly
discussion.

It looks like you and others prefer to never use the [ ] [ ] interface,
which is fine. But also pretend to impose that as the generalized opinion
of the group, which is not. And reasoning in circles will not change this.

 

[Kevin Hall]

This is completely reasonable. However, it is also reasonable that if a
point of him is far away of the consensus of the group, it must be changed,
or people must stop to quote him. The latter will be a shame.

Well, by all means, e-mail the author then. And I would suggest that
anyone who disagrees with the author to do so as well.

Personally though, I don't disagree with the FAQ Lite author. I think
he comes off strong, but I agree with what is written in the FAQ. If
this were part of a FAQ were official (i.e. something that the ISO C++
comittee had published ), then I would expect the language to be
greatly toned down, written more with recommended practice with
reasoning, etc.... But then again the ISO C++ comittee has enough to
worry about already instead of writing FAQs. ;-)