Re: [sage-devel] Re: On scientific computing, Python and Julia
> In my code I actually have
>
> myfun{T <: Ring}(a::Poly{T}, b::Poly{T})
>
> a lot. Is there a shorthand for this?
I don't think so. According to
https://github.com/JuliaLang/julia/issues/6984, it may be possible to
have the following in the future:
myfun{P<:Poly{<:Ring}}(a::P, b::P)
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Thursday, 28 August 2014 18:13:10 UTC+2, R. Fourquet wrote:
>
> > or to constrain argument types, e.g.
> > myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the
> same type
> which is better expressed as :
>
> myfun{P<:Poly}(a::P, b::P) = a+b
>
Thanks. I've figured this one out since.
In my code I actually have
myfun{T <: Ring}(a::Poly{T}, b::Poly{T})
a lot. Is there a shorthand for this?
>
> So a better example:
>
> myfun{T}(a::Poly{T}, b::Monomial{T}) = ...
>
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Thursday, 28 August 2014 16:48:31 UTC+2, R. Fourquet wrote:
>
> > Sorry, I had some errors in this next bit.
>
> >> myfun(a :: Union(EuclideanPoly, Poly))
>
> > It should have been
> > myfun{T <: Union(EuclideanPoly, Poly)}(a :: T)
>
> The first version is perfectly ok and more idiomatic in this case. You
> said earlier:
>
> > So typically function signatures will look like
> > fnname{T <: Z}(a :: T)
> > where we have:
> > a is a value
> > T is a type
> > Z is a typeclass
>
> Function signatures typically look like this only when T (a type
> variable) is used in the function definition, e.g.
> myfun{T}(::Poly{T}) = T
>
> or to constrain argument types, e.g.
> myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the same
> type
>
> or to constrain the type variable, e.g.
> myfun{T<:Field}(a::Poly{T}) = 1/coeff(a)[1] # method of myfun working
> only with Polys over fields (and "myfun(a::Poly{<:Field})" is
> envisioned)
>
> Otherwise, "fname(a :: Z)" is the way, even if Z is abstract
> (typeclass). And even then, the concrete type of "a" can be referred
> to via "typeof(a)". And fname will be compiled separately for each
> concrete type it is called on.
>
Thanks very much for pointing that out. I was not aware of this trick!
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
> or to constrain argument types, e.g.
> myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the same
> type
which is better expressed as :
myfun{P<:Poly}(a::P, b::P) = a+b
So a better example:
myfun{T}(a::Poly{T}, b::Monomial{T}) = ...
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
> Sorry, I had some errors in this next bit.
>> myfun(a :: Union(EuclideanPoly, Poly))
> It should have been
> myfun{T <: Union(EuclideanPoly, Poly)}(a :: T)
The first version is perfectly ok and more idiomatic in this case. You
said earlier:
> So typically function signatures will look like
> fnname{T <: Z}(a :: T)
> where we have:
> a is a value
> T is a type
> Z is a typeclass
Function signatures typically look like this only when T (a type
variable) is used in the function definition, e.g.
myfun{T}(::Poly{T}) = T
or to constrain argument types, e.g.
myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the same type
or to constrain the type variable, e.g.
myfun{T<:Field}(a::Poly{T}) = 1/coeff(a)[1] # method of myfun working
only with Polys over fields (and "myfun(a::Poly{<:Field})" is
envisioned)
Otherwise, "fname(a :: Z)" is the way, even if Z is abstract
(typeclass). And even then, the concrete type of "a" can be referred
to via "typeof(a)". And fname will be compiled separately for each
concrete type it is called on.
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
Oh how very silly of me. As soon as I pressed enter I figured out the right
way to do this.
abstract Ring
abstract EuclideanDomain <: Ring
abstract Field <: EuclideanDomain
type Poly{T <: Ring} <: Ring
end
type ZZ <: EuclideanDomain
end
type QQ <: Field
end
PolynomialRing{T <: Ring}(::Type{T}) = Poly{T}
function PolynomialRing{T <: Field}(::Type{T})
R = Poly{T}
R.super = EuclideanDomain
return R
end
So with those definitions, here is the result:
julia> R = PolynomialRing(ZZ)
Poly{ZZ} (constructor with 1 method)
julia> R <: EuclideanDomain
false
julia> S = PolynomialRing(QQ)
Poly{QQ} (constructor with 1 method)
julia> S <: EuclideanDomain
true
julia> ZZ <: EuclideanDomain
true
julia> QQ <: EuclideanDomain
true
julia> type Robert <: EuclideanDomain
end
julia> Robert <: EuclideanDomain
true
This is so elegant I can actually use it in Nemo. Great!
Bill.
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Tuesday, 26 August 2014 02:55:25 UTC+2, Robert Bradshaw wrote:
>
> On Mon, Aug 25, 2014 at 5:19 PM, Bill Hart > wrote:
> >
> >
> > On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
> >>
> >> On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart
> >> wrote:
> >>
> >> >> > Correct. But classes are essentially objects in Python because
> >> >> > everything is
> >> >> > an object, pretty much. This really muddies the water. Better to
> >> >> > think
> >> >> > of
> >> >> > classes and objects as being separate concepts.
> >> >>
> >> >> I, for one, find it very convenient (especially compared to using
> >> >> reflection and other hacks that are needed to reason about type at
> >> >> runtime in C++ or Java). Not that some languages aren't even better.
> >> >>
> >> >> > Also better to think of ZZ as a class in Sage and elements of ZZ
> as
> >> >> > objects,
> >> >> > even though actually ZZ happens to be an object too because
> Python.
> >> >>
> >> >> No. ZZ is an object because you might want to do things with it,
> like
> >> >> ask for it's properties (is it infinite?)
> >> >
> >> > Sorry if I have that wrong. But when I type ZZ?? into Sage, it pulls
> up
> >> > the
> >> > definition of a class.
> >>
> >> If a is an instance of class A, typing a?? will give you the definition
> of
> >> A.
> >
> > Ah thanks for pointing that out. I now see that 1 is an object of class
> > Integer, whereas ZZ is an object of class Integer_ring.
> >
> > So where I spoke of ZZ in Sage, please substitute Integer.
>
> Well, some of the places you wrote ZZ at least, as you interchange the
> two concepts quite a bit. That explains at least why you sounded so
> confused.
>
I wasn't really confused. Sage makes the distinction between the
mathematical domain, the type and the values.
I distinguish only types and values.
Sage is not wrong, it's just a bit overcomplicated. And it would be naive
to think it can push the carpet down at all the edges.
> >> I think so; the Euclidean property doesn't place any constraint on the
> >> morphisms.
> >
> >
> > I should have asked whether Fields were. Some references say yes, some
> no.
> >
> > It's also really funny that if you look up Category of Euclidean Domains
> on
> > the intertubes you get two types of pages in general. The first is Wiki
> > articles that use the words category and subcategory in the common
> speech
> > sense, not in the mathematical sense. Then there is the Sage
> documentation,
> > which speaks of the Category of Euclidean Domains.
> >
> > As a concept, it just isn't that useful to category theorists
> (apparently; I
> > wouldn't know, I'm not a category theorist).
> >
> > My point is really that having a typeclass hierarchy that revolves
> around
> > category theory isn't necessarily useful.
> >
> > Euclidean rings (and more specifically Euclidean domains) are a
> difficult
> > concept to model in a type hierarchy, because it is not that easy to
> tell
> > when a ring is a Euclidean ring, and if so, what the Euclidean function
> is
> > on that ring.
> >
> > Also, the Euclidean function may only be used implicitly in any
> algorithms
> > used to compute a gcd. So the Euclidean function is not that useful. And
> > there may be more than one Euclidean structure on a ring, e.g. Z/nZ for
> n
> > composite.
> >
> > The upshot of this is that whether or not a ring has a Euclidean
> function
> > defined on it is probably not something you want to represent in an
> > "interface". Thus, it is not that useful a concept when defining a
> typeclass
> > or interface for types to belong to.
> >
> > You could make your interface depend on whether there is a gcd function.
> But
> > such a function could just return an ideal, for example in a Dedekind
> domain
> > (Sage even does this; inconsistently). So whether there is a gcd
> function is
> > neither here nor there.
> >
> > So I would argue right from the outset that EuclideanDomain is neither a
> > useful concept category theory-wise, nor computationally.
> >
> > Note that there is no EuclideanDomain typeclass currently in Nemo (I
> know I
> > did provide it in my big long list of typeclasses that could be added).
> >
> >>
> >> I am still curious how you would express that
> >> UnivariatePolynomialRing{QQ} <: EuclideanDomans but the same doesn't
> >> hold for UnivariatePolynomialRing{ZZ} in Julia.
> >
> >
> > You wouldn't do this. But suppose you would.
> >
> > You might have:
> >
> > abstract Ring
> > abstract EuclideanDomain <: Ring
> >
> > type Poly{T <: Ring} <: Ring
> > # blah blah
> > end
> >
> > type EuclideanPoly{T <: Field} <: EuclideanDomain
> ># more blah blah
> > end
> >
> > The type construction function PolynomialRing can then be written such
> >
> > PolynomialRing{T <: Ring}(::Type{T}, S::string) # this is the generic
> > function which gets called if T is a ring but no
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Mon, Aug 25, 2014 at 5:19 PM, Bill Hart wrote:
>
>
> On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
>>
>> On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart
>> wrote:
>>
>> >> > Correct. But classes are essentially objects in Python because
>> >> > everything is
>> >> > an object, pretty much. This really muddies the water. Better to
>> >> > think
>> >> > of
>> >> > classes and objects as being separate concepts.
>> >>
>> >> I, for one, find it very convenient (especially compared to using
>> >> reflection and other hacks that are needed to reason about type at
>> >> runtime in C++ or Java). Not that some languages aren't even better.
>> >>
>> >> > Also better to think of ZZ as a class in Sage and elements of ZZ as
>> >> > objects,
>> >> > even though actually ZZ happens to be an object too because Python.
>> >>
>> >> No. ZZ is an object because you might want to do things with it, like
>> >> ask for it's properties (is it infinite?)
>> >
>> > Sorry if I have that wrong. But when I type ZZ?? into Sage, it pulls up
>> > the
>> > definition of a class.
>>
>> If a is an instance of class A, typing a?? will give you the definition of
>> A.
>
> Ah thanks for pointing that out. I now see that 1 is an object of class
> Integer, whereas ZZ is an object of class Integer_ring.
>
> So where I spoke of ZZ in Sage, please substitute Integer.
Well, some of the places you wrote ZZ at least, as you interchange the
two concepts quite a bit. That explains at least why you sounded so
confused.
>> I think so; the Euclidean property doesn't place any constraint on the
>> morphisms.
>
>
> I should have asked whether Fields were. Some references say yes, some no.
>
> It's also really funny that if you look up Category of Euclidean Domains on
> the intertubes you get two types of pages in general. The first is Wiki
> articles that use the words category and subcategory in the common speech
> sense, not in the mathematical sense. Then there is the Sage documentation,
> which speaks of the Category of Euclidean Domains.
>
> As a concept, it just isn't that useful to category theorists (apparently; I
> wouldn't know, I'm not a category theorist).
>
> My point is really that having a typeclass hierarchy that revolves around
> category theory isn't necessarily useful.
>
> Euclidean rings (and more specifically Euclidean domains) are a difficult
> concept to model in a type hierarchy, because it is not that easy to tell
> when a ring is a Euclidean ring, and if so, what the Euclidean function is
> on that ring.
>
> Also, the Euclidean function may only be used implicitly in any algorithms
> used to compute a gcd. So the Euclidean function is not that useful. And
> there may be more than one Euclidean structure on a ring, e.g. Z/nZ for n
> composite.
>
> The upshot of this is that whether or not a ring has a Euclidean function
> defined on it is probably not something you want to represent in an
> "interface". Thus, it is not that useful a concept when defining a typeclass
> or interface for types to belong to.
>
> You could make your interface depend on whether there is a gcd function. But
> such a function could just return an ideal, for example in a Dedekind domain
> (Sage even does this; inconsistently). So whether there is a gcd function is
> neither here nor there.
>
> So I would argue right from the outset that EuclideanDomain is neither a
> useful concept category theory-wise, nor computationally.
>
> Note that there is no EuclideanDomain typeclass currently in Nemo (I know I
> did provide it in my big long list of typeclasses that could be added).
>
>>
>> I am still curious how you would express that
>> UnivariatePolynomialRing{QQ} <: EuclideanDomans but the same doesn't
>> hold for UnivariatePolynomialRing{ZZ} in Julia.
>
>
> You wouldn't do this. But suppose you would.
>
> You might have:
>
> abstract Ring
> abstract EuclideanDomain <: Ring
>
> type Poly{T <: Ring} <: Ring
> # blah blah
> end
>
> type EuclideanPoly{T <: Field} <: EuclideanDomain
># more blah blah
> end
>
> The type construction function PolynomialRing can then be written such
>
> PolynomialRing{T <: Ring}(::Type{T}, S::string) # this is the generic
> function which gets called if T is a ring but not a field
># return a Poly
> end
>
> PolynomialRing{T <: Field}(::Type{T}, S::string) # this function specialises
> the previous one, when T happens to be a field
># return a EuclideanPoly
> end
>
> There are various ways you could handle functions that take either an
> EuclideanPoly or a Poly. For example
>
> myfun(a :: Union(EuclideanPoly, Poly))
>
> or
>
> typealias AnyPoly Union(EuclideanPoly, Poly)
>
> myfun(a :: AnyPoly)
>
> And there are various ways you could handle functions that take elements of
> a EuclideanDomain or a general Ring. E.g.
>
> myfun{T <: EuclideanDomain}(a :: T)
>
> myfun{T <: Ring}(a :: T)
>
> But I don't think there is any compelling reason to go to all of this
> trouble. A much better and cleaner way is
Re: [sage-devel] Re: On scientific computing, Python and Julia
Stoopid google.
On Tuesday, 26 August 2014 02:48:11 UTC+2, Bill Hart wrote:
>
> I am still curious how you would express that
UnivariatePolynomialRing{QQ} <: EuclideanDomans but the same doesn't
hold for UnivariatePolynomialRing{ZZ} in Julia.
>>>
>>>
So it doesn't get lost in all that noise. Here is an actual Julia session
expressing this:
julia> abstract Ring
julia> type ZZ <: Ring
end
julia> type Poly{T <: Ring} <: Ring
#blah
end
julia> abstract Field <: Ring
julia> type QQ <: Field
end
julia> typealias EuclideanDomain{T <: Field} Union(Field, Poly{T}, ZZ)
Union(Poly{T<:Field},Field,ZZ)
With all that defined, here is what Julia replies in response to various
questions about this:
julia> Field <: EuclideanDomain
true
julia> Ring <: EuclideanDomain
false
julia> ZZ <: EuclideanDomain
true
julia> QQ <: EuclideanDomain
true
julia> Poly{ZZ} <: EuclideanDomain
false
julia> Poly{QQ} <: EuclideanDomain
true
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
>
> I am still curious how you would express that
>>> UnivariatePolynomialRing{QQ} <: EuclideanDomans but the same doesn't
>>> hold for UnivariatePolynomialRing{ZZ} in Julia.
>>
>>
So it doesn't get lost in all that noise. Here is an actual Julia session
expressing this:
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Tuesday, 26 August 2014 02:19:25 UTC+2, Bill Hart wrote: > > > > On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote: >> >> On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart >> wrote: >> >> >> > Correct. But classes are essentially objects in Python because >> >> > everything is >> >> > an object, pretty much. This really muddies the water. Better to >> think >> >> > of >> >> > classes and objects as being separate concepts. >> >> >> >> I, for one, find it very convenient (especially compared to using >> >> reflection and other hacks that are needed to reason about type at >> >> runtime in C++ or Java). Not that some languages aren't even better. >> >> >> >> > Also better to think of ZZ as a class in Sage and elements of ZZ as >> >> > objects, >> >> > even though actually ZZ happens to be an object too because Python. >> >> >> >> No. ZZ is an object because you might want to do things with it, like >> >> ask for it's properties (is it infinite?) >> > >> > Sorry if I have that wrong. But when I type ZZ?? into Sage, it pulls up >> the >> > definition of a class. >> >> If a is an instance of class A, typing a?? will give you the definition >> of A. >> > > Ah thanks for pointing that out. I now see that 1 is an object of class > Integer, whereas ZZ is an object of class Integer_ring. > > So where I spoke of ZZ in Sage, please substitute Integer. > > (Except that I was using that as an argument for using ZZ as a name for my > bignum integer type in Julia; which argument you have now destroyed. I > would have liked to use Integer though. But it was already taken.) > > >> >> > Anyway, it's irrelevant because Python. >> > >> > In Julia types are also able to be passed around as first class >> objects. >> > Which means you can define multimethods which take types as parameters. >> I do >> > this all the time in Nemo. >> > >> > So I can send a type to a function which gives me some properties of >> the >> > type, if I so wish. I thought about adding properties like is_infinite >> to >> > types in Nemo. But I found that I had been thinking the wrong way about >> > things all along. >> >> Good, because I was worried there for a minute you were praising Julia >> for not treating types as first class objects. >> > > Nah. But I don't have anything against not making types first class > objects. So long as their constructors are. > > It also depends somewhat on your definition of first class. > > >> >> >> or use it as a parameter >> >> (e.g. the domain of a Map object). Sometimes the Objects (in the >> >> categorical sense) are more interesting than their elements. >> > >> > If you are a category theorist yes. Most mathematicians think >> categories are >> > just sets. >> > >> >> >> >> If your Objects are parameterized types, >> >> >> >> I'm curious how you handle in >> >> Julia the fact that R[x] is a Euclidean domain iff R is a field. >> > >> > I'm curious, is the category of Euclidean domains a full subcategory of >> > Rings? >> >> I think so; the Euclidean property doesn't place any constraint on the >> morphisms. >> > > I should have asked whether Fields were. Some references say yes, some no. > > It's also really funny that if you look up Category of Euclidean Domains > on the intertubes you get two types of pages in general. The first is Wiki > articles that use the words category and subcategory in the common speech > sense, not in the mathematical sense. Then there is the Sage documentation, > which speaks of the Category of Euclidean Domains. > > As a concept, it just isn't that useful to category theorists (apparently; > I wouldn't know, I'm not a category theorist). > > My point is really that having a typeclass hierarchy that revolves around > category theory isn't necessarily useful. > > Euclidean rings (and more specifically Euclidean domains) are a difficult > concept to model in a type hierarchy, because it is not that easy to tell > when a ring is a Euclidean ring, and if so, what the Euclidean function is > on that ring. > > Also, the Euclidean function may only be used implicitly in any algorithms > used to compute a gcd. So the Euclidean function is not that useful. And > there may be more than one Euclidean structure on a ring, e.g. Z/nZ for n > composite. > > The upshot of this is that whether or not a ring has a Euclidean function > defined on it is probably not something you want to represent in an > "interface". Thus, it is not that useful a concept when defining a > typeclass or interface for types to belong to. > > You could make your interface depend on whether there is a gcd function. > But such a function could just return an ideal, for example in a Dedekind > domain (Sage even does this; inconsistently). So whether there is a gcd > function is neither here nor there. > > So I would argue right from the outset that EuclideanDomain is neither a > useful concept category theory-wise, nor computati
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
>
> On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart > wrote:
>
> >> > Correct. But classes are essentially objects in Python because
> >> > everything is
> >> > an object, pretty much. This really muddies the water. Better to
> think
> >> > of
> >> > classes and objects as being separate concepts.
> >>
> >> I, for one, find it very convenient (especially compared to using
> >> reflection and other hacks that are needed to reason about type at
> >> runtime in C++ or Java). Not that some languages aren't even better.
> >>
> >> > Also better to think of ZZ as a class in Sage and elements of ZZ as
> >> > objects,
> >> > even though actually ZZ happens to be an object too because Python.
> >>
> >> No. ZZ is an object because you might want to do things with it, like
> >> ask for it's properties (is it infinite?)
> >
> > Sorry if I have that wrong. But when I type ZZ?? into Sage, it pulls up
> the
> > definition of a class.
>
> If a is an instance of class A, typing a?? will give you the definition of
> A.
>
Ah thanks for pointing that out. I now see that 1 is an object of class
Integer, whereas ZZ is an object of class Integer_ring.
So where I spoke of ZZ in Sage, please substitute Integer.
(Except that I was using that as an argument for using ZZ as a name for my
bignum integer type in Julia; which argument you have now destroyed. I
would have liked to use Integer though. But it was already taken.)
>
> > Anyway, it's irrelevant because Python.
> >
> > In Julia types are also able to be passed around as first class objects.
> > Which means you can define multimethods which take types as parameters.
> I do
> > this all the time in Nemo.
> >
> > So I can send a type to a function which gives me some properties of the
> > type, if I so wish. I thought about adding properties like is_infinite
> to
> > types in Nemo. But I found that I had been thinking the wrong way about
> > things all along.
>
> Good, because I was worried there for a minute you were praising Julia
> for not treating types as first class objects.
>
Nah. But I don't have anything against not making types first class
objects. So long as their constructors are.
It also depends somewhat on your definition of first class.
>
> >> or use it as a parameter
> >> (e.g. the domain of a Map object). Sometimes the Objects (in the
> >> categorical sense) are more interesting than their elements.
> >
> > If you are a category theorist yes. Most mathematicians think categories
> are
> > just sets.
> >
> >>
> >> If your Objects are parameterized types,
> >>
> >> I'm curious how you handle in
> >> Julia the fact that R[x] is a Euclidean domain iff R is a field.
> >
> > I'm curious, is the category of Euclidean domains a full subcategory of
> > Rings?
>
> I think so; the Euclidean property doesn't place any constraint on the
> morphisms.
>
I should have asked whether Fields were. Some references say yes, some no.
It's also really funny that if you look up Category of Euclidean Domains on
the intertubes you get two types of pages in general. The first is Wiki
articles that use the words category and subcategory in the common speech
sense, not in the mathematical sense. Then there is the Sage documentation,
which speaks of the Category of Euclidean Domains.
As a concept, it just isn't that useful to category theorists (apparently;
I wouldn't know, I'm not a category theorist).
My point is really that having a typeclass hierarchy that revolves around
category theory isn't necessarily useful.
Euclidean rings (and more specifically Euclidean domains) are a difficult
concept to model in a type hierarchy, because it is not that easy to tell
when a ring is a Euclidean ring, and if so, what the Euclidean function is
on that ring.
Also, the Euclidean function may only be used implicitly in any algorithms
used to compute a gcd. So the Euclidean function is not that useful. And
there may be more than one Euclidean structure on a ring, e.g. Z/nZ for n
composite.
The upshot of this is that whether or not a ring has a Euclidean function
defined on it is probably not something you want to represent in an
"interface". Thus, it is not that useful a concept when defining a
typeclass or interface for types to belong to.
You could make your interface depend on whether there is a gcd function.
But such a function could just return an ideal, for example in a Dedekind
domain (Sage even does this; inconsistently). So whether there is a gcd
function is neither here nor there.
So I would argue right from the outset that EuclideanDomain is neither a
useful concept category theory-wise, nor computationally.
Note that there is no EuclideanDomain typeclass currently in Nemo (I know I
did provide it in my big long list of typeclasses that could be added).
> I am still curious how you would express that
> UnivariatePolynomialRing{QQ
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart wrote:
>> > Correct. But classes are essentially objects in Python because
>> > everything is
>> > an object, pretty much. This really muddies the water. Better to think
>> > of
>> > classes and objects as being separate concepts.
>>
>> I, for one, find it very convenient (especially compared to using
>> reflection and other hacks that are needed to reason about type at
>> runtime in C++ or Java). Not that some languages aren't even better.
>>
>> > Also better to think of ZZ as a class in Sage and elements of ZZ as
>> > objects,
>> > even though actually ZZ happens to be an object too because Python.
>>
>> No. ZZ is an object because you might want to do things with it, like
>> ask for it's properties (is it infinite?)
>
> Sorry if I have that wrong. But when I type ZZ?? into Sage, it pulls up the
> definition of a class.
If a is an instance of class A, typing a?? will give you the definition of A.
> Anyway, it's irrelevant because Python.
>
> In Julia types are also able to be passed around as first class objects.
> Which means you can define multimethods which take types as parameters. I do
> this all the time in Nemo.
>
> So I can send a type to a function which gives me some properties of the
> type, if I so wish. I thought about adding properties like is_infinite to
> types in Nemo. But I found that I had been thinking the wrong way about
> things all along.
Good, because I was worried there for a minute you were praising Julia
for not treating types as first class objects.
>> or use it as a parameter
>> (e.g. the domain of a Map object). Sometimes the Objects (in the
>> categorical sense) are more interesting than their elements.
>
> If you are a category theorist yes. Most mathematicians think categories are
> just sets.
>
>>
>> If your Objects are parameterized types,
>>
>> I'm curious how you handle in
>> Julia the fact that R[x] is a Euclidean domain iff R is a field.
>
> I'm curious, is the category of Euclidean domains a full subcategory of
> Rings?
I think so; the Euclidean property doesn't place any constraint on the
morphisms.
I am still curious how you would express that
UnivariatePolynomialRing{QQ} <: EuclideanDomans but the same doesn't
hold for UnivariatePolynomialRing{ZZ} in Julia.
>> (As
>> you mention, trying to use the type hierarchy in Python to model
>> categorical relationships in Sage has generally lead to pain which is
>> why we're moving away from that...)
>
> Oh I can't think why.
I buy that the type system is more powerful in Julia (yay), but I'm
still skeptical that it is the best way to express the relationship
between objects and categories, and at the same time elements and
objects, and attach useful information to those categories and
objects.
- Robert
--
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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
Le 25/08/2014 23:26, Bill Hart a écrit : You want to be able to inherit fields, but that highlights the difference between Julia and the traditional OOP perspective. In the traditional perspective the focus is on the data. In the Julia paradigm, the focus is on the behaviour, i.e. the functions. In the Eiffel language, when you define a class foo with a "member variable" bar, the api just says that bar has such-type -- only the class writer knows if it's a constant or a function returning the value after a computation. Is that the same principle? Snark on #sagemath PS: it's off topic on that list, but I'm still glad following the discussion. -- 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.
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Monday, 25 August 2014 20:14:01 UTC+2, Robert Bradshaw wrote: > > On Mon, Aug 25, 2014 at 6:02 AM, Bill Hart > wrote: > > Hmm. Some more explaining is necessary. > > > > > > On Monday, 25 August 2014 12:04:16 UTC+2, Pierre wrote: > >> > >> Thanks again for the explanations. I realize that there were many > things > >> about Julia/Nemo which I had misunderstood. Let me explain a little, so > I > >> can (i) embarrass myself a little more, and (ii) perhaps give an > indication > >> of common mistakes, for anyone who would write a tutorial about > Julia/Nemo > >> :-) > >> > >> Mistake (1): taking it for OOP. > > > > > > Julia is OOP! > > > > There are two ways to do OOP. The first is with classes and usually > single > > dispatch and the other is with multi-methods. The latter is the Julia > way > > and it is more flexible. > > > > There is a dual notion for data structures as well, and Julia supports > that > > too, giving even greater flexibility. The combination of the two is more > > powerful than standard OOP, which can be very restrictive in practice. > > > >> > >> When hearing about the way Julia worked, I jumped when I saw it wasn't > OO, > >> and then naturally was looking for ways to emulate OOP with Julia > (rather > >> than make the effort of a paradigm shift). And with multi-dispatch, i > >> thought OK, if I want to write code that applies to objects of type A, > B and > >> C at once, just declare them A <: X, B <: X and C <: X and define f(x > :: X). > >> However this gave me the wrong intuition " A <: X is the same as A > inherits > >> from X". > > > > > > None of that makes sense. > > > > f(x :: X) is the way you write a function prototype in Julia. It > corresponds > > to the following prototype in C. > > > > void f(X x); > > > > X is just a type, like int or float or double or MyType, etc. In Julia, > you > > just write the type on the right, after a double colon, instead of on > the > > left like C. > > > > A <: X does not mean A is an object of type X. It means A is a subtype > of X, > > where both A and X are types (one or both may be abstract types). > > > > The way to write "A is an object of type X" is A :: X. > > > > The way to write "X is a subtype of Y" is X <: Y. > > > > But remember that subtype here *may* mean X is in the typeclass Y. > > > >> > >> At this point, the fact that abstract types could be instantiated was > seen > >> as a limitation compared to OOP. > > > > > > No. There is no similar concept in OOP, except for languages like scala > > which have traits/interfaces/typeclasses. It's an extension over and > above > > what is found in standard OOP languages. > > > > You can also write all your Julia programs without any <: symbols if you > > want. And in fact you can leave all types out too and let Julia figure > them > > out. > > > > Types and subtyping simply allows you to restrict what is allowed. > Otherwise > > everything is allowed, just like Python. > > > >> > >> And somehow, it is. > > > > > > No it is not. You never need to use the <: notation in Julia if you > don't > > want to. You can just stick to values (objects) and types (classes) if > you > > want. Then you have the same thing as standard OOP. You can even > restrict > > yourself to single dispatch if you want, in which case you have OOP > exactly. > > But there's no reason to restrict yourself in this way, because Julia > offers > > all the other goodies on top of that. > > > >> > >> Except at the same time, the type system does many new things. Apples > and > >> oranges, really. > >> > >> Mistake (2): taking types for sets. > > > > > > They sort of are. Formally a type is just a set of values. Well, not in > a > > mathematical sense. But in some intuitive sense. > > > > Types of course satisfy some calculus just as sets do and the rules of > the > > calculus are somewhat similar, but not quite the same. Technically > dependent > > types correspond exactly to predicates in the predicate logic, via Type > > theory (an extension of the Curry-Howard isomorphism). But that's all a > bit > > complicated, so we informally think of types as sets. > > > > One big difference is there are plenty of non-computable functions > between > > sets. But the functions between types are always computable. But again, > it's > > not even vaguely necessary to understand this to get the concept of a > type. > > It's intuitively just a name given to the collection of all values which > an > > object of that type can have. > > > >> This little discussion about names reveals another mistake of mine: > >> thinking of types as sets. I thought ZZ <: QQ for example. > > > > > > Yeah, the <: notation doesn't mean contained in. It's not a mathematical > > operator. It means "subtype of". There are three things the notation can > > mean: > > > > 1) If A <: B where A and B are types, then
Re: [sage-devel] Re: On scientific computing, Python and Julia
On Mon, Aug 25, 2014 at 6:02 AM, Bill Hart wrote: > Hmm. Some more explaining is necessary. > > > On Monday, 25 August 2014 12:04:16 UTC+2, Pierre wrote: >> >> Thanks again for the explanations. I realize that there were many things >> about Julia/Nemo which I had misunderstood. Let me explain a little, so I >> can (i) embarrass myself a little more, and (ii) perhaps give an indication >> of common mistakes, for anyone who would write a tutorial about Julia/Nemo >> :-) >> >> Mistake (1): taking it for OOP. > > > Julia is OOP! > > There are two ways to do OOP. The first is with classes and usually single > dispatch and the other is with multi-methods. The latter is the Julia way > and it is more flexible. > > There is a dual notion for data structures as well, and Julia supports that > too, giving even greater flexibility. The combination of the two is more > powerful than standard OOP, which can be very restrictive in practice. > >> >> When hearing about the way Julia worked, I jumped when I saw it wasn't OO, >> and then naturally was looking for ways to emulate OOP with Julia (rather >> than make the effort of a paradigm shift). And with multi-dispatch, i >> thought OK, if I want to write code that applies to objects of type A, B and >> C at once, just declare them A <: X, B <: X and C <: X and define f(x :: X). >> However this gave me the wrong intuition " A <: X is the same as A inherits >> from X". > > > None of that makes sense. > > f(x :: X) is the way you write a function prototype in Julia. It corresponds > to the following prototype in C. > > void f(X x); > > X is just a type, like int or float or double or MyType, etc. In Julia, you > just write the type on the right, after a double colon, instead of on the > left like C. > > A <: X does not mean A is an object of type X. It means A is a subtype of X, > where both A and X are types (one or both may be abstract types). > > The way to write "A is an object of type X" is A :: X. > > The way to write "X is a subtype of Y" is X <: Y. > > But remember that subtype here *may* mean X is in the typeclass Y. > >> >> At this point, the fact that abstract types could be instantiated was seen >> as a limitation compared to OOP. > > > No. There is no similar concept in OOP, except for languages like scala > which have traits/interfaces/typeclasses. It's an extension over and above > what is found in standard OOP languages. > > You can also write all your Julia programs without any <: symbols if you > want. And in fact you can leave all types out too and let Julia figure them > out. > > Types and subtyping simply allows you to restrict what is allowed. Otherwise > everything is allowed, just like Python. > >> >> And somehow, it is. > > > No it is not. You never need to use the <: notation in Julia if you don't > want to. You can just stick to values (objects) and types (classes) if you > want. Then you have the same thing as standard OOP. You can even restrict > yourself to single dispatch if you want, in which case you have OOP exactly. > But there's no reason to restrict yourself in this way, because Julia offers > all the other goodies on top of that. > >> >> Except at the same time, the type system does many new things. Apples and >> oranges, really. >> >> Mistake (2): taking types for sets. > > > They sort of are. Formally a type is just a set of values. Well, not in a > mathematical sense. But in some intuitive sense. > > Types of course satisfy some calculus just as sets do and the rules of the > calculus are somewhat similar, but not quite the same. Technically dependent > types correspond exactly to predicates in the predicate logic, via Type > theory (an extension of the Curry-Howard isomorphism). But that's all a bit > complicated, so we informally think of types as sets. > > One big difference is there are plenty of non-computable functions between > sets. But the functions between types are always computable. But again, it's > not even vaguely necessary to understand this to get the concept of a type. > It's intuitively just a name given to the collection of all values which an > object of that type can have. > >> This little discussion about names reveals another mistake of mine: >> thinking of types as sets. I thought ZZ <: QQ for example. > > > Yeah, the <: notation doesn't mean contained in. It's not a mathematical > operator. It means "subtype of". There are three things the notation can > mean: > > 1) If A <: B where A and B are types, then it means that if a function can > take an argument of type B, then an argument of type A will work just as > well in its place. In some sense, the set of values of type A is a > restriction of the set of values of type B. This is pretty close to a subset > meaning though technically it has more to do with the representation in bits > on the machine than anything mathematical. > > 2) If A <: B where A is a type and B is an abstract > type/typeclass/interface/trait, it means that a function which requires a
