Two Dimensional Array Template

[Daniel T.]

Daniel T. wrote:
...

I already have - multiple times - go re-read the posts. I picked them
apart in a previous post. The only justification the FAQ make is
blatantly false and then it's also debunked by the FAQ itself.

On Jan 3 you said, "The FAQ does state many false claims in support of
the position of using (,) over [][]." How about you state one assertion
that is in the FAQ that you think is false and let's see what happens.
Just one of the many you say exist so we don't get too distracted.

 

[Z.Meson]

The "all true Scotsman" fallacy, you are giving "reasonable" a special
definition.

Please note that I do not give any definition for "reasonable".

[snip]

I also commented, that in reasonable implementations, the proxies are
optimized away. To deal with your contention that there might be an
overhead in using [][] for element access, a much weaker statement would
suffice, namely the existence of implementation that do no incur overhead.

In short, I do not see any "true Scotsman" fallacy in my reasoning.

Now that the fallacy comment is out of the way,...

Hahahaha..... Yes you do give a definition for "reasonable"!!!
According to your statement, a C++ compiler implementation is not
reasonable if it does not optimize away the proxies.

But, as I have pointed out many other times in this thread, not all C++
compilers are great at optimizing. Sure, MSVC, GCC, Intel, Digital
Mars, and Comeau may be. but what about all those embedded compilers
out there. I know Analog Devices has a particularly bad compiler for
their DSP chips -- not only does it do a poor job at optimizing, but in
the times that it does optmize, it sometimes even introduces bugs that
go away when we ask it to not optimize. Are there any other C++
compilers for the Analog Devices DSP chips? Nope, what they provide is
all we've got. Is the Analog Devices compiler "reasonable"? Well, I
won't try to answer that question. But what I can say is that on some
platforms, compilers cannot optimize away these proxy classes and it is
foolish to assume that all compilers available today can. It's also
foolish to tell people that they don't have to worry about the proxy
classes because they *will* be optimized away -- unless you bring into
context the specific compiler and platform and have specific evidence
to back up your claim. While you have provided a code snippet and
timing data to suggest that the proxies get optimized away, you fail to
remind people that this is only a single test for a single compiler for
a single platform. Such results cannot be assumed to be true for all
situations.

Regards,

Kevin Hall

 

[Daniel T.]

From the FAQ: In particular, if these inner array-like objects
end up allocating their own block of memory for their row [or
column] of the matrix, the performance overhead for creating /
destroying your matrix objects can grow dramatically.

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

Note the "if" in the FAQ. In reasonable implementations, there
is no overhead for accessing a single element via a proxy.

The "all true Scotsman" fallacy, you are giving "reasonable" a
special definition.

Please note that I do not give any definition for "reasonable".

Of course you do. By your statement you are implying that any
implementation that does not optimize away the overhead for accessing a
single element via a proxy, no matter how standards conforming, or
amazing it may be otherwise, is not "reasonable".

You cannot state that all possible standards conforming implementations
make such an optimazation. If an implementation doesn't, it isn't
because there is anything wrong with the implementation.

In short, I do not see any "true Scotsman" fallacy in my reasoning.

OK, no "reasonable" Scotsman.

I responded by observing that what you quote from the FAQ is a
conditional statement starting with an "if". Such a statement does
not apply whenever the hypothesis is false.

Agreed. However, do you agree with the statemnt made? Is the statement
itself false or true? The FAQ says that *if* the optimazation is
unavailable, then the proxy solution will be slower. Do you agree with
that?

   (from FAQ 13.12)    If you have a decent compiler and if you
judiciously use inlining,    the compiler should optimize away the
temporary objects. In other    words, the operator[]-approach
above will hopefully not be slower    than what it would have been
if you had directly called    Matrix:perator()(unsigned row,
unsigned col) in the first place. Of    course you could have made
your life simpler and avoided most of the    above work by
directly calling Matrix:perator()(unsigned row,    unsigned col)
in the first place. So you might as well directly call  
 Matrix:perator()(unsigned row, unsigned col) in the first
place.

