Re: [boost] [rfc] A light weight statically typed matrix template class (again?)
On Thursday 06 December 2007, Andreas Harnack wrote:
Hi @,
shouldn't there be at least an elementary matrix class available in the standard? I notice there have been some discussions in the past, but there doesn't seem to be anything in the pipeline. So, is there any interest in a (really!) light weight statically typed matrix template class?
No, there shouldn't be. :-) The C++ landscape is littered with such things, from simpler than your example to fantastically elaborate. See <http://www.oonumerics.org/oon/> for a sample. One of the big problems is that everyone wants something slightly different. Example:
#include <algorithm> #include <functional>
template<typename T, unsigned int M, unsigned int N> class matrix { protected: T m[M][N];
OK, this makes the matrix size a compile-time decision. This is ideal for some cases and anathema for others. [...]
T& operator()(unsigned int i, unsigned int j) { return m[i][j]; } T const& operator()(unsigned int i, unsigned int j) const { return m[i][j]; }
OK, is that one-based or zero-based? Some people demand zero-based, others demand one-based. [...]
There are still a few essential but fairly basic things missing, like matrix multiplication and transposing a matrix. Elementary row operations might be useful as well for those, who want to provide complex algorithms, but that's it, basically. There shouldn't be anything in there that's more complicated than that. (Matrices are such a general concept that it can be very tricky, if not impossible, to provide any guaranties for anything above the basic stuff.)
OK, what does operator* mean? Inner product? Outer product? Direct product?
Any interest? Comments most welcome!
I'm not saying your code is wrong, it's not; it's just fine for what you want. But it's not at all fine for what the general matrix-using population wants. As an example of a library that *does* try to fill all those needs, look at Boost's very own UBlas. Flexible, has all the options covered... and IMHO rather difficult to use, and also rather slow. An an example of a library that probably does exactly what you want, but way way fast, look at 'tvmet'. My point is, I guess, that general-purpose one-size-fits-all libraries have historically been hard to use and slow; libraries that are easy to use and fast are not applicable to all uses. I personally think this issue is rather fundamental to the "computer linear algebra" problem, and nobody has yet come up with The Good Solution (not for lack of work). (BTW, I think that UBlas + template typedefs [in whatever form we get them] will grow up to be a big, strong, fast, and very useful library some day. It doesn't fit my needs at all yet, so I'm using something else). My $0.02. -- Dr. David Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> )
Dave Steffen schrieb:
On Thursday 06 December 2007, Andreas Harnack wrote:
Hi @,
shouldn't there be at least an elementary matrix class available in the standard? I notice there have been some discussions in the past, but there doesn't seem to be anything in the pipeline. So, is there any interest in a (really!) light weight statically typed matrix template class?
No, there shouldn't be. :-)
Well, I'm looking forward to a passionate discussion ;-)
The C++ landscape is littered with such things, from simpler than your example to fantastically elaborate. See <http://www.oonumerics.org/oon/> for a sample.
I'd take that as a proof that there is a need for standardization, however the result might look like.
One of the big problems is that everyone wants something slightly different. Example:
#include <algorithm> #include <functional>
template<typename T, unsigned int M, unsigned int N> class matrix { protected: T m[M][N];
OK, this makes the matrix size a compile-time decision. This is ideal for some cases and anathema for others.
Isn't that argument a bit like asking, why C++ does have arrays at all, instead of just pointers to dynamically allocated memory? The huge advantage I see here is that the size is part of the type and hence subject to compile-time checks. (That doesn't exclude the option to have alternative implementations as well.)
T& operator()(unsigned int i, unsigned int j) { return m[i][j]; } T const& operator()(unsigned int i, unsigned int j) const { return m[i][j]; }
OK, is that one-based or zero-based? Some people demand zero-based, others demand one-based.
That's zero based, like any other C++ array or container.
There are still a few essential but fairly basic things missing, like matrix multiplication and transposing a matrix. Elementary row operations might be useful as well for those, who want to provide complex algorithms, but that's it, basically. There shouldn't be anything in there that's more complicated than that. (Matrices are such a general concept that it can be very tricky, if not impossible, to provide any guaranties for anything above the basic stuff.)
OK, what does operator* mean? Inner product? Outer product? Direct product?
As far as I'm aware there's only one product to matrices; we're not talking about vectors here ;-). Of course, you can use row- or column-matrices to represent vectors, in which case the result (i.e. scalar or matrix) depends on the order of operands.
Any interest? Comments most welcome!
I'm not saying your code is wrong, it's not; it's just fine for what you want. But it's not at all fine for what the general matrix-using population wants.
Am I really the only one who needs this?
As an example of a library that *does* try to fill all those needs, look at Boost's very own UBlas. Flexible, has all the options covered... and IMHO rather difficult to use, and also rather slow.
Here, I think, we have a huge misunderstanding. I never tried, don't pretend I could and don't even want to provide a solution that suits anybodies need. I think that's impossible. I totally agree that there are plenty of good libraries out there, some of them even excellent. But I refuse to believe, that the C++ community consists only of people who do high performance scientific computing. For them is reasonably well cared for. But what about the rest of us?
An an example of a library that probably does exactly what you want, but way way fast, look at 'tvmet'.
Agreed, it does what I want. In fact, any library I looked and does what I want because all I want is really simple stuff. I just don't like to pay the price (i.e. the dependencies it introduces, the complexity that gets involved, the compile time overhead etc.).
My point is, I guess, that general-purpose one-size-fits-all libraries have historically been hard to use and slow; libraries that are easy to use and fast are not applicable to all uses. I personally think this issue is rather fundamental to the "computer linear algebra" problem, and nobody has yet come up with The Good Solution (not for lack of work).
I totally agree, but as I said, that wasn't my intention. And by the way, talking about matrices does by no means imply to talk about linear algebra. It just happens that linear algebra peoples are the ones that talk most about matrices. :-)
(BTW, I think that UBlas + template typedefs [in whatever form we get them] will grow up to be a big, strong, fast, and very useful library some day. It doesn't fit my needs at all yet, so I'm using something else).
Nicely phrased ;-). What do you use then? Andreas
From: Andreas Harnack
Dave Steffen schrieb:
On Thursday 06 December 2007, Andreas Harnack wrote:
Hi @,
shouldn't there be at least an elementary matrix class available in the standard? I notice there have been some discussions in the past, but there doesn't seem to be anything in the pipeline. So, is there any interest in a (really!) light weight statically typed matrix template class?
No, there shouldn't be. :-)
Well, I'm looking forward to a passionate discussion ;-) I think Dave's right.
The C++ landscape is littered with such things, from simpler than your example to fantastically elaborate. See <http://www.oonumerics.org/oon/> for a sample.
I'd take that as a proof that there is a need for standardization, however the result might look like.
That's a curious conclusion. If there are lots of attempts, it suggests that it is really difficult to get people to agree on the preferred approach.
One of the big problems is that everyone wants something slightly different. Example:
and this is the key point.
Here, I think, we have a huge misunderstanding. I never tried, don't pretend I could and don't even want to provide a solution that suits anybodies need.
Can I be excused a smile at this point? I think you probably meant to say "I don't want to provide a solution that suits EVERYbodies needs". (Sie schrieben, ungefähr, "Mein Idee ist für niemand" nicht "Mein Idee ist nicht für jemand".)
I think that's impossible. I totally agree that there are plenty of good libraries out there, some of them even excellent. But I refuse to believe, that the C++ community consists only of people who do high performance scientific computing. Certainly true. For them is reasonably well cared for. But what about the rest of us?
The trouble is that even if you ignore the HPC community, "the rest of us" are a pretty disparate bunch and there are lots of separate problems each of which can be described as needing a simple matrix class - but in fact each of them needing a /different/ simple matrix class.
An an example of a library that probably does exactly what you want, but way way fast, look at 'tvmet'.
Agreed, it does what I want. In fact, any library I looked and does what I want because all I want is really simple stuff. I just don't like to pay the price (i.e. the dependencies it introduces, the complexity that gets involved, the compile time overhead etc.).
Well, I don't see how adding it to boost is going to help then. You'll get all that stuff (just boost rather than tvmet).
My point is, I guess, that general-purpose one-size-fits-all libraries have historically been hard to use and slow; libraries that are easy to use and fast are not applicable to all uses. ... and this is why matrices don't belong in the standard.
I personally think this issue is rather fundamental to the "computer linear algebra" problem, and nobody has yet come up with The Good Solution (not for lack of work).
I totally agree, but as I said, that wasn't my intention. And by the way, talking about matrices does by no means imply to talk about linear algebra. It just happens that linear algebra peoples are the ones that talk most about matrices. :-)
But Dave's point -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
Serves me right for responding to the list without catching up on reading it first... On Tuesday 11 December 2007, Martin Bonner wrote: ... a much better reply than my last one, e.g. said most of the same things but better. :-)
From: Andreas Harnack
Dave Steffen schrieb:
On Thursday 06 December 2007, Andreas Harnack wrote: [...] The C++ landscape is littered with such things, from simpler than your example to fantastically elaborate. See <http://www.oonumerics.org/oon/> for a sample.
I'd take that as a proof that there is a need for standardization, however the result might look like.
That's a curious conclusion. If there are lots of attempts, it suggests that it is really difficult to get people to agree on the preferred approach.
Yes, that was exactly my point. :-) And by the way, I didn't really mean to imply that the OP (Andreas) really shouldn't roll his own library (although I probably said that, or something like it). He should, because it's a very instructive exercise. It wouldn't be such a bad idea to have one, or even several, small matrix libraries in Boost. It's just not a suitable thing for standardization. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 direct (970) 461-2422 x227 fax (970) 461-2004 Email: dave.steffen@numerica.us This message and any attachments are intended only for the individual or entity to which the message is addressed. This is a private message and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify me immediately by returning this email to me and deleting it from your computer.
On Monday 10 December 2007, Andreas Harnack wrote:
Dave Steffen schrieb:
On Thursday 06 December 2007, Andreas Harnack wrote:
Hi @,
shouldn't there be at least an elementary matrix class available in the standard? I notice there have been some discussions in the past, but there doesn't seem to be anything in the pipeline. So, is there any interest in a (really!) light weight statically typed matrix template class?
No, there shouldn't be. :-)
Well, I'm looking forward to a passionate discussion ;-)
Having been out for a few days with stomach flu, I don't know how passionate I'm gonna be. :-)
The C++ landscape is littered with such things, from simpler than your example to fantastically elaborate. See <http://www.oonumerics.org/oon/> for a sample.
I'd take that as a proof that there is a need for standardization, however the result might look like.
No, I meant precicely the opposite. Many many people have started out doing exactly what you're doing, for exactly the same reasons. No "one true way" has emerged, because it's a *hard* problem. We, as an industry, don't yet have a solution that's acceptable as a possible standard. Don't take my word for it. Go look. Look at Blit++, and it's offshoot tvmet (which I quite like, and sounds like what you want); look at MTL, and Boost's own UBlas, and TNT, and... The closest thing we have to a standard linear algebra library (that I know of) is BLAS + LAPACK, which has been around for decades (and was originally written in Fortran). And even that's not appropriate for everyone's needs. Again: doing this is much harder than it looks at first, and should only be attempted by people who know what they're doing. I'll go out on a limb and state that nobody who hasn't looked at some of the attempts at OO Linear Algebra out there knows what they're doing. :-)
One of the big problems is that everyone wants something slightly
different. Example:
#include <algorithm> #include <functional>
template<typename T, unsigned int M, unsigned int N> class matrix { protected: T m[M][N];
OK, this makes the matrix size a compile-time decision. This is ideal for some cases and anathema for others.
Isn't that argument a bit like asking, why C++ does have arrays at all, instead of just pointers to dynamically allocated memory? The huge advantage I see here is that the size is part of the type and hence subject to compile-time checks. (That doesn't exclude the option to have alternative implementations as well.)
It isn't even remotely like asking that question. Of course the advantage here is compile time checking, also no dynamic memory allocation, and (most importantly) huge performance gains from using template metaprogramming techniques (a la Blitz++ and tvmet). ... except that this doesn't support copy-on-write semantics (which you *can* do if the internal storage is dynamically allocated and stored e.g. in a smart pointer). And this doesn't scale well to large matrices (e.g. thousands of 400x400 matrices) on some machines. And this doesn't allow for compile-time sized matrices. And *all* of these issues can be deal breakers. In fact, they *are* all deal breakers for applications I work on.
T& operator()(unsigned int i, unsigned int j) { return m[i][j]; } T const& operator()(unsigned int i, unsigned int j) const { return m[i][j]; }
OK, is that one-based or zero-based? Some people demand zero-based, others demand one-based.
That's zero based, like any other C++ array or container.
Right, but sometimes you really want 1-based, like when you're also working with Fortran or Matlab code, or with Fortran or Matlab programmers, or even just Mathematics professors who write all their papers counting from 1 like all humans except C programmers. :-)
There are still a few essential but fairly basic things missing, like matrix multiplication and transposing a matrix. Elementary row operations might be useful as well for those, who want to provide complex algorithms, but that's it, basically. There shouldn't be anything in there that's more complicated than that. (Matrices are such a general concept that it can be very tricky, if not impossible, to provide any guaranties for anything above the basic stuff.)
OK, what does operator* mean? Inner product? Outer product? Direct product?
As far as I'm aware there's only one product to matrices; we're not talking about vectors here ;-). Of course, you can use row- or column-matrices to represent vectors, in which case the result (i.e. scalar or matrix) depends on the order of operands.
You're kidding, right? There are many ways to multiply two matrices together. I listed three above. Cross products are a fourth. The correct interface depends *heavily* on the intended uses.
Any interest? Comments most welcome!
I'm not saying your code is wrong, it's not; it's just fine for what you want. But it's not at all fine for what the general matrix-using population wants.
Am I really the only one who needs this?
No! Many people need what you're building (and either build it themselves, or use one of the available packages). But many more people need something *like* what you're proposing, except for this, that, and that other bit. Which is why you don't standardize this.
As an example of a library that *does* try to fill all those needs, look at Boost's very own UBlas. Flexible, has all the options covered... and IMHO rather difficult to use, and also rather slow.
Here, I think, we have a huge misunderstanding. I never tried, don't pretend I could and don't even want to provide a solution that suits anybodies need.
Then it's not suitable for standardization.
I think that's impossible. I totally agree that there are plenty of good libraries out there, some of them even excellent.
Not impossible, just difficult, and nobody in the community has a solution that they feel is good enough for standardization.
But I refuse to believe, that the C++ community consists only of people who do high performance scientific computing. For them is reasonably well cared for. But what about the rest of us?
That's nonsensical. The high performance scientific people are, alas, such a minority in the C++ community that the only attempt at any high-performance stuff in the C++ standard is "valarray", which is effectively a failure, IIRC because the only guy on the standardization committee who really understood the issues involved couldn't continue participating. But what about the rest of you? ...
An an example of a library that probably does exactly what you want, but way way fast, look at 'tvmet'.
Agreed, it does what I want. In fact, any library I looked and does what I want because all I want is really simple stuff. I just don't like to pay the price (i.e. the dependencies it introduces, the complexity that gets involved, the compile time overhead etc.).
And elsethread you wrote
I do plan indeed to add a more template parameters, first and foremost to allow to specify special matrix forms, like diagonal matrices, which have some special properties, that might be interesting to the user. Different storage models might interesting too.
... which means you're going to reinvent tvmet.
My point is, I guess, that general-purpose one-size-fits-all libraries have historically been hard to use and slow; libraries that are easy to use and fast are not applicable to all uses. I personally think this issue is rather fundamental to the "computer linear algebra" problem, and nobody has yet come up with The Good Solution (not for lack of work).
I totally agree, but as I said, that wasn't my intention. And by the way, talking about matrices does by no means imply to talk about linear algebra. It just happens that linear algebra peoples are the ones that talk most about matrices. :-)
That distinction isn't nearly as clear-cut as you think. But that aside, my fundamental statement stands: there's good reason not to standardize such a library (yet). I'll add another strong statement: don't roll your own unless you really know what you're doing. Use something already out there, and even then, test the hell out of your numerical results. (There are IIRC bugs in tvmet that can produce wrong answers. And poorly conditioned matrices can wreck havoc under any circumstances.)
(BTW, I think that UBlas + template typedefs [in whatever form we get them] will grow up to be a big, strong, fast, and very useful library some day. It doesn't fit my needs at all yet, so I'm using something else).
Nicely phrased ;-). What do you use then?
Interesting question. For years, we've been using dynamically-sized matrices with BLAS and LAPACK underneath, mainly because that was the only real option when our code base was born. It's not ideally suited for our application (LAPACK is particularly good for big matrices, but we almost always deal with small ones). We're looking at writing our own library right now. We may use tvmet, but probably not. The only reason we would consider doing our own from scratch is that we have the right kind of people to do so. (PhDs in math, computer science, and physics, with loads of scientific computing experience thrown in.) And even then, we're limiting the project scope severely, and building large testing frameworks around it. :-) -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) Email: dgsteffen @ numerica.us
On 12/12/07 11:08, Dave Steffen wrote:
On Monday 10 December 2007, Andreas Harnack wrote: [snip]
As far as I'm aware there's only one product to matrices; we're not talking about vectors here ;-). Of course, you can use row- or column-matrices to represent vectors, in which case the result (i.e. scalar or matrix) depends on the order of operands.
You're kidding, right? There are many ways to multiply two matrices together. I listed three above. Cross products are a fourth. The correct interface depends *heavily* on the intended uses.
I also thought outer and cross product dealt with vectors. The following page on outer product: http://documents.wolfram.com/mathematica/Built-inFunctions/AdvancedDocumenta... seems to support that conclusion about outer product, and the following on cross product: http://planetmath.org/encyclopedia/CrossProduct.html also supports that interpretation for cross product. I guess we're both (i.e. me and Andreas) thinking too narrowly. Could you provide some web page supporting your interpretation that outer and cross args are matrices instead of vectors? OOPS, wait. Looking at: http://planetmath.org/encyclopedia/OuterMultiplication.html maybe supports your interpretation, although I can't yet understand all the notation. Anyway, even if I and Andreas are thinking too narrowly, the first two web pages referenced suggest that thinking is understandable and maybe common for those not real familiar with the field. -regards, Larry
On Wednesday 12 December 2007, Larry Evans wrote:
On 12/12/07 11:08, Dave Steffen wrote:
On Monday 10 December 2007, Andreas Harnack wrote:
[snip]
As far as I'm aware there's only one product to matrices; we're not talking about vectors here ;-). Of course, you can use row- or column-matrices to represent vectors, in which case the result (i.e. scalar or matrix) depends on the order of operands.
You're kidding, right? There are many ways to multiply two matrices together. I listed three above. Cross products are a fourth. The correct interface depends *heavily* on the intended uses.
I also thought outer and cross product dealt with vectors. The following page on outer product:
Yes, I was typing fast and didn't clearly make my point. Yes, generally cross products are only done with vectors. They can IIRC be generalized (vectors are really just Nx1 or 1xN matrices, right?) but I don't think this is commonly used. However, outer and direct matrix products *are* used; generally not as often as inner products, true, but they exist. Not supporting them in a matrix library is fine for many (most?) users, and a deal breaker for others.
also supports that interpretation for cross product. I guess we're both (i.e. me and Andreas) thinking too narrowly. Could you provide some web page supporting your interpretation that outer and cross args are matrices instead of vectors?
OOPS, wait. Looking at:
http://planetmath.org/encyclopedia/OuterMultiplication.html
maybe supports your interpretation, although I can't yet understand all the notation.
Yeah, notation can be hard. Consider vector multiplication for a minute: row vector * column vector = inner product (results in a scalar) column vector * row vector = outer product (results in a matrix) row vector * row vector = error in some applications, but can be interpreted as a direct product in others (same for column vectors). All can be extended in fairly obvious ways to matrix multiplication. Which again supports my argument that building a matrix library *suitable for standardization* is extremely difficult (read: nobody's figured out what it should look like yet).
Anyway, even if I and Andreas are thinking too narrowly, the first two web pages referenced suggest that thinking is understandable and maybe common for those not real familiar with the field.
Exactly. See point above. And again, this is not a reason not to roll your own library that does what you want, nor is it a reason not to use other available libraries, or even to have multiple matrix/linear algebra libraries in Boost. But these are all reasons why there is no *standard* matrix library, and why there isn't likely to be one for a while. BTW: the more common discussion that happens here every now and then, and happens on the news groups with regularity, is about why there's no standard GUI library for C++ (as there is, or at least as there appears to be, for Java). Same problem, only much harder to solve. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> )
I'm not pretending to be an expert in Linear Algebra or in numerical computing and I certainly wouldn't dare to submit a full scale Linear Algebra library. (Though in all modesty, I probably could take one about 2/3 of the people out there working as professional programmers.) I'm just a computer engineer how thinks that matrices could be a very useful and handy tool in many situation, yet any time I reach out for it in my (standard) toolbox it's just not there. And if I go to the next DIY-market all I got offered is a whole range of highly sophisticated CNC-all-in-one solutions, that are very shiny and properly do an excellent job, but just won't fit into my modest workshop, where I just want to, let's say, drill a few holes. See my problem? And from what I read from the posts (this one as well as earlier ones) there are a few people out there feeling the same way. If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do? Complex numbers are useful in many situations, as matrices are, yet the complex number class doesn't support a single one of them. Or is there a function in the library to find the roots of a polynomial or one to transform a signal sample from the time to the frequency domain? No, and I think it shouldn't. So why is everybody so keen to have a function to find eigenvalues in a matrix class, which comes down to exactly the same problem? Actually the complex number class does next to nothing. It is essentially a structure of two equally typed elements, about the most primitive data structure one could think off. It only forwards a few operators of the base type, which are already available in the language or in some other library. By far the most complex function in the complex number class is the input operator. And yet, the class is there, it's in the standard and it is useful. (Well, at least it doesn't hurt.) All I'm trying to propose is to do the same thing with a two-dimensional array, about the second primitive data structure one could think of. (The third actually, one-dimensional arrays would come second, but it turned out that a matrix class without a dedicated vector class is more useful then vice versa and, after all, vectors are already in the standard too, though they do almost ignore the algebraic aspect of vectors.) This is not supposed to be an all-in-one solution, it shall only provide the most elementary stuff. By most elementary I mean operations, that are already there, somewhere in the standard. That's the reason I'm not too bothered about numerical problems. Adding two matrices doesn't impose more problems than folding a Plus-functor to a vector. It won't solve any equations, but matrices are not only about that. Andreas
Andreas Harnack wrote:
If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do?
There are a number of fundamental differences: the operations on complex numbers provided for in the standard covers exactly the same domain of tasks as are covered by the built-in floating point types. Standardization is possible because implementing those operations for complex in a numerically stable and efficient way is relatively simple (although even that can go astray pretty rapidly), and the "best" storage format of complex numbers on the hardware has long been well understood and agreed upon. Even the class interface can be agreed upon pretty trivially, and with minimal impact on implementation flexibility. For matrices, none of that is the case. Implementing even the simplest operations efficiently (addition, inner multiplies, subtraction) and correctly is exceedingly non-trivial, and the next simplest (but much much larger) class of operations is dramatically more complicated (inverses, strides, permutations, etc) with a vastly larger set of special cases. The minimally useful set of operations that _must be in the public interface_ to be used as building blocks for more complicated user defined operations are hard to list because they are so long. Unlike complex, the interface here will have an enormous impact on the underlying implementation choices. Heck, there is even continued debate on issues so trivial as the best _memory layouts_ (column major? row major? arcane subblock storage formats?). If that doesn't sway you, then by all means, you should consider trying to define a minimal interface for what you need, and see if you can get the standards committee to bite. I think you have a very hard uphill slog ahead of you, with a nearly certain rejection at the other end, but I wish you luck :-) -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------
On Monday 17 December 2007, Kevin Lynch wrote:
Andreas Harnack wrote:
If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do?
There are a number of fundamental differences: the operations on complex numbers provided for in the standard covers exactly the same domain of tasks as are covered by the built-in floating point types. Standardization is possible because implementing those operations for complex in a numerically stable and efficient way is relatively simple (although even that can go astray pretty rapidly), and the "best" storage format of complex numbers on the hardware has long been well understood and agreed upon. Even the class interface can be agreed upon pretty trivially, and with minimal impact on implementation flexibility.
Right. In addition, there is a precedent, in that Fortran supports complex number types natively. They're not uncommon in numerical code, and fairly easy to get right (and to get people to agree on the interface). Note, however, that nobody ever tries to standardize what sqrt(complex) means, because that's a vastly more compex problem (pun intended), and because people who need that sort of thing will go find a specialized library that supports it. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 direct (970) 461-2422 x227 fax (970) 461-2004 Email: dave.steffen@numerica.us This message and any attachments are intended only for the individual or entity to which the message is addressed. This is a private message and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify me immediately by returning this email to me and deleting it from your computer.
From: Andreas Harnack
If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do?
There is rather less discussion about possible interfaces for complex numbers than for matrices. (The last time I used matrices in my code, I wanted A=B*C to mean A[i,j] = B[i,j]*C[i,j].) I would be quite happy if there was no std::complex. [snip]
And yet, the class is there, it's in the standard and it is useful. (Well, at least it doesn't hurt.)
NOT SO! Having std::complex /does/ hurt me. It takes implementation and testing effort away from bits of the library that I use.
All I'm trying to propose is to do the same thing with a two-dimensional array, about the second primitive data structure one could think of.
Well, I think that what you are trying to do is mistaken; HOWEVER, you are most certainly going about it the right way. Propose an interface (with reference implementation) for boost; get it reviewed by boosters; have people get some real-world experience with it; /then/ write up a paper proposing it for the next TR. It's very possible that I am completely mistaken, and there is a simple interface that a large number of people would find useful. This is the way to find out. -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
On Tuesday 18 December 2007, Martin Bonner wrote:
From: Andreas Harnack
If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do?
There is rather less discussion about possible interfaces for complex numbers than for matrices. (The last time I used matrices in my code, I wanted A=B*C to mean A[i,j] = B[i,j]*C[i,j].)
Interesting: that's a direct product, which we hardly ever use. This supports my statement up-thread that while matrices in general are well known and commonly used, getting any two people to agree on the interface is difficult, because people use them so differently. That statement is not true of complex numbers, which pretty much everyone uses the same way. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) Email: dave.steffen@numerica.us
On Tue, Dec 18, 2007 at 03:02:12PM -0700, Dave Steffen wrote:
On Tuesday 18 December 2007, Martin Bonner wrote:
From: Andreas Harnack
If you think that this doesn't belong to the standard, then please allow me to ask one question: Why is there a complex number class in the standard and what does it actually do?
There is rather less discussion about possible interfaces for complex numbers than for matrices. (The last time I used matrices in my code, I wanted A=B*C to mean A[i,j] = B[i,j]*C[i,j].)
Interesting: that's a direct product, which we hardly ever use.
I don't think that's a direct product; c.f. http://mathworld.wolfram.com/MatrixDirectProduct.html Wikipedia suggests it's called the Hadamard (or Schur or entrywise) product; c.f. http://en.wikipedia.org/wiki/Matrix_multiplication Yours pedantically, -Steve
On Wednesday 19 December 2007, Steve M. Robbins wrote:
On Tue, Dec 18, 2007 at 03:02:12PM -0700, Dave Steffen wrote:
On Tuesday 18 December 2007, Martin Bonner wrote: [...]
There is rather less discussion about possible interfaces for complex numbers than for matrices. (The last time I used matrices in my code, I wanted A=B*C to mean A[i,j] = B[i,j]*C[i,j].)
Interesting: that's a direct product, which we hardly ever use.
I don't think that's a direct product; c.f. http://mathworld.wolfram.com/MatrixDirectProduct.html
Wikipedia suggests it's called the Hadamard (or Schur or entrywise) product; c.f. http://en.wikipedia.org/wiki/Matrix_multiplication
Yours pedantically, -Steve
Whoops, yes, you're right. I think we've used a direct product once here (in experimental code that no longer exists), and I didn't write it. :-) Thanks. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> )
On Monday 17 December 2007, Andreas Harnack wrote: [...] Let's step back a little. Your first question was "Why isn't there a simple matrix library in the standard". I've given you my answer to that, one or two others agree. A better place to ask such questions is the comp.std.c++ Usenet newsgroup. I'd encourage you to ask the question there, and see what happens. I suspect the answer you'll get there is "because nobody has presented a proposal", but we might get some insight from the C++ gods who read that group. You asked a secondary question, "Why is <complex> in the standard", regarding which I've also tossed my $0.02 US (value decreasing :-) into the hat. Also a good question for comp.std.c++. Now: I do recommend that you try rolling your own, since it's very educational. I'd also recommend that you take a second look at what's already out there, because something might fit your needs a save you a lot of time. It still sounds like tvmet would be a good starting place, and I have found tvmet to be *very* easy to work with. I also agree with what Martin Bonner said elsethread, that if you want to get such a library into the standard, you're going about it the right way. Write the library, submit it to Boost, weather the inevitable firestorm of (generally constructive) criticism, rinse, and repeat. If it (and you) survive, write a proposal and present it to the standards committee (the same C++ gods who hang out in comp.std.c++) and see what happens. Personally I think such things *belong* in third-party libraries. But then, Boost is such a library, and I'd very much like to see *several* matrix / linear algebra / etc libraries in Boost. So, I'd encourage you to contine. -- Dave Steffen - Software Engineer 4 Numerica Corporation (www.numerica.us <http://www.numerica.us/> )
participants (6)
-
Andreas Harnack -
Dave Steffen -
Kevin Lynch -
Larry Evans -
Martin Bonner -
Steve M. Robbins