On Saturday, July 19, 2014 8:22:39 AM UTC-7, Nils Bruin wrote: > > On Saturday, July 19, 2014 5:43:57 AM UTC-7, defeo wrote: > >> However, Julia multimethods are backed up by a powerful coercion >> system, so I do not understand the "step back" criticism. >> >> That comment wasn't made with respect to Julia, because that would be > comparing the coercion facilities of a CAS to those of a programming > language. Coercion in a CAS tends to be a *lot* more complicated than what > programming languages are designed for. As an example: > > Consider A+B where A is a polynomial in ZZ[x,y] and B is a power series in > F_q[[x]] (finite field with q elements). > > Do you expect your CAS to make sense of that addition? Sage does. >
A CAS that has representations for those two objects will very likely make sense of that addition, so Sage is hardly unique. It returns an answer in F_q[[x]][y] (i.e., a polynomial in y over power > series in x over F_q) . You can argue whether it's desirable for a system > to try to be that smart, but all computer algebra systems I know are a > "step back" relative to this. Programming languages do not tend to have > type models that would even allow you to try and make sense of this kind of > question. > A harder question is when the coercion is not so obvious, As a simple example, is the polynomial x^0 coerced to the integer 1? How do you add two bigfloats of different precision? Or add a float to an exact rational? Do you allow 1/(1+i) or do you coerce by rationalizing the denominator? The speed of dispatch and specialization has probably been explored in the context of compiling Lisp, ad nauseum. I don't know if Julia adds something to the mix, but I am skeptical that it has so much to do with the title of this thread (scientific computing). While Julia might be a superior vehicle for writing scientifc computing programs for any number of reasons, the issues it addresses may be irrelevant to the applications of computers in scientific disciplines, which tend to be written in stuff like Matlab, (or clones), C, or FORTRAN. It is not necessarily a technology problem as much as a marketing problem. >From personal experience I can attest to the fact that showing someone P who is relatively happy with programming language X that there is a "better" language Y for what he is doing, is not sufficient to convince P to rewrite all his programs and those of his friends/students in language Y. Usually. And if you DO make such a case, you find that the new programs in language Y use almost none of the features that make Y better than X. They are just programs transliterated into Y. Like FORTRAN programs, GOTOs and all, written in Lisp... But have fun, anyway. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
