- Boost - lists.boost.org

OK, Still gauging interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

Seems a few people think I may have given up too easily, so I will respond further later (time doesn't permit right now) and solicit any other feedback on the idea. (My previous comment comparing the number of responses about this to the number of responses about the web page logo was just intended as a joke; I of course realize that that was not an accurate way of assessing interest.) -- Mickey Moore

1 0

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Peter Petrov <ppetrov(a)ppetrov.com> Fecha: Domingo, Noviembre 28, 2004 10:30 pm Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > Anyway, I've just forged anoher idea. Not that I like > > it much, but the idea is a little different and might > > please some --sort of ++ breaking the barrier of sound > > or something. > > > > http://lists.boost.org/MailArchives/boost/png00027.png > > Hey, this is great! My favourite so far. > Thank you! I prefer my first design, though :( But Johnatan first Boost logo is also high in my list. > Why don't you try removing the distant parts of the circles > surrounding the + > signs (so that they look more like C's, rather than O's). > I think it's going to look clumsy, as the distants parts of the circles are mostly covered. In order to see something, the circles would have to be chopped way too much, roughly between 12:00 and 6:00, if you know what I mean. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Re: [boost] Gauging Interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

I appreciate everyone's comments (and I'll respond to a number below), but it seems interest in this is not widespread enough to justify trying to formally include it. I'll probably clean it up a bit and post it on my own web-site at some point in case someone somewhere might find it useful. It was a good exercise in humility to note that, judging from the message frequency, people are at least a hundred times more interested in the new logo for the Boost web-site. :) ------------------------------------------------------------ Regarding specific comments: Roland Schwarz wrote: > > For some applications, polar complex numbers have significant > > advantages over Cartesian complex (e.g., std::complex) in efficiency > > and numerical accuracy. > >Just out of curiosity: Can you give me an example of an algorithm where >this would be of advantage? Well, Hubert Holin gave one: tracking orbits (trajectories in polar coordinates). There are actually a number of subtleties to be aware of in mapping a physical 2D plane to the complex plane, so in that case, I would actually probably use a true polar_vector2D class rather than polar_complex. However, for field equations (including those from fluid dynamics, my area), using tools from complex analysis can create new, simpler formulations of problems in the complex plane. If the resulting mapping has a high order of circular symmetry, then polar_complex numbers have advantages. The most obvious use of polar_complex numbers would be in wave mechanics. The phase and magnitude are often weakly coupled; you can sometimes work with just one component in different parts of the calculations. At the lowest level, polar_complex numbers are best when the primary operations are multiplications/divisions and powers/roots. When you start adding/subtracting, then cartesian representations begin to win out (because of the cost of the trig functions). There's another advantage of polar_complex numbers that I didn't spell out separately: *development* efficiency, i.e. how quickly one can write an acceptable program for a simulation prototype or a quick-and-dirty calculation. Many problems (in fact, a majority of those I have worked with) are more naturally formulated in polar form; it's therefore easier to write a program that uses that representation. This is just the old programming adage "Think/write in the problem domain, not the language domain.". I'd address run-time efficiency later in those cases where it was a concern; I haven't yet seen any cases where the polar_complex representation was obviously inefficient. Hubert Holin wrote: > The main problems I foresee are in the commingling of the two >different classes. It is interesting to see a complex number (among >other ways) either as its two canonical coordinates, or in a polar >representation, but sometimes we just want to switch between the two for >a given instance. So I fear a substantial amount of typical run time >will be spent doing conversions. I defined explicit conversions to and from std::complex, but I used them fairly rarely. If the problem truly belongs in the polar representation, then you won't need many conversions. In fact, I wrote polar_complex in the first place in a case when I found myself very frequently calling abs, arg, and polar using std::complex -- the problem didn't belong in the cartesian representation. But you are right that the relation between them needs careful consideration; that was on my list of issues to address if I "boosted" it. > There is another, perhaps deeper, problem to consider, with the >representation of complex numbers (and others), as evidenced by a thread >on comp.std.c++ a couple of years back: layout guaranties. People >wanted, in essence, to be able to break encapsulation when it suited >them (for efficiency in time-critical code). The discussion also >encompassed thoughts about the polar representation (which, as you >remarked, also has advantages). As far as I know, there has been no >tangible result to that thread. > > In short, I am not sure a library for complex numbers in polar >form would be worthwhile, but I certainly think that if you could make >the above situation progress (as in: write a formal proposal), it would >be a great win for us all. Well, I needn't worry about polar_complex layout because there are no C or FORTRAN equivalents to be layout compatible with. :) Regarding std::complex, just about a month ago, I posted to comp.lang.c++.moderated about these very issues. The current status is in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1589.html The layout guarantee seems certain, and it lays out possible solutions for the second issue. I don't see much that I can add other than to give my recommendation on the solution and prod them to pick one already. I've already been doing both on clc++m; I suppose I could write Howard Hinnant directly, but he's responded to several threads so he's probably read most of my posts. This is becoming a digression, but my opinion, for what it's worth: std::complex should never have been encapsulated as it was in the first place. And to justify this, in addition to the efficiency issues, there is clarity of the code's intent. Consider: 1a) z = complex<double>(z.real(), 1); 2a) z.imag() = 1; 1b) z = complex<double>(z.real(), z.imag() + 1); 2b) z.imag() += 1; I think it's clearly much easier to read the intent of the code in the second cases. Matt Austern wrote: >But is it likely that you would want to use a package that provides >complex numbers in polar form? My experience is that if you're >working with complex numbers that you want to think of in the form >r exp(i phi), then you'll probably just do the work of separating out >the magnitude and phase ahead of time in your equations, and then >compute with them separately. After all: if you're doing something >where the magnitude-phase form is most convenient, it usually >means that putting numbers in that form makes the equations >simpler. True to a degree, though such separation is not always possible, especially in non-linear situations. And a similar argument is true for cartesian complex: if you're doing something where the real-imaginary form is most convenient, it also usually means that putting numbers in that form makes the equations simpler. But it's usually easier to keep track of, for instance, just vector< complex<double> > Numbers; than vector<double> NumbersReal; vector<double> NumbersImag; and there's usually no harm in combining them like that (unless of course complex is over-encapsulated, but I digress again. . .). Similarly, vector< polar_complex<double> > Wave; is simpler to deal with than vector<double> WaveAmplitude; vector<double> WaveMagnitude; so combine them if there's no harm in doing so. This is appealing to the "development efficiency" (and code clarity) argument I made above. > Still, from the discussion on comp.std.cpp a few years back, I >recall that there was a feeling that having multiple representations >(say cartesian and polar) at the same time would have been nice. Of >course, it would have been a bloated beast (at least in a naive >implementation), and a slow one at that (to keep track of the various >changes, in a naive implementation still). Furthermore it clashed with >the desire to have some layout guaranty which played nice with C (that >line of reasoning seems to have flown out in limbo, however). > > This illustration is merely there as a reminder that the wish for >concurrent multiple points of views of a given abstract entity is not a >futile one, if one that I fear can't be translated from mathematics to >CS. We've had another illustration of that recently with the affine >space/vector space discussion in a GUI thread a few days back here >(which also happens to be relevant to this discussion as well, at least >in two dimensions). Well now you are touching on an entirely separate point. For a mathematical primitive used in numerical work, making the same class hold different representations is a terrible idea. Pick the representation you need and stick with it, converting between representations only if/when you must. If you find yourself converting constantly, then you have picked the wrong algorithm or need another representation altogether. And how many representations should you implement in one class? Why cartesian and polar coordinates but not parabolic, elliptical, bipolar, etc.? ------------------------------------------------------------ Again, I appreciate all the comments, but the interest obviously isn't there for developing the class further. Thanks, Mickey Moore

