On Tuesday, August 19, 2014, Bill Hart <goodwillh...@googlemail.com> 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 > <javascript:_e(%7B%7D,'cvml','sage-devel%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to sage-devel@googlegroups.com > <javascript:_e(%7B%7D,'cvml','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 -- 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.
