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
