Mickey Moore wrote:
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.
Well, my question is, why is it useful to you? I mean, it sounds like the consensus is, if you want to use polar form, you will just need it in intermediate computations, and not in any explicit representations. So why have you not settled on this solution?
[...] 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 personally think this is a good argument, but I don't have a need for complex numbers in my work, so I can't speak as a domain expert.
[...] Well, I needn't worry about polar_complex layout because there are no C or FORTRAN equivalents to be layout compatible with. :)
Regardless, you should be mindful of representations which *do* give you layout guarantees, vs. those that don't. For instance, elements of an array are guaranteed to be contiguous, whereas members of a struct may be separated by padding. If someone wants to get at the raw data, they may prefer a type with a guaranteed layout so they can do dirty "bare metal" coding.
[...] 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.
This sounds like a good argument too, but might be even more compelling with some actual use-cases cited.
[...] Again, I appreciate all the comments, but the interest obviously isn't there for developing the class further.
Well, I wouldn't jump to that conclusion. I think it is worth noting that C++ hasn't exactly attracted a large numerics community, so the response you get right now may be more a reflection of that fact than anything else. I wonder if we had a lot of numerics people that perhaps more of them would say: "Yes, I definitely need polar complex numbers in my work and your encapsulation is very helpful." As it is, the competent numerics people seem to form a rather small segment of the Boost community. So in this case, perhaps you need to be an advocate for numerics, rather than assuming that because there is not a current need that there is no need at all. What might be particularly helpful is if you can get numerics people using *other languages* to say that polar representations are very useful in their work. That might be a compelling reason to add such support to C++. Or perhaps such support is not widespread, but useful; and people don't use it more because it doesn't exist. Then you need to argue why it is better than rewriting your equations to avoid needing intermediate polar representations. So my point is, programmers must be a jack-of-all-trades to some extent. The libraries that get the most attention are the ones that have the most general applicability, whether the library itself has considerable merit or not. Sometimes a proposal doesn't get attention because it lacks merit, and sometimes it doesn't get attention because the Boost community itself lacks experience in that domain. I think it is important to distinguish those cases and treat them appropriately. That is not to say that Hubert or Matt or anyone else is not a good mathematician or numerics expert. That is merely to say that they are not sufficiently numerous to form a compelling sample size. So don't judge the interest by the magnitude of the response. Instead, argue your case until everyone reaches a consensus or a deadlock. Even as a non-expert in this area, it seems to me that neither state has been reached, so more debate seems perfectly reasonable. In fact, it seems that education as much as debate is required here, and it is merely a lack of domain breadth that leads to a lack of interest. You have to remember that programmers are economical by nature, and resist adding things that aren't compellingly useful if it can be avoided. So you just need to motivate your library some more, and draw on the experiences of others in numerics if you must. I think people are willing to consider more use cases if you simply bring them to our attention.
[...] 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. :)
There's several things wrong with that conclusion. First of all, I think it's safe to say that the Boost community takes a certain amount of pride in its image. Something like a logo goes straight to the heart of that pride, which is why it is such a passionate issue for us. Second, art is by nature not rigorous and scientific, so anyone can contribute and comment without being proven wrong. Third, the logo is a creative expression issue, which is unlike anything else that goes on in Boost, so you really can't compare it to library proposals. Fourth, some issues and libraries simply need time to incubate in the collective consciousness, and only reach a critical amount of interest after an inscrutable length of time. It may be that in the future, we have enough numerics people that we will want to look at polar forms in earnest. It is probably the case that the Boost web site in general, and the logo in particular, have reached that critical point where change is motivated. In any case, a certain amount of humility isn't a bad thing; just don't overgeneralize because I think we have unique issues going on. Dave