Doug McNutt wrote: > As for complex operations which have multiple results I think a principle > value approach makes more sense than a list. It's well established for the > inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica.
In the hypothetical module that I'm describing, the principle value approach _would_ be used - in scalar context. The only time the "list of all possible results" approach would be used would be if you use list context. If you have no need of the list feature, then you don't have to use it. I believe that what I have outlined is a reasonable approach to handling complex numbers. It may or may not be the best way to do so (and I suspect that it isn't), but that isn't really the point. The point is that it _is_ reasonable, and I'd like to see how well Perl 6 handles it. Michele Dondi wrote: > I must say that I didn't follow the discussion very much. But this makes > me think of this too: the two representations are handy for different > calculations. It would be nice if they somehow declared what they can do > better (or at all) and have the "union" take care of which one's methods > to use. That's one of the points I had in mind. Rectilinear coordinates are useful for addition and subtraction, while polar coordinates fare better for multiplication, division, powers, logs, trigonometric functions, and hyperbolic functions. So define addition and subtraction for the rectilinear coordinate system and define the remaining operations for the polar coordinate system. The problem is that the two coordinate systems don't just differ in terms of which methods they make available; they also differ in terms of how they represent the value that they represent. So if you want to multiply two complex numbers that were defined using rectilinear coordinates, you'd need to transform them to polar coordinates first, and then multiply those numbers. Phrased in terms of roles, the rectilinear role would have $.x and $.y attributes (which its methods would use), while the polar role would have $.magnitude and $.direction attributes (which _its_ methods would use). That's two sets of attributes which contain identical data in vastly different formats; simply having one class or role do both of these roles would result in extra memory usage (as both sets of attributes would need storage allocated to them), not to mention the likelihood that the two sets of attributes may end up getting out of synch with each other. What I'm looking at is a way to declare that the two roles are different representatives of the same thing. Memory would be allocated to exactly one set of attributes at a time, and transformations between the different sets would be called whenever you change the underlying representation of the data. In the former regard, this would be much like C's union; but it would differ from them in that it would be designed to preserve the logical value (what the data represents) rather than the physical value (the sequence of bits in memory). -- Jonathan "Dataweaver" Lang
