http://groups.google.com/group/comp....092f0f6c9bf13a
I think that the operator[]() member function does not work correctly, does
anyone else know how to make a template for making two dimensional arrays from
std::vectors ??? I want to use normal Array[ROW][COL] Syntax.
Jan 1 '07
272  13849 
On Fri, 05 Jan 2007 09:27:40 +0000, Simon G Best wrote:
Also, the argument occasionally put forward that [][] isn't worth the
trouble of implementing is also
Lionel B wrote:
>On Thu, 04 Jan 2007 23:58:53 +0100, Julián Albo wrote:
>>Daniel T. wrote:
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.
No, reread the quoted statement more carefully. The point being made was:
assuming the *FAQ* is correct there is no reason to use the [][] interface.
It seems to me that the portion of the FAQ (or at least the interpretation
of the FAQ) quoted by Daniel T actually comprises two distinct claims:
(1) that (,) can easily provide an interface to a range of matrix
implementations such as row major, column major, sparse, ...
(2) that any implementation of [][] with similar capabilities will
inevitably be a "wrapper" (via proxies or whatever) for a (,) interface.
If both of these claims *are* correct then the statement "there is no
reason to use the [][] interface" becomes harder to argue against - except,
perhaps, for reasons of legacy code support or deep emotional attachment
to an alternate syntax.
Now no-one seems to have argued against point (1). Daniel T, on the other
hand, has requested (ad nauseam) that someone provide a convincing
refutation of point (2); I don't believe anyone has yet provided one.
Indeed, (1) is not in dispute. (2) isn't really in dispute, either.
What /is/ in dispute is whether or not we should be deciding what shall
and shall not go in the interface on the basis of such implementational
issues as in (2). (2) should be rejected as /irrelevant/ (*not*
incorrect) to the question of whether or not the interface should
support [][]. We should be looking at the issue from the outside, *not*
the inside.
[Excuse me for basically repeating my reply to a previous post of yours in
this thread.]
I agree *in general* - however there is one circumstance where I *would*
base interface on implementation, and that's where there is no reason
*not* to; eg. if there is no reason to prefer (,) over [][] or vice-versa
on any other grounds, then I will go with the interface which is *simpler
to implement* - namely (,). After all, why complicate life unnecessarily?
But Daniel T keeps banging on about (2), though :-(
I think for the above reason.
--
Lionel B
Simon G Best <si**********@btinternet.comwrote:
Daniel T. wrote:
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.
So, you're deciding what should go in the interface on the basis of
implementation?
Close. I'm deciding on what should go in the interface on the basis of
its flexibility in hiding the details of the implementation. I.E., on
its ability to abstract the problem space.
The interface that allows the most implementation flexibility with the
least effort is the better interface. Now in many cases, there may be
some tension between "flexibility" and "effort" (i.e., a question as to
whether the extra effort is worth the extra flexibility,) but in this
case (with the exception of legacy code situations) the more flexible
interface actually requires *less* effort.
Lionel B wrote:
On Fri, 05 Jan 2007 08:26:57 +0000, Simon G Best wrote:
....
>So, you're deciding what should go in the interface on the basis of
implementation? That *is* what you're doing.
Yes he is; judging by his previous posts, he would seem to be doing so on
the following basis: "all else being equal" - i.e. if there is no especial
reason[1] to use an alternate interface - we may as well go with the
interface that is simplest in terms of implementation. I don't see
anything wrong with that.
[1] eg. legacy code support, coders' sentimental attachment to a different
syntax, ...
Not all else /is/ equal in this case. operator[] for the whole,
two-dimensional array presents that array as a one-dimensional array of
rows. With suitable proxies, including operator[], each row is
presented as a one-dimensional array. [][] is just a special case of
use where the second [] happens to immediately follow the first. (The
two []s could easily be applied in different functions.) (,) doesn't
present two-dimensional arrays in that way. (With (,), it's a single
call. Both subscripts have to be provided together. You can't provide
one in one function, and the second in another.)
[]-style subscripting seems to be the more general of the two, with (,)
being (almost) equivalent to just a special case of []-style subscripting.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Daniel T. wrote:
Simon G Best <si**********@btinternet.comwrote:
....
>So, you're deciding what should go in the interface on the basis of
implementation?
Close. I'm deciding on what should go in the interface on the basis of
its flexibility in hiding the details of the implementation. I.E., on
its ability to abstract the problem space.
Since, as you've pointed out so many times, []-style subscripting can be
implemented in terms of (,), []-style subscripting must be at least as
flexible "in hiding the details of the implementation" as (,). (That
was the whole point of all that proxy stuff!!!)
The interface that allows the most implementation flexibility with the
least effort is the better interface. Now in many cases, there may be
some tension between "flexibility" and "effort" (i.e., a question as to
whether the extra effort is worth the extra flexibility,) but in this
case (with the exception of legacy code situations) the more flexible
interface actually requires *less* effort.
That's assuming that (,) is more flexible, but it isn't. Your own,
oft-repeated argument of [][] boiling down to (,) is persuasive on that
matter.
Also, something you seem to be stuck on is the idea that the two []s
have to go together. They don't. The first can be in one function, and
the second in another. And, as you /can/ use them together, [][]-style,
the []-style interface is actually /more/ general than (,), and no less
flexible.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Lionel B wrote:
>
[Excuse me for basically repeating my reply to a previous post of yours in
this thread.]
No worries. I believe I've just replied to that other post :-)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Lionel B wrote:
>>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.
No, reread the quoted statement more carefully. The point being made was:
assuming the *FAQ* is correct there is no reason to use the [][]
interface.
Yes, but the point is made by people that agree with that point of the
document, then I assume is also his own opinion. In other words, the
reasoning is: assuming that the point of the FAQ that says there is no
reason to use [ ] [ ] is correct, then there is no reason to use [ ] [ ]
q.e.d.
It seems to me that the portion of the FAQ (or at least the interpretation
of the FAQ) quoted by Daniel T actually comprises two distinct claims:
(1) that (,) can easily provide an interface to a range of matrix
implementations such as row major, column major, sparse, ...
I think nobody question that point... Well, maybe a novice can question
the "easily" part ;-)
(2) that any implementation of [][] with similar capabilities will
inevitably be a "wrapper" (via proxies or whatever) for a (,) interface.
This is the point that has been repeated ad nauseam in this thread, but
nobody proved it nor explained his meaning. What will be the way to
establish if some implementation is a wrapper or other or not, other than
see it explicitly done that way in the code?
If both of these claims *are* correct then the statement "there is no
reason to use the [][] interface" becomes harder to argue against -
except, perhaps, for reasons of legacy code support or deep emotional
attachment to an alternate syntax.
And this is a totally subjective and unproved claim, togeher with an
ad-hominem argument, and a conclussion that is no direct consequence of the
premises.
Daniel T, on the other hand, has requested (ad nauseam) that someone
provide a convincing refutation of point (2); I don't believe anyone has
yet provided one.
Can you provide a convincing refutation of the claim "In a planet near
Sirius there are an ancient civiliaztion of reptilian looking creatures"? I
suppose no. But the absence of that refutation does not prove the claim is
true.
But if you ask for one, you must establish the conditions to distinguish
what is "really a wrapper of" and what is not. Otherwise you are asking for
another endlessly discussion that will not convince nobody.
And even supposing the claim were true, that is not a reason to ban the
usage of other syntax. There are many cases in C++ where alternative syntax
peacefully coexist.
--
Salu2
On Fri, 05 Jan 2007 15:01:51 +0000, Simon G Best wrote:
Lionel B wrote:
>On Fri, 05 Jan 2007 08:26:57 +0000, Simon G Best wrote:
...
>>So, you're deciding what should go in the interface on the basis of
implementation? That *is* what you're doing.
Yes he is; judging by his previous posts, he would seem to be doing so on
the following basis: "all else being equal" - i.e. if there is no especial
reason[1] to use an alternate interface - we may as well go with the
interface that is simplest in terms of implementation. I don't see
anything wrong with that.
[1] eg. legacy code support, coders' sentimental attachment to a different
syntax, ...
Not all else /is/ equal in this case.
What is "this case"?
operator[] for the whole, two-dimensional array presents that array as a
one-dimensional array of rows. With suitable proxies, including
operator[], each row is presented as a one-dimensional array. [][] is
just a special case of use where the second [] happens to immediately
follow the first. (The two []s could easily be applied in different
functions.) (,) doesn't present two-dimensional arrays in that way.
"in that way" = "with the same interface syntax". *If* you require the
above functionality - and you may not - then you can implement it equally
with an operator(,), perhaps via row() and col() calls. The syntax then may
of course be different.
(With (,), it's a single call. Both subscripts have to be provided
together. You can't provide one in one function, and the second in
another.)
You can provide row() and col() interfaces.
[]-style subscripting seems to be the more general of the two, with (,)
being (almost) equivalent to just a special case of []-style subscripting.
....or vice-versa ;) I think we'll have to agree to disagree here.
--
Lionel B
Lionel B wrote:
On Fri, 05 Jan 2007 15:01:51 +0000, Simon G Best wrote:
>Not all else /is/ equal in this case.
What is "this case"?
Having operator[] return a proxy which has its own operator[] (and
perhaps other stuff, such as iterators,) compared with having operator()
take both subscripts together.
>operator[] for the whole, two-dimensional array presents that array as a
one-dimensional array of rows. With suitable proxies, including
operator[], each row is presented as a one-dimensional array. [][] is
just a special case of use where the second [] happens to immediately
follow the first. (The two []s could easily be applied in different
functions.) (,) doesn't present two-dimensional arrays in that way.
"in that way" = "with the same interface syntax". *If* you require the
above functionality - and you may not - then you can implement it equally
with an operator(,), perhaps via row() and col() calls. The syntax then may
of course be different.
"operator(,)"? In this thread, we've ended up with "(,)" being short
for "a(i, j)"-style subscripting, with "[][]" being short for
"a[i][j]"-style. If you're doing, say, a.row(i), that's not (,)-style.
Of course, you can overload operator() to take just the first
subscript, but then that's []-style with () for [], and is still not
(,)-style.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best <si**********@btinternet.comwrote:
Daniel T. wrote:
Simon G Best <si**********@btinternet.comwrote:
...
So, you're deciding what should go in the interface on the basis of
implementation?
Close. I'm deciding on what should go in the interface on the basis of
its flexibility in hiding the details of the implementation. I.E., on
its ability to abstract the problem space.
Since, as you've pointed out so many times, []-style subscripting can be
implemented in terms of (,), []-style subscripting must be at least as
flexible "in hiding the details of the implementation" as (,). (That
was the whole point of all that proxy stuff!!!)
As flexible, but no more so. See below...
The interface that allows the most implementation flexibility with the
least effort is the better interface. Now in many cases, there may be
some tension between "flexibility" and "effort" (i.e., a question as to
whether the extra effort is worth the extra flexibility,) but in this
case (with the exception of legacy code situations) the more flexible
interface actually requires *less* effort.
That's assuming that (,) is more flexible, but it isn't. Your own,
oft-repeated argument of [][] boiling down to (,) is persuasive on that
matter.
I do not dispute that the [][] interface provided by both the FAQ and
Gianni is as flexible as the (,) interface provided by the FAQ. However,
the [][] interface provided does not add flexibility and it requires
*more* effort to create than the (,) interface provided (except in
legacy code situations.) As I say above, when comparing two equally
flexible interfaces, the one that requires less effort is the better
interface.
Simon G Best wrote:
Noah Roberts wrote:
First, might has no place in design questions. There is no "might".
There is, and there is not. Either you have a requirement for the
interface or you do not.
Okay, Yoda, let me put it like this.
Two-dimensional arrays should be presented as two-dimensional arrays.
Which is why I didn't bring up the point to the OP. The discussion is
now about "matrices". A two dimensional array class doesn't do enough
to warrant its existance.
Two-dimensional arrays are both arrays of rows /and/ arrays of columns,
No, they are one or the other, not both. Common convention says they
are arrays of rows.
and they should be presented as such. It's conventional to subcript
arrays through operator[], so operator[] should be provided for the
array-of-rows and array-of-colums views of two-dimensional arrays.
You can only do it once. You can't do it for both. Why should one get
preference over the other?
In general, there's no reason to provide it for one view
and not the other, or to give preference to one view over the other.
(This is, I think, a much better argument against operator[] /as
considered in this thread/ than many of the other arguments offered.)
Yeah, I made it a long time ago. I guess you're not paying attention.
>
One way we could solve this problem is to derive our two-dimensional
array class from two interface-providing bases, one for the
array-of-rows view and one for the array-of-columns view. Each base
would then provide its own operator[] accordingly, as would the proxies
likely to be returned.
Yeah because calling mtx.(ColMjr::operator[])(5)[4], or
static_cast<ColMjr&>(mtx)[5][4] is so much more convenient than
mtx.row(5).value(4)
You guys are just too operator happy for your own good.
Julián Albo <JU********@terra.eswrote:
Lionel B wrote:
(2) that any implementation of [][] with similar capabilities will
inevitably be a "wrapper" (via proxies or whatever) for a (,) interface.
This is the point that has been repeated ad nauseam in this thread, but
nobody proved it nor explained his meaning. What will be the way to
establish if some implementation is a wrapper or other or not, other than
see it explicitly done that way in the code?
Julián, please see earlier in the thread where Gianni provided the [][]
interface that was a wrapper for the (,) interface. Alternatively, you
can follow the explanation for that interface given in the FAQ at the
bottom of question 13.12
And even supposing the claim were true, that is not a reason to ban the
usage of other syntax. There are many cases in C++ where alternative syntax
peacefully coexist.
I'm not looking to ban anything, nor does the FAQ attempt to ban
anything. Some people have taken exception to FAQ questions 13.10-12
while not denying anything claimed in them. That is irrational.
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
with the FAQ in this area, I would like to know what it is.
Interesting...
Daniel T. wrote:
Simon G Best <si**********@btinternet.comwrote:
>Daniel T. wrote:
>>Simon G Best <si**********@btinternet.comwrote:
...
>>>So, you're deciding what should go in the interface on the
basis of implementation?
Close. I'm deciding on what should go in the interface on the
basis of its flexibility in hiding the details of the
implementation. I.E., on its ability to abstract the problem
space.
Since, as you've pointed out so many times, []-style subscripting
can be implemented in terms of (,), []-style subscripting must be
at least as flexible "in hiding the details of the implementation"
as (,). (That was the whole point of all that proxy stuff!!!)
As flexible, but no more so. See below...
In the following, I note that you'd previously said, "the more flexible
interface actually requires *less* effort".
>>The interface that allows the most implementation flexibility
with the least effort is the better interface. Now in many cases,
there may be some tension between "flexibility" and "effort"
(i.e., a question as to whether the extra effort is worth the
extra flexibility,) but in this case (with the exception of
legacy code situations) the more flexible interface actually
requires *less* effort.
You now say:-
I do not dispute that the [][] interface provided by both the FAQ and
Gianni is as flexible as the (,) interface provided by the FAQ.
So, when it comes to flexibility *"in hiding the details of the
implementation"*, you do now accept that the (,)-style interface is no
more flexible than the []-style.
However, the [][] interface provided does not add flexibility and it
requires *more* effort to create than the (,) interface provided
(except in legacy code situations.) As I say above, when comparing
two equally flexible interfaces, the one that requires less effort is
the better interface.
It certainly adds no extra flexibility *"in hiding the details of the
implementation"*, but /it is a more general interface/ - something
you've conveniently snipped and ignored. Unsnipping it, I'd said:-
>Also, something you seem to be stuck on is the idea that the two []s
have to go together. They don't. The first can be in one function,
and the second in another. And, as you /can/ use them together,
[][]-style, the []-style interface is actually /more/ general than
(,), and no less flexible.
That's "/more/ general" *not* in the sense of /implementation/
flexibility, but in the sense of *use.*
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best wrote:
Also, something you seem to be stuck on is the idea that the two []s
have to go together. They don't. The first can be in one function,
and the second in another. And, as you /can/ use them together,
[][]-style, the []-style interface is actually /more/ general than
(,), and no less flexible.
That's "/more/ general" *not* in the sense of /implementation/
flexibility, but in the sense of *use.*
No it isn't. It is less flexible because you can't directly access any
given data coordinate without the unnecissary 2nd call and possible
creation of an extraneous proxy instance. It is also incapable of
expressing the function of both column and row but instead limited to
one or the other.
Without f(,) and f() the [][] interface is incomplete. With them the
[][] interface is just extra fluf. When and if the [][] is necissary
and the dependency can't be fixed you can wrap your abstraction in
something that provides it with minor work as Gianni showed (with the
minor modification that the first op[] doesn't have to be in the main
interface):
template < typename T >
class RowMjr
{
T & abstraction;
public:
RowMjr(T & t) : abstraction(t) {}
row_proxy operator[] (int x) { return abstraction.row(x); }
};
similarly for ColMjr. Now "legacy code" (that likely needs changes to
work with templates instead of assuming arrays now anyway) can be used
with a little less modification.
Any raw array of arrays can also be easily wrapped to adhere to the
abstraction's interface.
The fact is, the legacy issue is a non-issue. If you aren't worried
about the extra proxy class then you can't exactly be too worried about
tiny wrapper either. You can use adapters for either interface. It's
all a case of what is simpler. When starting from scratch there is no
need for the extra complexity and vagueness of your [] overloads. When
working with legacy issues it's a balancing act...there is no reason to
believe that [] overloads are any better without knowing the specifics
of the problem.
:-(
Noah Roberts wrote:
Simon G Best wrote:
....
>Two-dimensional arrays are both arrays of rows /and/ arrays of columns,
No, they are one or the other, not both. Common convention says they
are arrays of rows.
xxxxx
xxxxx
xxxxx
xxxxx
It's both. It can be viewed both ways, but it's still the same thing.
>and they should be presented as such. It's conventional to subcript
arrays through operator[], so operator[] should be provided for the
array-of-rows and array-of-colums views of two-dimensional arrays.
You can only do it once. You can't do it for both. Why should one get
preference over the other?
Once for each view. Base classes and proxies would both work for that.
>In general, there's no reason to provide it for one view
and not the other, or to give preference to one view over the other.
(This is, I think, a much better argument against operator[] /as
considered in this thread/ than many of the other arguments offered.)
Yeah, I made it a long time ago. I guess you're not paying attention.
Perhaps I missed it.
>One way we could solve this problem is to derive our two-dimensional
array class from two interface-providing bases, one for the
array-of-rows view and one for the array-of-columns view. Each base
would then provide its own operator[] accordingly, as would the proxies
likely to be returned.
Yeah because calling mtx.(ColMjr::operator[])(5)[4], or
static_cast<ColMjr&>(mtx)[5][4] is so much more convenient than
mtx.row(5).value(4)
I've already suggested row(), col(), and the like, in previous posts.
What was that about not paying attention?
You guys are just too operator happy for your own good.
array_of_columns &a(mtx); // Taking the array-of-columns view.
foo(a);
bar(a[5]);
baz(a.begin(), a.end());
qux(a[3].begin(), a[3].end());
for (array_of_columns::size_type i(0); i < a.size(); ++i) quux(a[i]);
....
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Noah Roberts wrote:
Simon G Best wrote:
>>>Also, something you seem to be stuck on is the idea that the two []s
have to go together. They don't. The first can be in one function,
and the second in another. And, as you /can/ use them together,
[][]-style, the []-style interface is actually /more/ general than
(,), and no less flexible.
That's "/more/ general" *not* in the sense of /implementation/
flexibility, but in the sense of *use.*
No it isn't. It is less flexible because you can't directly access any
given data coordinate without the unnecissary 2nd call and possible
creation of an extraneous proxy instance. It is also incapable of
expressing the function of both column and row but instead limited to
one or the other.
Okay. Fortunately I'm already in favour of including (,) in the
interface :-)
....
If you aren't worried
about the extra proxy class then you can't exactly be too worried about
tiny wrapper either.
....
Wrappers sound fine to me :-)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon,
Let me put this in a simple manor with a code example.
class array {
public:
// constructor(s) as necessary
int& operator[]( unsigned i );
};
class array2Da {
public:
// constructor(s) as necessary
array& operator[]( unsigned i );
array& col( unsigned i );
};
class array2Db {
public:
// constructor(s) as necessary
array& row( unsigned i );
array& col( unsigned i );
int& operator()( unsigned i, unsigned j );
};
Which of the two interfaces (array2Da or array2Db) are better, or is
neither better than the other?
IMO and according to the FAQ, array2Db is the better interface and
frankly, no one, AFAICT and despite all the protestations, has claimed
that array2Da is better except for Peter (the OP of this thread) in his
initial post, and he never justified his reasons for believing so.
Even Gianni, when pressed to actually show an implementation, provided
one that had array2Db as its interface (though he maintained the name
op[] rather than switch to "row".)
class array2Dc {
public:
// constructor(s) as necessary
array& operator[]( unsigned i );
array& col( unsigned i );
int& operator()( unsigned i, unsigned j );
};
The above is Gianni's interface proposal (and the one outlined in FAQ
13.12.) Now, given the above interface, if you want to access a single
element in the array, what is the best method in doing so?
Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.
Wow, I think you've really misunderstood me.
Daniel T. wrote:
....
>
Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.
No, I really think you've got that wrong. Just because there are some
of us who disagree with your reasons for objecting to the inclusion of
[]s, it doesn't mean that we're objecting to the inclusion and use of
(,). Indeed, as I'm sure I've already said in this thread, I'm in
favour of (,). Just because you think it has to be either [][] or (,),
it doesn't mean the rest of us do, too.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best <si**********@btinternet.comwrote:
Daniel T. wrote:
Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.
No, I really think you've got that wrong. Just because there are some
of us who disagree with your reasons for objecting to the inclusion of
[]s, it doesn't mean that we're objecting to the inclusion and use of
(,).
I have not objected to the inclusion of []s in the interface. The FAQ
also doesn't object to the inclusion of []s in the interface (it even
mentions it as an option.) What I, and the FAQ, object to is people who
think [][] should be the only method provided to access a single element
of a 2D array.
Just because you think it has to be either [][] or (,), it doesn't
mean the rest of us do, too.
When the user of the array wants to access one element of a 2D array, he
must either use [][] or (,) (assuming both are available,) so yes it has
to be either [][] or (,). In that case, the (,) is the best choice for
the user. To deny him that choice (the best choice) is silly.
Let me ask you directly. After reading the FAQs 13.10-12, is there
anything you spicifically object to? There has been a lot of heat in
this thread about those FAQs yet *no one*, not even Gianni has pointed
to any paragraph in any of those questions and said, "this is wrong."
The question above goes out to everybody. If no one objects to any part
of the FAQs in question, I don't see why there is so much heat over them.
Daniel T. wrote:
Simon G Best <si**********@btinternet.comwrote:
>Daniel T. wrote:
>>Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.
No, I really think you've got that wrong. Just because there are some
of us who disagree with your reasons for objecting to the inclusion of
[]s, it doesn't mean that we're objecting to the inclusion and use of
(,).
I have not objected to the inclusion of []s in the interface.
Who are you trying to kid?
If you're objecting to having [][] in the interface, you /are/ objecting
to the inclusion of the []s, *because that's all that [][] is!* And you
most certainly have objected, as you've previously given the extra
complexity of implementing them as a reason for not having them.
The FAQ
also doesn't object to the inclusion of []s in the interface (it even
mentions it as an option.) What I, and the FAQ, object to is people who
think [][] should be the only method provided to access a single element
of a 2D array.
Again, who are you trying to kid?
What you've done, in previous posts, is to argue against /including/
[][]. That's not the same as merely objecting to the idea that [][]
should be the /only/ method.
>Just because you think it has to be either [][] or (,), it doesn't
mean the rest of us do, too.
When the user of the array wants to access one element of a 2D array, he
must either use [][] or (,) (assuming both are available,) so yes it has
to be either [][] or (,). In that case, the (,) is the best choice for
the user. To deny him that choice (the best choice) is silly.
Oh, come on! Do you /really/ think that's what I meant? That it's
possible to use [][] and (,) simultaneously for the same, single access
operation? Huh?
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best <si**********@btinternet.comwrote:
Daniel T. wrote:
I have not objected to the inclusion of []s in the interface.
Who are you trying to kid?
Quotes from me:
(Jan 1)
Read the following two FAQs before making such a mistake. [The FAQs
in question are 13.10-12 and the mistake in question was to create a
class that didn't have any means to access a single element except
through [][] ].
(Jan 4)
...there is no reason to use the [][] interface when the (,)
interface is available. [Note: I said "use", not "include".]
(Jan 5)
I'm not looking to ban anything, nor does the FAQ attempt to ban
anything.
However, I have no interest in arguing with you about what I really
meant. I'm willing to accept that I have been unable to articulate my
position well enough. Hence the reason I kept trying to clarify it.
Daniel T. wrote:
Julián Albo <JU********@terra.eswrote:
>Lionel B wrote:
>>(2) that any implementation of [][] with similar capabilities will
inevitably be a "wrapper" (via proxies or whatever) for a (,) interface.
This is the point that has been repeated ad nauseam in this thread, but
nobody proved it nor explained his meaning. What will be the way to
establish if some implementation is a wrapper or other or not, other than
see it explicitly done that way in the code?
Julián, please see earlier in the thread where Gianni provided the [][]
interface that was a wrapper for the (,) interface. Alternatively, you
can follow the explanation for that interface given in the FAQ at the
bottom of question 13.12
You seem to have a very narrow perspective of the example. Why do you
insist on believing that [][] must be a wrapper to (,) ?
>
>And even supposing the claim were true, that is not a reason to ban the
usage of other syntax. There are many cases in C++ where alternative syntax
peacefully coexist.
I'm not looking to ban anything, nor does the FAQ attempt to ban
anything. Some people have taken exception to FAQ questions 13.10-12
while not denying anything claimed in them. That is irrational.
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
with the FAQ in this area, I would like to know what it is.
Gianni Mariani <gi*******@mariani.wswrote:
Daniel T. wrote:
Julián Albo <JU********@terra.eswrote:
Lionel B wrote:
>
(2) that any implementation of [][] with similar capabilities
will inevitably be a "wrapper" (via proxies or whatever) for a
(,) interface.
>
This is the point that has been repeated ad nauseam in this
thread, but nobody proved it nor explained his meaning. What
will be the way to establish if some implementation is a wrapper
or other or not, other than see it explicitly done that way in
the code?
Julián, please see earlier in the thread where Gianni provided the
[][] interface that was a wrapper for the (,) interface.
Alternatively, you can follow the explanation for that interface
given in the FAQ at the bottom of question 13.12
You seem to have a very narrow perspective of the example. Why do
you insist on believing that [][] must be a wrapper to (,) ?
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
with the FAQ in this area, I would like to know what it is.
Up to this point, you have not denied any spcific claim made by the FAQ,
you have simply said you don't like it, while at the same time you
posted code that specifically conforms to the FAQ.
Daniel T. wrote:
Simon G Best <si**********@btinternet.comwrote:
>Daniel T. wrote:
>>I have not objected to the inclusion of []s in the interface.
Who are you trying to kid?
Quotes from me:
....
>
(Jan 4)
...there is no reason to use the [][] interface when the (,)
interface is available. [Note: I said "use", not "include".]
Yet you'd previously given the extra effort of implementing the []s as a
reason against them. At least, that appeared to be the case, such as in
the following:-
(Jan 5)
So, you're deciding what should go in the interface on the basis
of implementation?
Close. I'm deciding on what should go in the interface on the basis
of its flexibility in hiding the details of the implementation.
I.E., on its ability to abstract the problem space.
The interface that allows the most implementation flexibility with
the least effort is the better interface. Now in many cases, there
may be some tension between "flexibility" and "effort" (i.e., a
question as to whether the extra effort is worth the extra
flexibility,) but in this case (with the exception of legacy code
situations) the more flexible interface actually requires *less*
effort.
And:-
(Also Jan 5)
I do not dispute that the [][] interface provided by both the FAQ
and Gianni is as flexible as the (,) interface provided by the FAQ.
However, the [][] interface provided does not add flexibility and it
requires *more* effort to create than the (,) interface provided
(except in legacy code situations.) As I say above, when comparing
two equally flexible interfaces, the one that requires less effort
is the better interface.
All the extra effort is in the implementing, /not/ the use.
I'm done with this.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best wrote:
Wow, I think you've really misunderstood me.
Daniel T. wrote:
...
Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.
No, I really think you've got that wrong. Just because there are some
of us who disagree with your reasons for objecting to the inclusion of
[]s, it doesn't mean that we're objecting to the inclusion and use of
(,). Indeed, as I'm sure I've already said in this thread, I'm in
favour of (,). Just because you think it has to be either [][] or (,),
it doesn't mean the rest of us do, too.
There is no reason to have two functions that do the same thing. You
should really pick one or the other. If there is a legacy issue it
should be deemed deprecated and only included for backwards compat.
All code using the function in question should be changed.
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
>Noah Roberts wrote:
Julián Albo wrote:
Noah Roberts wrote:
Since [][] is a chaining of function calls, and not a single
call, it requires an additional object which (,) does not.
[][] requires this extra object while (,) simply does not
preclude it. Since it requires less and imposes no more it is
the more abstract solution.
This is a detail of the implementation that has no relation with
the level of abstraction.
The extra object is exposed in the interface. If it has no
relation to the abstraction it has no business in the interface
and again (,) is the better alternative.
But of course row proxies have a relation to the matrix abstraction.
What makes a matrix a 2-dimensional array is that it has rows and
columns. Any interface that does not provide a way of addressing
these important sum-matrices as some type of vector is very
low-level.
The matrix class I use has row and column proxies. You can get a row
by the row() method and a column by the column() method. It happens
that operator[] returns a row proxy. The main advantage of the proxy
classes is not that they allow [][] notation but lies in the way
they enrich the interface.
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 proxy gets
optimized away by any modern compiler. Please have a look at my exchange
with Alf Steinbach on this matter: http://groups.google.com/group/comp....cce09e32c2dfc6
Best
Kai-Uwe Bux
Noah Roberts wrote:
>
Kai-Uwe Bux wrote:
>Noah Roberts wrote:
>
Julián Albo wrote:
Noah Roberts wrote:
Since [][] is a chaining of function calls, and not a single call,
it
requires an additional object which (,) does not. [][] requires
this
extra object while (,) simply does not preclude it. Since it
requires less and imposes no more it is the more abstract solution.
This is a detail of the implementation that has no relation with the
level of abstraction.
The extra object is exposed in the interface. If it has no relation to
the abstraction it has no business in the interface and again (,) is
the better alternative.
But of course row proxies have a relation to the matrix abstraction. What
makes a matrix a 2-dimensional array is that it has rows and columns. Any
interface that does not provide a way of addressing these important
sum-matrices as some type of vector is very low-level.
The matrix class I use has row and column proxies. You can get a row by
the row() method and a column by the column() method. It happens that
operator[] returns a row proxy. The main advantage of the proxy classes
is not that they allow [][] notation but lies in the way they enrich the
interface. For instance, I can say
swap( A.row(i), A.row(j) );
Yes, accessing row and column objects is likely needed in a matrix.
You are likely to want both at different times. For instance,
multiplying two matrices involves taking a row from one site, a column
from another, multiplying them and repeating. So there should be a
column vector object as well. Since there are two, and only one
operator[], it makes more sense to do what you have done above and not
pick one to get the [] interface.
Like Daniel said as well, there if there is no need you shouldn't have
to pay the cost. This is rather fundamental to C++. If you don't need
row/column objects you shouldn't have to allocate them.
In my experience, compilers optimize away the proxy objects if you just use
them to access a matrix coefficient. See http://groups.google.com/group/comp....cce09e32c2dfc6
for some measurements.
Yes, this can
be sped up quite a bit through even more complexity and become a rather
negligable cost in runtime but the principles still hold.
The test code I used in that thread is totally straight forward. In my
experience, there is no runtime overhead for [][] even for the most
straight forward implementations of row and column proxies.
Best
Kai-Uwe Bux
Daniel T. wrote:
....
>
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
with the FAQ in this area, I would like to know what it is.
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.
>
Up to this point, you have not denied any spcific claim made by the FAQ,
you have simply said you don't like it, while at the same time you
posted code that specifically conforms to the FAQ.
What are you smoking, really! I want some.
Kai-Uwe Bux <jk********@gmx.netwrote:
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.
(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::operator()(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::operator()(unsigned row,
unsigned col) in the first place. So you might as well directly call
Matrix::operator()(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?
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
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".
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.
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, I just would like to
reiterate the point that the fear of overhead in [][] over (,) is
unfounded. I provided a reference for a post where I backed up that claim
with empirical data. Of course, such claims and measurements are compiler
specific. I would appreciate if someone could show an optimizing compiler
that makes [][] slower than (,) given the simple implementation from http://groups.google.com/group/comp....cce09e32c2dfc6
* *(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::operator()(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::operator()(unsigned row,
* *unsigned col) in the first place. So you might as well directly call
* *Matrix::operator()(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. 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.
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 (,).
So what would be the reason, not to provide [][]? Please note that I do not
claim that one should not provide (,).
Best
Kai-Uwe Bux
Kai-Uwe Bux wrote:
Now that the fallacy comment is out of the way, I just would like to
reiterate the point that the fear of overhead in [][] over (,) is
unfounded. I provided a reference for a post where I backed up that claim
with empirical data.
By the way, the usage of a class that provides a [ ] [ ] interface
implemented with proxies together with other way without proxies does not
harm even in the case of people with compilers unable to do a good
optimization of the proxies used. They are not forced to use the [ ] [ ]
syntax just because exists.
--
Salu2
Gianni Mariani <gi*******@mariani.wswrote:
Daniel T. wrote:
...
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
with the FAQ in this area, I would like to know what it is.
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.
Kai-Uwe Bux wrote:
Daniel T. wrote:
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
Kai-Uwe Bux <jk********@gmx.netwrote:
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
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::operator()(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::operator()(unsigned row, * *unsigned col)
in the first place. So you might as well directly call *
*Matrix::operator()(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[i][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::operator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix::operator()(unsigned row,
unsigned col) in the first place."
Do you disagree with the above? Z.*****@gmail.com wrote:
>
Kai-Uwe Bux wrote:
>Daniel T. wrote:
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.
Nope. It is not a definition. It is a claim. I can easily be proven wrong if
someone shows a reasonable compiler that does not optimize away the
proxies. Feel free to do that.
However, the optimization techniques that a compiler has to employ in order
to do away with temporary row proxies as used in simple matrix entry access
are well known, widely implemented, and cannot be considered cutting edge
technologies anymore. That does not preclude the existence of compilers
that fail on this task, and it may not even preclude the existence of
reasonable compilers in this category. This is, why my claim could be false
and could even be successfully refuted (which would not be the case if it
was a definition).
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.
Why not?
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.
I would be very interested to learn what the compiler you mentioned above
does to the test code.
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.
Proxy classes, expression templates, and many more c++ programming
techniques benefit a lot from the compilers ability to optimize away small
temporaries. In the case under discussion, the row and column proxy classes
lead to more readable (IMO) client code that is easier to maintain (at the
cost of a more involved matrix implementation). To warn against such
techniques because some compilers may do a poor job on optimization is a
case of premature optimization.
I provided the test code so that others could measure. If you have to work
under tight performance constraints, you do not need to be told in a news
group that you will have to measure and carefully decide on the tradeoffs.
Also note that I never promoted the view that (,) should not be implemented
or should be implemented in terms of [][]. I just find it unreasonable to
argue against [][]. The matrix classes I use provides both interfaces. If
you find that [][] is too costly with the compiler of your choice, simply
use (,). The key point remains that on a conceptual level, proxy classes
for rows and columns allow higher order abstractions for dealing with
matrices, which one should not throw out of the window just because low
level element access does not need them.
Best
Kai-Uwe Bux
Daniel T. wrote:
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[i][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::operator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix::operator()(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.
--
Salu2
Julián Albo <JU********@terra.eswrote:
Daniel T. wrote:
... you could have made your life simpler and avoided most of the
above work [of making proxies] by directly calling
Matrix::operator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix::operator()(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
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
>Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
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.
>In short, I do not see any "true Scotsman" fallacy in my reasoning.
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::operator()(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::operator()(unsigned row, * *unsigned col)
in the first place. So you might as well directly call
Matrix::operator()(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[i][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::operator()(unsigned row, unsigned col) in the first place. So
you might as well directly call Matrix::operator()(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
Daniel T. wrote:
Gianni Mariani <gi*******@mariani.wswrote:
Daniel T. wrote:
...
>
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
>at all portable.
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.
Axter wrote:
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
Daniel T. wrote:
>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?
--
Salu2
Axter wrote:
I recommend using standard syntax [][] over the non standard ambiguous
(,) method.
There is nothing at all non-standard or ambiguous about function calls.
Noah Roberts wrote:
Axter wrote:
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];
Noah Roberts wrote:
Axter wrote:
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.
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/co...e=source&hl=en
I explained it all paragraph by paragraph. What more do you want ?
* Axter:
Daniel T. wrote:
>Gianni Mariani <gi*******@mariani.wswrote:
>>Daniel T. wrote:
...
If you care to deny any of the claims made in the FAQ questions 13.10-12
(and their justifications,) then please do so. If there is a problem
at all portable.
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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Kai-Uwe Bux <jk********@gmx.netwrote:
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
Daniel T. wrote:
Kai-Uwe Bux <jk********@gmx.netwrote:
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.
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?
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[i][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.
Julián Albo <JU********@terra.eswrote:
Daniel T. wrote:
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.
Daniel T. wrote:
<snip>
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[i][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].
>
Since I was quoting Beliavsky, I will hope he answers. I haven't
programmed in Fortran since the early '80s.
"Gianni Mariani" <gi*******@mariani.wswrote:
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/co...2ca6?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? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ip4ram |
last post by:
I used to work with C and have a set of libraries which allocate
multi-dimensional arrays(2 and 3) with single malloc call.
data_type **myarray
=...
|
by: Peter Olcott |
last post by:
I need to know how to get the solution mentioned below to work. The
solution is from gbayles Jan 29 2001, 12:50 pm, link is provided below:
>...
|
by: hyena |
last post by:
Hi,
I have a problem regarding passin 2 dimensional array into a function.
I have a to pass into function f(), f is called many times and the size
of a will change for each call.
I am not...
|
by: Gernot Frisch |
last post by:
Hi,
I need a class, that has a 4 dimensional array (can be 3 dimensional,
too)
with such an operator:
T operator()(int x1, int x2=0, int x3=0, int x4=0);
that can be used as:
|
by: nw |
last post by:
Hi,
We've been having a discussion at work and I'm wondering if anyone
here would care to offer an opinion or alternative solution. Aparently
in the C programming HPC community it is common to...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