Is there anything in FAQs 13.10-12 that you specifically object
to? If yes, what is it and why?

I did not address the FAQ. I addressed the virtues of proxies.

In this thread, I have been attempting to defend the veractiy of FAQs
13.10-12.

I think that

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

is much more suggestive notation than

row_of( A, i, j, factor );

Only my refutation of your claim that proxies incur an overhead and
therefore should be avoided for simple element access got us into
FAQ area, and I only responded to the part of the FAQ you quoted.

You were refuting a straw man then. I never claimed that proxies
necessarally incur any overhead. Other than the overhead of actually
writing them of course.

To me the situation looks as follows:

a) proxies provide very useful syntactic sugar for linear algebra.
b) even with very simple minded proxy implementations, [][] is not
slower than (,).

Item (b) is incorrect for all standards conforming compilers, but I will
conceed that it is correct for any compiler you would consider
"reasonable."

As for (a)... Several other languages, including ones that are
spicifically designed for numeric computation and scientific computing
do not use [][]. Beliavsky mentioned in this thread, "[Fortran,] S (the
language of S-Plus and R), Matlab, Python/Numpy, and Visual Basic also
use commas to delimit the dimensions of an array, even when they use []
rather than () to enclose the subscripts. a[j][k] is awkward compared
to a[i,j,k] or a(i,j,k) IMO."

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

So what would be the reason, not to provide [][]? Please note that I
do not claim that one should not provide (,).

Again, the FAQ makes no claim that [][] should *not* be provided.
However,

... you could have made your life simpler and avoided most of the
above work [of making proxies] by directly calling
Matrix:perator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix:perator()(unsigned row,
unsigned col) in the first place."

Do you disagree with the above?

 

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

As for (a)... Several other languages, including ones that are
spicifically designed for numeric computation and scientific computing
do not use [][]. Beliavsky mentioned in this thread, "[Fortran,] S (the
language of S-Plus and R), Matlab, Python/Numpy, and Visual Basic also
use commas to delimit the dimensions of an array, even when they use []
rather than () to enclose the subscripts. a[j][k] is awkward compared
to a[i,j,k] or a(i,j,k) IMO."

But we are talking about C++, and C++ uses [ ] [ ] for arrays of arrays. I
know that "real programmers can write FORTRAN code in any language", of
course, but "real programmers" don't read FAQs.

... you could have made your life simpler and avoided most of the
above work [of making proxies] by directly calling
Matrix:perator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix:perator()(unsigned row,
unsigned col) in the first place."
Do you disagree with the above?

I disagree. If you want, for example, write a template function that works
with the matrix class and with arrays or arrays, not providing a [ ] [ ]
makes life more complicated.

 

[Daniel T.]

... you could have made your life simpler and avoided most of the
above work [of making proxies] by directly calling
Matrix:perator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix:perator()(unsigned row,
unsigned col) in the first place."
Do you disagree with the above?

I disagree. If you want, for example, write a template function that works
with the matrix class and with arrays or arrays, not providing a [ ] [ ]
makes life more complicated.

The FAQ makes an exception for legacy code support so unless you are
advocating that people *should use* raw arrays of arrays in new code, I
don't see where your comment applies. I will accept though that *if* you
disagree with FAQ 34.1, then you probably also disagree with the above
(the tail end of 13.12.) Do you disagree with 34.1? Maybe we should
start a new thread...

"The world already has way too many exposed data structures and way too
many out-of-bounds parameters, and those cost way too much money and
cause way too many delays and way too many defects." -- FAQ 13.12

 

[Kai-Uwe Bux]

From the FAQ: In particular, if these inner array-like objects
end up allocating their own block of memory for their row [or
column] of the matrix, the performance overhead for creating /
destroying your matrix objects can grow dramatically.

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

Note the "if" in the FAQ. In reasonable implementations, there
is no overhead for accessing a single element via a proxy.

The "all true Scotsman" fallacy, you are giving "reasonable" a
special definition.

Please note that I do not give any definition for "reasonable".

Of course you do. By your statement you are implying that any
implementation that does not optimize away the overhead for accessing a
single element via a proxy, no matter how standards conforming, or
amazing it may be otherwise, is not "reasonable".