7 6

regex and g++ 3.4.2 problem
by Maciej Sobczak 29 Nov '04

29 Nov '04

Hi, $ g++ --version g++ (GCC) 3.4.2 [FreeBSD] 20040728 (boost version 1.32) When compiling a very simple example for the regex library, I've got the following error: In file included from /usr/local/include/boost_1_32_0/boost/regex/v4/regex.hpp:99, from /usr/local/include/boost_1_32_0/boost/regex.hpp:34, from regex.cc:1: /usr/local/include/boost_1_32_0/boost/regex/v4/instances.hpp:71: error: ISO C++ forbids the use of `extern' on explicit instantiations *** Error code 1 A short investigation points to the following code in the instances.hpp file: #elif (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) || defined(__GNUC__) # ifndef BOOST_REGEX_INSTANTIATE # define template extern template // (*) # endif # ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660) # endif template class BOOST_REGEX_DECL reg_expression< BOOST_REGEX_CHAR_T >; IMHO (and rather guessing), the #define in (*) is performed unnecessarily for g++ 3.4.2, but is executed just because of too generic __GNUC__ a little bit higher. As a temporary solution, I have just uncommented the following line in boost/regex/user.hpp: #define BOOST_REGEX_NO_EXTERNAL_TEMPLATES Now the simple program compiles and works fine. What influence will the above change in user.hpp have on bigger programs? Is this a known problem? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

3 3

Gauging Interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

