From: Elizabeth F. <rp...@co...> - 2016-01-08 19:41:12
|
Hello, I received the following response to my recent query about the status of Blitz++ (edited by me): Based upon the website, I don't know how active Blitz++ is anymore. Many > of the named individuals have moved on... If I were you, I would fork the project onto Github with git-svn (I assume > like most older projects on SourceForge, Blitz++ is using Subversion), both > because it will obviate the need for repo permissions while at the same > time encouraging the Blitz++ community to move into this decade :-) I agree, this would be a sensible approach. But to make it work, we would need momentum on the new repository. It's best if the people in charge of the SourceForge site can close it down, or post prominent information such as "This site is obsolete; please go over to GitHub if you want the latest version of Blitz++." To that end, here are my thoughts: *) I would really like to wait a reasonable length of time (a couple days), to see if we hear from the current Blitz++ developers. *Is there anybody out there?* *) There's already a Blitz++ fork on GitHub, at: https://github.com/syntheticpp/blitz I don't know how much interest its author (Peter Kümmel) has in maintaining this, or if he just forked it to make sure it didn't disappear. I don't know to what extent it might have diverged from the latest Blitz++ tarball. *) I can't for the life of me find ANY repository on SourceForge anymore, just a tarball. Maybe the repository for Blitz++ has been disabled? If anyone can point me to a repository URL for Blitz++ on SourceForge, that would be greatly appreciated. *) Is anyone other than myself interested in contributing or being a developer on this project? Blitz++ is a quality, stable piece of software. But I don't want to replace one abandonware repository with another; better to start with at least a little momentum. Thank you, -- Elizabeth |
From: Mario E. <ma...@em...> - 2016-01-08 23:00:05
|
Hi, there are still many people lurking around the project, but I think the development is not very active. You may want to check a bit the mailing list archive for more info. For example, the newest repo that I know of is: http://blitz.hg.sourceforge.net/hgweb/blitz/blitz Cheers, Mario On 08.01.2016 20:41, Elizabeth Fischer wrote: > Hello, > > I received the following response to my recent query about the status of Blitz++ > (edited by me): > > Based upon the website, I don't know how active Blitz++ is anymore. Many of > the named individuals have moved on... > > > > If I were you, I would fork the project onto Github with git-svn (I assume > like most older projects on SourceForge, Blitz++ is using Subversion), both > because it will obviate the need for repo permissions while at the same time > encouraging the Blitz++ community to move into this decade :-) > > > I agree, this would be a sensible approach. But to make it work, we would need > momentum on the new repository. It's best if the people in charge of the > SourceForge site can close it down, or post prominent information such as "This > site is obsolete; please go over to GitHub if you want the latest version of > Blitz++." > > To that end, here are my thoughts: > > *) I would really like to wait a reasonable length of time (a couple days), to > see if we hear from the current Blitz++ developers. *Is there anybody out there?* > > *) There's already a Blitz++ fork on GitHub, at: > https://github.com/syntheticpp/blitz > I don't know how much interest its author (Peter Kümmel) has in maintaining > this, or if he just forked it to make sure it didn't disappear. I don't know to > what extent it might have diverged from the latest Blitz++ tarball. > > *) I can't for the life of me find ANY repository on SourceForge anymore, just a > tarball. Maybe the repository for Blitz++ has been disabled? If anyone can > point me to a repository URL for Blitz++ on SourceForge, that would be greatly > appreciated. > > *) Is anyone other than myself interested in contributing or being a developer > on this project? Blitz++ is a quality, stable piece of software. But I don't > want to replace one abandonware repository with another; better to start with at > least a little momentum. > > Thank you, > -- Elizabeth > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > > > > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstrasse 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ |
From: Peter K. <syn...@gm...> - 2016-01-09 11:10:36
|
I would say Blitz is in maintenance mode, nobody really develops it any more. I only use it because once it was a nice option. Because of C++11/14/17 I assume much code is obsolete now or much to verbose. Am 08.01.2016 um 20:41 schrieb Elizabeth Fischer: > > *) There's already a Blitz++ fork on GitHub, at: > https://github.com/syntheticpp/blitz > I don't know how much interest its author (Peter Kümmel) has > in maintaining this, or if he just forked it to make sure it > didn't disappear. I don't know to what extent it might have > diverged from the latest Blitz++ tarball. I imported it from the repository (I assume somehow I found also the hg repository) and only commited some small fixes, because upstream is dead. > > *) I can't for the life of me find ANY repository on > SourceForge anymore, just a tarball. Maybe the repository > for Blitz++ has been disabled? If anyone can point me to a > repository URL for Blitz++ on SourceForge, that would be > greatly appreciated. > > *) Is anyone other than myself interested in contributing or > being a developer on this project? Blitz++ is a quality, > stable piece of software. But I don't want to replace one > abandonware repository with another; better to start with at > least a little momentum. > > Thank you, > -- Elizabeth > |
From: Peter B. <pa...@ph...> - 2016-01-13 21:52:10
|
Hi, Just a small comment — I’m working on a distributed MPP cartesian grid code. github.com/paboyle/Grid Certainly not pitching it as it is niche, focussed on particle physics, but I found C++11 does enable MUCH smaller more compact expression template engines ~ 250 LOC. Something I learned from Antonin Portelli, CC’d. The corresponding C++98 US QDP++ package was more like 100k LOC using PETE. So I agree that there is VERY much scope for a rewrite/update using features that were not originally available. Peter > On 9 Jan 2016, at 11:10, Peter Kümmel <syn...@gm...> wrote: > > I would say Blitz is in maintenance mode, nobody > really develops it any more. I only use it because > once it was a nice option. > > Because of C++11/14/17 I assume much code is obsolete > now or much to verbose. > > Am 08.01.2016 um 20:41 schrieb Elizabeth Fischer: >> >> *) There's already a Blitz++ fork on GitHub, at: >> https://github.com/syntheticpp/blitz >> I don't know how much interest its author (Peter Kümmel) has >> in maintaining this, or if he just forked it to make sure it >> didn't disappear. I don't know to what extent it might have >> diverged from the latest Blitz++ tarball. > > I imported it from the repository (I assume somehow I found > also the hg repository) and only commited some small fixes, > because upstream is dead. > >> >> *) I can't for the life of me find ANY repository on >> SourceForge anymore, just a tarball. Maybe the repository >> for Blitz++ has been disabled? If anyone can point me to a >> repository URL for Blitz++ on SourceForge, that would be >> greatly appreciated. >> >> *) Is anyone other than myself interested in contributing or >> being a developer on this project? Blitz++ is a quality, >> stable piece of software. But I don't want to replace one >> abandonware repository with another; better to start with at >> least a little momentum. >> >> Thank you, >> -- Elizabeth >> > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: thomas v. <vr...@gm...> - 2016-01-13 17:43:56
|
Hi all, Blitz++ was part of projects for years, but due to the lack of developments we recently port every usage of blitz::array to Eigen::Tensor (currently in beta). For multi-dimentional array, slicing it provide a nice replacement (lack of range, lower bounds, and certainly many others). Tiny vectors and other basic classes have their equivalent in Eigen core too. Just saying perhaps if we want blitz++ to find its place in the c++ library offer it should take advantage of such well maintain library under the hood and focus on more specific stuff it does (was doing) pretty well ... Thomas 2016-01-09 6:10 GMT-05:00 Peter Kümmel <syn...@gm...>: > I would say Blitz is in maintenance mode, nobody > really develops it any more. I only use it because > once it was a nice option. > > Because of C++11/14/17 I assume much code is obsolete > now or much to verbose. > > Am 08.01.2016 um 20:41 schrieb Elizabeth Fischer: > > > > *) There's already a Blitz++ fork on GitHub, at: > > https://github.com/syntheticpp/blitz > > I don't know how much interest its author (Peter Kümmel) has > > in maintaining this, or if he just forked it to make sure it > > didn't disappear. I don't know to what extent it might have > > diverged from the latest Blitz++ tarball. > > I imported it from the repository (I assume somehow I found > also the hg repository) and only commited some small fixes, > because upstream is dead. > > > > > *) I can't for the life of me find ANY repository on > > SourceForge anymore, just a tarball. Maybe the repository > > for Blitz++ has been disabled? If anyone can point me to a > > repository URL for Blitz++ on SourceForge, that would be > > greatly appreciated. > > > > *) Is anyone other than myself interested in contributing or > > being a developer on this project? Blitz++ is a quality, > > stable piece of software. But I don't want to replace one > > abandonware repository with another; better to start with at > > least a little momentum. > > > > Thank you, > > -- Elizabeth > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > |
From: Elizabeth F. <rp...@co...> - 2016-01-13 18:20:18
|
Thomas, Thank you; until I heard about Eigen::Tensor today, I didn't know about any other package offering the equivalent of blitz::Array. However... but due to the lack of developments we recently port every usage of > blitz::array to Eigen::Tensor (currently in beta). > Were there specific things you needed developed that Blitz didn't provided? Or was it a general sense of "this is a dead end..."? > For multi-dimentional array, slicing it provide a nice replacement (lack > of range, lower bounds, and certainly many others). > Can you please clarify? One nice thing about Blitz is you can exactly replicate Fortran arrays (column major dimensions, starting at 1). I'm wondering if the Eigen project would be better off just taking blitz::Array themselves, rather than rewriting from scratch. Do you know if that's been considered? should take advantage of such well maintain library under the hood and > focus on more specific stuff it does (was doing) pretty well ... Can you please elaborate on that? I've always used Blitz just for blitz::Array. -- Elizabeth On Wed, Jan 13, 2016 at 12:43 PM, thomas vincent <vr...@gm...> wrote: > Hi all, > > Blitz++ was part of projects for years, but due to the lack of > developments we recently port every usage of blitz::array to Eigen::Tensor > (currently in beta). > > For multi-dimentional array, slicing it provide a nice replacement (lack > of range, lower bounds, and certainly many others). > Tiny vectors and other basic classes have their equivalent in Eigen core > too. > > Just saying perhaps if we want blitz++ to find its place in the c++ > library offer it should take advantage of such well maintain library under > the hood and focus on more specific stuff it does (was doing) pretty well > ... > > Thomas > > |
From: thomas v. <vr...@gm...> - 2016-01-13 21:02:01
|
2016-01-13 13:20 GMT-05:00 Elizabeth Fischer <rp...@co...>: > Thomas, > > Thank you; until I heard about Eigen::Tensor today, I didn't know about > any other package offering the equivalent of blitz::Array. However... > > but due to the lack of developments we recently port every usage of >> blitz::array to Eigen::Tensor (currently in beta). >> > > Were there specific things you needed developed that Blitz didn't > provided? Or was it a general sense of "this is a dead end..."? > No, not really. blitz::Array was far enough for us. I was tired get warnings on recent compilers. I was wondering that one day it wont build anymore. > > >> For multi-dimentional array, slicing it provide a nice replacement (lack >> of range, lower bounds, and certainly many others). >> > > Can you please clarify? One nice thing about Blitz is you can exactly > replicate Fortran arrays (column major dimensions, starting at 1). > No sure about the starting at 1 but ordering is part of Eigen::Tensor for sure. > > I'm wondering if the Eigen project would be better off just taking > blitz::Array themselves, rather than rewriting from scratch. Do you know > if that's been considered? > I have no clue on this one, sure fact Eigen::Tensor seems build up from scrach. > > should take advantage of such well maintain library under the hood and >> focus on more specific stuff it does (was doing) pretty well ... > > > Can you please elaborate on that? I've always used Blitz just for > blitz::Array. > I not sure any more if some 'magic' blitz provided back in the day remain available, like meta-programming of stencils and stuff like that. And I don't know either if performance gains they provided are really interesting nowadays. But if it is the case then perhaps blitz++ should focus on that ... not sure if it's clearer :) > > -- Elizabeth > > > On Wed, Jan 13, 2016 at 12:43 PM, thomas vincent <vr...@gm...> wrote: > >> Hi all, >> >> Blitz++ was part of projects for years, but due to the lack of >> developments we recently port every usage of blitz::array to Eigen::Tensor >> (currently in beta). >> > > >> For multi-dimentional array, slicing it provide a nice replacement (lack >> of range, lower bounds, and certainly many others). >> Tiny vectors and other basic classes have their equivalent in Eigen core >> too. >> >> Just saying perhaps if we want blitz++ to find its place in the c++ >> library offer it should take advantage of such well maintain library under >> the hood and focus on more specific stuff it does (was doing) pretty well >> ... >> >> Thomas >> >> > > |
From: Benoit J. <jac...@gm...> - 2016-01-13 21:08:09
|
Folks - just FYI - this eigen-core-team list is a very restricted audience and does not include the key maintainer of the Eigen::Tensor module, who is Benoit Steiner. I'm CC'ing him now. In general we encourage everyone to keep technical discussion on the public mailing list, eigen@. Cheers, Benoit 2016-01-13 16:01 GMT-05:00 thomas vincent <vr...@gm...>: > > > 2016-01-13 13:20 GMT-05:00 Elizabeth Fischer <rp...@co...>: > >> Thomas, >> >> Thank you; until I heard about Eigen::Tensor today, I didn't know about >> any other package offering the equivalent of blitz::Array. However... >> >> but due to the lack of developments we recently port every usage of >>> blitz::array to Eigen::Tensor (currently in beta). >>> >> >> Were there specific things you needed developed that Blitz didn't >> provided? Or was it a general sense of "this is a dead end..."? >> > > No, not really. blitz::Array was far enough for us. I was tired get > warnings on recent compilers. I was wondering that one day it wont build > anymore. > > >> >> >>> For multi-dimentional array, slicing it provide a nice replacement (lack >>> of range, lower bounds, and certainly many others). >>> >> >> Can you please clarify? One nice thing about Blitz is you can exactly >> replicate Fortran arrays (column major dimensions, starting at 1). >> > > No sure about the starting at 1 but ordering is part of Eigen::Tensor for > sure. > > >> >> I'm wondering if the Eigen project would be better off just taking >> blitz::Array themselves, rather than rewriting from scratch. Do you know >> if that's been considered? >> > > I have no clue on this one, sure fact Eigen::Tensor seems build up from > scrach. > > >> >> should take advantage of such well maintain library under the hood and >>> focus on more specific stuff it does (was doing) pretty well ... >> >> >> Can you please elaborate on that? I've always used Blitz just for >> blitz::Array. >> > > I not sure any more if some 'magic' blitz provided back in the day remain > available, like meta-programming of stencils and stuff like that. > And I don't know either if performance gains they provided are really > interesting nowadays. > But if it is the case then perhaps blitz++ should focus on that ... not > sure if it's clearer :) > > >> >> -- Elizabeth >> >> >> On Wed, Jan 13, 2016 at 12:43 PM, thomas vincent <vr...@gm...> >> wrote: >> >>> Hi all, >>> >>> Blitz++ was part of projects for years, but due to the lack of >>> developments we recently port every usage of blitz::array to Eigen::Tensor >>> (currently in beta). >>> >> >> >>> For multi-dimentional array, slicing it provide a nice replacement (lack >>> of range, lower bounds, and certainly many others). >>> Tiny vectors and other basic classes have their equivalent in Eigen core >>> too. >>> >>> Just saying perhaps if we want blitz++ to find its place in the c++ >>> library offer it should take advantage of such well maintain library under >>> the hood and focus on more specific stuff it does (was doing) pretty well >>> ... >>> >>> Thomas >>> >>> >> >> > |
From: Elizabeth F. <rp...@co...> - 2016-01-18 22:16:19
|
Hello Blitzers, Thank you all for your input on this issue. After much consideration, I think that Blitz++ is worth keeping around. Even in 2016, it remains unique in concept and execution. Blitz++ claims to do one thing only: *provide multi-dimensional arrays for C++*, similar to those in Fortran 90, Python/Numpy, and APL. Notice that Fortran 2008 has this feature but nothing like STL, and is widely used for scientific computing. It is clear that multi-dim arrays are essential in a way that STL is not. Of course, a system offering both is even more useful... It is therefore disappointing that such arrays are still not part of the C++ standard. This is after 15 years of work on Blitz++, boost::multi_array, etc. Without any standard, different libraries use different classes for the same data structure, limiting compatibility between them. Interoperability is cumbersome, and often requires unnecessary copying of multi-dimensional data structures (assuming there's enough RAM). Many of us confuse multi-dimensional arrays with matrices and vectors. Matrices and vectors are essential to scientific computing, and may be the most common type of arrays used. However, they do not take the place of the more general multi-dimensional array. This becomes clear to anyone attempting to read 5-dimensional data out of a HDF/NetCDF file. In an ideal world, matrix and vector classes (and operations) would be built upon a foundation of rank 1 and 2 arrays, thereby enhancing compatibility between different linear algebra libraries. By offering *only* multi-dimensional arrays, Blitz++ provides a foundation upon which linear algebra and other libraries may be built. The fact that none have taken advantage of this foundation seems to be a missed opportunity. However... until/unless something better comes along, I believe we should continue to support Blitz++. Why is Blitz++ so good? 1. It works, it's stable, it's well-tested. There's really nothing wrong with it. Sometimes, software is updated infrequently because it's not buggy. That's a reason to KEEP it, not throw it away. 2. It's well documented. The manual may feel long in the tooth compared to today's manuals. But the information you need is all there, and it works. 3. It does one thing well and has no dependencies. I don't have to link to BLAS in order to read a NetCDF file with Blitz++. 4. It's versatile. Blitz++ offers the full functionality of Fortran 90 arrays, and is able to use arrays in memory allocated by others. There are no restrictions on the dope vectors it allows. It is therefore REALLY useful for interfacing Fortran and Python code with C++. And since any array-like data structure can be converted (copy-free) to a blitz::Array, writing your functions to take blitz::Array parameters is an easy way to make them flexible as well. 5. It's FAST. Benchmarks have shown it to be about as fast as Fortran 90 arrays. In my review, I found only two other serious efforts to offer multi-dimensional arrays for C++. Both have potentially serious problems: ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it offers most/all of Blitz++ functionality. However, it has many downsides at this point compared to Blitz++: 1. It's a less mature product, could be evolving, could come with bugs, etc. 2. We don't know how fast it is. It could be a lot slower than Blitz++. 3. It's not as well documented. It provides some features that could be useful, but that I just didn't know were there because I couldn't find them in the documentation. 4. *If the authors do a good job, they will end up with a library similar in functionality and speed to Blitz++. * I just don't see the upside to re-developing this functionality from scratch. ** boost::multi_array* showed initial promise as being part of the boost ecosystem, and therefore (possibly) on track to becoming a C++ standard. However, it has languished in boost, apparently with little or no interest. This project is even deader than Blitz++. Maybe one reason is benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept that people who want multi-dimensional arrays to be part of their language standard will have to use Fortran for many years to come: "I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." *-- Tony Hoare [CarHoare <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during the 1982 AFIPS National Computing Conference.* A number of other libraries exist that provide specialized matrix and vector classes. I do not need to mention them here because they don't provide multi-dimensional arrays. ----------------------------- I propose the following roadmap for the continued viability of Blitz++: 1. We get volunteers. *Please contact me if you are interested in any of the tasks listed below.* 2. We move the repo to github.com/oonumerics/ <http://github.com/oonumerics/blitz>blitz <http://github.com/oonumerics/blitz>. In the past, Blitz++ was hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code from SourceForge and direct people to GitHub. We also move the mailing list and try to move the mailing list archives, if possible. 3. Once things are moved, we can start putting updates into a ticket system. I would suggest the following priorities: 1. Reformatted documentation, posted on-line. Doxygen docs would be nice. 2. Identify and seek resolution on any warnings Blitz++ might be causing with modern compilers. We need to assure users that Blitz++ won't just stop working some day. 3. Release the results of this as "Blitz 1.0" 4. We then start working on Blitz 2.0, which will make use of features in C++11 and beyond. C++98 users can continue to use Blitz 1.0. Updates might include: 1. Replace TinyVector with std::array 2. Much has changed now, with std::unique_ptr<> and std::shared_ptr<> now being part of the C++ standard. It would be worth seeing if some of the shared_ptr functionality currently built into Blitz++ is worth factoring out. 5. Consider adding new functionality that will make blitz::Array more useful out-of-the-box. I'm envisioning some stuff I've already written as little "utility" functions, but we'd want to do it right before putting it into the library. Possibilities include: 1. A reshape() function. 2. Easy ways to read/write to NetCDF files. (This would ONLY be compiled if Blitz++ is configured with NetCDF dependency. We don't want to add any REQUIRED dependencies). 3. Copy-free conversions between blitz::Array and std::vector. 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 arrays. In any case, please share your comments and suggestions on this roadmap. (Ane please volunteer too!) Thank you, -- Elizabeth |
From: Patrik J. <co...@fa...> - 2016-01-18 23:24:22
|
Hi Elizabeth, Thanks for digging into this task! If you give me access to oonumerics on github, I can convert the repo. I've been doing a bunch of hg->git migrations of my other repos lately anyway. One more thing that can be added to the improvements list is better handling of vectorization. The last big update to blitz was when I added support for vectorization by making it more obvious to the compiler when arrays were contiguous. However, this relies on the compiler to do the actual vectorization. The inter compiler was quite good at this, but as far as I remember gcc does not vectorize loops at all. Since the majority of users probably use gcc, this is a substantial disadvantage. If someone wanted to look into ways to add explicitly vectorized operations, that would greatly improve blitz's performance under gcc, I think. That does require diving deep into the guts of the expression template mechanism, though. Regards, /Patrik On Mon, Jan 18, 2016 at 12:16 PM, Elizabeth Fischer <rp...@co...> wrote: > Hello Blitzers, > > Thank you all for your input on this issue. After much consideration, I > think that Blitz++ is worth keeping around. Even in 2016, it remains > unique in concept and execution. > > Blitz++ claims to do one thing only: *provide multi-dimensional arrays > for C++*, similar to those in Fortran 90, Python/Numpy, and APL. Notice > that Fortran 2008 has this feature but nothing like STL, and is widely used > for scientific computing. It is clear that multi-dim arrays are essential > in a way that STL is not. Of course, a system offering both is even more > useful... > > It is therefore disappointing that such arrays are still not part of the > C++ standard. This is after 15 years of work on Blitz++, > boost::multi_array, etc. Without any standard, different libraries use > different classes for the same data structure, limiting compatibility > between them. Interoperability is cumbersome, and often requires > unnecessary copying of multi-dimensional data structures (assuming there's > enough RAM). > > Many of us confuse multi-dimensional arrays with matrices and vectors. > Matrices and vectors are essential to scientific computing, and may be the > most common type of arrays used. However, they do not take the place of > the more general multi-dimensional array. This becomes clear to anyone > attempting to read 5-dimensional data out of a HDF/NetCDF file. In an > ideal world, matrix and vector classes (and operations) would be built upon > a foundation of rank 1 and 2 arrays, thereby enhancing compatibility > between different linear algebra libraries. > > By offering *only* multi-dimensional arrays, Blitz++ provides a > foundation upon which linear algebra and other libraries may be built. The > fact that none have taken advantage of this foundation seems to be a missed > opportunity. However... until/unless something better comes along, I > believe we should continue to support Blitz++. > > Why is Blitz++ so good? > > 1. It works, it's stable, it's well-tested. There's really nothing > wrong with it. Sometimes, software is updated infrequently because it's > not buggy. That's a reason to KEEP it, not throw it away. > 2. It's well documented. The manual may feel long in the tooth > compared to today's manuals. But the information you need is all there, > and it works. > 3. It does one thing well and has no dependencies. I don't have to > link to BLAS in order to read a NetCDF file with Blitz++. > 4. It's versatile. Blitz++ offers the full functionality of Fortran > 90 arrays, and is able to use arrays in memory allocated by others. There > are no restrictions on the dope vectors it allows. It is therefore REALLY > useful for interfacing Fortran and Python code with C++. And since any > array-like data structure can be converted (copy-free) to a blitz::Array, > writing your functions to take blitz::Array parameters is an easy way to > make them flexible as well. > 5. It's FAST. Benchmarks have shown it to be about as fast as Fortran > 90 arrays. > > In my review, I found only two other serious efforts to offer > multi-dimensional arrays for C++. Both have potentially serious problems: > > ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it > offers most/all of Blitz++ functionality. However, it has many downsides > at this point compared to Blitz++: > > 1. It's a less mature product, could be evolving, could come with > bugs, etc. > 2. We don't know how fast it is. It could be a lot slower than > Blitz++. > 3. It's not as well documented. It provides some features that could > be useful, but that I just didn't know were there because I couldn't find > them in the documentation. > 4. *If the authors do a good job, they will end up with a library > similar in functionality and speed to Blitz++. * I just don't see the > upside to re-developing this functionality from scratch. > > ** boost::multi_array* showed initial promise as being part of the boost > ecosystem, and therefore (possibly) on track to becoming a C++ standard. > However, it has languished in boost, apparently with little or no > interest. This project is even deader than Blitz++. Maybe one reason is > benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept > that people who want multi-dimensional arrays to be part of their language > standard will have to use Fortran for many years to come: > > "I don't know what the language of the year 2000 will look like, but I > know it will be called Fortran." *-- Tony Hoare [CarHoare > <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during > the 1982 AFIPS National Computing Conference.* > > > A number of other libraries exist that provide specialized matrix and > vector classes. I do not need to mention them here because they don't > provide multi-dimensional arrays. > > ----------------------------- > > I propose the following roadmap for the continued viability of Blitz++: > > 1. We get volunteers. *Please contact me if you are interested in any > of the tasks listed below.* > 2. We move the repo to github.com/oonumerics/ > <http://github.com/oonumerics/blitz>blitz > <http://github.com/oonumerics/blitz>. In the past, Blitz++ was hosted > by oonumerics. Once this new repo is set up, we remove Blitz++ code from > SourceForge and direct people to GitHub. We also move the mailing list and > try to move the mailing list archives, if possible. > 3. Once things are moved, we can start putting updates into a ticket > system. I would suggest the following priorities: > 1. Reformatted documentation, posted on-line. Doxygen docs would > be nice. > 2. Identify and seek resolution on any warnings Blitz++ might be > causing with modern compilers. We need to assure users that Blitz++ won't > just stop working some day. > 3. Release the results of this as "Blitz 1.0" > 4. We then start working on Blitz 2.0, which will make use of features > in C++11 and beyond. C++98 users can continue to use Blitz 1.0. > Updates might include: > 1. Replace TinyVector with std::array > 2. Much has changed now, with std::unique_ptr<> and > std::shared_ptr<> now being part of the C++ standard. It would be worth > seeing if some of the shared_ptr functionality currently built into Blitz++ > is worth factoring out. > 5. Consider adding new functionality that will make blitz::Array more > useful out-of-the-box. I'm envisioning some stuff I've already written as > little "utility" functions, but we'd want to do it right before putting it > into the library. Possibilities include: > 1. A reshape() function. > 2. Easy ways to read/write to NetCDF files. (This would ONLY be > compiled if Blitz++ is configured with NetCDF dependency. We don't want to > add any REQUIRED dependencies). > 3. Copy-free conversions between blitz::Array and std::vector. > 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 > arrays. > > In any case, please share your comments and suggestions on this roadmap. > (Ane please volunteer too!) > > Thank you, > -- Elizabeth > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > > |
From: Patrick G. <p....@uc...> - 2016-01-19 11:27:05
|
HI Elizabeth, Thank you for your sustainability initiative for Blitz++. I completely support your ideas! I don't have much time to devote to Blitz++ but I am happy to be kept in the loop and help when I get time. I have some experience setting up the autoconf/automake/libtool tools for Blitz as well as the doxgen configuration. I like your utilities idea. I also have some wrapper functions to read/write HDF4/5 files and use FFTW 1D transforms (in/out of place, real/complex). The Fits file format for multidimensional array might also be of interest to consider. Regards, Patrick On 18/01/16 22:16, Elizabeth Fischer wrote: > Hello Blitzers, > > Thank you all for your input on this issue. After much consideration, I > think that Blitz++ is worth keeping around. Even in 2016, it remains > unique in concept and execution. > > Blitz++ claims to do one thing only: /provide multi-dimensional arrays > for C++/, similar to those in Fortran 90, Python/Numpy, and APL. Notice > that Fortran 2008 has this feature but nothing like STL, and is widely > used for scientific computing. It is clear that multi-dim arrays are > essential in a way that STL is not. Of course, a system offering both > is even more useful... > > It is therefore disappointing that such arrays are still not part of the > C++ standard. This is after 15 years of work on Blitz++, > boost::multi_array, etc. Without any standard, different libraries use > different classes for the same data structure, limiting compatibility > between them. Interoperability is cumbersome, and often requires > unnecessary copying of multi-dimensional data structures (assuming > there's enough RAM). > > Many of us confuse multi-dimensional arrays with matrices and vectors. > Matrices and vectors are essential to scientific computing, and may be > the most common type of arrays used. However, they do not take the > place of the more general multi-dimensional array. This becomes clear > to anyone attempting to read 5-dimensional data out of a HDF/NetCDF > file. In an ideal world, matrix and vector classes (and operations) > would be built upon a foundation of rank 1 and 2 arrays, thereby > enhancing compatibility between different linear algebra libraries. > > By offering /only/ multi-dimensional arrays, Blitz++ provides a > foundation upon which linear algebra and other libraries may be built. > The fact that none have taken advantage of this foundation seems to be a > missed opportunity. However... until/unless something better comes > along, I believe we should continue to support Blitz++. > > Why is Blitz++ so good? > > 1. It works, it's stable, it's well-tested. There's really nothing > wrong with it. Sometimes, software is updated infrequently because > it's not buggy. That's a reason to KEEP it, not throw it away. > 2. It's well documented. The manual may feel long in the tooth > compared to today's manuals. But the information you need is all > there, and it works. > 3. It does one thing well and has no dependencies. I don't have to > link to BLAS in order to read a NetCDF file with Blitz++. > 4. It's versatile. Blitz++ offers the full functionality of Fortran 90 > arrays, and is able to use arrays in memory allocated by others. > There are no restrictions on the dope vectors it allows. It is > therefore REALLY useful for interfacing Fortran and Python code with > C++. And since any array-like data structure can be converted > (copy-free) to a blitz::Array, writing your functions to take > blitz::Array parameters is an easy way to make them flexible as well. > 5. It's FAST. Benchmarks have shown it to be about as fast as Fortran > 90 arrays. > > In my review, I found only two other serious efforts to offer > multi-dimensional arrays for C++. Both have potentially serious problems: > > ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it > offers most/all of Blitz++ functionality. However, it has many > downsides at this point compared to Blitz++: > > 1. It's a less mature product, could be evolving, could come with bugs, > etc. > 2. We don't know how fast it is. It could be a lot slower than Blitz++. > 3. It's not as well documented. It provides some features that could > be useful, but that I just didn't know were there because I couldn't > find them in the documentation. > 4. *If the authors do a good job, they will end up with a library > similar in functionality and speed to Blitz++. * I just don't see > the upside to re-developing this functionality from scratch. > > ** boost::multi_array* showed initial promise as being part of the boost > ecosystem, and therefore (possibly) on track to becoming a C++ > standard. However, it has languished in boost, apparently with little > or no interest. This project is even deader than Blitz++. Maybe one > reason is benchmarks showed it to be about 1/2 as fast as Blitz++. We > must accept that people who want multi-dimensional arrays to be part of > their language standard will have to use Fortran for many years to come: > > "I don't know what the language of the year 2000 will look like, but > I know it will be called Fortran." /-- Tony Hoare [CarHoare > <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed > during the 1982 AFIPS National Computing Conference./ > > > A number of other libraries exist that provide specialized matrix and > vector classes. I do not need to mention them here because they don't > provide multi-dimensional arrays. > > ----------------------------- > > I propose the following roadmap for the continued viability of Blitz++: > > 1. We get volunteers. *Please contact me if you are interested in any > of the tasks listed below.* > 2. We move the repo to github.com/oonumerics/ > <http://github.com/oonumerics/blitz>blitz > <http://github.com/oonumerics/blitz>. In the past, Blitz++ was > hosted by oonumerics. Once this new repo is set up, we remove > Blitz++ code from SourceForge and direct people to GitHub. We also > move the mailing list and try to move the mailing list archives, if > possible. > 3. Once things are moved, we can start putting updates into a ticket > system. I would suggest the following priorities: > 1. Reformatted documentation, posted on-line. Doxygen docs would > be nice. > 2. Identify and seek resolution on any warnings Blitz++ might be > causing with modern compilers. We need to assure users that > Blitz++ won't just stop working some day. > 3. Release the results of this as "Blitz 1.0" > 4. We then start working on Blitz 2.0, which will make use of features > in C++11 and beyond. C++98 users can continue to use Blitz 1.0. > Updates might include: > 1. Replace TinyVector with std::array > 2. Much has changed now, with std::unique_ptr<> and > std::shared_ptr<> now being part of the C++ standard. It would > be worth seeing if some of the shared_ptr functionality > currently built into Blitz++ is worth factoring out. > 5. Consider adding new functionality that will make blitz::Array more > useful out-of-the-box. I'm envisioning some stuff I've already > written as little "utility" functions, but we'd want to do it right > before putting it into the library. Possibilities include: > 1. A reshape() function. > 2. Easy ways to read/write to NetCDF files. (This would ONLY be > compiled if Blitz++ is configured with NetCDF dependency. We > don't want to add any REQUIRED dependencies). > 3. Copy-free conversions between blitz::Array and std::vector. > 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 > arrays. > > In any case, please share your comments and suggestions on this roadmap. > (Ane please volunteer too!) > > Thank you, > -- Elizabeth > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > > > > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > |
From: Peter K. <syn...@gm...> - 2016-01-18 22:47:59
|
Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer <rp...@co...>: >Hello Blitzers, > >Thank you all for your input on this issue. After much consideration, >I >think that Blitz++ is worth keeping around. Even in 2016, it remains >unique in concept and execution. > >Blitz++ claims to do one thing only: *provide multi-dimensional arrays >for >C++*, similar to those in Fortran 90, Python/Numpy, and APL. Notice >that >Fortran 2008 has this feature but nothing like STL, and is widely used >for >scientific computing. It is clear that multi-dim arrays are essential >in a >way that STL is not. Of course, a system offering both is even more >useful... > >It is therefore disappointing that such arrays are still not part of >the >C++ standard. This is after 15 years of work on Blitz++, >boost::multi_array, etc. Without any standard, different libraries use >different classes for the same data structure, limiting compatibility >between them. Interoperability is cumbersome, and often requires >unnecessary copying of multi-dimensional data structures (assuming >there's >enough RAM). > >Many of us confuse multi-dimensional arrays with matrices and vectors. >Matrices and vectors are essential to scientific computing, and may be >the >most common type of arrays used. However, they do not take the place >of >the more general multi-dimensional array. This becomes clear to anyone >attempting to read 5-dimensional data out of a HDF/NetCDF file. In an >ideal world, matrix and vector classes (and operations) would be built >upon >a foundation of rank 1 and 2 arrays, thereby enhancing compatibility >between different linear algebra libraries. > >By offering *only* multi-dimensional arrays, Blitz++ provides a >foundation >upon which linear algebra and other libraries may be built. The fact >that >none have taken advantage of this foundation seems to be a missed >opportunity. However... until/unless something better comes along, I >believe we should continue to support Blitz++. > >Why is Blitz++ so good? > > 1. It works, it's stable, it's well-tested. There's really nothing >wrong with it. Sometimes, software is updated infrequently because >it's > not buggy. That's a reason to KEEP it, not throw it away. >2. It's well documented. The manual may feel long in the tooth >compared > to today's manuals. But the information you need is all there, and it > works. >3. It does one thing well and has no dependencies. I don't have to >link > to BLAS in order to read a NetCDF file with Blitz++. >4. It's versatile. Blitz++ offers the full functionality of Fortran 90 >arrays, and is able to use arrays in memory allocated by others. There >are > no restrictions on the dope vectors it allows. It is therefore REALLY >useful for interfacing Fortran and Python code with C++. And since any >array-like data structure can be converted (copy-free) to a >blitz::Array, >writing your functions to take blitz::Array parameters is an easy way >to > make them flexible as well. > 5. It's FAST. Benchmarks have shown it to be about as fast as Fortran > 90 arrays. > >In my review, I found only two other serious efforts to offer >multi-dimensional arrays for C++. Both have potentially serious >problems: > >** Eigen::Tensor* is a relatively new part of Eigen. In theory, it >offers >most/all of Blitz++ functionality. However, it has many downsides at >this >point compared to Blitz++: > >1. It's a less mature product, could be evolving, could come with bugs, > etc. >2. We don't know how fast it is. It could be a lot slower than >Blitz++. >3. It's not as well documented. It provides some features that could >be >useful, but that I just didn't know were there because I couldn't find >them > in the documentation. > 4. *If the authors do a good job, they will end up with a library > similar in functionality and speed to Blitz++. * I just don't see the > upside to re-developing this functionality from scratch. > >** boost::multi_array* showed initial promise as being part of the >boost >ecosystem, and therefore (possibly) on track to becoming a C++ >standard. >However, it has languished in boost, apparently with little or no >interest. This project is even deader than Blitz++. Maybe one reason >is >benchmarks showed it to be about 1/2 as fast as Blitz++. We must >accept >that people who want multi-dimensional arrays to be part of their >language >standard will have to use Fortran for many years to come: > >"I don't know what the language of the year 2000 will look like, but I >know >it will be called Fortran." *-- Tony Hoare [CarHoare ><http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed >during >the 1982 AFIPS National Computing Conference.* > > >A number of other libraries exist that provide specialized matrix and >vector classes. I do not need to mention them here because they don't >provide multi-dimensional arrays. > >----------------------------- > >I propose the following roadmap for the continued viability of Blitz++: > > 1. We get volunteers. *Please contact me if you are interested in any > of the tasks listed below.* > 2. We move the repo to github.com/oonumerics/ > <http://github.com/oonumerics/blitz>blitz > <http://github.com/oonumerics/blitz>. In the past, Blitz++ was hosted >by oonumerics. Once this new repo is set up, we remove Blitz++ code >from >SourceForge and direct people to GitHub. We also move the mailing list >and > try to move the mailing list archives, if possible. > 3. Once things are moved, we can start putting updates into a ticket > system. I would suggest the following priorities: > 1. Reformatted documentation, posted on-line. Doxygen docs would be > nice. > 2. Identify and seek resolution on any warnings Blitz++ might be > causing with modern compilers. We need to assure users that >Blitz++ won't > just stop working some day. > 3. Release the results of this as "Blitz 1.0" > 4. We then start working on Blitz 2.0, which will make use of features > in C++11 and beyond. C++98 users can continue to use Blitz 1.0. > Updates might include: > 1. Replace TinyVector with std::array > 2. Much has changed now, with std::unique_ptr<> and std::shared_ptr<> >now being part of the C++ standard. It would be worth seeing if some >of > the shared_ptr functionality currently built into Blitz++ is worth > factoring out. > 5. Consider adding new functionality that will make blitz::Array more >useful out-of-the-box. I'm envisioning some stuff I've already written >as >little "utility" functions, but we'd want to do it right before putting >it > into the library. Possibilities include: > 1. A reshape() function. > 2. Easy ways to read/write to NetCDF files. (This would ONLY be > compiled if Blitz++ is configured with NetCDF dependency. We >don't want to > add any REQUIRED dependencies). > 3. Copy-free conversions between blitz::Array and std::vector. > 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 > arrays. > >In any case, please share your comments and suggestions on this >roadmap. > (Ane please volunteer too!) > >Thank you, >-- Elizabeth > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >Site24x7 APM Insight: Get Deep Visibility into Application Performance >APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >Monitor end-to-end web transactions and take corrective actions now >Troubleshoot faster and improve end-user experience. Signup Now! >http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > >------------------------------------------------------------------------ > >_______________________________________________ >Blitz-devel mailing list >Bli...@li... >https://lists.sourceforge.net/lists/listinfo/blitz-devel Many thanks for this great summary, Elizabeth! Instead of oonumerics we could just create a Blitz++ group on github, this is much more google-friendly than the somehow obsolete oonumerics name. |
From: Jeff H. <jef...@gm...> - 2016-01-19 03:19:08
|
Whenever this ends up on Github, I'll be happy to contribute Travis CI (continuous integration i.e. automated testing) support, since I'm on a role with that lately. CI will be particularly useful when pull requests start coming in and C++11 features are added. I recall seeing something for C++17 that looked like it helped with multidimensional arrays, but of course, that's just a proposal. Best, Jeff On Monday, January 18, 2016, Peter Kümmel <syn...@gm...> wrote: > Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer < > rp...@co... > <javascript:_e(%7B%7D,'cvml','rp...@co...');>>: >> >> Hello Blitzers, >> >> Thank you all for your input on this issue. After much consideration, I >> think that Blitz++ is worth keeping around. Even in 2016, it remains >> unique in concept and execution. >> >> Blitz++ claims to do one thing only: *provide multi-dimensional arrays >> for C++*, similar to those in Fortran 90, Python/Numpy, and APL. Notice >> that Fortran 2008 has this feature but nothing like STL, and is widely used >> for scientific computing. It is clear that multi-dim arrays are essential >> in a way that STL is not. Of course, a system offering both is even more >> useful... >> >> It is therefore disappointing that such arrays are still not part of the >> C++ standard. This is after 15 years of work on Blitz++, >> boost::multi_array, etc. Without any standard, different libraries use >> different classes for the same data structure, limiting compatibility >> between them. Interoperability is cumbersome, and often requires >> unnecessary copying of multi-dimensional data structures (assuming there's >> enough RAM). >> >> Many of us confuse multi-dimensional arrays with matrices and vectors. >> Matrices and vectors are essential to scientific computing, and may be the >> most common type of arrays used. However, they do not take the place of >> the more general multi-dimensional array. This becomes clear to anyone >> attempting to read 5-dimensional data out of a HDF/NetCDF file. In an >> ideal world, matrix and vector classes (and operations) would be built upon >> a foundation of rank 1 and 2 arrays, thereby enhancing compatibility >> between different linear algebra libraries. >> >> By offering *only* multi-dimensional arrays, Blitz++ provides a >> foundation upon which linear algebra and other libraries may be built. The >> fact that none have taken advantage of this foundation seems to be a missed >> opportunity. However... until/unless something better comes along, I >> believe we should continue to support Blitz++. >> >> Why is Blitz++ so good? >> >> 1. It works, it's stable, it's well-tested. There's really nothing >> wrong with it. Sometimes, software is updated infrequently because it's >> not buggy. That's a reason to KEEP it, not throw it away. >> 2. It's well documented. The manual may feel long in the tooth >> compared to today's manuals. But the information you need is all there, >> and it works. >> 3. It does one thing well and has no dependencies. I don't have to >> link to BLAS in order to read a NetCDF file with Blitz++. >> 4. It's versatile. Blitz++ offers the full functionality of Fortran >> 90 arrays, and is able to use arrays in memory allocated by others. There >> are no restrictions on the dope vectors it allows. It is therefore REALLY >> useful for interfacing Fortran and Python code with C++. And since any >> array-like data structure can be converted (copy-free) to a blitz::Array, >> writing your functions to take blitz::Array parameters is an easy way to >> make them flexible as well. >> 5. It's FAST. Benchmarks have shown it to be about as fast as >> Fortran 90 arrays. >> >> In my review, I found only two other serious efforts to offer >> multi-dimensional arrays for C++. Both have potentially serious problems: >> >> ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it >> offers most/all of Blitz++ functionality. However, it has many downsides >> at this point compared to Blitz++: >> >> 1. It's a less mature product, could be evolving, could come with >> bugs, etc. >> 2. We don't know how fast it is. It could be a lot slower than >> Blitz++. >> 3. It's not as well documented. It provides some features that could >> be useful, but that I just didn't know were there because I couldn't find >> them in the documentation. >> 4. *If the authors do a good job, they will end up with a library >> similar in functionality and speed to Blitz++. * I just don't see the >> upside to re-developing this functionality from scratch. >> >> ** boost::multi_array* showed initial promise as being part of the boost >> ecosystem, and therefore (possibly) on track to becoming a C++ standard. >> However, it has languished in boost, apparently with little or no >> interest. This project is even deader than Blitz++. Maybe one reason is >> benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept >> that people who want multi-dimensional arrays to be part of their language >> standard will have to use Fortran for many years to come: >> >> "I don't know what the language of the year 2000 will look like, but I >> know it will be called Fortran." *-- Tony Hoare [CarHoare >> <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during >> the 1982 AFIPS National Computing Conference.* >> >> >> A number of other libraries exist that provide specialized matrix and >> vector classes. I do not need to mention them here because they don't >> provide multi-dimensional arrays. >> >> ----------------------------- >> >> I propose the following roadmap for the continued viability of Blitz++: >> >> 1. We get volunteers. *Please contact me if you are interested in >> any of the tasks listed below.* >> 2. We move the repo to github.com/oonumerics/ >> <http://github.com/oonumerics/blitz>blitz >> <http://github.com/oonumerics/blitz>. In the past, Blitz++ was >> hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code >> from SourceForge and direct people to GitHub. We also move the mailing >> list and try to move the mailing list archives, if possible. >> 3. Once things are moved, we can start putting updates into a ticket >> system. I would suggest the following priorities: >> 1. Reformatted documentation, posted on-line. Doxygen docs would >> be nice. >> 2. Identify and seek resolution on any warnings Blitz++ might be >> causing with modern compilers. We need to assure users that Blitz++ won't >> just stop working some day. >> 3. Release the results of this as "Blitz 1.0" >> 4. We then start working on Blitz 2.0, which will make use of >> features in C++11 and beyond. C++98 users can continue to use Blitz >> 1.0. Updates might include: >> 1. Replace TinyVector with std::array >> 2. Much has changed now, with std::unique_ptr<> and >> std::shared_ptr<> now being part of the C++ standard. It would be worth >> seeing if some of the shared_ptr functionality currently built into Blitz++ >> is worth factoring out. >> 5. Consider adding new functionality that will make blitz::Array more >> useful out-of-the-box. I'm envisioning some stuff I've already written as >> little "utility" functions, but we'd want to do it right before putting it >> into the library. Possibilities include: >> 1. A reshape() function. >> 2. Easy ways to read/write to NetCDF files. (This would ONLY be >> compiled if Blitz++ is configured with NetCDF dependency. We don't want to >> add any REQUIRED dependencies). >> 3. Copy-free conversions between blitz::Array and std::vector. >> 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 >> arrays. >> >> In any case, please share your comments and suggestions on this roadmap. >> (Ane please volunteer too!) >> >> Thank you, >> -- Elizabeth >> >> ------------------------------ >> >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> >> ------------------------------ >> >> Blitz-devel mailing list >> Bli...@li... <javascript:_e(%7B%7D,'cvml','Bli...@li...');> >> https://lists.sourceforge.net/lists/listinfo/blitz-devel >> >> > Many thanks for this great summary, Elizabeth! > > Instead of oonumerics we could just create a Blitz++ group on github, this > is much more google-friendly than the somehow obsolete oonumerics name. > -- Jeff Hammond jef...@gm... http://jeffhammond.github.io/ |
From: thomas v. <vr...@gm...> - 2016-01-19 15:04:06
|
This is a great initiative, I'm almost regretting moving to Eigen::Tensor ! What your are proposing is great, really. I do second Peter on the github move instead oonumerics, blitz++ really need more visibility and easy access. One thing that we had to develop (only for 3d array) and I do thing should be part of blitz++ itself is efficient file serialization to persist / cache / share blitz array. Thomas 2016-01-18 17:47 GMT-05:00 Peter Kümmel <syn...@gm...>: > Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer < > rp...@co...>: > >> Hello Blitzers, >> >> Thank you all for your input on this issue. After much consideration, I >> think that Blitz++ is worth keeping around. Even in 2016, it remains >> unique in concept and execution. >> >> Blitz++ claims to do one thing only: *provide multi-dimensional arrays >> for C++*, similar to those in Fortran 90, Python/Numpy, and APL. Notice >> that Fortran 2008 has this feature but nothing like STL, and is widely used >> for scientific computing. It is clear that multi-dim arrays are essential >> in a way that STL is not. Of course, a system offering both is even more >> useful... >> >> It is therefore disappointing that such arrays are still not part of the >> C++ standard. This is after 15 years of work on Blitz++, >> boost::multi_array, etc. Without any standard, different libraries use >> different classes for the same data structure, limiting compatibility >> between them. Interoperability is cumbersome, and often requires >> unnecessary copying of multi-dimensional data structures (assuming there's >> enough RAM). >> >> Many of us confuse multi-dimensional arrays with matrices and vectors. >> Matrices and vectors are essential to scientific computing, and may be the >> most common type of arrays used. However, they do not take the place of >> the more general multi-dimensional array. This becomes clear to anyone >> attempting to read 5-dimensional data out of a HDF/NetCDF file. In an >> ideal world, matrix and vector classes (and operations) would be built upon >> a foundation of rank 1 and 2 arrays, thereby enhancing compatibility >> between different linear algebra libraries. >> >> By offering *only* multi-dimensional arrays, Blitz++ provides a >> foundation upon which linear algebra and other libraries may be built. The >> fact that none have taken advantage of this foundation seems to be a missed >> opportunity. However... until/unless something better comes along, I >> believe we should continue to support Blitz++. >> >> Why is Blitz++ so good? >> >> 1. It works, it's stable, it's well-tested. There's really nothing >> wrong with it. Sometimes, software is updated infrequently because it's >> not buggy. That's a reason to KEEP it, not throw it away. >> 2. It's well documented. The manual may feel long in the tooth >> compared to today's manuals. But the information you need is all there, >> and it works. >> 3. It does one thing well and has no dependencies. I don't have to >> link to BLAS in order to read a NetCDF file with Blitz++. >> 4. It's versatile. Blitz++ offers the full functionality of Fortran >> 90 arrays, and is able to use arrays in memory allocated by others. There >> are no restrictions on the dope vectors it allows. It is therefore REALLY >> useful for interfacing Fortran and Python code with C++. And since any >> array-like data structure can be converted (copy-free) to a blitz::Array, >> writing your functions to take blitz::Array parameters is an easy way to >> make them flexible as well. >> 5. It's FAST. Benchmarks have shown it to be about as fast as >> Fortran 90 arrays. >> >> In my review, I found only two other serious efforts to offer >> multi-dimensional arrays for C++. Both have potentially serious problems: >> >> ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it >> offers most/all of Blitz++ functionality. However, it has many downsides >> at this point compared to Blitz++: >> >> 1. It's a less mature product, could be evolving, could come with >> bugs, etc. >> 2. We don't know how fast it is. It could be a lot slower than >> Blitz++. >> 3. It's not as well documented. It provides some features that could >> be useful, but that I just didn't know were there because I couldn't find >> them in the documentation. >> 4. *If the authors do a good job, they will end up with a library >> similar in functionality and speed to Blitz++. * I just don't see the >> upside to re-developing this functionality from scratch. >> >> ** boost::multi_array* showed initial promise as being part of the boost >> ecosystem, and therefore (possibly) on track to becoming a C++ standard. >> However, it has languished in boost, apparently with little or no >> interest. This project is even deader than Blitz++. Maybe one reason is >> benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept >> that people who want multi-dimensional arrays to be part of their language >> standard will have to use Fortran for many years to come: >> >> "I don't know what the language of the year 2000 will look like, but I >> know it will be called Fortran." *-- Tony Hoare [CarHoare >> <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during >> the 1982 AFIPS National Computing Conference.* >> >> >> A number of other libraries exist that provide specialized matrix and >> vector classes. I do not need to mention them here because they don't >> provide multi-dimensional arrays. >> >> ----------------------------- >> >> I propose the following roadmap for the continued viability of Blitz++: >> >> 1. We get volunteers. *Please contact me if you are interested in >> any of the tasks listed below.* >> 2. We move the repo to github.com/oonumerics/ >> <http://github.com/oonumerics/blitz>blitz >> <http://github.com/oonumerics/blitz>. In the past, Blitz++ was >> hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code >> from SourceForge and direct people to GitHub. We also move the mailing >> list and try to move the mailing list archives, if possible. >> 3. Once things are moved, we can start putting updates into a ticket >> system. I would suggest the following priorities: >> 1. Reformatted documentation, posted on-line. Doxygen docs would >> be nice. >> 2. Identify and seek resolution on any warnings Blitz++ might be >> causing with modern compilers. We need to assure users that Blitz++ won't >> just stop working some day. >> 3. Release the results of this as "Blitz 1.0" >> 4. We then start working on Blitz 2.0, which will make use of >> features in C++11 and beyond. C++98 users can continue to use Blitz >> 1.0. Updates might include: >> 1. Replace TinyVector with std::array >> 2. Much has changed now, with std::unique_ptr<> and >> std::shared_ptr<> now being part of the C++ standard. It would be worth >> seeing if some of the shared_ptr functionality currently built into Blitz++ >> is worth factoring out. >> 5. Consider adding new functionality that will make blitz::Array more >> useful out-of-the-box. I'm envisioning some stuff I've already written as >> little "utility" functions, but we'd want to do it right before putting it >> into the library. Possibilities include: >> 1. A reshape() function. >> 2. Easy ways to read/write to NetCDF files. (This would ONLY be >> compiled if Blitz++ is configured with NetCDF dependency. We don't want to >> add any REQUIRED dependencies). >> 3. Copy-free conversions between blitz::Array and std::vector. >> 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 >> arrays. >> >> In any case, please share your comments and suggestions on this roadmap. >> (Ane please volunteer too!) >> >> Thank you, >> -- Elizabeth >> >> ------------------------------ >> >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> >> ------------------------------ >> >> Blitz-devel mailing list >> Bli...@li... >> https://lists.sourceforge.net/lists/listinfo/blitz-devel >> >> > Many thanks for this great summary, Elizabeth! > > Instead of oonumerics we could just create a Blitz++ group on github, this > is much more google-friendly than the somehow obsolete oonumerics name. > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > > |
From: Theodore P. <The...@in...> - 2016-01-19 16:05:50
Attachments:
smime.p7s
|
On 01/19/2016 04:03 PM, thomas vincent wrote: > This is a great initiative, I'm almost regretting moving to Eigen::Tensor ! > > What your are proposing is great, really. > > I do second Peter on the github move instead oonumerics, blitz++ really > need more visibility and easy access. +256 I really startes to decrease my blitz contribution with the swicth to bzr, which I do not master as well as svn or git. > One thing that we had to develop (only for 3d array) and I do thing > should be part of blitz++ itself is efficient file serialization to > persist / cache / share blitz array. One task that really needs to be added is the cleanup of all the macro stuff that was needed to support old non-standard compilers. Nowadays, we can certainly rely on features such as exceptions, namespace, partial templates, .... Thank's for the revival... Theo. |
From: Florian O. <flo...@gm...> - 2016-01-19 15:08:32
|
+1 for github good to see the phoenix rise from the ashes. On 19 January 2016 at 16:03, thomas vincent <vr...@gm...> wrote: > This is a great initiative, I'm almost regretting moving to Eigen::Tensor ! > > What your are proposing is great, really. > > I do second Peter on the github move instead oonumerics, blitz++ really > need more visibility and easy access. > > One thing that we had to develop (only for 3d array) and I do thing should > be part of blitz++ itself is efficient file serialization to persist / > cache / share blitz array. > > Thomas > > > 2016-01-18 17:47 GMT-05:00 Peter Kümmel <syn...@gm...>: > >> Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer < >> rp...@co...>: >> >>> Hello Blitzers, >>> >>> Thank you all for your input on this issue. After much consideration, I >>> think that Blitz++ is worth keeping around. Even in 2016, it remains >>> unique in concept and execution. >>> >>> Blitz++ claims to do one thing only: *provide multi-dimensional arrays >>> for C++*, similar to those in Fortran 90, Python/Numpy, and APL. >>> Notice that Fortran 2008 has this feature but nothing like STL, and is >>> widely used for scientific computing. It is clear that multi-dim arrays >>> are essential in a way that STL is not. Of course, a system offering both >>> is even more useful... >>> >>> It is therefore disappointing that such arrays are still not part of the >>> C++ standard. This is after 15 years of work on Blitz++, >>> boost::multi_array, etc. Without any standard, different libraries use >>> different classes for the same data structure, limiting compatibility >>> between them. Interoperability is cumbersome, and often requires >>> unnecessary copying of multi-dimensional data structures (assuming there's >>> enough RAM). >>> >>> Many of us confuse multi-dimensional arrays with matrices and vectors. >>> Matrices and vectors are essential to scientific computing, and may be the >>> most common type of arrays used. However, they do not take the place of >>> the more general multi-dimensional array. This becomes clear to anyone >>> attempting to read 5-dimensional data out of a HDF/NetCDF file. In an >>> ideal world, matrix and vector classes (and operations) would be built upon >>> a foundation of rank 1 and 2 arrays, thereby enhancing compatibility >>> between different linear algebra libraries. >>> >>> By offering *only* multi-dimensional arrays, Blitz++ provides a >>> foundation upon which linear algebra and other libraries may be built. The >>> fact that none have taken advantage of this foundation seems to be a missed >>> opportunity. However... until/unless something better comes along, I >>> believe we should continue to support Blitz++. >>> >>> Why is Blitz++ so good? >>> >>> 1. It works, it's stable, it's well-tested. There's really nothing >>> wrong with it. Sometimes, software is updated infrequently because it's >>> not buggy. That's a reason to KEEP it, not throw it away. >>> 2. It's well documented. The manual may feel long in the tooth >>> compared to today's manuals. But the information you need is all there, >>> and it works. >>> 3. It does one thing well and has no dependencies. I don't have to >>> link to BLAS in order to read a NetCDF file with Blitz++. >>> 4. It's versatile. Blitz++ offers the full functionality of Fortran >>> 90 arrays, and is able to use arrays in memory allocated by others. There >>> are no restrictions on the dope vectors it allows. It is therefore REALLY >>> useful for interfacing Fortran and Python code with C++. And since any >>> array-like data structure can be converted (copy-free) to a blitz::Array, >>> writing your functions to take blitz::Array parameters is an easy way to >>> make them flexible as well. >>> 5. It's FAST. Benchmarks have shown it to be about as fast as >>> Fortran 90 arrays. >>> >>> In my review, I found only two other serious efforts to offer >>> multi-dimensional arrays for C++. Both have potentially serious problems: >>> >>> ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it >>> offers most/all of Blitz++ functionality. However, it has many downsides >>> at this point compared to Blitz++: >>> >>> 1. It's a less mature product, could be evolving, could come with >>> bugs, etc. >>> 2. We don't know how fast it is. It could be a lot slower than >>> Blitz++. >>> 3. It's not as well documented. It provides some features that >>> could be useful, but that I just didn't know were there because I couldn't >>> find them in the documentation. >>> 4. *If the authors do a good job, they will end up with a library >>> similar in functionality and speed to Blitz++. * I just don't see >>> the upside to re-developing this functionality from scratch. >>> >>> ** boost::multi_array* showed initial promise as being part of the >>> boost ecosystem, and therefore (possibly) on track to becoming a C++ >>> standard. However, it has languished in boost, apparently with little or >>> no interest. This project is even deader than Blitz++. Maybe one reason >>> is benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept >>> that people who want multi-dimensional arrays to be part of their language >>> standard will have to use Fortran for many years to come: >>> >>> "I don't know what the language of the year 2000 will look like, but I >>> know it will be called Fortran." *-- Tony Hoare [CarHoare >>> <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during >>> the 1982 AFIPS National Computing Conference.* >>> >>> >>> A number of other libraries exist that provide specialized matrix and >>> vector classes. I do not need to mention them here because they don't >>> provide multi-dimensional arrays. >>> >>> ----------------------------- >>> >>> I propose the following roadmap for the continued viability of Blitz++: >>> >>> 1. We get volunteers. *Please contact me if you are interested in >>> any of the tasks listed below.* >>> 2. We move the repo to github.com/oonumerics/ >>> <http://github.com/oonumerics/blitz>blitz >>> <http://github.com/oonumerics/blitz>. In the past, Blitz++ was >>> hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code >>> from SourceForge and direct people to GitHub. We also move the mailing >>> list and try to move the mailing list archives, if possible. >>> 3. Once things are moved, we can start putting updates into a ticket >>> system. I would suggest the following priorities: >>> 1. Reformatted documentation, posted on-line. Doxygen docs would >>> be nice. >>> 2. Identify and seek resolution on any warnings Blitz++ might be >>> causing with modern compilers. We need to assure users that Blitz++ won't >>> just stop working some day. >>> 3. Release the results of this as "Blitz 1.0" >>> 4. We then start working on Blitz 2.0, which will make use of >>> features in C++11 and beyond. C++98 users can continue to use Blitz >>> 1.0. Updates might include: >>> 1. Replace TinyVector with std::array >>> 2. Much has changed now, with std::unique_ptr<> and >>> std::shared_ptr<> now being part of the C++ standard. It would be worth >>> seeing if some of the shared_ptr functionality currently built into Blitz++ >>> is worth factoring out. >>> 5. Consider adding new functionality that will make blitz::Array >>> more useful out-of-the-box. I'm envisioning some stuff I've already >>> written as little "utility" functions, but we'd want to do it right before >>> putting it into the library. Possibilities include: >>> 1. A reshape() function. >>> 2. Easy ways to read/write to NetCDF files. (This would ONLY be >>> compiled if Blitz++ is configured with NetCDF dependency. We don't want to >>> add any REQUIRED dependencies). >>> 3. Copy-free conversions between blitz::Array and std::vector. >>> 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 >>> arrays. >>> >>> In any case, please share your comments and suggestions on this roadmap. >>> (Ane please volunteer too!) >>> >>> Thank you, >>> -- Elizabeth >>> >>> ------------------------------ >>> >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >>> >>> ------------------------------ >>> >>> Blitz-devel mailing list >>> Bli...@li... >>> https://lists.sourceforge.net/lists/listinfo/blitz-devel >>> >>> >> Many thanks for this great summary, Elizabeth! >> >> Instead of oonumerics we could just create a Blitz++ group on github, >> this is much more google-friendly than the somehow obsolete oonumerics >> name. >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> Blitz-devel mailing list >> Bli...@li... >> https://lists.sourceforge.net/lists/listinfo/blitz-devel >> >> > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > > |
From: Stefan D. <st...@dr...> - 2016-01-19 06:44:07
|
Am 18.01.16 um 23:47 schrieb Peter Kümmel: > Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer > <rp...@co...>: > > Hello Blitzers, > > Thank you all for your input on this issue. After much > consideration, I think that Blitz++ is worth keeping around. Even > in 2016, it remains unique in concept and execution. > ... [8<] > ----------------------------- > > I propose the following roadmap for the continued viability of Blitz++: > > 1. We get volunteers. *Please contact me if you are interested in > any of the tasks listed below.* > 2. We move the repo to github.com/oonumerics/ > <http://github.com/oonumerics/blitz>blitz > <http://github.com/oonumerics/blitz>. In the past, Blitz++ was > hosted by oonumerics. Once this new repo is set up, we remove > Blitz++ code from SourceForge and direct people to GitHub. We > also move the mailing list and try to move the mailing list > archives, if possible. > 3. Once things are moved, we can start putting updates into a > ticket system. I would suggest the following priorities: > 1. Reformatted documentation, posted on-line. Doxygen docs > would be nice. > 2. Identify and seek resolution on any warnings Blitz++ might > be causing with modern compilers. We need to assure users > that Blitz++ won't just stop working some day. > 3. Release the results of this as "Blitz 1.0" > 4. We then start working on Blitz 2.0, which will make use of > features in C++11 and beyond. C++98 users can continue to use > Blitz 1.0. Updates might include: > 1. Replace TinyVector with std::array > 2. Much has changed now, with std::unique_ptr<> and > std::shared_ptr<> now being part of the C++ standard. It > would be worth seeing if some of the shared_ptr > functionality currently built into Blitz++ is worth > factoring out. > 5. Consider adding new functionality that will make blitz::Array > more useful out-of-the-box. I'm envisioning some stuff I've > already written as little "utility" functions, but we'd want to > do it right before putting it into the library. Possibilities > include: > 1. A reshape() function. > 2. Easy ways to read/write to NetCDF files. (This would ONLY > be compiled if Blitz++ is configured with NetCDF > dependency. We don't want to add any REQUIRED dependencies). > 3. Copy-free conversions between blitz::Array and std::vector. > 4. Conversions between blitz::Array, Numpy arrays and Fortran > 90 arrays. > > In any case, please share your comments and suggestions on this > roadmap. (Ane please volunteer too!) > > Thank you, > -- Elizabeth > ... [8<] > > > Many thanks for this great summary, Elizabeth! > > Instead of oonumerics we could just create a Blitz++ group on github, > this is much more google-friendly than the somehow obsolete oonumerics > name. +1 from me for the ammended suggestions (ie. creating a github Blitz++ group) All the best, Stefan. |
From: Daniel O. <dan...@gm...> - 2016-01-19 23:51:09
|
If you Do this I will definitely watch it and maybe pick up some tasks, send pull requests. Cleanup and vectorization might be starting points. Von meinem iPad gesendet > Am 19.01.2016 um 07:30 schrieb Stefan Drees <st...@dr...>: > >> Am 18.01.16 um 23:47 schrieb Peter Kümmel: >> Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer >> <rp...@co...>: >> >> Hello Blitzers, >> >> Thank you all for your input on this issue. After much >> consideration, I think that Blitz++ is worth keeping around. Even >> in 2016, it remains unique in concept and execution. >> ... [8<] >> ----------------------------- >> >> I propose the following roadmap for the continued viability of Blitz++: >> >> 1. We get volunteers. *Please contact me if you are interested in >> any of the tasks listed below.* >> 2. We move the repo to github.com/oonumerics/ >> <http://github.com/oonumerics/blitz>blitz >> <http://github.com/oonumerics/blitz>. In the past, Blitz++ was >> hosted by oonumerics. Once this new repo is set up, we remove >> Blitz++ code from SourceForge and direct people to GitHub. We >> also move the mailing list and try to move the mailing list >> archives, if possible. >> 3. Once things are moved, we can start putting updates into a >> ticket system. I would suggest the following priorities: >> 1. Reformatted documentation, posted on-line. Doxygen docs >> would be nice. >> 2. Identify and seek resolution on any warnings Blitz++ might >> be causing with modern compilers. We need to assure users >> that Blitz++ won't just stop working some day. >> 3. Release the results of this as "Blitz 1.0" >> 4. We then start working on Blitz 2.0, which will make use of >> features in C++11 and beyond. C++98 users can continue to use >> Blitz 1.0. Updates might include: >> 1. Replace TinyVector with std::array >> 2. Much has changed now, with std::unique_ptr<> and >> std::shared_ptr<> now being part of the C++ standard. It >> would be worth seeing if some of the shared_ptr >> functionality currently built into Blitz++ is worth >> factoring out. >> 5. Consider adding new functionality that will make blitz::Array >> more useful out-of-the-box. I'm envisioning some stuff I've >> already written as little "utility" functions, but we'd want to >> do it right before putting it into the library. Possibilities >> include: >> 1. A reshape() function. >> 2. Easy ways to read/write to NetCDF files. (This would ONLY >> be compiled if Blitz++ is configured with NetCDF >> dependency. We don't want to add any REQUIRED dependencies). >> 3. Copy-free conversions between blitz::Array and std::vector. >> 4. Conversions between blitz::Array, Numpy arrays and Fortran >> 90 arrays. >> >> In any case, please share your comments and suggestions on this >> roadmap. (Ane please volunteer too!) >> >> Thank you, >> -- Elizabeth >> ... [8<] >> >> >> Many thanks for this great summary, Elizabeth! >> >> Instead of oonumerics we could just create a Blitz++ group on github, >> this is much more google-friendly than the somehow obsolete oonumerics >> name. > > +1 from me for the ammended suggestions (ie. creating a github Blitz++ > group) > > All the best, > Stefan. > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel |
From: Jeff H. <jef...@gm...> - 2016-01-19 15:15:27
|
On Tue, Jan 19, 2016 at 7:03 AM, thomas vincent <vr...@gm...> wrote: > This is a great initiative, I'm almost regretting moving to Eigen::Tensor ! > > What your are proposing is great, really. > > I do second Peter on the github move instead oonumerics, blitz++ really > need more visibility and easy access. > > blitz, blitzpp, and blitzxx are already taken on Github, and blitz++ is verboten (on account of the non-alphanumeric characters). blitzplusplus is available though, as are versions of blitzpp and blitzxx that contain hyphens. Related to this, github.com/oonumerics/blitz++ would be created as github.com/oonumerics/blitz-, so repo names have essentially the same limitation. Jeff > One thing that we had to develop (only for 3d array) and I do thing should > be part of blitz++ itself is efficient file serialization to persist / > cache / share blitz array. > > Thomas > > > 2016-01-18 17:47 GMT-05:00 Peter Kümmel <syn...@gm...>: > >> Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer < >> rp...@co...>: >> >>> Hello Blitzers, >>> >>> Thank you all for your input on this issue. After much consideration, I >>> think that Blitz++ is worth keeping around. Even in 2016, it remains >>> unique in concept and execution. >>> >>> Blitz++ claims to do one thing only: *provide multi-dimensional arrays >>> for C++*, similar to those in Fortran 90, Python/Numpy, and APL. >>> Notice that Fortran 2008 has this feature but nothing like STL, and is >>> widely used for scientific computing. It is clear that multi-dim arrays >>> are essential in a way that STL is not. Of course, a system offering both >>> is even more useful... >>> >>> It is therefore disappointing that such arrays are still not part of the >>> C++ standard. This is after 15 years of work on Blitz++, >>> boost::multi_array, etc. Without any standard, different libraries use >>> different classes for the same data structure, limiting compatibility >>> between them. Interoperability is cumbersome, and often requires >>> unnecessary copying of multi-dimensional data structures (assuming there's >>> enough RAM). >>> >>> Many of us confuse multi-dimensional arrays with matrices and vectors. >>> Matrices and vectors are essential to scientific computing, and may be the >>> most common type of arrays used. However, they do not take the place of >>> the more general multi-dimensional array. This becomes clear to anyone >>> attempting to read 5-dimensional data out of a HDF/NetCDF file. In an >>> ideal world, matrix and vector classes (and operations) would be built upon >>> a foundation of rank 1 and 2 arrays, thereby enhancing compatibility >>> between different linear algebra libraries. >>> >>> By offering *only* multi-dimensional arrays, Blitz++ provides a >>> foundation upon which linear algebra and other libraries may be built. The >>> fact that none have taken advantage of this foundation seems to be a missed >>> opportunity. However... until/unless something better comes along, I >>> believe we should continue to support Blitz++. >>> >>> Why is Blitz++ so good? >>> >>> 1. It works, it's stable, it's well-tested. There's really nothing >>> wrong with it. Sometimes, software is updated infrequently because it's >>> not buggy. That's a reason to KEEP it, not throw it away. >>> 2. It's well documented. The manual may feel long in the tooth >>> compared to today's manuals. But the information you need is all there, >>> and it works. >>> 3. It does one thing well and has no dependencies. I don't have to >>> link to BLAS in order to read a NetCDF file with Blitz++. >>> 4. It's versatile. Blitz++ offers the full functionality of Fortran >>> 90 arrays, and is able to use arrays in memory allocated by others. There >>> are no restrictions on the dope vectors it allows. It is therefore REALLY >>> useful for interfacing Fortran and Python code with C++. And since any >>> array-like data structure can be converted (copy-free) to a blitz::Array, >>> writing your functions to take blitz::Array parameters is an easy way to >>> make them flexible as well. >>> 5. It's FAST. Benchmarks have shown it to be about as fast as >>> Fortran 90 arrays. >>> >>> In my review, I found only two other serious efforts to offer >>> multi-dimensional arrays for C++. Both have potentially serious problems: >>> >>> ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it >>> offers most/all of Blitz++ functionality. However, it has many downsides >>> at this point compared to Blitz++: >>> >>> 1. It's a less mature product, could be evolving, could come with >>> bugs, etc. >>> 2. We don't know how fast it is. It could be a lot slower than >>> Blitz++. >>> 3. It's not as well documented. It provides some features that >>> could be useful, but that I just didn't know were there because I couldn't >>> find them in the documentation. >>> 4. *If the authors do a good job, they will end up with a library >>> similar in functionality and speed to Blitz++. * I just don't see >>> the upside to re-developing this functionality from scratch. >>> >>> ** boost::multi_array* showed initial promise as being part of the >>> boost ecosystem, and therefore (possibly) on track to becoming a C++ >>> standard. However, it has languished in boost, apparently with little or >>> no interest. This project is even deader than Blitz++. Maybe one reason >>> is benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept >>> that people who want multi-dimensional arrays to be part of their language >>> standard will have to use Fortran for many years to come: >>> >>> "I don't know what the language of the year 2000 will look like, but I >>> know it will be called Fortran." *-- Tony Hoare [CarHoare >>> <http://c2.com/cgi/wiki?CarHoare>], apparently on a card distributed during >>> the 1982 AFIPS National Computing Conference.* >>> >>> >>> A number of other libraries exist that provide specialized matrix and >>> vector classes. I do not need to mention them here because they don't >>> provide multi-dimensional arrays. >>> >>> ----------------------------- >>> >>> I propose the following roadmap for the continued viability of Blitz++: >>> >>> 1. We get volunteers. *Please contact me if you are interested in >>> any of the tasks listed below.* >>> 2. We move the repo to github.com/oonumerics/ >>> <http://github.com/oonumerics/blitz>blitz >>> <http://github.com/oonumerics/blitz>. In the past, Blitz++ was >>> hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code >>> from SourceForge and direct people to GitHub. We also move the mailing >>> list and try to move the mailing list archives, if possible. >>> 3. Once things are moved, we can start putting updates into a ticket >>> system. I would suggest the following priorities: >>> 1. Reformatted documentation, posted on-line. Doxygen docs would >>> be nice. >>> 2. Identify and seek resolution on any warnings Blitz++ might be >>> causing with modern compilers. We need to assure users that Blitz++ won't >>> just stop working some day. >>> 3. Release the results of this as "Blitz 1.0" >>> 4. We then start working on Blitz 2.0, which will make use of >>> features in C++11 and beyond. C++98 users can continue to use Blitz >>> 1.0. Updates might include: >>> 1. Replace TinyVector with std::array >>> 2. Much has changed now, with std::unique_ptr<> and >>> std::shared_ptr<> now being part of the C++ standard. It would be worth >>> seeing if some of the shared_ptr functionality currently built into Blitz++ >>> is worth factoring out. >>> 5. Consider adding new functionality that will make blitz::Array >>> more useful out-of-the-box. I'm envisioning some stuff I've already >>> written as little "utility" functions, but we'd want to do it right before >>> putting it into the library. Possibilities include: >>> 1. A reshape() function. >>> 2. Easy ways to read/write to NetCDF files. (This would ONLY be >>> compiled if Blitz++ is configured with NetCDF dependency. We don't want to >>> add any REQUIRED dependencies). >>> 3. Copy-free conversions between blitz::Array and std::vector. >>> 4. Conversions between blitz::Array, Numpy arrays and Fortran 90 >>> arrays. >>> >>> In any case, please share your comments and suggestions on this roadmap. >>> (Ane please volunteer too!) >>> >>> Thank you, >>> -- Elizabeth >>> >>> -- Jeff Hammond jef...@gm... http://jeffhammond.github.io/ |
From: Daniel O. <dan...@gm...> - 2016-01-19 23:55:39
|
+1 for blitzplusplus Also more kudos. I really never found anything as nice as blitz and I would really like to play with simd acceleration, as I remember that being the only shortcoming. Von meinem iPad gesendet > Am 19.01.2016 um 16:15 schrieb Jeff Hammond <jef...@gm...>: > > > >> On Tue, Jan 19, 2016 at 7:03 AM, thomas vincent <vr...@gm...> wrote: >> This is a great initiative, I'm almost regretting moving to Eigen::Tensor ! >> >> What your are proposing is great, really. >> >> I do second Peter on the github move instead oonumerics, blitz++ really need more visibility and easy access. > > blitz, blitzpp, and blitzxx are already taken on Github, and blitz++ is verboten (on account of the non-alphanumeric characters). blitzplusplus is available though, as are versions of blitzpp and blitzxx that contain hyphens. > > Related to this, github.com/oonumerics/blitz++ would be created as github.com/oonumerics/blitz-, so repo names have essentially the same limitation. > > Jeff > >> One thing that we had to develop (only for 3d array) and I do thing should be part of blitz++ itself is efficient file serialization to persist / cache / share blitz array. >> >> Thomas >> >> >> 2016-01-18 17:47 GMT-05:00 Peter Kümmel <syn...@gm...>: >>> Am 18. Januar 2016 23:16:10 MEZ, schrieb Elizabeth Fischer <rp...@co...>: >>>> Hello Blitzers, >>>> >>>> Thank you all for your input on this issue. After much consideration, I think that Blitz++ is worth keeping around. Even in 2016, it remains unique in concept and execution. >>>> >>>> Blitz++ claims to do one thing only: provide multi-dimensional arrays for C++, similar to those in Fortran 90, Python/Numpy, and APL. Notice that Fortran 2008 has this feature but nothing like STL, and is widely used for scientific computing. It is clear that multi-dim arrays are essential in a way that STL is not. Of course, a system offering both is even more useful... >>>> >>>> It is therefore disappointing that such arrays are still not part of the C++ standard. This is after 15 years of work on Blitz++, boost::multi_array, etc. Without any standard, different libraries use different classes for the same data structure, limiting compatibility between them. Interoperability is cumbersome, and often requires unnecessary copying of multi-dimensional data structures (assuming there's enough RAM). >>>> >>>> Many of us confuse multi-dimensional arrays with matrices and vectors. Matrices and vectors are essential to scientific computing, and may be the most common type of arrays used. However, they do not take the place of the more general multi-dimensional array. This becomes clear to anyone attempting to read 5-dimensional data out of a HDF/NetCDF file. In an ideal world, matrix and vector classes (and operations) would be built upon a foundation of rank 1 and 2 arrays, thereby enhancing compatibility between different linear algebra libraries. >>>> >>>> By offering only multi-dimensional arrays, Blitz++ provides a foundation upon which linear algebra and other libraries may be built. The fact that none have taken advantage of this foundation seems to be a missed opportunity. However... until/unless something better comes along, I believe we should continue to support Blitz++. >>>> >>>> Why is Blitz++ so good? >>>> It works, it's stable, it's well-tested. There's really nothing wrong with it. Sometimes, software is updated infrequently because it's not buggy. That's a reason to KEEP it, not throw it away. >>>> It's well documented. The manual may feel long in the tooth compared to today's manuals. But the information you need is all there, and it works. >>>> It does one thing well and has no dependencies. I don't have to link to BLAS in order to read a NetCDF file with Blitz++. >>>> It's versatile. Blitz++ offers the full functionality of Fortran 90 arrays, and is able to use arrays in memory allocated by others. There are no restrictions on the dope vectors it allows. It is therefore REALLY useful for interfacing Fortran and Python code with C++. And since any array-like data structure can be converted (copy-free) to a blitz::Array, writing your functions to take blitz::Array parameters is an easy way to make them flexible as well. >>>> It's FAST. Benchmarks have shown it to be about as fast as Fortran 90 arrays. >>>> In my review, I found only two other serious efforts to offer multi-dimensional arrays for C++. Both have potentially serious problems: >>>> >>>> * Eigen::Tensor is a relatively new part of Eigen. In theory, it offers most/all of Blitz++ functionality. However, it has many downsides at this point compared to Blitz++: >>>> It's a less mature product, could be evolving, could come with bugs, etc. >>>> We don't know how fast it is. It could be a lot slower than Blitz++. >>>> It's not as well documented. It provides some features that could be useful, but that I just didn't know were there because I couldn't find them in the documentation. >>>> If the authors do a good job, they will end up with a library similar in functionality and speed to Blitz++. I just don't see the upside to re-developing this functionality from scratch. >>>> * boost::multi_array showed initial promise as being part of the boost ecosystem, and therefore (possibly) on track to becoming a C++ standard. However, it has languished in boost, apparently with little or no interest. This project is even deader than Blitz++. Maybe one reason is benchmarks showed it to be about 1/2 as fast as Blitz++. We must accept that people who want multi-dimensional arrays to be part of their language standard will have to use Fortran for many years to come: >>>> >>>> "I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." -- Tony Hoare [CarHoare], apparently on a card distributed during the 1982 AFIPS National Computing Conference. >>>> >>>> A number of other libraries exist that provide specialized matrix and vector classes. I do not need to mention them here because they don't provide multi-dimensional arrays. >>>> >>>> ----------------------------- >>>> >>>> I propose the following roadmap for the continued viability of Blitz++: >>>> We get volunteers. Please contact me if you are interested in any of the tasks listed below. >>>> We move the repo to github.com/oonumerics/blitz. In the past, Blitz++ was hosted by oonumerics. Once this new repo is set up, we remove Blitz++ code from SourceForge and direct people to GitHub. We also move the mailing list and try to move the mailing list archives, if possible. >>>> Once things are moved, we can start putting updates into a ticket system. I would suggest the following priorities: >>>> Reformatted documentation, posted on-line. Doxygen docs would be nice. >>>> Identify and seek resolution on any warnings Blitz++ might be causing with modern compilers. We need to assure users that Blitz++ won't just stop working some day. >>>> Release the results of this as "Blitz 1.0" >>>> We then start working on Blitz 2.0, which will make use of features in C++11 and beyond. C++98 users can continue to use Blitz 1.0. Updates might include: >>>> Replace TinyVector with std::array >>>> Much has changed now, with std::unique_ptr<> and std::shared_ptr<> now being part of the C++ standard. It would be worth seeing if some of the shared_ptr functionality currently built into Blitz++ is worth factoring out. >>>> Consider adding new functionality that will make blitz::Array more useful out-of-the-box. I'm envisioning some stuff I've already written as little "utility" functions, but we'd want to do it right before putting it into the library. Possibilities include: >>>> A reshape() function. >>>> Easy ways to read/write to NetCDF files. (This would ONLY be compiled if Blitz++ is configured with NetCDF dependency. We don't want to add any REQUIRED dependencies). >>>> Copy-free conversions between blitz::Array and std::vector. >>>> Conversions between blitz::Array, Numpy arrays and Fortran 90 arrays. >>>> In any case, please share your comments and suggestions on this roadmap. (Ane please volunteer too!) >>>> >>>> Thank you, >>>> -- Elizabeth > > > -- > Jeff Hammond > jef...@gm... > http://jeffhammond.github.io/ > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel |
From: Mario E. <ma...@em...> - 2016-01-20 09:32:35
|
Hi all, the LMB in Freiburg around Olaf Ronneberger and others has worked for a long time with blitz++ in combination with HDF5. If people are interested, I can kindly ask if the code is mature, and if it can be shared publicly. Of course this would rather be an _optional_ extra or maybe a separate project, similar to the integration of netcdf, to ensure that those dependencies are purely optional. Cheers, Mario On 08.01.2016 20:41, Elizabeth Fischer wrote: > Hello, > > I received the following response to my recent query about the status of Blitz++ (edited by me): > > Based upon the website, I don't know how active Blitz++ is anymore. Many of the named individuals have moved on... > > > > If I were you, I would fork the project onto Github with git-svn (I assume like most older projects on SourceForge, Blitz++ is using Subversion), both > because it will obviate the need for repo permissions while at the same time encouraging the Blitz++ community to move into this decade :-) > > > I agree, this would be a sensible approach. But to make it work, we would need momentum on the new repository. It's best if the people in charge of the > SourceForge site can close it down, or post prominent information such as "This site is obsolete; please go over to GitHub if you want the latest version of > Blitz++." > > To that end, here are my thoughts: > > *) I would really like to wait a reasonable length of time (a couple days), to see if we hear from the current Blitz++ developers. *Is there anybody out there?* > > *) There's already a Blitz++ fork on GitHub, at: > https://github.com/syntheticpp/blitz > I don't know how much interest its author (Peter Kümmel) has in maintaining this, or if he just forked it to make sure it didn't disappear. I don't know to > what extent it might have diverged from the latest Blitz++ tarball. > > *) I can't for the life of me find ANY repository on SourceForge anymore, just a tarball. Maybe the repository for Blitz++ has been disabled? If anyone can > point me to a repository URL for Blitz++ on SourceForge, that would be greatly appreciated. > > *) Is anyone other than myself interested in contributing or being a developer on this project? Blitz++ is a quality, stable piece of software. But I don't > want to replace one abandonware repository with another; better to start with at least a little momentum. > > Thank you, > -- Elizabeth Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstrasse 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ |
From: thomas v. <vr...@gm...> - 2016-01-20 15:45:17
|
Hi all, Looks like blitzcpp & blitz-cpp are available on github ... I find those simpler that blitzplusplus ... Someone in here must create open-source organization soon, until some decent name are remaining. Thomas 2016-01-20 4:32 GMT-05:00 Mario Emmenlauer <ma...@em...>: > > Hi all, > > the LMB in Freiburg around Olaf Ronneberger and others has worked > for a long time with blitz++ in combination with HDF5. If people > are interested, I can kindly ask if the code is mature, and if it > can be shared publicly. Of course this would rather be an _optional_ > extra or maybe a separate project, similar to the integration of > netcdf, to ensure that those dependencies are purely optional. > > Cheers, > > Mario > > > > On 08.01.2016 20:41, Elizabeth Fischer wrote: > > Hello, > > > > I received the following response to my recent query about the status of > Blitz++ (edited by me): > > > > Based upon the website, I don't know how active Blitz++ is anymore. > Many of the named individuals have moved on... > > > > > > > > If I were you, I would fork the project onto Github with git-svn (I > assume like most older projects on SourceForge, Blitz++ is using > Subversion), both > > because it will obviate the need for repo permissions while at the > same time encouraging the Blitz++ community to move into this decade :-) > > > > > > I agree, this would be a sensible approach. But to make it work, we > would need momentum on the new repository. It's best if the people in > charge of the > > SourceForge site can close it down, or post prominent information such > as "This site is obsolete; please go over to GitHub if you want the latest > version of > > Blitz++." > > > > To that end, here are my thoughts: > > > > *) I would really like to wait a reasonable length of time (a couple > days), to see if we hear from the current Blitz++ developers. *Is there > anybody out there?* > > > > *) There's already a Blitz++ fork on GitHub, at: > > https://github.com/syntheticpp/blitz > > I don't know how much interest its author (Peter Kümmel) has in > maintaining this, or if he just forked it to make sure it didn't > disappear. I don't know to > > what extent it might have diverged from the latest Blitz++ tarball. > > > > *) I can't for the life of me find ANY repository on SourceForge > anymore, just a tarball. Maybe the repository for Blitz++ has been > disabled? If anyone can > > point me to a repository URL for Blitz++ on SourceForge, that would be > greatly appreciated. > > > > *) Is anyone other than myself interested in contributing or being a > developer on this project? Blitz++ is a quality, stable piece of > software. But I don't > > want to replace one abandonware repository with another; better to start > with at least a little momentum. > > > > Thank you, > > -- Elizabeth > > > > Viele Gruesse, > > Mario Emmenlauer > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstrasse 43 mailto: memmenlauer * biodataanalysis.de > D-81669 München http://www.biodataanalysis.de/ > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Blitz-devel mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-devel > |
From: Gael G. <gae...@gm...> - 2016-01-20 01:06:13
Attachments:
bench_tensor_blitz.cpp
|
On Mon, Jan 18, 2016 at 11:16 PM, Elizabeth Fischer <rp...@co...> wrote: > ** Eigen::Tensor* is a relatively new part of Eigen. In theory, it > offers most/all of Blitz++ functionality. However, it has many downsides > at this point compared to Blitz+: > 2. We don't know how fast it is. It could be a lot slower than > Blitz++. > Don't worry, Eigen in general and the Tensor module in particular is developed with very high constraints to deliver optimal speed. For the fun, I've implemented a small benchmark stressing tensor products, perhaps not representative of your use cases, but anyway, here are the results (the code is very small and attached below): Eigen: 0.342062s Blitz++: 14.6185s (compiled with gcc 5 -O3 -DNDEBUG -mfma) and Eigen::Tensor can also use OpenMP or CUDA for even higher performance. There is no magic here, just several days/weeks of work to implement highly optimized matrix-matrix product kernels onto which efficient tensor products can be constructed. On the other hand it's true that Eigen is less matured (though it is heavily used in production code), the documentation could be improved (who said that best documentations are written by the users? ;) ), and you won't find all blitz features yet (but you will find many others). And most importantly, best wishes in resurrecting blitz development. Cheers, Gael |
From: Christoph H. <ch...@in...> - 2016-01-20 09:45:25
|
On 2016-01-20 02:05, Gael Guennebaud wrote: > Eigen: 0.342062s > > Blitz++: 14.6185s > > (compiled with gcc 5 -O3 -DNDEBUG -mfma) I was not surprised that Eigen is faster -- mostly as it uses SIMD. But I think for a fairer comparison, you should at least initialize the values in the Blitz++ implementation (working on uninitialized values tends to be slow, if there is a number of NaNs and Infs in the data), and probably also compare how big the difference without SIMD would be (or with just SSE2/3/4, instead of AVX+FMA). Christoph -- Dipl. Inf., Dipl. Math. Christoph Hertzberg Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftsstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel.: +49 421 178 45-4021 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: ch...@in... Weitere Informationen: http://www.informatik.uni-bremen.de/robotik |