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 <goodwi...@googlemail.com>
>> 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
>
>
Sorry, I had some errors in this next bit.
> myfun(a :: Union(EuclideanPoly, Poly))
>
> or
>
> typealias AnyPoly Union(EuclideanPoly, Poly)
>
> myfun(a :: AnyPoly)
>
>
It should have been
myfun{T <: Union(EuclideanPoly, Poly)}(a :: T)
or
typealias AnyPoly Union(EuclideanPoly, Poly)
myfun{T <: AnyPoly}(a :: T)
I didn't compile this lot to check. It's a silly way to do things. Trying
too hard to be clever.
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.
