On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
>
> On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart <goodwi...@googlemail.com
> <javascript:>> 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} <: 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 the following.
abstract Ring
type Poly{T <: Ring} <: Ring
# blah blah
end
abstract GCDDomain <: Ring
abstract Field <: GCDDomain # it's questionable whether you really want to
do this instead of Field <: Ring, but that's another story
typealias EuclideanDomain{T <: Field} Union(GCDDomain, Poly{T})
function myfun{T <: EuclideanDomain}(a :: T)
# blah
end
This lot all compiles by the way. And you can check it really works:
First define a type which belongs to Field:
type Bill <: Field
end
julia> myfun(Bill())
julia> myfun(Poly{Bill}())
No complaints.
Now define a type which is not a field, but just a ring:
type Fred <: Ring
end
And then:
julia> myfun(Poly{Fred}())
ERROR: `myfun` has no method matching myfun(::Poly{Fred})
julia> myfun(Fred())
ERROR: `myfun` has no method matching myfun(::Fred)
However, in all of the above, you see that I never actually used GCDDomain
at all. So it can really be removed if so desired. It's likely you defined
a gcd function for some clean set of rings in the first place, which can
all be delineated nicely without having some special typeclass for it.
And then, in reality, EuclideanDomain is just a union of various types,
just as the particular rings you can define a gcd function for is an
eclectic mix, with no particular rhyme or reason to it.
> >> (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.
>
That was kind of the point of my earlier post. There is no such best way.
Categories don't match any concept in computer science (well, that is not
strictly true, but that's a long diversion into n-categories and homotopy
types). Usually we can't push the carpet down around all the corners of the
room, but we can get it sufficiently flat locally.
Bill.
> - 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.