Although my claim implies that, the statement I made is not a definition. I
am ready to encounter reasonable compilers that do not optimize away the
proxies. As soon as that happens, I will consider my statement refuted. If
that statement was a definition, I would not need to be ready for that
possibility.

Would you care to provide an example of a compiler (reasonable or not) that
does not make the optimization under discussion?

You cannot state that all possible standards conforming implementations
make such an optimazation. If an implementation doesn't, it isn't
because there is anything wrong with the implementation.

The optimization techniques needed to do away with small redundant
temporaries that are introduced by code abstractions such a expression
templates or proxy classes are well known, widely implemented, and by no
means cutting edge technology. I agree, however, that failure to implement
these optimizations by and in itself does not mean a compiler is seriously
flawed. I can certainly picture a reasonable compiler failing in this area.
I just happen to think, that such a compiler (although possible) does not
exist.

OK, no "reasonable" Scotsman.

That a statement has implications (in this case my statement implying that
certain compilers are not reasonable) does not turn it into a definition.
My claim would only be a definition if it was to be considered "true by
stipulation". That, however, I something you read into it. I just claimed
it as "factually true": I have never encountered a compiler that did not
optimize away the temporary proxies involved in the test code; the
optimization techniques involved are by now common knowledge among compiler
writers; and I would be surprised to find a reasonable compiler not
implementing them. Here, I stick in "reasonable" just to exclude student
term projects, proofs of concept, alpha versions, discontinued products,
etc.

Had I meant the statement as a definition, I would have worded it
accordingly: "Let us call a compiler 'reasonable' if it optimizes away
small redundant temporaries such a row proxies used in simple element
access." I did not write that because I did not mean it.

I responded by observing that what you quote from the FAQ is a
conditional statement starting with an "if". Such a statement does
not apply whenever the hypothesis is false.

Agreed. However, do you agree with the statemnt made? Is the statement
itself false or true? The FAQ says that *if* the optimazation is
unavailable, then the proxy solution will be slower. Do you agree with
that?

(from FAQ 13.12)    If you have a decent compiler and if you
judiciously use inlining,    the compiler should optimize away the
temporary objects. In other    words, the operator[]-approach
above will hopefully not be slower    than what it would have been
if you had directly called    Matrix:perator()(unsigned row,
unsigned col) in the first place. Of    course you could have made
your life simpler and avoided most of the    above work by
directly calling Matrix:perator()(unsigned row,    unsigned col)
in the first place. So you might as well directly call
Matrix:perator()(unsigned row, unsigned col) in the first
place.

Is there anything in FAQs 13.10-12 that you specifically object
to? If yes, what is it and why?

I did not address the FAQ. I addressed the virtues of proxies.

In this thread, I have been attempting to defend the veractiy of FAQs
13.10-12.

I think that

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

is much more suggestive notation than

row_of( A, i, j, factor );

Only my refutation of your claim that proxies incur an overhead and
therefore should be avoided for simple element access got us into
FAQ area, and I only responded to the part of the FAQ you quoted.

You were refuting a straw man then. I never claimed that proxies
necessarally incur any overhead. Other than the overhead of actually
writing them of course.

To me the situation looks as follows:

a) proxies provide very useful syntactic sugar for linear algebra.
b) even with very simple minded proxy implementations, [][] is not
slower than (,).

Item (b) is incorrect for all standards conforming compilers,

Did you mean "may be false for some standard conforming compilers"?

Also, do you happen to know an actual standard conforming compiler, for
which the statement (b) is false?

but I will
conceed that it is correct for any compiler you would consider
"reasonable."

You are again misreading my statement for a definition.

As for (a)... Several other languages, including ones that are
spicifically designed for numeric computation and scientific computing
do not use [][]. Beliavsky mentioned in this thread, "[Fortran,] S (the
language of S-Plus and R), Matlab, Python/Numpy, and Visual Basic also
use commas to delimit the dimensions of an array, even when they use []
rather than () to enclose the subscripts. a[j][k] is awkward compared
to a[i,j,k] or a(i,j,k) IMO."

