Somewhere in the E.U., le 29/11/2004 Bonjour In article <6.1.0.6.2.20041123072043.027c5898@pop-server.austin.rr.com>, Mickey Moore <mgmoore@austin.rr.com> 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