[boost] Re: Gauging Interest: polar_complex

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-11-29 10:24:17

Somewhere in the E.U., le 29/11/2004

   Bonjour

In article 
<6.1.0.6.2.20041123072043.027c5898_at_[hidden]>,
 Mickey Moore <mgmoore_at_[hidden]> 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.
> 
> 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.

      Yes.

[SNIP]

> >       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 

      Well, as others in this thread have said, it is not because you 
have not (yet) convinced the few of us which have replied, that your 
proposal has no merit. There is definitely the possibility that other 
arguments would sway us (but then they would have to really be good).

      I would like to comment further on the above part of your post. 
What you refer to as "making the same class hold different 
representations is a terrible idea", would be what I call a naive 
implementation. Certainly, "stacking" representations and insuring that 
they are always in synch would result in an awfully bloated, miserably 
slow creature. However, the goal of "multiplicity of concurrent points 
of view" ("structural polymorphism"?) is a compelling one. I am only 
dreaming out loud here, but is there really no way of having some aspect 
of it? Something like a "lazy" implementation, perhaps, that would 
freeze its actual internals at critical junctures rather than all the 
time? I certainly do not know how to create such a thing, but 
considering the invention of expression templates and the other 
metamagic we see here, one can only wonder if such is really impossible.

   Merci

         Hubert Holin