(a) does not talk about [][] versus (,). It talks about the abstraction
benefit that comes with introducing ways of addressing rows and columns of
a matrix. Once you introduce those proxies (for other reasons), operator[]
becomes a nice add-on. There are good reasons to introduce these proxies
independent of supporting [][] notation. Do those languages provide means
for manipulating/addressing rows and columns of a matrix?

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 [][].
Personally, I do not put much weight on this feature. Others, who have a
different code base, however, may find this a major point attracting them
to [][] notation.

So what would be the reason, not to provide [][]? Please note that I
do not claim that one should not provide (,).

Again, the FAQ makes no claim that [][] should *not* be provided.
However,

... you could have made your life simpler and avoided most of the
above work [of making proxies] by directly calling
Matrix:perator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix:perator()(unsigned row,
unsigned col) in the first place."

Do you disagree with the above?

I disagree with the implied statement that life without row and column
proxies would be easier. The simplicity of my life depends not only on the
code that goes into the matrix class. It mostly depends on the readability
of the code that uses the matrix class. The overhead of the row and column
proxies, as explained above, cannot be eliminated without getting rid of
expressions like

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

and

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

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. IMO, how to deal with element
access is a minor issue in the design of a matrix class, and I would just
put in both methods. To be more specific: I would have (,) be provided by a
policy that also defines the storage layout. On top of that, row and column
proxies are realized along with expression template machinery. Then, it is
just a minor add on to have operator[](i) return row(i), following the math
convention that row indices go first.

There are many tricky issues in designing a matrix class (or just its
interface), and the [][] vs (,) issue is none of the interesting ones. The
main flaw of the FAQ is to focus on a minor design issue and draw general
recommendations (e.g., against row proxies) from a rather narrow minded
discussion.


Best

Kai-Uwe Bux

 

[Axter]

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?

To eliminate the humongous learning curve cost of violating a universal
standard.

IMHO, that's a good reason to use common syntax.
I disagree with the C++ FAQ. This FAQ is created by one person, and
its contents are not determined by any formal peer review.
The C++ FAQ is a good guideline, but it should not be taken as
indisputable facts by any measure.


Consider the following methods:
http://code.axter.com/dynamic_2d_array.h
http://www.codeguru.com/forum/showthread.php?t=297838

 

[Axter]

IMHO, these FAQs (13.10, 13.11, 13.12) should be deleted or modified to
include both sides of the view point for using [][] or (,) syntax.
As these FAQs stand right now, they're not written in a manner that
gives factual and BALANCE information.
They're written in a persuasive manner, which only gives one side of
the facts, and builds on a week argument for justifying using the
non-standard syntax.

Case in point:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
[13.10] How do I create a subscript operator for a Matrix class?
When you have multiple subscripts, the cleanest way to do it is with
operator() rather than with operator[]. The reason is that operator[]
always takes exactly one parameter, but operator() can take any number
of parameters.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

At worse, the above comment is false, and at best, it's misleading.
It gives the reader the impression that the [][] syntax can not be
done, and/or that you can't create a matrix class based on that type
of syntax.
That's clearly wrong.

Then FAQ 13.11, makes the justification of using (,) based on
performance tricks, which almost nobody would ever use. I talked to
the author of the C++ FAQ, and the performance trick he was referring
to was highly dependent on a particular hardware and OS. It was not at
all portable.

FAQ [13.12], also makes the following claim:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The problem with the "it's faster" argument is that it's not - at
least not on the latest version of two of the world's best known C++
compilers.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Notice how the author carefully puts this in the context of two
compilers which he fails to specify.
The author and I had emailed back and forth the results of four
different compilers. Some of which contradicts the above FAQ.
He claimed he was going to put the results on the FAQ, but that was
over a year ago, and I still haven't seen anything on it.


These three FAQ really represents one developer's experience which is
not at all representative of the majority of programmers and their
requirements.
Moreover, the FAQ is not posted as factual data, which would involve
information from both sides (balance).
It's an opinionated persuasive FAQ, posted as propaganda for the
operator (,) argument.

