[boost] Re: Gauging Interest: polar_complex

From: David B. Held (dheld_at_[hidden])
Date: 2004-11-28 02:02:47

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