Too late. Whatever succeeded Sage already included Sage in it. Anyway, that is a brilliant idea. But you should start now, not when it is too late. And I mean that with all sincerity.
On Wednesday, 20 August 2014 06:19:21 UTC+2, wstein wrote: > > > > On Tuesday, August 19, 2014, Bill Hart wrote: > >> >> >> On Thursday, 31 July 2014 06:11:28 UTC+2, rjf wrote: >>> >>> >>> 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. >>> >>> >> >> Oh what a shame I missed the party. And I don't have time to read all the >> wonderfully eloquent nonsense in this thread. But this above really wasn't >> a good example. >> >> The new flint interpreter, written in Julia, did this in week 1 I think. >> It is not even a coercion from my perspective (I call it ad hoc >> polymorphism): >> >> julia> R = ResidueRing(ZZ, 13) >> Residue ring of ZZ modulo 13 (constructor with 4 methods) >> >> julia> a = R(5) + 10 >> 2 >> >> julia> typeof(a) >> Residue ring of ZZ modulo 13 (constructor with 4 methods) >> >> Now, Nemo (that's the name of the flint interpreter) doesn't handle "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)", for two reasons: >> >> 1) I haven't implemented power series yet (the other objects are there, >> and give me another week on the power series). >> >> 2) I wouldn't implement such a coercion. The problem is that, at best, it >> will create a ring that the user did not define. So I am firmly in the camp >> that believes the user should create the ring they want these added in, >> then convert at least one of the objects to that ring. Then the coercion >> system can take over from there. Whether Nemo will even go that far, I'm >> not sure. It's just a little flint interpreter and it certainly doesn't >> need to be overengineered! (Note to self: the above example is an example >> of overengineering.) >> >> In fact, I wouldn't want that example to even make sense. The variable x >> is a generator of a certain ring, with type information attached to it, and >> shouldn't be used in two different ways. You are effectively redefining x. >> When I type parent(x), what will it tell me? Or does x also get lifted to >> the common ring before I even try to add objects from the two different >> rings? Suddenly the example makes me feel like I don't understand any more >> what Sage is even going to do when I type stuff into it. >> >> Magma does silly things like this. You define a univariate polynomial >> ring over x and another over y. It happily adds the two together, >> forgetting that x is not y, so long as it can coerce the coefficient rings >> to a common ring (or something like that -- it depends how people felt on a >> certain day), which is really not useful when that gives you the wrong >> answer entirely, which it does (I have nontrivial examples where this >> really matters). >> >> Two important things to note: >> >> 1) I did not give a reason "this would be hard to do in Julia". Because >> it wouldn't. It's so trivial as to be embarrassing. And yes it is zero >> cost. No looking up things in hash tables or whatever. Julia can even >> programmatically generate coercions on-the-fly. And I do this already in >> Nemo!! Powerful metaprogramming + dependent and parametric types + >> multimethods + type inference + jit + conversion functions + promotion >> rules + bare metal types + efficient C FFI = something Python can never do >> and will never do. >> >> The proof is in the pudding. Just generic multivariate polynomial >> multiplication is already 3 times faster than Sage. And I didn't even try >> yet. Believe it or not, you can in theory actually resoundingly beat C at >> generic algorithms with Julia. And that is not an empty claim. We are >> already at exactly the same speed as a fast hand written C generic rings >> implementation. And I didn't even try yet! I've literally applied one >> trivial optimisation, which Sage certainly uses. In theory, a language like >> Julia can do *much* better. >> >> 2) I'm not defending Sage here, even though Richard's example was >> completely trivial. Obviously I check the answers from the flint >> interpreter against what comes out of Sage, Magma and Pari. And Sage leaves >> me scratching my head pretty often. Magma errs on the side of not defining >> questionable things at all, or if it does, it gives answers you really >> don't expect, because it loses type information when doing coercion. Sage >> errs on the side of defining the balmy and bizarre. Pari errs on the side >> of not being a serious programming language. >> >> Writing a little interpreter has certainly opened my eyes to >> the vagaries of computer algebra and mathematics in general. I'm a little >> more sympathetic as a whole to the difficulties of writing computer algebra >> systems. And I now see mathematics itself as a patchwork of competing >> definitions and nomenclature and a set of noncompatible axiom systems, >> rather than a unified whole. >> >> But I think Julia is good for a few years yet. It's one of the few truly >> 21st century programming languages available. I don't know if Julia is >> going to be the language to displace Python or not. It has some seriously >> difficult problems to solve ahead of it (fortunately they don't include >> parallel programming, a package manager which works, an IPython interface, >> efficient C, C++ or Python interfaces, an extremely modern syntax or >> language features, a well-fleshed-out standard library, scientific >> computing capabilities, high performance, profiling and timing, disassembly >> features, etc.). I'm sure you can sense from Stefan's posts here that the >> Julia developers are no idiots. A language like Julia has the potential to >> be a game changer for computer algebra. Python doesn't. I've been saying >> that for years, and the reasons haven't changed one bit. You can check my >> git repository and see that for years I've been working on toy programming >> languages based on LLVM, with type inference, parameterised type systems, a >> REPL, Jit, all the things Julia is. I never got around to implementing >> serious metaprogramming, but there are blog and even sage-devel posts going >> back years where I've advocated that. >> >> Computer scientists have a lot more to offer the mathematics community >> than it is currently letting them do. I'm glad for the existence of Sage. >> It's a great community of great people, and a useful tool. It's an >> outstanding accomplishment. But technology is moving at a far faster pace >> than the past. Sage is not keeping up. Not even nearly. It will be >> superceded, and I want to be on record as having said so (again). >> > > > > If so, we'll just include whatever supersedes sage in Sage... > > > -- >> 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. >> > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > wst...@uw.edu <javascript:> > -- 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.