Every time this subject comes up, I see plenty of developers arguing
against the non standard operator(,).
Clearly, there is not a consensus on this issue, and (IMHO) the FAQ
author should not write the C++ FAQ in a manner that would imply there
is.

I recommend using standard syntax [][] over the non standard ambiguous
(,) method.

 

[Noah Roberts]

Consider the following methods:
http://code.axter.com/dynamic_2d_array.h
http://www.codeguru.com/forum/showthread.php?t=297838

No, please don't. These "expert" examples are perfect examples of what
NOT to do. A much better way of implementing [][] has already been
discussed in this thread there's no need to degrade it even further.
The serious flaws in the first have been discussed ad nausium and
continue to remain unfixed. It shows numerous mistakes that catch new
developers all the time and should not be passed of as advice
ever...unless it is, "Don't do anything like this."

http://tinyurl.com/yjkzj7

 

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

I disagree. If you want, for example, write a template function that
works with the matrix class and with arrays or arrays, not providing a [
] [ ] makes life more complicated.

The FAQ makes an exception for legacy code support so unless you are
advocating that people *should use* raw arrays of arrays in new code, I
don't see where your comment applies.

I supposed you were clever enough to take an example as an example, and
other messages in this thread already mentioned vectors of vectors, for
example (again).

By the way: are you advocating that people should never use arrays? Why?

"The world already has way too many exposed data structures and way too
many out-of-bounds parameters, and those cost way too much money and
cause way too many delays and way too many defects." -- FAQ 13.12

Because of that? Said I something that implied exposing the data?

 

[Noah Roberts]

I recommend using standard syntax [][] over the non standard ambiguous
(,) method.

There is nothing at all non-standard or ambiguous about function calls.

 

[Axter]

I recommend using standard syntax [][] over the non standard ambiguous
(,) method.

There is nothing at all non-standard or ambiguous about function calls.

It's non-standard in that it's not the standard method for referencing
an array.

Example of ambiguous usage:

x = foofo(1, 3);

Is foofoo a function, or is foofoo an array. The above syntax does not
make that clear.

The following syntax is less ambiguous:
x = foofoo[1][3];

 

[Axter]

Consider the following methods:
http://code.axter.com/dynamic_2d_array.h
http://www.codeguru.com/forum/showthread.php?t=297838

No, please don't. These "expert" examples are perfect examples of what
NOT to do. A much better way of implementing [][] has already been
discussed in this thread there's no need to degrade it even further.
The serious flaws in the first have been discussed ad nausium and
continue to remain unfixed. It shows numerous mistakes that catch new
developers all the time and should not be passed of as advice
ever...unless it is, "Don't do anything like this."

http://tinyurl.com/yjkzj7

Care to give specifics, or do you prefer to remain as ambiguous as the
FAQ on this matter.

 

[Gianni Mariani]

Daniel T. wrote:
....

On Jan 3 you said, "The FAQ does state many false claims in support of
the position of using (,) over [][]." How about you state one assertion
that is in the FAQ that you think is false and let's see what happens.
Just one of the many you say exist so we don't get too distracted.

Read this post:
http://groups.google.com.au/group/comp.lang.c++/msg/c3bbd70542232ca6?dmode=source&hl=en

I explained it all paragraph by paragraph. What more do you want ?

 

[Alf P. Steinbach]

* Axter:

IMHO, these FAQs (13.10, 13.11, 13.12) should be deleted or modified to
include both sides of the view point for using [][] or (,) syntax.
As these FAQs stand right now, they're not written in a manner that
gives factual and BALANCE information.
They're written in a persuasive manner, which only gives one side of
the facts, and builds on a week argument for justifying using the
non-standard syntax.

Case in point:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
[13.10] How do I create a subscript operator for a Matrix class?
When you have multiple subscripts, the cleanest way to do it is with
operator() rather than with operator[]. The reason is that operator[]
always takes exactly one parameter, but operator() can take any number
of parameters.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

At worse, the above comment is false, and at best, it's misleading.
It gives the reader the impression that the [][] syntax can not be
done, and/or that you can't create a matrix class based on that type
of syntax.
That's clearly wrong.

