I think I know how I will solve the Julia package issue for Nemo.
I will definitely make Nemo a standard Julia package. People who want to
just do Pkg.add("Nemo") from within Julia will be able to do so. If you
have Julia on your machine that should be all that is necessary. It'll
automatically check out flint for you and install it. This sort of thing
happens with a lot of Julia packages, as many of them depend on external
native libraries.
For people who want algebraic semantics for the operators and possibly
bignum parsing as default (if it turns out to be workable), there will be
an additional AlgebraicBase module which people will be able to download
and install in bare module mode.
I think this should keep everyone happy.
On Friday, 22 August 2014 19:38:01 UTC+2, Bill Hart wrote:
>
> One interesting thing I should mention is that loading Julia in bare
> module mode and redefining all the basic operators and so on does not break
> all of Julia's libraries. They all continue to operate as normal.
>
> This was quite a surprise to me when I first found out, but all those
> modules have to import Base themselves, and so as far as they are
> concerned, everything operates just as it would in normal Julia.
>
> The operators don't get redefined for everybody when those modules import
> Base, but they just get locally redefined for the modules that use them.
>
> Maybe that's also the same with Python. I guess it must be. But it costs
> nothing, at least, in Julia.
>
> On Friday, 22 August 2014 19:17:29 UTC+2, Bill Hart wrote:
>>
>>
>>
>> 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.
