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.

Reply via email to