Then FAQ 13.11, makes the justification of using (,) based on
performance tricks, which almost nobody would ever use. I talked to
the author of the C++ FAQ, and the performance trick he was referring
to was highly dependent on a particular hardware and OS. It was not at
all portable.

FAQ [13.12], also makes the following claim:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The problem with the "it's faster" argument is that it's not - at
least not on the latest version of two of the world's best known C++
compilers.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Notice how the author carefully puts this in the context of two
compilers which he fails to specify.
The author and I had emailed back and forth the results of four
different compilers. Some of which contradicts the above FAQ.
He claimed he was going to put the results on the FAQ, but that was
over a year ago, and I still haven't seen anything on it.

It's possible that Marshall hasn't had much time to maintain the FAQ
recently. Keep in mind that there's only so much one person can do.
Let's be grateful that there is a FAQ, and a good one, even if every one
of us, possibly also Marshall himself, disagrees with something...

CC: Marshall.

 

[Daniel T.]

Daniel T. wrote:

From the FAQ: In particular, if these inner array-like objects
end up allocating their own block of memory for their row [or
column] of the matrix, the performance overhead for creating /
destroying your matrix objects can grow dramatically.

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

Note the "if" in the FAQ. In reasonable implementations, there
is no overhead for accessing a single element via a proxy.

The "all true Scotsman" fallacy, you are giving "reasonable" a
special definition.

Please note that I do not give any definition for "reasonable".

Of course you do. By your statement you are implying that any
implementation that does not optimize away the overhead for accessing a
single element via a proxy, no matter how standards conforming, or
amazing it may be otherwise, is not "reasonable".

Although my claim implies that, the statement I made is not a definition. I
am ready to encounter reasonable compilers that do not optimize away the
proxies. As soon as that happens, I will consider my statement refuted. If
that statement was a definition, I would not need to be ready for that
possibility.

Would you care to provide an example of a compiler (reasonable or not) that
does not make the optimization under discussion?

How about g++ with all optimizations turned off. I don't think it makes
the optimization under discussion and yet is a perfectly reasonable and
useful complier.

Can I consider your lack of answer, agreement?

To me the situation looks as follows:

a) proxies provide very useful syntactic sugar for linear algebra.
b) even with very simple minded proxy implementations, [][] is not
slower than (,).

Item (b) is incorrect for all standards conforming compilers,

Did you mean "may be false for some standard conforming compilers"?

I meant "is not true for all possible standards conforming compilers".
So I think that means yes.

Also, do you happen to know an actual standard conforming compiler, for
which the statement (b) is false?

As mentioned above, g++ with all optimizations turned off.

As for (a)... Several other languages, including ones that are
specifically designed for numeric computation and scientific computing
do not use [][]. Beliavsky mentioned in this thread, "[Fortran,] S (the
language of S-Plus and R), Matlab, Python/Numpy, and Visual Basic also
use commas to delimit the dimensions of an array, even when they use []
rather than () to enclose the subscripts. a[j][k] is awkward compared
to a[i,j,k] or a(i,j,k) IMO."

(a) does not talk about [][] versus (,).

So it is irrelevant to the discussion at hand.

Do those languages provide means for manipulating/addressing rows
and columns of a matrix?

Since I was quoting Beliavsky, I will hope he answers. I haven't
programmed in Fortran since the early '80s.

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.

Personally, I do not put much weight on this feature. Others, who have a
different code base, however, may find this a major point attracting them
to [][] notation.
Agreed.

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.

I don't agree here. I will agree that the FAQ creates the impression
that single element access is the main confusion of designing a matrix
class and from the longevity of this thread that assumption seems
justified.

The main flaw of the FAQ is to focus on a minor design issue and
draw general recommendations (e.g., against row proxies) from a
rather narrow minded discussion.

A minor design issue that none the less obviously draws a lot of heat.

Several of us have suggested that a matrix class simply isn't complete
until a function exists for direct single element access (either op() or
some have suggested a named function such as 'at',) you seem to be among
that number. Thus you agree with the FAQ in general. However, a matrix
class can be considered complete without array of array access. As long
as single element access through op() or whatever is implemented, the
proxies can be written as completely separate objects.

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.

