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). -- 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.