I wanted to gauge whether there might be interest in a class for complex numbers with data stored in polar form. For some applications, polar complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy. (I spent some time Googling and, somewhat to my surprise, didn't find any freely available versions of this.) I have a fairly well developed class that implements this; "boosting" it to be worthy of consideration would probably be straight-forward but non-trivial. My version of this is of course templated on the contained numeric type. It is also uses a policy-based design that determines whether or not the polar angle phi is always maintained in principal form or not and what constitutes principal form (default: no, -pi < phi <= pi). Thanks, Mickey Moore ---------------------------------------- Mitchell G. (Mickey) Moore, Ph.D. mgmoore(a)austin.rr.com

4 7

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 29 Nov '04

29 Nov '04

Thanks for the link. I'm not sure it applies though; the prog isn't spawning the threads simultaneously, so it shouldn't be taking many resources. I've found that even if I only have one thread spawned at one time (where the previous thread has died out before the new one is spawned) it still aborts at the same place. Over the holiday I pared my program down to just the thread spawning, and on my Mandrake setup at home it dies at the nice even (computer) number of 256 threads. The same pared-down prog dies on my work Fedora Core 3 machine at 405. Under Windows, it doesn't ever seem to die. I'm getting pretty convinced this is a bug in the boost library that manifests itself only under Linux, and not my code. Perhaps resources are not being properly released when the threads are dying out. Since the prog is pretty small, I'll include it here. It spawns a thread every second, and each thread only last one second. #include <iostream> #include <string> #include <stdlib.h> // for multithreading #include <boost/thread/mutex.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> int totalthreads = 0; boost::mutex io_mutex; // iostreams boost::mutex numthreads_mutex; // for changing value of numthreads boost::mutex threadid_mutex; // for manipulating thread_id using namespace std; void threadfunc() { // wait some secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread Exiting. " << std::endl; } } main() { boost::thread_group thrds; boost::xtime xt; int maxthreads=99999; // ******************************** // Main thread-spawning loop for (int i=0; i<=maxthreads; i++) { totalthreads++; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << "MAIN: Thread:" << totalthreads << " being spawned... " << std::endl; } thrds.create_thread( &threadfunc); // wait some seconds boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } // end thread-spawning for loop thrds.join_all(); std::cout << "Done." << std::endl; } Here's the Makefile I build it with: lib = /usr/local/lib/libboost_thread-gcc-mt-1_32.so threadtest : threadtest.o g++ $(lib) $(lib2) -o threadtest threadtest.o -ldl -lc -lpthread threadtest.o : threadtest.cpp g++ -Wall threadtest.cpp -I/usr/local/include/boost-1_32 -pthread -c -w -O -o threadtest.o -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Friday, November 26, 2004 2:07 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? Tim Laplaca wrote: > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after > spawning 283 or so threads, it stops running and 'Aborted' is printed. Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: Another logo proposal
by Beman Dawes 29 Nov '04

29 Nov '04

At 01:11 PM 11/23/2004, Beman Dawes wrote: >At 06:18 PM 11/22/2004, Rich Johnson wrote: >> >>On Monday, November 22, 2004, at 04:02 PM, JOAQUIN LOPEZ MU?Z wrote: >> >>>> Is there a single color restriction for ease of printing? If not >>>> adding a third '+' in a different color (or perhaps in outline) >>>> would >>>> further emphasize building on C++. >>> >>> You mean, like the version attached? >>> I don't know, it kind of looks too irregularly shaped. Not >>> so blocky as the other designs. >>> >>> Joaquín M López Muñoz >>> Telefónica, Investigación y Desarrollo >>> <boost.gif> >> >>I was thinking more like: >> >> >> >> >> >>Which yields two steps up. I like that a bit. Is anyone keeping a list of the more likely candidates? --Beman

6 10

RE: [boost] Re: [ANN] Phoenix-2 Preview
by Eyal Farago 29 Nov '04

29 Nov '04

I'm not that familiar with phoenix (yet) but I think your implementation fails to handle const arguments. I think that the return type deduction mechanizm should first 'remove_cv' the argument type, then get the appropriate type from your existing metafunction, then 'add_const' if the argument was const and then 'add_reference'. (all of these can be easily done using boost::mpl and boost::type_traits libs). am I missing anything? maybe the framework does this for you? eyal. -----Original Message----- From: Reece Dunn [mailto:msclrhd@hotmail.com] Sent: Monday, November 29, 2004 2:06 PM To: boost(a)lists.boost.org Cc: spirit-general(a)lists.sourceforge.net; spirit-devel(a)lists.sourceforge.net Subject: [boost] Re: [ANN] Phoenix-2 Preview Joel wrote: > Reece Dunn wrote: >> I have written lazy veraions of pair.first and pair.second (see >> attachment). > > Nice! Seems like a beginning of a utility module. If you'd like > to submit it as part of the library, I'd need a test program. Done. Note that the libs/spirit/phoenix/test/Jamfile.v2 needs + # bring in rules for testing + import testing ; at the top to allow you to run bjam from that directory, otherwise it complains about 'run' being unrecognised. > I'd also > request conformance with the implied coding styles for the sake > of consistency. Done. > Many thanks! :) Regards, Reece

1 0

[repost][aligned_storage] problem for GCC 3.2 and proposed solution
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

Allow me to repost this, since seems it has gone thru the list indavertently. I'd be grateful if people with various versions of GCC can try the snippet so as to determine to which extent the problem shows. Original post follows: The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Website MPL Docs.
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Thomas Witt <witt(a)acm.org> Fecha: Viernes, Noviembre 26, 2004 9:20 pm Asunto: [boost] Website MPL Docs. > > Maybe I am just going nuts but the mpl doc links on the website > seem to > be broken. > > http://www.boost.org/libs/libraries.htm > > contains a link to: > > http://www.boost.org/libs/mpl/doc/index.html > > This document seems to be outdated and all the > links in this document seem to be broken. > > The following url seems to point to the current docs > > http://www.boost.org/libs/mpl/doc > > I am lost > I think your browser cache is playing tricks on you. Everything looks OK from mine. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4