As an analogy, it would be like people arguing against having 'empty()'
in container classes because, after all, 'size()' exists and we can
always check 'size()' against 0. 'empty()' was added to containers, and
should be used, because it may be faster in some implementations and
will never be slower.

 

[Daniel T.]

I disagree. If you want, for example, write a template function
that works with the matrix class and with arrays or arrays, not
providing a [][] makes life more complicated.

The FAQ makes an exception for legacy code support so unless you
are advocating that people *should use* raw arrays of arrays in
new code, I don't see where your comment applies.

I supposed you were clever enough to take an example as an example,
and other messages in this thread already mentioned vectors of
vectors, for example (again).

Now that is something that should be in the FAQ but isn't. So many new
programmers ask about how to make a vector of vectors--more than ask how
to sub-script a matrix class...

By the way: are you advocating that people should never use arrays? Why?

Read FAQ 34.1. But let's keep this thread focused on 13.10-12, it's
already too big. If you want to dispute 34.1 start a new thread.

 

[Beliavsky]

Daniel T. wrote:

As for (a)... Several other languages, including ones that are
specifically designed for numeric computation and scientific computing
do not use [][]. Beliavsky mentioned in this thread, "[Fortran,] S (the
language of S-Plus and R), Matlab, Python/Numpy, and Visual Basic also
use commas to delimit the dimensions of an array, even when they use []
rather than () to enclose the subscripts. a[j][k] is awkward compared
to a[i,j,k] or a(i,j,k) IMO."

(a) does not talk about [][] versus (,).

So it is irrelevant to the discussion at hand.

Do those languages provide means for manipulating/addressing rows
and columns of a matrix?

Fortran 90+, Matlab, S, and Python/Numpy allow this, using a[i,:] and
a[:,i] to refer to row or column i, except that Fortran uses () instead
of [] and S uses a[i,] and a[,i], dropping the colon. The languages
also allow one to refer to sections such as a[i1:i2, j1:j2:jstep].

 

[Daniel T.]

Daniel T. wrote:
...

On Jan 3 you said, "The FAQ does state many false claims in support of
the position of using (,) over [][]." How about you state one assertion
that is in the FAQ that you think is false and let's see what happens.
Just one of the many you say exist so we don't get too distracted.

Read this post:
http://groups.google.com.au/group/comp.lang.c++/msg/c3bbd70542232ca6?dmode=sou
rce&hl=en

I explained it all paragraph by paragraph. What more do you want ?

Thanks. When you posted that, I said then that 13.11 specifically says
in its opening paragraph that it is "all about" a specific
implementation of [][], the kind of implementation that started this
thread. You assert in your post that this FAQ doesn't apply to all
possible implementations of [][] and I (and the FAQ itself) agree... it
was never meant to.

You continually agree with the FAQ in detail (witness the code you
posted,) and argue against straw men (the above referenced post,) while
telling us that using a single function call to index into a
multi-dimensional array should not be allowed. You also claim that
others agree with you, but I'm not so sure. The consensus seems to be
that both access methods should be implemented, at least in the two
dimensional case. (Which is not something I agree with, but can accept.)

You say, "there is no good reason to use (,)." The FAQ states numerous
reasons but apparently you don't think any of them are "good". Why is it
that you think an implementor should not allow a user to access a single
element of a multi-dimensional array through a single function call?

 

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

Now that is something that should be in the FAQ but isn't. So many new
programmers ask about how to make a vector of vectors--more than ask how
to sub-script a matrix class...

Interesting observation, but completely unrelated to this thread.

Read FAQ 34.1.

For example the paragraph that says: "Container classes aren't best for
everything, and sometimes you may need to use arrays."?

But let's keep this thread focused on 13.10-12, it's already too big. If
you want to dispute 34.1 start a new thread.

Looks to me that is you who wants to discuss that point. It does not
advocate that people should never use arrays, then I don't see why you
refer to it as an answer to my question.