Thanks for the examples. However, given that in Julia you can re-define about everything (cf your example with the function extracting elements from a list, replaced by " print 'test' "), surely you could change, say, the behaviour of the function / upon loading the Nemo module? (without mention of a bare-module mode or anything) This in order to make the ordinary machine words behave consistently in comparison with bignums. (There would be the occasional problem when someone has written code speciafically expecting a/b to be a float, but will you ever mix code involving floats with your own ?) This would be the exact reverse of the "from __future__ import division" which you see at the beginning of so many python+numpy scripts.
I don't think the factorization of a = 2*3*5^2*17*71*65537*123456543234565433489*3249861239487619238746032103420132947612384712340813246341 is a good example. You can expect the user to known that this will fail, and wrap things in ZZ. (Do not underestimate the users: there are zillions of casual C programmers out there who realize that "int" is not the same as "double"; understanding the difference between Int64 and ZZ is no harder.) Of course Python or Sage users don't have to worry about that. But isn't Julia about better performance at the cost of specifying types? As for : >It's also a pain in the neck to take output from one system, such as Pari/GP and cut and paste a long polynomial, having to put ZZ(...) around every bignum. It's just not practical. i tend to disagree. A little function parse_PARI(string) or whatever would be easy to write. I also have an unrelated question, still about Nemo. I think in Julia's type system, when A <: B, then the intuition is that elements of type A are also of type B, or am I wrong? Like elements of type Int64 are also of type Integer (or whatever it's called). If so, your supertype of ZZ should not be called Ring, but RingElement. For an element of ZZ is not a ring. Well, abstract types are not types, they are more like type classes, but still with the machine types the logic is as I've said. Pierre -- 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.