On Wednesday, July 23, 2014 8:22:39 PM UTC-7, Robert Bradshaw wrote: > > On Wed, Jul 23, 2014 at 5:47 PM, rjf <fat...@gmail.com <javascript:>> > 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. >
Certainly Macsyma has been able to add taylor series and polynomials for, oh, 40 years. If it had taylor series over F_q, it would have to make sense of that addition as well. Perhaps Axiom and Fricas have such odd Taylor series objects; they don't seem to be something that comes up much, and I would expect they have some uncomfortable properties. Note that even adding 5 mod 13 and the integer 10 is potentially uncomfortable, and the rather common operation of Hensel lifting requires doing arithmetic in a combination of fields (or rings) of different related sizes. > > >> 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. > That means that 1 is not a polynomial. Adds to some checking, if you assume that a polynomial has a main variable, but 1 does not. As does the representation of zero as a polynomial with no terms, or a polynomial with one term, say 0*x^0. > > > How do you add two bigfloats of different precision? > > Return the result in lower precision. > I would say that is wrong. Macsyma converts both to the globally set precision. There is no reason to believe that a "low precision" representation is inaccurate, and that one can raise the precision by adding (binary) zeros on the right. Or not. > > > Or add a float to an exact rational? > > Coerce to a rational (same rule as above). > That's not the rule used in most programming languages, where the result is returned as a float. Like FORTRAN did, I guess. Any float can be converted to an exact rational, but do you want to do that? Sometimes. That's why it is sticky. > > > 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. > So now you are going to require users to have a background in, what, modern algebra? > > > 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 can't parse this. Are you being sarcastic and saying it took Common Lisp decades to compile object-oriented code? I don't think this is true, generally. But maybe I don't understand. > > > 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.
