On Friday, 22 August 2014 14:10:10 UTC+2, Pierre wrote: > > 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. >
You can redefine things that have already been defined, but it sometimes incurs a compiler warning. I will have to look into what can be done. > > 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. > > A <: B either tells you if a type A is of abstract type B or if abstract type A is of abstract type B. So, whether or not you use RingElement or Ring depends on whether you consider an element of ZZ to be a ring element or whether you think the integers ZZ form a ring. With the machine types, we really want a :: T where T <: Integer <: Ring. Again with the baremodule idea, we might be able to do this, but it's not possible if you use the standard provided modules, as far as I can tell. The logic from my point of view is that a type is a collection of values, and as such Integer <: Ring, not Integer <: RingElement. But the distinction is arbitrary. In the case of finite fields, I had an argument with myself about whether I should use FFElem or FField. I decided on the latter. I would have liked to use FiniteField, but this is the name I wanted to give to the function that constructs an FField type (what some people call a factory I think). It's a shame that Julia allows a composite type and constructor to have the same name, but a bitstype and constructor can't have the same name and a factory and composite type cannot have the same name. Similarly a module name and the filename can be the same, but the module name and the main type it defines can't be. Those are all things I would do differently in Julia. And perhaps some of these will change in a future release, who knows. They are minor nuisances at best. And there are probably important reasons for those decisions. For example, if a type and factory could have the same name, there could be issues with overloading the dot operator for both. And that's something a lot of people seem to want Julia to do, so that they can write Python in Julia. Bill. > > 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.
