On Wed, Jul 23, 2014 at 5:47 PM, rjf <fate...@gmail.com> wrote: > > > 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.
Show me one. >> 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? The *polynomial* x^0, yes. > How do you add two bigfloats of different precision? Return the result in lower precision. > Or add a float to an exact rational? Coerce to a rational (same rule as above). > Do you allow 1/(1+i) or do you coerce by rationalizing the denominator? That depends on what you're going to do with it. Viewed as elements of C, or Q[i], yes, rationalize the denominator. > The speed of dispatch and specialization has probably been explored in the > context of compiling Lisp, ad nauseum. Which is one of the reasons it didn't take decades to get to where it is. > 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. Often P isn't happy with language X. Or, in my personal case, P is interested in languages in general (especially so called "goldilocks languages"). > 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... Though I've seen this, that hasn't been my experience in general. > But have fun, anyway. Oh, we will :). - Robert -- 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.
