Nicolas, I think you might be reading more than I intended into my mention of polymorphism. It is true that the real-to-complex transition fits as an extension of the domain of a function, but I'm less comfortable doing that with real-to-matrix. The real line is a subset of the complex plane. Real numbers can be treated as linear transformations[*] which makes them a 1x1 matrix. Still, it feels like a stretch to extend that into a higher dimensional space, but I might be missing something.
However, my focus was not on mathematics but on the software aspects of the problem: in a C* world, there are only functions, and putting aside C++'s overloading capabilities, the procedural programmer is "forced" to start with a function, and to use a different name for each argument type. So they end up with normReal(x); normMatrix(x); etc. where we can simply do x := Float pi. x norm. x := Matrix vandermonde:5. x norm. and get sensible answers for each via polymorphism. Does that make sense? Of course, sometimes a number is just a number, and they can be pretty useful by themselves. We should not throw them away too easily. I suspect that any package that breaks floating point computation will be summarily ignored. Bill [*] If nothing else, that is the insight behind the Frechet Derivative which rearranges the familiar difference quotient to view the derivative itself as a linear transformation, all the way down to the one-dimensional case. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Cellier Sent: Thursday, August 13, 2009 8:23 PM To: [email protected] Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Schwab,Wilhelm K <[email protected]>: > Nicolas, > > If I'm following you on the matlab matrix exponential business, we should be > able to handle such things polymorphically: exp sent to a matrix would do the > right thing for a matrix, just as Float and Complex would respond > appropriately. The sticking point here is whether operations on floats > should produce complex numbers in place of bounds errors; based on the > arguments presented over the past few days, I vote no. > > Bill > Agree for pragmatic reasons. I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them. To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with polymorphism: f: A -> A f: B -> B Problems arise when f is defined only on a subset A* of A, but has an extension over B: f: A* -> A f: A -> B f: B -> B First two definitions are ambiguous, and expectations will vary with applications. This is the case of #sqrt. Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt. So far so good, and this is in the spirit of Squeak Complex implementation. But Igor added that in case of this property on a subset B* f: B* -> A then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i. I argue that though the two features are appealling, they are hard to mix. That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions... Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though. That's longer, I don't know if clearer... Nicolas _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
