What is the current status of all Boost mathmatical, statistical and econometric libraries currently in development? The collection of boost math libraries that are currently included in the library are world-class and provide a wonderful foundation to build-upon. However, many areas of advanced statistical and mathmatical inference are not currently being addressed by any of the boost libraries. Is there currently a way for those boost developers with a background in mathmatics to coordinate their efforts. If not, why not? Lets get such a discussion started. A continued and regular dialog of mathmatics as it relates to boost library development would be of great use, primaryily to avoid overaping our efforts. If your a mathmetician and agree with me that boost is a great foundation to build-upon, let the group/me know. Points for Discussion: 1) We should keep a seperate list of boost::math libraries that are currently under development and provide a forum for advanced discussions. How can we do this? 2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians? 3) We should create a list of mathmatical algorithims and libraries that are needed. 4) We need some very basic boost specific math-tutorials for our future mathemiticans and potential library writers. 5) We need to advertise to the development community about how strong of a foundation boost is for mathmatical library development. In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be. Comments? Regards, Tom Brinkman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Tom Brinkman" <reportbase@yahoo.com> wrote in message news:20040602235400.88511.qmail@web50401.mail.yahoo.com...
[...] 2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians? [...]
I would guess that we would need to bring Boost up to the level of currently available libraries, in C++ or any other language in order to gain the attention of serious mathematicians. Since there is already a huge investment in other languages (such as GSL, which is written in C), this will be a significant hurdle. We should also ask whether C++ *is* the best development platform for mathematical applications. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
Dave Held wrote:
I would guess that we would need to bring Boost up to the level of currently available libraries, in C++ or any other language in order to gain the attention of serious mathematicians. Since there is already a huge investment in other languages (such as GSL, which is written in C), this will be a significant hurdle. We should also ask whether C++ *is* the best development platform for mathematical applications.
Well, it definitely has the potential to be... with the proper Boost... /David
there is already a huge investment in other languages (such as GSL, which is written in C), this will be a significant hurdle.
I've not used the GSL: would it benefit in either usability (*) or efficiency if it used C++ templates/objects? If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel. Darren *: e.g. see: http://www.gnu.org/software/gsl/manual/gsl-ref_2.html#SEC17
Darren Cook <darren@dcook.org> wrote:
there is already a huge investment in other languages (such as GSL, which is written in C), this will be a significant hurdle.
I've not used the GSL: would it benefit in either usability (*) or efficiency if it used C++ templates/objects?
Absolutely. I've done some work with it, and it was rather painful compared to what I'm used to in C++. If I had more time, I would have written a wrapper.
If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel.
Almost certainly not. They are not even willing to entertain going to the LGPL. There used to be a blurb on their website saying that if you can't handle the GPL, then use something else. Regards, Walter Landry wlandry@ucsd.edu
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20040602.224424.33319794.wlandry@ucsd.edu...
Darren Cook <darren@dcook.org> wrote: [...]
If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel.
Almost certainly not. They are not even willing to entertain going to the LGPL. There used to be a blurb on their website saying that if you can't handle the GPL, then use something else.
Do you suppose it's legal to write a Boost-compatible C++ interface on top of GSL? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
"David B. Held" <dheld@codelogicconsulting.com> wrote:
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20040602.224424.33319794.wlandry@ucsd.edu...
Darren Cook <darren@dcook.org> wrote: [...]
If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel.
Almost certainly not. They are not even willing to entertain going to the LGPL. There used to be a blurb on their website saying that if you can't handle the GPL, then use something else.
Do you suppose it's legal to write a Boost-compatible C++ interface on top of GSL?
Since the Boost license is compatible with the GPL, it would be legal to write, compile, and distribute a C++ interface. But it wouldn't gain you anything license-wise, since the C++ interface plus GSL would still be effectively licensed under the GPL. The GSL authors did this on purpose. They don't want to allow proprietary software to use GSL. Regards, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
Since the Boost license is compatible with the GPL, it would be legal to write, compile, and distribute a C++ interface. But it wouldn't gain you anything license-wise, since the C++ interface plus GSL would still be effectively licensed under the GPL. The GSL authors did this on purpose. They don't want to allow proprietary software to use GSL.
<nitpicking> They certainly allow proprietary software to use GSL. What they don't want is people extending their work (and that's how they would look at a boost wrapper) be able to distribute that work under less free terms than what GPL provides (http://www.gnu.org/philosophy/free-sw.html). Note that the operative term here is 'distribute', not 'use'. If you don't distribute you don't need to look into license issues. </nitpicking> Regards, Stefan
"Stefan Seefeld" <seefeld@sympatico.ca> wrote in message news:40BEA50C.1050003@sympatico.ca...
[...] They certainly allow proprietary software to use GSL. What they don't want is people extending their work (and that's how they would look at a boost wrapper) be able to distribute that work under less free terms than what GPL provides (http://www.gnu.org/philosophy/free-sw.html).
Note that the operative term here is 'distribute', not 'use'. If you don't distribute you don't need to look into license issues. [...]
So are you saying that Boost could produce a GSL wrapper, distribute it independently, and ask users to obtain GSL themselves? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
David B. Held wrote:
So are you saying that Boost could produce a GSL wrapper, distribute it independently, and ask users to obtain GSL themselves?
whether a GSL wrapper would be distributed together with GSL or separate has no bearing on the constraints on the license: the GPL requests that all distributors of GPL software (and that includes 'extended work' such as a library wrapper) have to provide those four freedoms. This is the 'viral' effect of the GPL: often the other license isn't compatible with GPL, so a hybrid work is not distributable at all, or the other way around (as in this case): the other author doesn't want to comply with the GPL requirements (http://www.boost.org/more/license_info.html#FAQ). Regards, Stefan
On Wed, Jun 02, 2004 at 11:42:24PM -0500, David B. Held wrote:
"Stefan Seefeld" <seefeld@sympatico.ca> wrote in message news:40BEA50C.1050003@sympatico.ca...
[...] They certainly allow proprietary software to use GSL. What they don't want is people extending their work (and that's how they would look at a boost wrapper) be able to distribute that work under less free terms than what GPL provides (http://www.gnu.org/philosophy/free-sw.html).
Note that the operative term here is 'distribute', not 'use'. If you don't distribute you don't need to look into license issues. [...]
So are you saying that Boost could produce a GSL wrapper, distribute it independently, and ask users to obtain GSL themselves?
Yes. A wrapper around GSL would not violate the licence, although it might have to be written from within the European Union. EU law says that the public interface (i.e. the header files and the prototypes they contain) are not protected by copyright law, so you can read the headers and write code that uses the interface without having to comply to the licence terms. This is from http://eu.conecta.it/paper/Open_source_copyright_law.html: The rationale is that the header contains only information about the access points to the routines, and provides no information on the inner workings of the software. This allows open source developers to recreate a compatible version of any library or component for which a header file is available. This applies equally to commercial libraries and to copylefted (GPL) ones. There was a discussion about this on advogato.org recently, but that site's down so here's the google cache version: http://tinyurl.com/2hmx2 jon -- "The most costly of all follies is to believe passionately in the palpably not true. It is the chief occupation of mankind." - H.L. Mencken
Walter Landry wrote:
Darren Cook <darren@dcook.org> wrote:
If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel.
Almost certainly not. They are not even willing to entertain going to the LGPL. There used to be a blurb on their website saying that if you can't handle the GPL, then use something else.
I just checked their website, and it still reads this way. The authors of GSL seem to think that anything other that the GPL prevents scientific collaboration. Thus, an FAQ entry that asks if GSL code can ever be used in commercial software says simply, "No. Sorry." John Phillips
operative phrase is "seem to think"..... I challenge the word think...but it's their work and they're free to say how it's used (even if they are distressingly misinformed). At Wednesday 2004-06-02 22:31, you wrote:
Walter Landry wrote:
Darren Cook <darren@dcook.org> wrote:
If so I wonder if the GSL authors would be open to a dual, boost-compatible license so that a boost library could borrow code as it needed to, rather than having to re-invent the wheel.
Almost certainly not. They are not even willing to entertain going to the LGPL. There used to be a blurb on their website saying that if you can't handle the GPL, then use something else.
I just checked their website, and it still reads this way. The authors of GSL seem to think that anything other that the GPL prevents scientific collaboration. Thus, an FAQ entry that asks if GSL code can ever be used in commercial software says simply, "No. Sorry."
John Phillips
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
operative phrase is "seem to think"..... I challenge the word think...but it's their work and they're free to say how it's used (even if they are distressingly misinformed).
Yep. No need to take a legalistic point of view. It is honourable to honour their intention. matt.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held Sent: Wednesday, June 02, 2004 7:29 PM To: boost@lists.boost.org Subject: [boost] Re: Boost Mathematicians
"Tom Brinkman" <reportbase@yahoo.com> wrote in message news:20040602235400.88511.qmail@web50401.mail.yahoo.com...
[...] 2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians? [...]
I would guess that we would need to bring Boost up to the level of currently available libraries, in C++ or any other language in order to gain the attention of serious mathematicians. Since there is already a huge investment in other languages (such as GSL, which is written in C), this will be a significant hurdle. We should also ask whether C++ *is* the best development platform for mathematical applications.
I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." I've been the rounds on that one with some exceedingly knowledgeable folk for the last fifteen years. The usual candidate is FORTRAN, and there used to be some good reasons it was true. I think that margin has been razored down until it isn't too meaningful any more, but any library that wants to compete will have to really, really get it right concerning a lot of things like error bounding, precision, error propagation and handling (yeah, I know the STL design philosophy doesn't swing that way), and then prove it on all the standard benchmark suites. About the only significant advantages I can still see in FORTRAN's favor, apart from the obvious one of the huge base of existing code, are the existence of native operators for things like exponentiation (overloading, of course, with a tiny performance penalty on some compilers), and the ease with which FORTRAN lends itself to parallel processing (and the existing compilers for doing that). I've seen one instance where a decision to switch heavy iron platforms forced a rewrite of all existing FORTRAN supercomputer code at a big research university (different loop nesting order); just modifying the FORTRAN loops probably cost more than the cost of the computer, when you factor in the time it cost all the research groups. You could hear the screams in the corridors (only a small exaggeration ;) ). I've done a lot of middlin' heavy math in C++, but it didn't have critical consequences if it wasn't up to rigorous scientific standards (well, once); a library used for actual scientific computing would have to meet those standards. I think, though, that the perception problem would still be the tougher problem, sadly. Oddly enough, scientists is usually pretty conservative folk; they like what they know. And, as I mentioned, they're often tied to particular hardware (although Boost isn't intended for the supercomputer market, any parts of it accepted into the next spec will eventually end up being used there). Anyway, that's my 0.02 Zorkmids. Reid Sweatman
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
[...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
And that's not the case I would make in this scenario. I'd say that it only makes sense to port all that code from other languages if C++ offers compelling reasons to do so. Just because it can be "just as fast" or "just as accurate" doesn't mean that we should invest all this time in it. Isn't it possible to call a FORTRAN library from C++? There are many other languages that offer this feature or that feature better than C++. But at the end of the day, I have to say that C++ is the right choice for a lot of projects because of factors other than speed or size. And by that I mean things like installed code base, user support, platform support, etc. The fact that people have been writing scientific code in FORTRAN pretty much since the language was invented means that there is a huge installed base of tools for working with it. These are the kinds of factors I have in mind when I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having to reinvent the wheel? For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
David B. Held wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
[...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
Dave
Some clear and obvious benefits of offering at least wrappers for math libraries written in other languages (not a complete list, but to start the conversation). *Access to C++ type safety. For all the usual reasons about compile time type checking. *The ability to work only with STL-like containers. Bad pointer arithmetic in C causes many code errors around the Physics Department I am a member of. It is a better idea to confine it to the internals of well tested algorithms (if it is needed for efficiency) and let the user code with well behaved containers. *Easier function pointer handling. Since many methods require the user to pass a function pointer (or a function object, or the like) for the algorithm to operate on, the tools offered by C++ and Boost that allow binding, composition and other manipulation of the function pointer can greatly simplify code. This simplification would have to be weighed against possible performance losses, however. *Making generic algorithms generic. Templates and overloading, of course, are able to simplify the library interface substantially. No more separate names for the float, double and complex versions of what is really the same algorithm. Some things that may be natural in C++ implementations and very difficult or impossible in other libraries (again, not a complete list, but the ones I am thinking of at the moment). *Policy based design There are many different methods for finding the roots of a known function. In some cases, they require different inputs from the user, and so are sensibly very different members of a code library. However, some use the same input information but do different things with the information while finding roots. These appear to me to be different policies for a more generic root finder. More generally, many operations that a numeric library should address appear to me to have sensible orthogonal decompositions into policies. *Metaprogramming A utility I would love to have for some things I have done in the past is a good, general tensor library. One that allows compile time selection of the number of covariant and contravariant indices, raising and lowering operations, index contraction, a wide variety of element types (at least double, complex and functions that return doubles or complexes), and all the other basic tools of tensor manipulation that numeric work might need. If I ever get the time, I would start trying to implement this using the boost preprocessor and metaprogramming libraries to keep the size of the code base sensible. *Use of boost::interval for error checking. Interval could be a great library for people doing numeric work. However, if I understand it correctly (and someone should please correct me if I don't), using interval with C or FORTRAN libraries would be a mess. The user would have to almost recreate much of the functionality, since in a complicated algorithm it is very hard to estimate what would happen to an interval. It is only practical one operation at a time. Similar facilities to boost::interval that take into account the fact that the errors are not uniformly distributed on the interval would also be nice. Armed with these two tools and a small (but selected to be characteristic) data set, the user could produce conservative error intervals and more likely accurate error distributions from the very same code used to actually analyze the full data set. I'm sure that none of these reasons are impossible to disagree with. I'm also sure there are good reasons to make C++ libraries that I have left out and good reasons not to that have not already been brought up in this thread. However, as it stands at the moment, I am very enthusiastic about this project and I hope to contribute to its development. John Phillips
On 3/06/2004, at 6:48 PM, John Phillips wrote:
*Making generic algorithms generic. Templates and overloading, of course, are able to simplify the library interface substantially. No more separate names for the float, double and complex versions of what is really the same algorithm.
Some things that may be natural in C++ implementations and very difficult or impossible in other libraries (again, not a complete list, but the ones I am thinking of at the moment).
With careful planning, there could be a lot of advantages from writing an object-oriented math library using generic programming etc. When I first heard about templates I wrote a floating-point-type generic ODE integrator, which I thought was great. But it was just a transliteration into C++ of a bog standard algorithm. Perhaps in a carefully thought-out OO design, each ODE step would be an object, and so things like recording of results and interpolating at intermediate points would have trivial interfaces. There may be other ways of re-thinking numerical algorithms into object oriented or metaprogramming frameworks - and I think that the C++ expertise of boost would be a good forum to develop ideas like that. There's a risk, though, that C++ features intruding to a low level would slow things down a lot. Can we hope that's something the compiler writers will sort out? Cheers, Geoff
John Phillips <phillips@mps.ohio-state.edu> wrote:
*Metaprogramming A utility I would love to have for some things I have done in the past is a good, general tensor library. One that allows compile time selection of the number of covariant and contravariant indices, raising and lowering operations, index contraction, a wide variety of element types (at least double, complex and functions that return doubles or complexes), and all the other basic tools of tensor manipulation that numeric work might need. If I ever get the time, I would start trying to implement this using the boost preprocessor and metaprogramming libraries to keep the size of the code base sensible.
Have you looked at http://www.oonumerics.org/FTensor/ It implements a fair number of different tensor types (e.g. symmetric, antisymmetic), the element type is templated, and it has natural ways of specifying contractions. It doesn't have separate covariant and contravariant tensors, but that wouldn't be that hard to implement. It would just be a fair amount of work for quesionable gain. I used it for my General Relativity code, and I never missed the distinction between covariant and contravariant indices. I bill it as a high performance tensor library, though now I think it might actually be better to use ordinary loops instead of the compile-time loops. Regards, Walter Landry wlandry@ucsd.edu
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20040603.220540.74755357.wlandry@ucsd.edu...
[...] http://www.oonumerics.org/FTensor/ [...]
From what I can see, oonumerics is just a loose collection of libraries without any particular reviewing standards. Is that a fair claim? I don't see why Boost couldn't contact the authors of the libraries featured there and ask them to submit their libraries to Boost. Would that be a sensible thing to do? After all, it looks like those libraries are probably well-developed and thought out by experts in those domains. The benefit of having them in Boost, of course, is the review that ensures high code quality, uniformity, and sharing of redundant facilities. And I don't see that there is any conflict between having them listed on oonumerics.org and also be Boost libraries. Is there?
Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
David B. Held wrote:
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20040603.220540.74755357.wlandry@ucsd.edu...
[...] http://www.oonumerics.org/FTensor/ [...]
From what I can see, oonumerics is just a loose collection of libraries without any particular reviewing standards. Is that a fair claim? I don't see why Boost couldn't contact the authors of the libraries featured there and ask them to submit their libraries to Boost. Would that be a sensible thing to do? After all, it looks like those libraries are probably well-developed and thought out by experts in those domains. The benefit of having them in Boost, of course, is the review that ensures high code quality, uniformity, and sharing of redundant facilities. And I don't see that there is any conflict between having them listed on oonumerics.org and also be Boost libraries. Is there?
Dave
The only problem I see is that many of the libraries listed at oonumerics haven't been under development for a few years. This could be because the authors are happy with what they have and see no need for further work on it or because they just stopped working on it. I have no way to know that, but either way I would expect it to be hard to get them involved in boostifying the work. John
"John Phillips" <phillips@mps.ohio-state.edu> wrote in message news:40C21944.5060001@mps.ohio-state.edu...
[...] The only problem I see is that many of the libraries listed at oonumerics haven't been under development for a few years. This could be because the authors are happy with what they have and see no need for further work on it or because they just stopped working on it. I have no way to know that, but either way I would expect it to be hard to get them involved in boostifying the work.
At the least it would be a good idea to see if they would let us use their libraries as a starting point, wouldn't it? At the very least, we could ask them to license their libraries under the BSL. I mean, for a task as big as making C++ a first-rate scientific computing language, we need all the help we can get, no? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
Walter Landry <wlandry@ucsd.edu> writes:
Have you looked at
http://www.oonumerics.org/FTensor/
It implements a fair number of different tensor types (e.g. symmetric, antisymmetic), the element type is templated, and it has natural ways of specifying contractions. It doesn't have separate covariant and contravariant tensors, but that wouldn't be that hard to implement. It would just be a fair amount of work for quesionable gain. I used it for my General Relativity code, and I never missed the distinction between covariant and contravariant indices.
I bill it as a high performance tensor library, though now I think it might actually be better to use ordinary loops instead of the compile-time loops.
Really? Please say more. I clearly remember your talk on that work; weren't you saying that ordinary loops were so hard to write correctly that they compromised the chances of success in your projects? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
Have you looked at
http://www.oonumerics.org/FTensor/
It implements a fair number of different tensor types (e.g. symmetric, antisymmetic), the element type is templated, and it has natural ways of specifying contractions. It doesn't have separate covariant and contravariant tensors, but that wouldn't be that hard to implement. It would just be a fair amount of work for quesionable gain. I used it for my General Relativity code, and I never missed the distinction between covariant and contravariant indices.
I bill it as a high performance tensor library, though now I think it might actually be better to use ordinary loops instead of the compile-time loops.
Really? Please say more.
I clearly remember your talk on that work; weren't you saying that ordinary loops were so hard to write correctly that they compromised the chances of success in your projects?
Sorry, I was not clear. Yes, if I had written out all of those loops by hand, I would never have finished. Rather, my comment above is about the internal mechanism to auto-generate the loops. In FTensor, I used compile time loops. Now I think it might be better to just use run-time loops. To use a factorial as an example, instead of something like template<int N> class Factorial { public: enum { value = N * Factorial<N-1>::value }; }; class Factorial<1> { public: enum { value = 1 }; }; I think it might be better to ditch a lot of the template metaprogramming stuff and just use int factorial(int F) { int result(1); for(int i=F; i>1; --i) result*=i; return result; } I described some benchmarks here: http://groups.google.com/groups?q=g:thl3194341146d&dq=&hl=en&lr=&ie=UTF-8&selm=87d6rdlirf.fsf%40grue.ucsd.edu&rnum=7 Of course, it is possible that I just screwed up the implementation of FTensor ;) Cheers, Walter Landry wlandry@ucsd.edu
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held Sent: Wednesday, June 02, 2004 9:13 PM To: boost@lists.boost.org Subject: [boost] Re: Re: Boost Mathematicians
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0B GKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net... [...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
And that's not the case I would make in this scenario. I'd say that it only makes sense to port all that code from other languages if C++ offers compelling reasons to do so. Just because it can be "just as fast" or "just as accurate" doesn't mean that we should invest all this time in it. Isn't it possible to call a FORTRAN library from C++?
There are many other languages that offer this feature or that feature better than C++. But at the end of the day, I have to say that C++ is the right choice for a lot of projects because of factors other than speed or size. And by that I mean things like installed code base, user support, platform support, etc. The fact that people have been writing scientific e in FORTRAN pretty much since the language was invented means that there is a huge installed base of tools for working with it. These are the kinds of factors I have in mind when I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having > to reinvent the wheel?
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the >implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
Sure, I agree. The motivating influence, I'd say, would be to have such a thing in the C++ STL spec, as that's the raison d'etre for Boost to begin with. If it's already out there, freely available in some other language, and there's no reason for wanting it in the spec, then sure, don't do it. Question is, is all of that true? And would it be of value to have it incorporated into the language spec? From my standpoint, yes. Others may not agree. Reid
"David B. Held" <dheld@codelogicconsulting.com> writes:
I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having to reinvent the wheel?
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
The big advantage that C++ has over other languages is the ability of metaprograms to use high-level domain knowledge to optimize arbitrary, *readable* calculations. Yes, it's worth "reinventing" all of those FORTRAN algorithms, because using LAPACK et al. doesn't result in expressive code - every combination of input types has to be handled by a different function with some oddball name. Furthermore, if implementations are not generated programmatically, then they're bug-prone. Even if they are generated programmatically, they are limited (want to work on a matrix of octonions or of small matrices? Sorry -- you're out of luck). Furthermore, pre-generated optimized calculations don't scale. If your FORTRAN library contains a routine to add 3 arrays efficiently, it may not be able to do the same thing for 4 or 5 arrays. With expression templates you can just write the expression and let the metaprograms deal with scaling up the calculation. I don't mean to be sanguine about the very real hurdles faced by C++ numerical software, but we *do* have some real advantages that counter low-level disadvantages such as the possibility of aliasing. As the sorts of calculations people want to do grow more and more complex, the inability of statically-built FORTRAN libraries to adapt, and the inability of those using the libraries to write code that is clear, expressive, and maintainable, will become more of a liability. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Yes, it's worth "reinventing" all of those FORTRAN algorithms, because using LAPACK et al. doesn't result in expressive code - every combination of input types has to be handled by a different function with some oddball name. Furthermore, if implementations are not generated programmatically, then they're bug-prone. Even if they are generated programmatically, they are limited (want to work on a matrix of octonions or of small matrices? Sorry -- you're out of luck). Furthermore, pre-generated optimized calculations don't scale. If your FORTRAN library contains a routine to add 3 arrays efficiently, it may not be able to do the same thing for 4 or 5 arrays. With expression templates you can just write the expression and let the metaprograms deal with scaling up the calculation.
I was skimming through Todd Veldhuizen's notes on high performance C++ computing that are accessible from the oonumerics site and I noticed another potential problem with just writing FORTRAN wrappers. According to his notes, FORTRAN compilers are not consistent about symbol naming, so a wrapper needs to know what FORTRAN compiler is being used. The notes are from 2000, so there has been time for the situation to change, but this is an important issue if wrappers are used. John
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoenzz8gi.fsf@boost-consulting.com...
[...] The big advantage that C++ has over other languages is the ability of metaprograms to use high-level domain knowledge to optimize arbitrary, *readable* calculations. [...]
Ok, I think that's a pretty good argument. Now we just have to convince all the folks that worked on the original canonical libraries to help us write decent C++ versions. ;) Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
Somewhere in the E.U., le 15/06/2004 Bonjour In article <c9m4td$alu$1@sea.gmane.org>, "David B. Held" <dheld@codelogicconsulting.com> wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJAA AQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
[...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
And that's not the case I would make in this scenario. I'd say that it only makes sense to port all that code from other languages if C++ offers compelling reasons to do so. Just because it can be "just as fast" or "just as accurate" doesn't mean that we should invest all this time in it. Isn't it possible to call a FORTRAN library from C++?
There is no guaranteed way to do so, and no guaranty that if the call is allowed it will do what is intended. You may also have to consider costs considerations. First, you may have to buy an additional compiler (for instance if your C++ compiler does not play nice with a freely available FORTRAN one). Then you have to maintain software written in two language, one of which is not exactly user friendly (to play devil's advocate, I will not say which ;-) ). This means to keep on staff people who still know FORTRAN. Today, a sizable proportion of the people who use FORTRAN are those who studied it when C was still on the horizon, but in ten years? In twenty? Why would young people *still* want to learn FORTRAN? Latin may soon prove more useful... If you have a large software which must still run in ten to twenty years from now, are you confident you will find staff schooled in that arcane knowledge by then? Even if such is the case, will you be able to afford them? A quick buck now can mean a huge expenditure tomorrow. If you are faced with a legacy program, written in a language you do not know, and you want to fix a bug (and there ARE bugs, there will ALWAYS be bugs), what do you do? Of course, this is a temporality issue. FORTRAN's time has come (or so I believe), C++'s will also. But there is a window of need, and now we do need algorithms in the native language of the rest of the program. Obviously, this does not preclude coding certain portions in other language if there is undeniable gain (now and later), of using code-generating techniques, but homogeneity of language is an help towards the longevity of a given software, and the ease in making it take advantage of new opportunities (multi-threaded MATLAB, anyone?).
There are many other languages that offer this feature or that feature better than C++. But at the end of the day, I have to say that C++ is the right choice for a lot of projects because of factors other than speed or size. And by that I mean things like installed code base, user support, platform support, etc. The fact that people have been writing scientific code in FORTRAN pretty much since the language was invented means that there is a huge installed base of tools for working with it. These are the kinds of factors I have in mind when I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having to reinvent the wheel?
Boost allows *users* not to reinvent the wheel.
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
Dave
It is not that simple. Complex computations can benefit, in terms of expressiveness and thus correction, of object orientation. Wrapping a C or FORTRAN library wont cut it, in the vast majority of cases. Then there is the issue of error detection, flow of calculation, etc.. Hubert Holin
Sorry to top-post, but I'm shot and in a hurry. Briefly, I thought I'd implied all that. Wasn't suggesting anyone rewrite huge amounts of FORTRAN, because very few people will. I wouldn't. Unless someone wanted to set me up with a sinecure for life <g>. Reid
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hubert Holin Sent: Tuesday, June 15, 2004 6:20 AM To: boost@lists.boost.org Subject: [boost] Re: Boost Mathematicians
Somewhere in the E.U., le 15/06/2004
Bonjour
In article <c9m4td$alu$1@sea.gmane.org>, "David B. Held" <dheld@codelogicconsulting.com> wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message
news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1
QAAAKJAA AQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
[...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
And that's not the case I would make in this scenario. I'd say that it only makes sense to port all that code from other languages if C++ offers compelling reasons to do so. Just because it can be "just as fast" or "just as accurate" doesn't mean that we should invest all this time in it. Isn't it possible to call a FORTRAN library from C++?
There is no guaranteed way to do so, and no guaranty that if the call is allowed it will do what is intended.
You may also have to consider costs considerations. First, you may have to buy an additional compiler (for instance if your C++ compiler does not play nice with a freely available FORTRAN one). Then you have to maintain software written in two language, one of which is not exactly user friendly (to play devil's advocate, I will not say which ;-) ). This means to keep on staff people who still know FORTRAN. Today, a sizable proportion of the people who use FORTRAN are those who studied it when C was still on the horizon, but in ten years? In twenty? Why would young people *still* want to learn FORTRAN? Latin may soon prove more useful... If you have a large software which must still run in ten to twenty years from now, are you confident you will find staff schooled in that arcane knowledge by then? Even if such is the case, will you be able to afford them? A quick buck now can mean a huge expenditure tomorrow.
If you are faced with a legacy program, written in a language you do not know, and you want to fix a bug (and there ARE bugs, there will ALWAYS be bugs), what do you do?
Of course, this is a temporality issue. FORTRAN's time has come (or so I believe), C++'s will also. But there is a window of need, and now we do need algorithms in the native language of the rest of the program.
Obviously, this does not preclude coding certain portions in other language if there is undeniable gain (now and later), of using code-generating techniques, but homogeneity of language is an help towards the longevity of a given software, and the ease in making it take advantage of new opportunities (multi-threaded MATLAB, anyone?).
There are many other languages that offer this feature or that feature better than C++. But at the end of the day, I have to say that C++ is the right choice for a lot of projects because of factors other than speed or size. And by that I mean things like installed code base, user support, platform support, etc. The fact that people have been writing scientific code in FORTRAN pretty much since the language was invented means that there is a huge installed base of tools for working with it. These are the kinds of factors I have in mind when I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having to reinvent the wheel?
Boost allows *users* not to reinvent the wheel.
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
Dave
It is not that simple. Complex computations can benefit, in terms of expressiveness and thus correction, of object orientation. Wrapping a C or FORTRAN library wont cut it, in the vast majority of cases. Then there is the issue of error detection, flow of calculation, etc..
Hubert Holin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
What was that comment in "Field of Dreams"? "Build it and they will come"? It might take a while, but I think it'll happen. I think the idea of building a serious boost math library is great! I am more of a mathematician than a C++ programmer, and I think both C++ and boost are absolutely wonderful. C++ allows me to implement in code the same principles and techniques of abstraction that I use in my (completely pure) research. All of boost is built using these same principles; I found it completely miraculous that I could find a software library that is completely compatible with the same philosophy that I use to do mathematics and write software. If boost can package crucial mathematical algorithms and functions in a suitable abstract framework, it would be great.
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net... | Oddly enough, scientists is usually pretty | conservative folk; they like what they know. Is that so odd? Yesterday I talked with a matematician here in Sydney about Fortran. He uses Fortran because it is good enough for what he is doing. It would probably take quite some time for him to learn C++, so why should he? br Thorsten
Thorsten Ottosen wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
| Oddly enough, scientists is usually pretty | conservative folk; they like what they know.
Is that so odd? Yesterday I talked with a matematician here in Sydney about Fortran. He uses Fortran because it is good enough for what he is doing. It would probably take quite some time for him to learn C++, so why should he?
Agreed. It's the newcomers that we want to snare, before they've been indoctrinated into Fortran. New mathematicians tend to have at least some computer science training, so they will be looking for more than Fortran to write their code in. The competition will in fact be in the other direction, from languages like Ocaml.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Deane Yang Sent: Thursday, June 03, 2004 8:19 AM To: boost@lists.boost.org Subject: [boost] Re: Boost Mathematicians
Thorsten Ottosen wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message
news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0B GKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
| Oddly enough, scientists is usually pretty | conservative folk; they like what they know.
Is that so odd? Yesterday I talked with a matematician here in Sydney about Fortran. He uses Fortran because it is good enough for what he is doing. It would probably take quite some time for him to learn C++, so why should he?
Agreed. It's the newcomers that we want to snare, before they've been indoctrinated into Fortran. New mathematicians tend to have at least some computer science training, so they will be looking for more than Fortran to write their code in. The competition will in fact be in the other direction, from languages like Ocaml.
No, no. Irony. It's a literary device. The tip-off that I was attempting to employ it is the American colloquialism in re verb number. ;) Reid
Reid Sweatman wrote:
Thorsten Ottosen wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message
| Oddly enough, scientists is usually pretty | conservative folk; they like what they know.
Is that so odd? Yesterday I talked with a matematician here in Sydney
about Fortran.
He uses Fortran because it is good enough for what he is doing. It would
probably take quite some
time for him to learn C++, so why should he?
Agreed. It's the newcomers that we want to snare, before they've been indoctrinated into Fortran. New mathematicians tend to have at least some computer science training, so they will be looking for more than Fortran to write their code in. The competition will in fact be in the other direction, from languages like Ocaml.
No, no. Irony. It's a literary device. The tip-off that I was attempting to employ it is the American colloquialism in re verb number. ;)
Reid
That said, every researcher is conscious of what brings the money in. Especially in times that are tight for funding, no one wants to spend time on learning new programming languages unless it allows them something they don't know how to get from what they already know. This is not the most long-sighted view, but it is common. John
somewhere in the E.U., le 15/06/2004 Bonjour In article <c9nc0o$7d5$1@sea.gmane.org>, Deane Yang <deane_yang@yahoo.com> wrote:
Thorsten Ottosen wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJ AAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
| Oddly enough, scientists is usually pretty | conservative folk; they like what they know.
Is that so odd? Yesterday I talked with a matematician here in Sydney about Fortran. He uses Fortran because it is good enough for what he is doing. It would probably take quite some time for him to learn C++, so why should he?
Agreed. It's the newcomers that we want to snare, before they've been indoctrinated into Fortran. New mathematicians tend to have at least some computer science training, so they will be looking for more than Fortran to write their code in. The competition will in fact be in the other direction, from languages like Ocaml.
Why would he want to learn C++ to do his computations? What about better expressivity? If you need complex numbers, you want to treat them as full-blown critters, and (most frequently, if not always) not as simply a couple of reals. You want to write a+b and x*z, and that the various components work correctly. If your favorite plaything is even weirder, you definitely want to consider it as an object. One thing should be kept in mind: a great many tasks which require to too trivial math either will be carried out with ***prototyping*** software such as MATLAB or SciLab, or made into a custom software which will only be run a few times. In that case, rapid deployment is essential. In that case the object approach (including its C++ incarnation) shine. One would of course want that once the prototyping is done, minimal effort would be involved to put into place a frequently-run, or expensive-run (a.k.a. Cray-like "supercomputer" using) software. But for one such software, how many smaller ones have been made (just to test an idea)? Furthermore, Massive Mainframe Mastodons may perhaps not really represent the future of supercomputing (think "cluster", and distributed computing is a can of worms in and of itself). Waste is bad, but being too clever for one's sake can also not be too good (just consider the original Mac's handling of memory: it was designed to have large programs run with tiny physical memory available, it was brilliant, it was a reason why developers hated working on that platform...). So perhaps not having the best-possible-ever optimization will appear increasingly less significant. So the perceived efficiency edge of FORTRAN will, IMHO, prove increasingly irrelevant. So why not learn C++, which will *also* help with other programing tasks (GUI, etc.)? There are other reasons, such as error handling, and the flow of computing which must be adapted to it. I would favor (and this is the approach I took with the libraries I submitted) an exception-based flow, as it seems (to me at least) more natural that what FORTRAN, C and others currently have. Hubert Holin
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-43D9FC.12043615062004@sea.gmane.org... | What about better expressivity? If you need complex numbers, you | want to treat them as full-blown critters, and (most frequently, if not | always) not as simply a couple of reals. Complex numbers are a funny bunch to implement. We actually don't want too much encapsulation; in fact you can find several proposals on open-std that seek to remove much of the encapsultion of the complex class in C++. br Thorsten
Somewhere in the E.U., le 16/06/2004 Bonjour In article <camtfe$9ja$1@sea.gmane.org>, "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote:
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-43D9FC.12043615062004@sea.gmane.org...
| What about better expressivity? If you need complex numbers, you | want to treat them as full-blown critters, and (most frequently, if not | always) not as simply a couple of reals.
Complex numbers are a funny bunch to implement. We actually don't want too much encapsulation; in fact you can find several proposals on open-std that seek to remove much of the encapsultion of the complex class in C++.
br
Thorsten
What I understood is that people wanted the best of both worlds (sometimes it's an object and sometimes it's just an array), and in this case it could actually happen! What was called for, IIRC, is a guaranty about layout, for which language support was needed. I unfortunately do not know the current situation, but would most like to. Merci Hubert Holin
Regarding std::complex<> Hubert Holin wrote:
What I understood is that people wanted the best of both worlds (sometimes it's an object and sometimes it's just an array), and in this case it could actually happen! What was called for, IIRC, is a guaranty about layout, for which language support was needed. I unfortunately do not know the current situation, but would most like
to. At http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html ... Issue 387 (std::complex over-encapsulated) seems to be what you are referring to and the final remark is... "The LWG believes that C99 compatibility would be enough justification for this change even without other considerations. All existing implementations already have the layout proposed here." ...but I don't know the time-scale for things like this being adopted, even if (for the sake of argument) everyone thinks its a good idea.
"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message news:carmco$8f6$1@sea.gmane.org... | Regarding std::complex<> | | At http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html ... | | Issue 387 (std::complex over-encapsulated) seems to be what you are | referring to and the final remark is... | | "The LWG believes that C99 compatibility would be enough | justification | for this change even without other considerations. All existing | implementations already have the layout proposed here." | | ...but I don't know the time-scale for things like this being adopted, | even if (for the sake of argument) everyone thinks its a good idea. Well, at least for C++0x this would be resolved. br Thorsten
I am very interested, and I have spent some thought on how to create some of these submissions myself. Coming from an Astrophysics research group, I am quite pleased with the boost standards for code and documentation and I feel that the boost license is a good basis for research software writing since it is always possible that a research application could become the basis for a commercial application, but you also want direct access to the source code and the ability to modify. John Phillips Tom Brinkman wrote:
What is the current status of all Boost mathmatical, statistical and econometric libraries currently in development?
The collection of boost math libraries that are currently included in the library are world-class and provide a wonderful foundation to build-upon.
However, many areas of advanced statistical and mathmatical inference are not currently being addressed by any of the boost libraries.
Is there currently a way for those boost developers with a background in mathmatics to coordinate their efforts. If not, why not? Lets get such a discussion started.
A continued and regular dialog of mathmatics as it relates to boost library development would be of great use, primaryily to avoid overaping our efforts.
If your a mathmetician and agree with me that boost is a great foundation to build-upon, let the group/me know.
[snip]
Regards, Tom Brinkman
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman <reportbase@yahoo.com> writes:
In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be.
Comments?
1. I think oonumerics.org has the jump on us here, though the site seems to be douwn at this moment. 2. I will be starting work on a rewrite of MTL (the Matrix Template Library) for linear algebra soon. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufz9c4t4x.fsf@boost-consulting.com... | 2. I will be starting work on a rewrite of MTL (the Matrix Template | Library) for linear algebra soon. sounds excellent. Do you plan to implement generic matrix algorithms like these for square matrices: invert spectral deconposition trace determinant transpose pow/sqrt eigen_solve ? With these algorithms we would get a long way when doing fully generic multivariate statistics. br Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufz9c4t4x.fsf@boost-consulting.com...
| 2. I will be starting work on a rewrite of MTL (the Matrix Template | Library) for linear algebra soon.
sounds excellent. Do you plan to implement generic matrix algorithms like these for square matrices:
invert spectral deconposition trace determinant transpose pow/sqrt eigen_solve
None of those are on my list, but if the framework is done right it should be easy to attack any of them -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Tom Brinkman <reportbase@yahoo.com> writes:
In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be.
Comments?
1. I think oonumerics.org has the jump on us here, though the site seems to be douwn at this moment.
2. I will be starting work on a rewrite of MTL (the Matrix Template Library) for linear algebra soon.
What do you plan for MTL? How is it different than ublas?
"Neal D. Becker" <ndbecker2@verizon.net> writes:
David Abrahams wrote:
Tom Brinkman <reportbase@yahoo.com> writes:
In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be.
Comments?
1. I think oonumerics.org has the jump on us here, though the site seems to be douwn at this moment.
2. I will be starting work on a rewrite of MTL (the Matrix Template Library) for linear algebra soon.
What do you plan for MTL? How is it different than ublas?
MTL is aimed at linear algebra, whereas IIUC ublas is not. There's a lot more to what's in the current plan than I can lay out here, but the focus will be on support for different kinds of matrices with combinations of these aspects o Shape o Orientation o Symmetry o Sparsity o Blocking o Upper / Lower storage o Unit diagonal o Etc. and operations like: o scalar-vector (vector-scalar) multiplication o vector addition (and subtraction) o apply linear operator (left) o norm o inner product o triangular solve ... with expression templates, and of course, zero abstraction penalty ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Perhaps it's my own bias, but I think an underutilized concept is that of a dual vector space and the corresponding contraction of a vector and a dual vector. If you assume the vector space is R^n, then of course you can identify the dual vector space with the original vector space and the contraction as just being the inner product. And since every vector space in a computer program is implemented as R^n (or F^n, F a field), I think people always assume that there is no point in designing an interface that expresses duality. However, in many situations you gain additional protection against mathematical and computation errors, if you treat vectors and dual vectors as being in different vector spaces and constrain the operations between them appropriately. I use this routinely in my hand calculations when doing my research. A simple example is the duality between position vectors and momentum vectors in physics. Any chance you would want to implement this, too? David Abrahams wrote:
MTL is aimed at linear algebra, whereas IIUC ublas is not.
There's a lot more to what's in the current plan than I can lay out here, but the focus will be on support for different kinds of matrices with combinations of these aspects
o Shape o Orientation o Symmetry o Sparsity o Blocking o Upper / Lower storage o Unit diagonal o Etc.
and operations like:
o scalar-vector (vector-scalar) multiplication o vector addition (and subtraction) o apply linear operator (left) o norm o inner product o triangular solve ...
with expression templates, and of course, zero abstraction penalty ;-)
Deane Yang <deane_yang@yahoo.com> writes:
Perhaps it's my own bias, but I think an underutilized concept is that of a dual vector space and the corresponding contraction of a vector and a dual vector.
If you assume the vector space is R^n, then of course you can identify the dual vector space with the original vector space and the contraction as just being the inner product. And since every vector space in a computer program is implemented as R^n (or F^n, F a field), I think people always assume that there is no point in designing an interface that expresses duality.
However, in many situations you gain additional protection against mathematical and computation errors, if you treat vectors and dual vectors as being in different vector spaces and constrain the operations between them appropriately. I use this routinely in my hand calculations when doing my research.
A simple example is the duality between position vectors and momentum vectors in physics.
Any chance you would want to implement this, too?
My first priorities are being determined by other clients, but we'd be happy to take contracts for development of additional capabilities. Not that I fully understand what you're describing, yet... ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
with expression templates, and of course, zero abstraction penalty ;-)
Is a reference-counted array type also part of the plan? Thanks, Ralf __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
with expression templates, and of course, zero abstraction penalty ;-)
Is a reference-counted array type also part of the plan?
Not specifically. We'll probably be relying on Boost.Move (in the sandbox) to avoid unneccessary copies. We may use reference-counting to implement an "fine-grained immutable" array type, but if so, that will provide a complete illusion of value semantics and *not* reference semantics. It's crucial that array a = b; a *= 2; never alters b. A concept taxonomy in which b is sometimes altered and sometimes not would be impossible to write generic code for. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
with expression templates, and of course, zero abstraction penalty ;-)
Is a reference-counted array type also part of the plan?
Not specifically. We'll probably be relying on Boost.Move (in the sandbox) to avoid unneccessary copies. We may use reference-counting to implement an "fine-grained immutable" array type, but if so, that will provide a complete illusion of value semantics and *not* reference semantics. It's crucial that
array a = b; a *= 2;
never alters b. A concept taxonomy in which b is sometimes altered and sometimes not would be impossible to write generic code for.
You are hitting the nail on the head. Experience with my own reference-counted array type tells me that the issue of immutability/constness needs extreme care. My own solution has the glaring shortcoming of not providing a const-reference-counted array type (excuses available on request :-). But having said that, I found it a lot worse not to be able to write a function that returns a new array without incurring a deep copy. Move semantics in one form or another is absolutely crucial to enable writing of readable code. Some related thoughts from an amateur array library designer that may or may not be useful: 0. The two fundamental properties of array types are: - Memory management model - Indexing model 1. I found the following memory management models for arrays to be essential in practical applications (i.e. I implemented them all, and make heavy use of all): stack, fixed size stack, variable size, fixed capacity heap, variable capacity, one owner (e.g. std::vector) heap, variable capacity, shared ownership reference to any of these (i.e. "no management") 2. Common "indexing models" are 1-dim indexing (e.g. std::vector), 2-dim (matrix types), n-dim regular grids (e.g. Fortran's DIMENSION statement, Python's Numeric arrays, Blitz). However, these are just typical examples. Applications often require custom indexing models (e.g. we have periodic grids and grids with other types of symmetry; spare matrices may be viewed as another example). 3. A general purpose array library should provide a mechanism for reusing memory management models and indexing models in various combinations. This could lead to: memory_model<typename ValueType, typename IndexingModelType> or indexing_model<typename ValueType, typename MemoryModelType> 4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to: template < typename ValueType, typename MemoryModelType, typename IndexingModelType, typename AlgebraType> array; In an ideal world I could then do this: template <typename ValueType, std::size_t MaxSize> typedef array< ValueType, stack_variable<MaxSize>, matrix_indexing, matrix_algebra> small_matrix; small_matrix<double, 20> a(3,3), b(4,5); template <typename ValueType> typedef array< ValueType, heap_shared, matrix_indexing, matrix_algebra> shared_matrix; shared_matrix<double> a(300, 400); template <typename ValueType, std::size_t NDim> typedef array< ValueType, heap_shared, c_convention<NDim>, // or fortran_convention<NDim> element_wise_algebra> n_dim_c_array; n_dim_c_array<double, 3> a(10,20,30); [I know we don't have template typedefs :-( :-( ] 5. Expression templates are an optimization on top of all this and in my practical experience the least important of all the points mentioned here. In all likelihood the 5-10% of code that matter for runtime performance have to be hand-optimized anyway, usually leading to distortions of the original, intuitive code beyond recognition. Having or not having to throw in a few extra loops by hand doesn't make a difference. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
with expression templates, and of course, zero abstraction penalty ;-)
Is a reference-counted array type also part of the plan?
Not specifically. We'll probably be relying on Boost.Move (in the sandbox) to avoid unneccessary copies. We may use reference-counting to implement an "fine-grained immutable" array type, but if so, that will provide a complete illusion of value semantics and *not* reference semantics. It's crucial that
array a = b; a *= 2;
never alters b. A concept taxonomy in which b is sometimes altered and sometimes not would be impossible to write generic code for.
You are hitting the nail on the head. Experience with my own reference-counted array type tells me that the issue of immutability/constness needs extreme care. My own solution has the glaring shortcoming of not providing a const-reference-counted array type (excuses available on request :-). But having said that, I found it a lot worse not to be able to write a function that returns a new array without incurring a deep copy.
It seems quite a few compilers implement one or another form of RVO.l
Move semantics in one form or another is absolutely crucial to enable writing of readable code.
Some related thoughts from an amateur array library designer that may or may not be useful:
0. The two fundamental properties of array types are:
- Memory management model - Indexing model
I guess you haven't read the MTL concept breakdown: - Shape - Storage (I think this is what you're calling memory management) - Orientation (row-major, column-major, diagonal-major...)
1. I found the following memory management models for arrays to be essential in practical applications (i.e. I implemented them all, and make heavy use of all):
stack, fixed size stack, variable size, fixed capacity heap, variable capacity, one owner (e.g. std::vector) heap, variable capacity, shared ownership reference to any of these (i.e. "no management")
That's storage.
2. Common "indexing models" are 1-dim indexing (e.g. std::vector), 2-dim (matrix types), n-dim regular grids (e.g. Fortran's DIMENSION statement, Python's Numeric arrays, Blitz). However, these are just typical examples. Applications often require custom indexing models (e.g. we have periodic grids and grids with other types of symmetry; spare matrices may be viewed as another example).
For linear algebra, you only need 1-dimensional vectors and 2-dimensional matrices. However, you can have matrices of matrices which could be thought of as 4D (although that's probably a flawed way to look at them). I should point out that an "array library" like Blitz++ is probably a different beast from a Matrix/Linear Algebra library like MTL, so what I'm going to be working on may not be aimed at the things you're interested in.
3. A general purpose array library should provide a mechanism for reusing memory management models and indexing models in various combinations. This could lead to:
memory_model<typename ValueType, typename IndexingModelType> or indexing_model<typename ValueType, typename MemoryModelType>
I don't understand why you think one of them should take the other as a parameter.
4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to:
5. Expression templates are an optimization on top of all this and in my practical experience the least important of all the points mentioned here. In all likelihood the 5-10% of code that matter for runtime performance have to be hand-optimized anyway, usually leading to distortions of the original, intuitive code beyond recognition.
The aim is to make the library smart enough to do those optimizations correctly so you don't have to do it by hand. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
You are hitting the nail on the head. Experience with my own reference-counted array type tells me that the issue of immutability/constness needs extreme care. My own solution has the glaring shortcoming of not providing a const-reference-counted array type (excuses available on request :-). But having said that, I found it a lot worse not to be able to write a function that returns a new array without incurring a deep copy.
It seems quite a few compilers implement one or another form of RVO.l
Sorry, I don't know what RVO.l is. Is it portable? Does code exploiting RVO.l to achieve move semantics look intuitive?
I guess you haven't read the MTL concept breakdown:
Right. When I started with my array library (two years ago) it was clear that MTL is too specialized for my purposes.
- Shape - Storage (I think this is what you're calling memory management) - Orientation (row-major, column-major, diagonal-major...)
Is "Orientation" a specialization of "Shape". Couldn't both be viewed as "Indexing models?"
1. I found the following memory management models for arrays to be essential in practical applications (i.e. I implemented them all, and make heavy use of all):
stack, fixed size stack, variable size, fixed capacity heap, variable capacity, one owner (e.g. std::vector) heap, variable capacity, shared ownership reference to any of these (i.e. "no management")
That's storage.
Right. Which of these are you going to support?
3. A general purpose array library should provide a mechanism for reusing memory management models and indexing models in various combinations. This could lead to:
memory_model<typename ValueType, typename IndexingModelType> or indexing_model<typename ValueType, typename MemoryModelType>
I don't understand why you think one of them should take the other as a parameter.
That's what I could cope with at the time with with my 12 months C++ experience and Visual C++ 6 support in mind (brrrrrr). [I settled on memory_model<>; it works OK for me; the biggest disadvantage is that I had to replicate the algebras for each memory model.]
4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to:
Does my generic array design look too daunting? Do we have to wait for another language before array libraries can be implemented in such a generic way?
5. Expression templates are an optimization on top of all this and in my practical experience the least important of all the points mentioned here. In all likelihood the 5-10% of code that matter for runtime performance have to be hand-optimized anyway, usually leading to distortions of the original, intuitive code beyond recognition.
The aim is to make the library smart enough to do those optimizations correctly so you don't have to do it by hand.
A case of "premature optimization?" I am still waiting for an example of real-world code where the critical section is so large that the reduction in code size/gain in maintainability due to the availability of expression templates would justify the cost of implementing the ET library and the increased compile times. -- Maybe I am just too spoiled by Python. :-) I am constantly taking a performance hit of about two orders of magnitude, writing only the critical code in C++, and it turns out to be very practical because the old 90-10 rule is true! Sometimes I even win out compared to brute force number crunching approaches because the very high abstraction level of Python allows me to push bookkeeping and high-level decision making to a point where I know how to skip much of the brute force work. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
You are hitting the nail on the head. Experience with my own reference-counted array type tells me that the issue of immutability/constness needs extreme care. My own solution has the glaring shortcoming of not providing a const-reference-counted array type (excuses available on request :-). But having said that, I found it a lot worse not to be able to write a function that returns a new array without incurring a deep copy.
It seems quite a few compilers implement one or another form of RVO.l
Sorry, I don't know what RVO.l is. Is it portable? Does code exploiting RVO.l to achieve move semantics look intuitive?
Sorry, the "l" was a typo. I meant Return Value Optimization, where values can be returned from functions without actually invoking the copy ctor.
I guess you haven't read the MTL concept breakdown:
Right. When I started with my array library (two years ago) it was clear that MTL is too specialized for my purposes.
- Shape - Storage (I think this is what you're calling memory management) - Orientation (row-major, column-major, diagonal-major...)
Is "Orientation" a specialization of "Shape". Couldn't both be viewed as "Indexing models?"
No, shape is separate. No point in me trying to explain here when you can google for a good explanation from the MTL authors, though ;-)
1. I found the following memory management models for arrays to be essential in practical applications (i.e. I implemented them all, and make heavy use of all):
stack, fixed size stack, variable size, fixed capacity heap, variable capacity, one owner (e.g. std::vector) heap, variable capacity, shared ownership reference to any of these (i.e. "no management")
That's storage.
Right. Which of these are you going to support?
Whatever you like. There will be well-formed concepts, so you can build any storage policy you like if it isn't directly supplied.
4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to:
HilbertSpace, BanachSpace, VectorSpace, LinearAlgebra, RModule, Field, Ring, AbelianGroup, LinearOperator, TransposableLinearOperator were the algebraic concepts we had in mind. I don't think these things should neccessarily be part of the array type though.
Does my generic array design look too daunting?
Not neccessarily... but I doubt I'm going to implement your design. We have specific needs ;-).
Do we have to wait for another language before array libraries can be implemented in such a generic way?
I don't know what you mean. We do intend to make the MTL rewrite very generic.
5. Expression templates are an optimization on top of all this and in my practical experience the least important of all the points mentioned here. In all likelihood the 5-10% of code that matter for runtime performance have to be hand-optimized anyway, usually leading to distortions of the original, intuitive code beyond recognition.
The aim is to make the library smart enough to do those optimizations correctly so you don't have to do it by hand.
A case of "premature optimization?"
No, one of the main _goals_ of this project (from a CS/research point-of-view) is to demonstrate that it can be done.
I am still waiting for an example of real-world code where the critical section is so large that the reduction in code size/gain in maintainability due to the availability of expression templates would justify the cost of implementing the ET library and the increased compile times.
I think iterative solvers are a good example. But expression templates shouldn't be hard to implement given modern TMP knowledge and I can see no reason they need to induce long compile times either.
-- Maybe I am just too spoiled by Python. :-) I am constantly taking a performance hit of about two orders of magnitude, writing only the critical code in C++, and it turns out to be very practical because the old 90-10 rule is true!
Of course it is. If you're taking a performance hit of about two orders of magnitude in your linear algebra code, and you can still afford it, you're simply not in a domain where it matters all that much; other computations are swamping those costs.
Sometimes I even win out compared to brute force number crunching approaches because the very high abstraction level of Python allows me to push bookkeeping and high-level decision making to a point where I know how to skip much of the brute force work.
I'll have to take your word for it. It seems to me that if you can skip the brute force work in Python you can do it in C++, too. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Sorry, the "l" was a typo. I meant Return Value Optimization, where values can be returned from functions without actually invoking the copy ctor.
That would be a cool thing to have, but searching for "RVO" and "Return Value Optimization" in the C++ ISO standard didn't produce any hits. As long as it isn't written down in the standard it is impractical for us (as scientific application developers) to count on it.
I guess you haven't read the MTL concept breakdown:
Right. When I started with my array library (two years ago) it was clear that MTL is too specialized for my purposes.
- Shape - Storage (I think this is what you're calling memory management) - Orientation (row-major, column-major, diagonal-major...)
Is "Orientation" a specialization of "Shape". Couldn't both be viewed as "Indexing models?"
No, shape is separate. No point in me trying to explain here when you can google for a good explanation from the MTL authors, though ;-)
I looked and in my mind Orientation only makes sense given a Shape, and even Storage is only concerned with indexing! So I still believe Orientation is a specialization of Shape. :-) And I cannot find the equivalent of my "MemoryModel" concept (stack, heap, etc.) at all. "dense , banded, packed, banded_view," etc., that's all just concerned with indexing. Googling for "heap stack" at the MTL site didn't turn up a hit. So that fundamental property of an array seems to be magically abstracted away.
Whatever you like. There will be well-formed concepts, so you can build any storage policy you like if it isn't directly supplied.
If that means I can choose between "heap" and "stack", "heap shared", etc. I am excited.
4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to:
HilbertSpace, BanachSpace, VectorSpace, LinearAlgebra, RModule, Field, Ring, AbelianGroup, LinearOperator, TransposableLinearOperator were the algebraic concepts we had in mind. I don't think these things should neccessarily be part of the array type though.
My hope was that you'd cleanly separate MemoryModel from the rest of matrix properties, and that the general framework is reusable for other array types, i.e. n-dim arrays.
Does my generic array design look too daunting?
Not neccessarily... but I doubt I'm going to implement your design. We have specific needs ;-).
Right now it seems to me that MTL matrices have a specific memory model hardwired in (e.g. I see reference-counted std::vectors). That makes the library a lot less interesting to me. Most of our matrices are small (3x3, sometimes 9x12, in that ballpark). A heap based array type is therefore of little interest. If "heap" or "stack" are not template parameters in some form the whole matrix algebra code has to be replicated. That's not very generic.
The aim is to make the library smart enough to do those optimizations correctly so you don't have to do it by hand.
A case of "premature optimization?"
No, one of the main _goals_ of this project (from a CS/research point-of-view) is to demonstrate that it can be done.
Can't argue with that. Only that this is not what I as a scientific application developer am interested in. :-)
Of course it is. If you're taking a performance hit of about two orders of magnitude in your linear algebra code,
No, of course that's all happening in C++.
I'll have to take your word for it. It seems to me that if you can skip the brute force work in Python you can do it in C++, too.
Sure, I could even do in in machine language... if only I'd live long enough. Python is very good at getting high-level bookkeeping done with relatively little effort compared to C++. This makes it practical to accumulate the knowledge that is required to selectively skip brute force number crunching work. It doesn't mean I do everything in Python. Thanks heaven we have Boost.Python and I can quickly farm out the number crunching stuff to C++. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
Sorry, the "l" was a typo. I meant Return Value Optimization, where values can be returned from functions without actually invoking the copy ctor.
That would be a cool thing to have, but searching for "RVO" and "Return Value Optimization" in the C++ ISO standard didn't produce any hits. As long as it isn't written down in the standard it is impractical for us (as scientific application developers) to count on it.
It is written in the standard, but not by that name. Look for the word "elide", and check section 12.2. Still, all optimizations are optional by definition, so you can still decide that you don't want to count on it.
No, shape is separate. No point in me trying to explain here when you can google for a good explanation from the MTL authors, though ;-)
I looked and in my mind Orientation only makes sense given a Shape, and even Storage is only concerned with indexing! So I still believe Orientation is a specialization of Shape. :-) And I cannot find the equivalent of my "MemoryModel" concept (stack, heap, etc.) at all. "dense , banded, packed, banded_view," etc., that's all just concerned with indexing.
This stuff is Jeremy's bailiwick, so I'll leave it to him to answer.
Googling for "heap stack" at the MTL site didn't turn up a hit. So that fundamental property of an array seems to be magically abstracted away.
It's not fundamental because you can never force anything to always be on the stack: new some_matrix<double, stack_allocated> will defeat it. Internal vs. external might be more appropriate terms.
Whatever you like. There will be well-formed concepts, so you can build any storage policy you like if it isn't directly supplied.
If that means I can choose between "heap" and "stack", "heap shared", etc. I am excited.
Then you're excited.
My hope was that you'd cleanly separate MemoryModel from the rest of matrix properties, and that the general framework is reusable for other array types, i.e. n-dim arrays.
Should be.
Does my generic array design look too daunting?
Not neccessarily... but I doubt I'm going to implement your design. We have specific needs ;-).
Right now it seems to me that MTL matrices have a specific memory model hardwired in (e.g. I see reference-counted std::vectors).
The old MTL codebase is not really worth looking at for the purposes of this discussion. It's the concept taxonomy that I'm referring to.
That makes the library a lot less interesting to me. Most of our matrices are small (3x3, sometimes 9x12, in that ballpark).
Specific support for small matrices including register-level blocking is part of the plan.
A heap based array type is therefore of little interest. If "heap" or "stack" are not template parameters in some form the whole matrix algebra code has to be replicated. That's not very generic.
Didn't I make it clear in my last message that you'll be able to use any storage policy you like?
A case of "premature optimization?"
No, one of the main _goals_ of this project (from a CS/research point-of-view) is to demonstrate that it can be done.
Can't argue with that. Only that this is not what I as a scientific application developer am interested in. :-)
Fair enough.
Of course it is. If you're taking a performance hit of about two orders of magnitude in your linear algebra code,
No, of course that's all happening in C++.
I'll have to take your word for it. It seems to me that if you can skip the brute force work in Python you can do it in C++, too.
Sure, I could even do in in machine language... if only I'd live long enough. Python is very good at getting high-level bookkeeping done with relatively little effort compared to C++.
I think that's mostly due to the fact that you don't have the right C++ libraries at your disposal. Of course you know I think there are real advantages to hybrid development, but there's no reason that Python and C++ should be so different aside from access to the right libraries.
This makes it practical to accumulate the knowledge that is required to selectively skip brute force number crunching work.
I can't really imagine how you do that selective skipping nor how Python helps you get there. It all sounds very much like black magic over here.
It doesn't mean I do everything in Python. Thanks heaven we have Boost.Python and I can quickly farm out the number crunching stuff to C++.
:) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
I think that's mostly due to the fact that you don't have the right C++ libraries at your disposal. Of course you know I think there are real advantages to hybrid development, but there's no reason that Python and C++ should be so different aside from access to the right libraries.
This makes it practical to accumulate the knowledge that is required to selectively skip brute force number crunching work.
I can't really imagine how you do that selective skipping nor how Python helps you get there. It all sounds very much like black magic over here.
It is very real. I feel a bit awkward bothering you with this, but to backup my point, look for "Automatic termination" near the bottom of p. 1970 of: http://cci.lbl.gov/publications/download/ba5048_reprint.pdf I realize this is not easy to grasp for non-crystallographers. Think: You can fly even though you didn't turn your arms into wings. OK, I'll shut up now. Just hoping that someone writes *the* array library that can be the foundation for any more specialized array type. What you write about your project looks more and more interesting in this respect. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
This makes it practical to accumulate the knowledge that is required to selectively skip brute force number crunching work.
I can't really imagine how you do that selective skipping nor how Python helps you get there. It all sounds very much like black magic over here.
It is very real. I feel a bit awkward bothering you with this, but to backup my point, look for "Automatic termination" near the bottom of p. 1970 of:
http://cci.lbl.gov/publications/download/ba5048_reprint.pdf
I realize this is not easy to grasp for non-crystallographers.
Oh, I find it perfectly easy to grasp, at least in a general sense. Your're using an iterative method and you want to know when your solution is "good enough". You've implemented a heuristic for deciding. Right? What I don't understand in this is why the use of Python makes a crucial difference in this heuristic. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Oh, I find it perfectly easy to grasp, at least in a general sense. Your're using an iterative method and you want to know when your solution is "good enough". You've implemented a heuristic for deciding. Right?
Yes! Although it is more a multi-trial/trial-and-error method than an iterative method.
What I don't understand in this is why the use of Python makes a crucial difference in this heuristic.
Because I could never have done what I did in the same amount of time if I had tried it in C++. Python is simply unbeatable when it comes to programmer efficiency. It might be intimately connected to how I work as a scientist, though. Initially I often have only a vague idea of what will work and I have to try many different approaches. C++ is too rigid to support this kind of "scientific research" efficiently. But Python is not just good for rapid prototyping and testing of ideas. Here comes the 90-10 rule again: in the end there are many algorithms that I don't even have to reimplement in C++. So I never have to spent the time typing in twice the amount of code, working around compiler bugs as soon as I start using new features of the language or new libraries, and I don't have to wait for 15 minutes once more until everything is rebuilt after changing just two lines in a core part of the system. To back this up with an example: yesterday our whole ~100k C++ lines package (plus Boost) worked fine everywhere except for a SEGFAULT on one platform out of 13. It took me three hours to find out that changing boost::python::extract<int> to boost::python::extract<long> fixed the problem. This was in code that I was using for years; the only thing I did was moving it wholesale to a different extension module. There is no obvious explanation for the SEGFAULT because the size of int and long are exactly the same on that platform (RH 7.3, gcc 2.96). Something like this happens to me all the time and over the year the hours add up to months worth of time. Frustrations like this *never* happen in Python. It is only a couple of decades ago or so that people thought it is worth writing machine code in the interest of runtime efficiency, and the people with compiled code where thought of as the unmanly guys. These days I see myself one level up. Compiled code vs. Python today is like machine code vs. compiled code yesterday... I guess I could go on and on about this and I'll soon be banned from this list. :-) To bring this back to where we started: if I have to go through the pains of "dropping down" to C++ I don't care about the extra loop that I might have to write. What I would love to have though is a generic way to return large arrays from functions without the copy, or small ones without the dynamic memory allocation overhead. Hence my proposal with the array<MemoryModel, IndexingModel> where I can plug in the memory model that is best for a given situation. As far as I can tell the world has been very busy with IndexingModels calling them all kinds of things including Storage, but MemoryModels as parameters have been largely neglected. To me it seems once this problem is solved many things will fall nicely into place. Instead of arguing about the best indexing model, just plug in your own. Inherit from the existing and customize as necessary, freely combine with different memory models as needed or even better, array<MemoryModel, IndexingModel, AlgebraModel>, with different algebras as well. This would be a tool that I could see as increasing my efficiency in using C++ -- when I have no choice. :-) Just my $10. I realize other people have other goals. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Somewhere in the E.U., le 15/06/2004 In article <uvfi7xstw.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
"Neal D. Becker" <ndbecker2@verizon.net> writes:
David Abrahams wrote:
Tom Brinkman <reportbase@yahoo.com> writes:
In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be.
Comments?
1. I think oonumerics.org has the jump on us here, though the site seems to be douwn at this moment.
2. I will be starting work on a rewrite of MTL (the Matrix Template Library) for linear algebra soon.
What do you plan for MTL? How is it different than ublas?
MTL is aimed at linear algebra, whereas IIUC ublas is not.
There's a lot more to what's in the current plan than I can lay out here, but the focus will be on support for different kinds of matrices with combinations of these aspects
o Shape o Orientation o Symmetry o Sparsity o Blocking o Upper / Lower storage o Unit diagonal o Etc.
and operations like:
o scalar-vector (vector-scalar) multiplication o vector addition (and subtraction) o apply linear operator (left) o norm o inner product o triangular solve ...
with expression templates, and of course, zero abstraction penalty ;-)
Huzzah! [sorry for the quote/post ratio, but consider the above in factor of each and every line :-) ] Hubert Holin P.S.: please include singular value decomposition.
Below follow some thoughts on why a potential Boost math library ought to be implemented within C++ - if not from scratch, then with the help of existing C++ libraries such as Blitz++. I don't think I adress any of Tom's discussion points very directly, but overall I would say I agree with him that there is a lot of potential for new libraries in the area. I think it's fair to say (?) that there are more mathematicians than computer scientists in the world. Within computer science alone, we've managed to devise a great number of languages and several of them are in common use: C, C++, Fortran, Java, Pascal, Basic, Python, to name a few. Assuming all these languages provided equivalent math functionality, all of them would likely attract mathematicians, the same way they already attract computer scientists. So, why shouldn't we be able to bring a large number of mathematicians to C++? The only reason, so far, is probably just lack of tools ("If you build it they will come" as Deane Yang put it). Many (if not the majority of) projects are not purely mathematical, but perform many tasks where scientific computing plays one role. Once you choose C++ for some reason (John Philips names many reasons), I think most people agree that it is much less hassle to stay within the language if you can, rather than hiring FORTRAN programmers and trying to make everything link together. Thus, even if implementations exist for other languages, I think one in C++ is worthwhile. There's been some discussion on whether to just provide wrappers to other libraries, or to implement them from scratch. At the same time, the library is viewed in the perspective of something that might end up in the language specification. That assumption does not quite mix with the wrapper discussion. Since a language specification would only define the interface, the use of FORTRAN libraries or whatever in the core would be at std library vendor's discretion. However, in addition to the interface, the Boost community provides a reference implementation. The question is, would we want this reference implementation to require external compilers for other languages? Furthermore, if the interface is not proven to be implementable efficiently in C++, can we be sure that it is at all possible? I think being able to implement 99% of the language specification within the language itself is important. If such a goal isn't met, we would essentially limit C++ to platforms that also provide the other languages needed. I don't think it would be a defeat to show comparison graphs where FORTRAN turns out to run faster than C++. There are many times when other things are important than that extra bit of speed. Speed of implementing the algorithm, for instance. If I see graphs where FORTRAN is, say, 10% faster, I might just decide it's worth losing 10% speed in order to gain something else. /Mattias
Mattias Flodin wrote:
I don't think it would be a defeat to show comparison graphs where FORTRAN turns out to run faster than C++. There are many times when other things are important than that extra bit of speed. Speed of implementing the algorithm, for instance. If I see graphs where FORTRAN is, say, 10% faster, I might just decide it's worth losing 10% speed in order to gain something else.
That's putting it mildly! I'm willing to stick to C++ for its advantages even if there is incontrovertible proof (which there never is) that Fortran or C can do it 100% faster. A difference of 10% is absolutely inconsequential. Of course, thoughts like this lead me to wonder about other languages that seem to be easier to use than C++.
"Deane Yang" <deane_yang@yahoo.com> wrote in message news:c9q0av$mfj$1@sea.gmane.org...
[...] That's putting it mildly! I'm willing to stick to C++ for its advantages even if there is incontrovertible proof (which there never is) that Fortran or C can do it 100% faster. A difference of 10% is absolutely inconsequential.
Of course, thoughts like this lead me to wonder about other languages that seem to be easier to use than C++.
Yeah, if performance is no object, why not go functional? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
"Mattias Flodin" <flodin@cs.umu.se> wrote in message news:1086354003.5749.68.camel@katran...
[...] However, in addition to the interface, the Boost community provides a reference implementation. The question is, would we want this reference implementation to require external compilers for other languages?
This is a good question.
[...] I think being able to implement 99% of the language specification within the language itself is important. If such a goal isn't met, we would essentially limit C++ to platforms that also provide the other languages needed.
Not quite. You need only provide the libraries, which could possibly be cross-compiled. And you will be hard-pressed to find a platform used for scientific computing that wouldn't already have the external lanugages in question.
I don't think it would be a defeat to show comparison graphs where FORTRAN turns out to run faster than C++. There are many times when other things are important than that extra bit of speed. Speed of implementing the algorithm, for instance. If I see graphs where FORTRAN is, say, 10% faster, I might just decide it's worth losing 10% speed in order to gain something else.
You might. But if you're buying 100 hours of time on a supercomputer at $100/hr. (not sure what going rates are), 10% could mean the difference between $10,000 and $9,000. If we're talking $1,000/hr. or many more hours (like a month), then the absolute savings is obviously much greater. If we aren't targeting the high-end computing market, then perhaps this is all irrelevant. But if you want the best mathematicians in the world to take these libraries seriously, then perhaps we do want to target the high-performance computing market. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
Hi, On Fri, Jun 04, 2004 at 11:01:38AM -0500, David B. Held wrote:
"Mattias Flodin" <flodin@cs.umu.se> wrote in message news:1086354003.5749.68.camel@katran...
[snip]
You might. But if you're buying 100 hours of time on a supercomputer at $100/hr. (not sure what going rates are), 10% could mean the difference between $10,000 and $9,000. If we're talking $1,000/hr. or many more hours (like a month), then the absolute savings is obviously much greater. If we aren't targeting the high-end computing market, then perhaps this is all irrelevant. But if you want the best mathematicians in the world to take these libraries seriously, then perhaps we do want to target the high-performance computing market.
I have followed the discussion here for a while. I think, that the reasoning here is missing one important point. If the mathematical library will be implemented somehow, it will not be used solely by mathematicians. There is a lot of application software out there that needs to do some math. Boost mathematical library would fill a very important gasp. Since most of the programmers are not math scientist, this library would provide a great help. For a math scientist it does not realy matter which language to use for a particular problem. On the other hand, an application programmer is often tied by strong constraints since the math part is usualy only a small piece of whole. I'm pretty sure that for such an application the slight decrease in performance compared to fortran for example, would have marginal importance when compared to simplicity of integration and usage. So I think, that implementing a mathematical library in boost is very good idea. Because of the reasons I stated, full C++ implementaion might be better than a wrapper over some fortran libraries. Every mathematician have fortran installed, but this is not true for an application programmers. Thats my 0.5SKK Regards, Pavol
"Pavol Droba" <droba@topmail.sk> wrote in message news:20040604180033.GD19968@lenin.felcer.sk... | Thats my 0.5SKK hm...does that mean you don't have the Euro (or the Teuro as the Germans say) in the Slovak Republic? :-) -Thorsten
On Sat, Jun 05, 2004 at 01:47:44PM +1000, Thorsten Ottosen wrote:
"Pavol Droba" <droba@topmail.sk> wrote in message news:20040604180033.GD19968@lenin.felcer.sk...
| Thats my 0.5SKK
hm...does that mean you don't have the Euro (or the Teuro as the Germans say) in the Slovak Republic? :-)
Not yet ;) It's still a couple of years ahead. Pavol.
David B. Held wrote:
You might. But if you're buying 100 hours of time on a supercomputer at $100/hr. (not sure what going rates are), 10% could mean the difference between $10,000 and $9,000. If we're talking $1,000/hr. or many more hours (like a month), then the absolute savings is obviously much greater. If we aren't targeting the high-end computing market, then perhaps this is all irrelevant. But if you want the best mathematicians in the world to take these libraries seriously, then perhaps we do want to target the high-performance computing market.
Dave
In computational physics there is a bit of folklore about the scale of problems people are willing to attempt. The largest problems done take about a month on the best machines available. In that setting, 10% is a big deal and 100% is completely unacceptable. However, if someone is not doing the most complex computational problems there is not nearly as much pressure for performance. At the physics department that I am a part of, much research computation is done on personal computers and in run times of less than an hour. In that setting, if you don't have to do too many runs, 10% is not a big deal. John
|-----Original Message----- |From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf |Of Tom Brinkman |Sent: 03 June 2004 00:54 |To: boost@lists.boost.org |Subject: [boost] Boost Mathematicians |What is the current status of all Boost mathmatical, |statistical and econometric libraries currently in |development? |The collection of boost math libraries that are |currently included in the library are world-class and |provide a wonderful foundation to build-upon. |However, many areas of advanced statistical and |mathmatical inference are not currently being \addressed by any of the boost libraries. I have been off-line for some time, but have now caught up with this discussion a bit. Strongly support your views and need these things yesterday ;-) Apart from messing about with Microsoft Windows problems, I have been preparing a formal proposal for C and C++ Standard Library TR-2 of a list of Math 'Special' Functions (additional to those from Walter Brown which have been accepted into TR-1). This list will include all the usual statistical suspects - including Student's t, Chi sqr, and F, so that at last it will be possible easily write C++ to provide the probability that means of two series of measurements differ. (The key function is the incomplete beta; it is also the most difficult to write well). Fortunately I have persuaded Stephen Moshier, author of the Cephes function library (in C) to make this available under Boost licence terms. So implementors will have no excuse to hide behind (the reason why these functions were omitted by Walter Brown). It should be possible to produce a working (and I believe rather good) implementation with little more than renaming the functions. This might be submitted for a Boost library. I hope to expose a revised draft to the rigours of Boost and C++.std newsgroup Real Soon Now. Paul Paul A. Bristow Prizet Farmhouse, Kendal UK LA8 8AB +44 1539 561830 07714 33 02 04 pbristow@hetp.u-net.com
Somewhere in the E.U., le 15/06/2004 Bonjour In article <20040602235400.88511.qmail@web50401.mail.yahoo.com>, Tom Brinkman <reportbase@yahoo.com> wrote:
What is the current status of all Boost mathmatical, statistical and econometric libraries currently in development?
I am still desperately trying to find time to work on special functions. As things look now, the first time slot I have available for this is the last week of July. I *will* work on them, however.
The collection of boost math libraries that are currently included in the library are world-class and provide a wonderful foundation to build-upon.
[collective blush]
However, many areas of advanced statistical and mathmatical inference are not currently being addressed by any of the boost libraries.
Is there currently a way for those boost developers with a background in mathmatics to coordinate their efforts. If not, why not? Lets get such a discussion started.
The main problem is time (see above). Then there are genuine field-specific difficulties, as evidenced by the math constants proposalS.
A continued and regular dialog of mathmatics as it relates to boost library development would be of great use, primaryily to avoid overaping our efforts.
If your a mathmetician and agree with me that boost is a great foundation to build-upon, let the group/me know.
Points for Discussion:
1) We should keep a seperate list of boost::math libraries that are currently under development and provide a forum for advanced discussions. How can we do this?
The usual procedure for all Boost libraries work very well here as well. Several proposals are floated on this list. Usually, when we get to the nitty-gritty, personal E-mails are best, and then the review process is by far the best honing tool before release. Then it's user feedback, and the next iteration.
2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians?
Develop and they will come :-) .
3) We should create a list of mathmatical algorithims and libraries that are needed.
These sporadically appear here. Perhaps a more permanent (if of varying content) document in the Boost distribution would be beneficial?
4) We need some very basic boost specific math-tutorials for our future mathemiticans and potential library writers.
Everybody is welcome to contribute. Even though I have (still) not had the time to look at this, perhaps the wiki could be levered?
5) We need to advertise to the development community about how strong of a foundation boost is for mathmatical library development.
In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be.
Comments?
Regards, Tom Brinkman
There *are* issues with math development in C++. Some deal with efficiency, and are pointed out in other components of this thread. Others that apparently have not been, requires language support. For instance default template parameters are sadly limited in kind (has this been fixed while I was in Limbo?). Another one (which evades me at the moment, sorry, really need some vacation) involves template functions (but not classes) and either default parameters or overloading. Hubert Holin
participants (23)
-
Darren Cook -
David Abrahams -
David B. Held -
David Bergman -
Deane Yang -
Geoff Leyland -
Hubert Holin -
John Fuller -
John Phillips -
Jonathan Wakely -
Ken Hagan -
Matt Hurd -
Mattias Flodin -
Neal D. Becker -
Paul A Bristow -
Pavol Droba -
Ralf W. Grosse-Kunstleve -
Reid Sweatman -
Stefan Seefeld -
Thorsten Ottosen -
Tom Brinkman -
Victor A. Wagner Jr. -
Walter Landry