[sage-devel] "Not a git repository"

[john_perry_usm]

Hello

I'm trying to review a bug. I haven't worked with git before, so I tried 
following the Sage Development Guide. I'm getting stuck on the step where 
I'm supposed to set up git-trac. I seem to have installed it (didn't 
complain, anyway) and then I try to follow the commands 
at 
http://www.sagemath.org/doc/developer/git_trac.html#git-and-trac-configuration. 
I get the output listed below.

Any help would be appreciated.

john perry

git trac config --user john_perry --pass 
'not_in_your_wildest_dreams_would_i_reveal_this'
Traceback (most recent call last):
  File "/Applications/sage/git-trac-command/bin/git-trac", line 18, in 

cmdline.launch()
  File "/Applications/sage/git-trac-command/git_trac/cmdline.py", line 240, 
in launch
app.add_remote()
  File "/Applications/sage/git-trac-command/git_trac/app.py", line 441, in 
add_remote
remotes = self.git.remote().split()
  File "/Applications/sage/git-trac-command/git_trac/git_interface.py", 
line 341, in meth
return self.execute(git_cmd, *args, **kwds)
  File "/Applications/sage/git-trac-command/git_trac/git_interface.py", 
line 328, in execute
popen_stderr=subprocess.PIPE)
  File "/Applications/sage/git-trac-command/git_trac/git_interface.py", 
line 263, in _run
raise GitError(result)
git_trac.git_error.GitError: git returned with non-zero exit code (128) 
when executing "git remote"
STDERR: fatal: Not a git repository (or any of the parent directories): 
.git

-- 
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: About docs (and code) of poset

[Travis Scrimshaw]

Hey Jori,

>
> OK. I have used to using html docs, but this of course varies. 
>

Of course (although I should be a little more honest and state that my 
viewpoint comes primarily from people who I've told to use the `?`).

>
> Neither way, at least .show() function for poset does not tell about 
> figsize-option etc. 
>

Well, I've never really been able to understand the graph plotting. IIRC 
most of the doc is in the header of some module... just use view(P, 
tightpage=True), it uses dot2tex if you install the optional spkg (with 
sage -i dot2tex). IMO the output is much prettier.

>
> Trying to understand... mathematically there is kind of diamond inclusion 
> of classes: 
>
> finite lattices \subset lattices 
> finite lattices \subset finite posets 
> lattices \subset posets 
> finite posets \subset posets 
>
> Which means that, for example, every function for finite lattice is 
> available for finite poset, but not necessarily other way. On C++ 
> this could be modelled with multiple inheritance. 
>

Otherway around, any methods for finite posets is also for finite lattices, 
but you're right, it's basically multiple inheritance.

>
> But how come categories to this picture? 
>

As I stated, they can act like ABC's (abstract base classes), but can be 
set at runtime based on inputs (see MatrixSpace(R, m, n) with m = n and 
with m != n). Here's also a nice tutorial on the subject 
. 
Although they carry more information with them which is used for the 
morphisms.

>
> This is still quite confusing (or I am dumb, or both). To get posets of 
> size 5 one can say 
>
> Posets(5) 
>
> which internally does something like 
>
> [x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()] 
>
> To get lattices of size 5 one says 
>
> [sage.combinat.posets.lattices.FiniteLatticePoset(x) for x in Posets(5) if 
> x.is_lattice()] 
>
> Because a) FiniteLatticePoset is not available on global namespace and b) 
> there is no ready method to get lattices of given size. 
>
> Am I right on this? 
>

`Posets` is special; it's not the actual category object, like say Groups 
is. It's somewhat of an abuse here IMO, but it's minor. Although I don't 
think we have methods to get all lattices of a given rank yet in Sage...IDK 
off-hand for sure.

Best,
Travis

-- 
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.

[sage-devel] Re: Result of "sage -coverage" in sage -tp ?

[Travis Scrimshaw]

It would be annoying to me. Often times when I'm implementing a new 
feature, I don't have full doctest coverage. However when I make changes, I 
want to make sure the tests that I currently do have still work and don't 
want to be told that I don't have full coverage. The right tool for the 
right job, most multi/omni tools tend to make life more difficult.

Best,
Travis


On Monday, August 25, 2014 8:24:47 AM UTC-7, Nathann Cohen wrote:
>
> Hello everybody ! 
>
> I just had to run "sage -coverage" a couple of times (it tells you if 
> some methods need doctests) and wondered if we should add this to the 
> output of "sage -t" ? 
>
> This way we would get to see more often the list of functions which 
> need a doctest, and perhaps fix that faster. 
>
> What do you think ? 
>
> Have fuuun ! 
>
> Nathann 
>

-- 
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

[Bill Hart]

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

[Bill Hart]

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

[Robert Bradshaw]

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

[Bill Hart]

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

[Bill Hart]

>
> 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.

[sage-devel] Re: Student looking to contirbute to Sage

[Rohit Shinde]

> Also, what's your background … for some things you have to know a lot of 
> maths, for other aspects more programming.
>
> -- H 
>

I am an engineering student. I have some knowledge of Laplace Transforms, 
Fourier Transforms, Double and Triple Integration, Partial Differentiation. 
In general, I am quite familiar with Calculus. I know algebraic geometry. 
However, I am quite bad with Number Theory. 

As for programming, my language of choice is Python. I would prefer to do 
something which makes me use some Python. However, I am quite proficient 
with C++ and Java as well.

-- 
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.

[sage-devel] Re: Student looking to contirbute to Sage

[Rohit Shinde]

I do not have anything specific in mind.

However, I am average in maths. I am not that great. I know Python very 
well and am quite proficient in C++ and Java.

I would like to contribute more toward the UI and the Notebook. However, if 
there were any mathematics functions which could be implemented by me, I 
would be glad. 

-- 
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

[Bill Hart]

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

[Bill Hart]

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

[Robert Bradshaw]

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

[Julien Puydt]

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.

[sage-devel] Re: On scientific computing, Python and Julia

[Bill Hart]

On Monday, 25 August 2014 17:42:46 UTC+2, Pierre wrote:
>
>
> Julia is OOP!
>>
>>
> If it is, 
>

It is. 

how do you do the following in Julia: define a class (i'm using Python 
> parlance) Foo 
>

 type Foo
data1::T1
data2::T2
end

with some attributes,
>

is_infinite(::Type{Foo}) = yes
is_pierrian(::Type{Foo}) = no
 

> say if x is an instance of Foo it has an integer x.n ; and then define a 
> class Bar that inherits from Foo, that is, has all the attributes from Foo, 
> and some more, for example if y is an instance of Bar it has y.n because it 
> is an instance of Foo, and say it also has a string y.name. In python
>
> class Foo:
> n= 0
>
> class Bar(Foo):
> name= ""
>

Tongue-in-cheek solution:

abstract FooBar
 
type Foo <: FooBar
end

type Bar <: FooBar
end

n{T <: FooBar}(::Type{T}) = 0

name(::Type{Bar}) = ""

Though quite obviously the above is clearly not what you meant. 


> These classes don't even have methods, so it's not exactly complicated 
> OOP. Yet, I'm not sure how to do this (emulate this?) the Julia way. 
> Presumably, not with the <: relation at all. I'm wondering how 
> multi-dispatch comes in, given there are no methods involved.
>

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 a very well defined sense, functions and types are dual. Just as you can 
inherit structure in traditional OOP, you can inherit 
behaviour/functionality in the multimethod approach.

The key feature of Julia in this regard is the ability to add new methods 
to a generic function. So instead of classes and attributes becoming the 
focus of inheritance, in Julia, Generic functions and their (multi)methods 
become the focus.

The Julia authors claim that this is more flexible than traditional OOP. A 
lot of the real world restrictions of OOP come from their servitude to the 
structure inheritance paradigm.

So in short, if you want to write bad Python or C++ in Julia, you can't. 
But you also can't write good Julia in Python or C++.

In order to see why the other approach to OOP is not a restriction, you 
have to go back to what you were trying to model in the first place.

You have in mind something like this:

A real world thing, such as a Rectangle and inheriting from it a 
ColouredRectangle.

Perhaps the Rectangles are part of a windowing system, and as such any 
object of type Rectangle (I will avoid using the word class because it may 
be confused with typeclass, which has nothing to do with the concept of a 
class) will have a width and length and any object of type 
ColouredRectangle has the same fields as Rectangle, but also has associated 
with it a colour.

So that describes the structure of Rectangles and ColouredRectangles.

Now I think about what behaviour I want.

I clearly want to be able to resize any rectangle. I also want to be able 
to compute the area of a rectangle. I'd like to be able to enquire what the 
current colour of a coloured rectangle is.

Oh and by the way, some time whilst this project is underway, Circles are 
invented. We want all the same behaviour for those too, according to 
management.

So in Julia:

abstract Shape 

abstract RecShape <: Shape

type Rectangle <: RecShape
   width::Int
   height::Int
end

type ColouredRectangle <: RecShape
   width::Int
   height::Int
   colour::Int
end

function resize{T <: RecShape}(a :: T, width :: Int, height :: Int)
   a.width = width
   a.height = height
end

getcolour(a::ColouredRectangle) = a.colour

Oh damn, just got the fax from management. They want Circles too. But 
Circles don't inherit the structure of rectangles at all. They don't even 
have sides! What to do?

abstract CircShape <: Shape

type Circle <: CircShape
   radius::Int
end

type ColouredCircle <: CircShape
   radius::Int
   colour::Int
end

resize{T <: CircShape}(a::T, radius::Int)
a.radius = radius
end

getcolour(a::ColouredCircle) = a.colour

Notice how I inherited the behaviour called resize between the different 
kinds of rectangles. But later, when a type came along with a different 
structure, I could still add to the same behaviour resize by adding another 
method to the generic function resize.

And I also didn't need to rewrite the function getcolour either. I only 
really needed to go back to the original definition and change it to

getcolour(a::Union(ColouredCircle, ColouredRectangle)) = a.colour

Or if there was multiple inheritance (Julia doesn't have it yet) I could 
add some more nodes in my abstract type graph so that there is 
ColouredShape <: Shape. Then just have

getcolour{T <: ColouredShape}(a::T) = a.colour
 
Now, one final observation will demonstrate why this is such a useful 
paradigm:

Most real world computer programs define *far* fewer classes than methods. 
The ability to inherit structure is not a

[sage-devel] Sage 6.3 on ARM

[Julien Puydt]

Hi,

I have compiled sage 6.3 on my little ARM box, and made a bdist 
available in sage.math.washington.edu:/home/jpuydt/bdist/


It would be nice if this bdist could be made available : I'm quite 
annoyed to see the latest version available in the mirrors is 5.13... 
when I have been building&pushing bdist for 6.0, 6.1, 6.1.1 and 6.2 !


Snark on #sagemath

--
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

[Bill Hart]

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

[Robert Bradshaw]

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

Re: [sage-devel] On scientific computing, Python and Julia

[Robert Bradshaw]

On Fri, Aug 22, 2014 at 7:38 PM, rjf  wrote:
>
> On Friday, August 22, 2014 2:04:35 PM UTC-7, Bill Hart wrote:
>>
>>
>>> RJF said...
>>> I don't know about canonical maps.  The term "canonical representation"
>>> makes sense to me.
>>
>>
>> He means this. In algebra Z/nZ is actually a ring modulo an ideal. Z is
>> the ring, nZ is the ideal.
>>
>> The elements of Z/nZ are usually written a + nZ. It means precisely this:
>>
>> a + nZ = { x in Z such that x = a +nk for some k in Z }
>>
>> So it is a *set* of numbers (actually, in algebra it is called a coset).
>>
>> When you write Mod(a, n) you really mean a + nZ if you are an algebraist,
>> i.e. the *set* of numbers congruent to a modulo n.
>>
>> So Z/nZ consists of (co)sets of the form C = Mod(a, n) = a + nZ. If you
>> like Z/nZ is a set of sets (actually a group of cosets in algebra).
>>
>> There is a canonical map from Z to Z/nZ: we map b in Z to the (co)set C in
>> Z/nZ that contains b.
>>
>> If a = b mod n then C = mod(a, n) is the *only* one of these sets which
>> contains b. So the map is canonical. We only have one choice.
>>
>> But there is no canonical map going the other way. For any such (co)set C,
>> which element of Z are you going to pick? Any of the elements of C will do.
>>
>> You can make an arbitrary choice, e.g. pick the unique element of C in the
>> range [0, n). Or you could pick the unique element in the range (-n/2, n/2].
>> But that is not a canonical choice. You had to make an arbitrary choice.
>> Someone else may have made a different choice. (Indeed some people use the
>> latter choice because some algorithms, such as gcd and Jacobi symbols run
>> faster with this choice.)
>>
>> So canonical map means there is only one way you could define the map. You
>> don't need to tell anyone what your map is, because they *have* to make the
>> same choice as you, as there are no alternatives. That's the meaning of
>> canonical in mathematics.
>>
>> It's probably not a terminology they teach in Computer Algebra,
>
>
> There are few courses in Computer Algebra.   But the term canonical is used
> differently.   In fact, two systems could
> have different canonical forms   (e.g. in your example, [0,n-1]or
> [-(n-1)/2, (n-1)/2]   for representatives of the numbers mod n.
>
> Just as one system could have  1+x+x^2   and another x^2+x+1.
>
> But for each system with a canonical form for polynomials, all polynomials
> in its canonical form would be
> identical bit patterns.   Some systems e.g. Maple go further and have all
> canonical and equal forms stored
> at the same machine address.

I think this highlights the difference between your perspective and
mine. When I write "the map Z -> Z/nZ in Sage" you seem to be
interpreting that as "a map from representatives of the integers to
representatives of the integers mod n" and I'm thinking "a
representation of the (canonical) map Z -> Z/nZ." Same for Rings,
Fields, etc.

>> but it is taught to undergraduates around the world in pure mathematics.
>
> Um, some English speaking students who take, um, certain electives?

Many more than take courses in computer algebra. I'd say.

>> The whole argument here is that because only one direction gives a
>> canonical map, coercion must only proceed in that direction. Otherwise your
>> computer algebra system is making a choice that someone else's computer
>> algebra system does not.
>
>
> But that is perfectly all right.  canoncality is with respect to a
> particular computer system.  At least
> my kind of canonicality.

Clearly, despite some overlap, you're a computer scientist, and I'm a
mathematician:

http://en.wikipedia.org/wiki/Canonical

-- 
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Pierre]

> Julia is OOP!
>
>
If it is, how do you do the following in Julia: define a class (i'm using 
Python parlance) Foo with some attributes, say if x is an instance of Foo 
it has an integer x.n ; and then define a class Bar that inherits from Foo, 
that is, has all the attributes from Foo, and some more, for example if y 
is an instance of Bar it has y.n because it is an instance of Foo, and say 
it also has a string y.name. In python

class Foo:
n= 0

class Bar(Foo):
name= ""

These classes don't even have methods, so it's not exactly complicated OOP. 
Yet, I'm not sure how to do this (emulate this?) the Julia way. Presumably, 
not with the <: relation at all. I'm wondering how multi-dispatch comes in, 
given there are no methods involved.

(btw I guess i'm only trying to supply another example of a novice's 
misunderstanding of what he's read here and there. With zero actual Julia 
practice (who installs a language when reading a tutorial?) May it help you 
deal with users' questions in the future.)

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, Francesco Biscani  wrote:
> --089e013c6576f2ddd4050175975f
> Content-Type: text/plain; charset=UTF-8
>
> On 25 August 2014 16:28, Dima Pasechnik  wrote:
>>
>> apparently it's better, but it's only supported on certain more
>> expensive versions of Windows 7 and Windows Server 2008.
>>
>> to quote:
>>
>> Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
>> Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
>> 64-bit edition;
>
>
> Ah bummer... I wonder if the version check is strict or if it can be worked
> around somehow. 
good luck doing this - you will need to provide a hack that does this
to be distributed with Sage :)

As well, SUA is deprecated in Windows 8, and won't be
supported beyond Windows 8.

> Seems like at some point Debian had an Interix port:
>
> http://www.debian-interix.net/
>
> (As a side question, what versions of Windows are commonly found on
> desktops/laptops these days? Are people switching over to Windows 8?)

some time ago retailers offered a choice of Windows 7 or 8, but I 
guess this will stop sooner of later.
Anyhow, I've never seen a retailer offering a windows edition
other than Home or Pro.


>
> There's quite a bit of material on how to write a replacement of fork()
> using the Windows API. See, e.g.,
>
> http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525
> http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216
>
> And it seems MinGW has the prototype for fork(), although not the
> implementation:
>
> http://stackoverflow.com/questions/9612315/why-does-my-compiler-not-accept-fork-despite-my-inclusion-of-unistd-h
>
> Even if the implementation is not 100% conforming, it would probably be
> adequate for some purposes. Is the lack of fork() the biggest showstopper
> or just one of many roadblocks? I would imagine a lot of external
> components included in sage are not written with platform independence in
> mind (but IMO this would rather be an argument to work with upstream to
> rectify the issue instead of working around it).
>
GAP uses fork, mmap, and ioctl - none of which are supported by MinGW/MSYS.
Dunno about PARI and Singular.'





-- 
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.

[sage-devel] Result of "sage -coverage" in sage -tp ?

[Nathann Cohen]

Hello everybody !

I just had to run "sage -coverage" a couple of times (it tells you if
some methods need doctests) and wondered if we should add this to the
output of "sage -t" ?

This way we would get to see more often the list of functions which
need a doctest, and perhaps fix that faster.

What do you think ?

Have fuuun !

Nathann

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Jean-Pierre Flori]

My souvenir here is that Sage almost builds out of the box on Cygwin64 
modulo some patches i posted in different tickets.
It is not really funcitonnal though, last time I tried it seemed to me that 
Python itself was horribly broken.

On Monday, August 25, 2014 4:58:56 PM UTC+2, kcrisman wrote:
>
> My understanding was that Cygwin 32 had been "solved", largely due to work 
> by JP, though perhaps feature creep and upgrades have changed that, and the 
> current status of Cygwin 64 is at 
> http://trac.sagemath.org/wiki/Cygwin64Port
>
> Among other tickets needing review for this:
> MPIR upgrade - http://trac.sagemath.org/ticket/15015
> IML tiny fix - http://trac.sagemath.org/ticket/14648
> Something PPL related - http://trac.sagemath.org/ticket/16152
> gf2x fixes - http://trac.sagemath.org/ticket/16152
>
> JP's been doing an awesome job keeping things up-to-date as he can.  If we 
> had a buildbot for Cygwin that would make things a lot easier of course.
>

-- 
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: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 16:28, Dima Pasechnik  wrote:
>
> apparently it's better, but it's only supported on certain more
> expensive versions of Windows 7 and Windows Server 2008.
>
> to quote:
>
> Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
> Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
> 64-bit edition;


Ah bummer... I wonder if the version check is strict or if it can be worked
around somehow. Seems like at some point Debian had an Interix port:

http://www.debian-interix.net/

(As a side question, what versions of Windows are commonly found on
desktops/laptops these days? Are people switching over to Windows 8?)

There's quite a bit of material on how to write a replacement of fork()
using the Windows API. See, e.g.,

http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525
http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216

And it seems MinGW has the prototype for fork(), although not the
implementation:

http://stackoverflow.com/questions/9612315/why-does-my-compiler-not-accept-fork-despite-my-inclusion-of-unistd-h

Even if the implementation is not 100% conforming, it would probably be
adequate for some purposes. Is the lack of fork() the biggest showstopper
or just one of many roadblocks? I would imagine a lot of external
components included in sage are not written with platform independence in
mind (but IMO this would rather be an argument to work with upstream to
rectify the issue instead of working around it).

-- 
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: How practical/useful would a native windows subset be?

[Jean-Pierre Flori]

On Monday, August 25, 2014 1:35:29 PM UTC+2, wstein wrote:
>
>
> This reminds me of Michael Abshoff.  He was supposed to port Sage to 
>
> That was the name I was looking for I guess.
And one of the posts I was thinking of:
https://groups.google.com/d/msg/sage-devel/QXy_2KMbP1k/Z3cfpCieYzgJ  

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[kcrisman]

My understanding was that Cygwin 32 had been "solved", largely due to work 
by JP, though perhaps feature creep and upgrades have changed that, and the 
current status of Cygwin 64 is at http://trac.sagemath.org/wiki/Cygwin64Port

Among other tickets needing review for this:
MPIR upgrade - http://trac.sagemath.org/ticket/15015
IML tiny fix - http://trac.sagemath.org/ticket/14648
Something PPL related - http://trac.sagemath.org/ticket/16152
gf2x fixes - http://trac.sagemath.org/ticket/16152

JP's been doing an awesome job keeping things up-to-date as he can.  If we 
had a buildbot for Cygwin that would make things a lot easier of course.

-- 
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] sage make fail @ ntl

[Jori Mantysalo]

On Mon, 25 Aug 2014, Volker Braun wrote:


Thats not how it works. Try "sage -f ntl"


It works. But:

libtool: install: ranlib /home/jm58660/sage-6.3/local/lib/libntl.a
libtool: finish: 
PATH="/home/jm58660/sage-6.3/src/bin:/home/jm58660/sage-6.3/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/jm58660/bin:/sbin" 
ldconfig -n /home/jm58660/sage-6.3/local/lib
ldconfig: Can't link 
/home/jm58660/sage-6.3/local/lib//home/jm58660/sage-6.3/local/lib/libtatlas.so 
to libtatlas.so
ldconfig: Can't link 
/home/jm58660/sage-6.3/local/lib//home/jm58660/sage-6.3/local/lib/libsatlas.so 
to libsatlas.so


This is not copypaste-error. Somewhere is bug like $SOMEPATH$SOMEPATH 
where should be only $SOMEPATH.


--
Jori Mäntysalo

--
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, Francesco Biscani  wrote:
> --089e0115ece08dd452050174a8ff
> Content-Type: text/plain; charset=UTF-8
>
> On 25 August 2014 15:04, Dima Pasechnik  wrote:
>>
>> cause M$ is unwilling to release specifications of kernel
>> calls needed to make a good modern implementation of fork().
>>
>> It is a constant fight against a fundamentally shaky fork()
>> as implemented in Cygwin :-(
>>
>
> Is the fork() implementation in SUA shaky as well?
>
> http://stackoverflow.com/questions/4243880/substitute-for-forking-in-windows
> http://www.microsoft.com/en-us/download/details.aspx?id=2391

apparently it's better, but it's only supported on certain more
expensive versions of Windows 7 and Windows Server 2008. 

to quote:

Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
64-bit edition;


-- 
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: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 15:04, Dima Pasechnik  wrote:
>
> cause M$ is unwilling to release specifications of kernel
> calls needed to make a good modern implementation of fork().
>
> It is a constant fight against a fundamentally shaky fork()
> as implemented in Cygwin :-(
>

Is the fork() implementation in SUA shaky as well?

http://stackoverflow.com/questions/4243880/substitute-for-forking-in-windows
http://www.microsoft.com/en-us/download/details.aspx?id=2391

-- 
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: How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Aug 2014 14:21, "Jeroen Demeyer"  wrote:
>
> On 2014-08-25 13:27, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:
>>
>> I would not think it too hard to generate a parser which is linked to the
>>
>> * GMP
>> * MPFR
>> * GNU scientific library
>>
>> which I would expect would compile with Qt or WxWidgets without too many
>> changes. If it used Qt, the code could be developed on virtually any
>> platform.
>
> And the result would be something like this:
>
http://www.online-tech-tips.com/wp-content/uploads/2010/08/Windows7ScientificCalculatorMode_thumb.png

No it would be s lot better than the Windows scientific calculator you
refere to.

* It would have arbitrary precision in both FP and integer.
* All the functionality of the GSL - Bessel functions for example.
* Highly portable.

Dave.

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) 
 wrote:
> --bcaec51b1b9968213b050172c4f7
> Content-Type: text/plain; charset=UTF-8
>
> On 25 Aug 2014 12:44, "Jeroen Demeyer"  wrote:
>
>> I think Sage-on-Cygwin is fay more realistic than a pure native (even
> stripped down) version of Sage. I you care about Windows, concentrate your
> efforts on the Cygwin port.
>
> Why has so much time been spent on it, without success?

cause M$ is unwilling to release specifications of kernel
calls needed to make a good modern implementation of fork().

It is a constant fight against a fundamentally shaky fork()
as implemented in Cygwin :-(

>
> William wrote in 2007 Sage would probably never be built on Cygwin
>
> http://markmail.org/message/fapx25o3kqipdeg2
>
> Then in 2010 described how he got it to build
>
> https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w
>
> and while I can't find the post,  I think William later expressed some
> doubt whether it would ever work properly.
>
> I am on my mobile phone now,  so not too easy to browse the web, but I
> pretty sure that the Cygwin port was due to be finished before the Solaris
> port.
>
> Maybe there's a case for a fresh start with more modest aims and a cleaner
> interface.

fresh or not, but Win64-only should probably be more doable.
And it would satisfy most of the current demand, IMHO.



>
> Dave
>

-- 
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Bill Hart]

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 
type in class B can take the type A. This is not a subset meaning. It means 
the type A belongs to the typeclass B.

3) If A <: B where A and B are both abstract 
types/t

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, Julien Puydt  wrote:
> Hi,
>
> Le 25/08/2014 11:04, Dima Pasechnik a écrit :
>> On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) 
>>  wrote:
>>> --089e01537eba8a9d2805016fca81
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> It seems Sage really could do with a native windows port. I am wondering
>>> how practical it would be to make a version which is a subset of Sage, with
>>> something like Qt which runs on Windows,  Linux,  OSX and Solaris and has
>>> the look and feel of those platforms.
>>
>> Sage components such as GAP, Singular, PARI/GP do not have native Windows 
>> ports.
>> Without them you'd better run IPython directly, it will provide you better
>> experience and roughly the same functionality.
>
> I don't understand why people insist on trying to build the windows port 
> on windows with cygwin ; it's also possible to cross-build windows ports :
> http://wiki.ekiga.org/index.php/Building_Ekiga_for_Windows
>
> Of course, that requires some sanitization of build systems, clean 
> sources, etc...

Ekiga only does mingw(64/32) builds, but mingw does not provide enough
POSIX (no fork(), etc).
So the sources need to be worked on quite a bit...
(and native mingw builds aren't so problematic, in fact)

-- 
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.

[sage-devel] Re: Random behaviour on show()

[Volker Braun]

Feature... you can provide a seed for the spring layout if you want.


On Monday, August 25, 2014 1:05:36 PM UTC+1, Jori Mantysalo wrote:
>
> Graph({'Pekka':['Matti', 'Leena', 'Timo'], 
> 'Matti':['Mari']}).show(vertex_size=1500) 
>
> There is nothing wrong with output, but why it changes every time I run 
> the command? Bug or feature? 
>
> -- 
> Jori Mäntysalo 
>

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, mmarco  wrote:
> --=_Part_2559_2117096191.1408960189386
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> IIRC, GAP and Pari/GP do have a native windows version. Singular has a=20
> cygwin version.

no, GAP does not have a native Windows version.
It has a prebuilt distribution for Windows with cygwin DLL bundled in.

I think native GAP port to Windows should be doable, but it still needs to be 
done. It's not completely trivial.


>
> El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pasechnik escribi=C3=B3=
>:
>>
>> On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <
>> drki...@kirkbymicrowave.co.uk > wrote:=20
>> > --089e01537eba8a9d2805016fca81=20
>> > Content-Type: text/plain; charset=3DUTF-8=20
>> >=20
>> > It seems Sage really could do with a native windows port. I am wonderin=
> g=20
>> > how practical it would be to make a version which is a subset of Sage,=
>=20
>> with=20
>> > something like Qt which runs on Windows,  Linux,  OSX and Solaris and=
>=20
>> has=20
>> > the look and feel of those platforms.=20
>>
>> Sage components such as GAP, Singular, PARI/GP do not have native Windows=
>=20
>> ports.=20
>> Without them you'd better run IPython directly, it will provide you bette=
> r=20
>> experience and roughly the same functionality.=20
>>
>>
>>
>
> --=20
> 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 e=
> mail 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.
>
> --=_Part_2559_2117096191.1408960189386
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> IIRC, GAP and Pari/GP do have a native windows version. Singular has a cygw=
> in version.El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pase=
> chnik  escribi=C3=B3: argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-0=
> 8-25, Dr. David Kirkby (Kirkby Microwave Ltd) < arget=3D"_blank" gdf-obfuscated-mailto=3D"15NGl7oNS-cJ" onmousedown=3D"this=
> .href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
> turn true;">drki...@kirkbymicrowave.co.uk> wrote:
>> --089e01537eba8a9d2805016fca81
>> Content-Type: text/plain; charset=3DUTF-8
>>
>> It seems Sage really could do with a native windows port. I am won=
> dering
>> how practical it would be to make a version which is a subset of S=
> age, with
>> something like Qt which runs on Windows,  Linux,  OSX an=
> d Solaris and has
>> the look and feel of those platforms.
>
>Sage components such as GAP, Singular, PARI/GP do not have native Windo=
> ws ports.
>Without them you'd better run IPython directly, it will provide you bet=
> ter
>experience and roughly the same functionality.
>
>
>
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups &=
> quot;sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to mailto:sage-devel+unsubscr...@googlegroups.com";>sage-dev=
> el+unsubscr...@googlegroups.com.
> To post to this group, send email to mailto:sage-devel@googlegro=
> ups.com">sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel";>h=
> ttp://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout";>http=
> s://groups.google.com/d/optout.
>
> --=_Part_2559_2117096191.1408960189386--
>

-- 
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: How practical/useful would a native windows subset be?

[Jeroen Demeyer]

On 2014-08-25 13:27, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:

I would not think it too hard to generate a parser which is linked to the

* GMP
* MPFR
* GNU scientific library

which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform.

And the result would be something like this:
http://www.online-tech-tips.com/wp-content/uploads/2010/08/Windows7ScientificCalculatorMode_thumb.png

--
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.

[sage-devel] Random behaviour on show()

[Jori Mantysalo]

Graph({'Pekka':['Matti', 'Leena', 'Timo'], 
'Matti':['Mari']}).show(vertex_size=1500)

There is nothing wrong with output, but why it changes every time I run 
the command? Bug or feature?


--
Jori Mäntysalo

--
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: How practical/useful would a native windows subset be?

[maldun]

There a reports on Trac that sage 5.9 worked fine on windows 7 64-Bit. 
http://trac.sagemath.org/wiki/CygwinPort
So it is no science-fiction to say that sage on Cygwin is possible.
Indeed it will not come without some trouble and hard work.

On Monday, August 25, 2014 1:48:41 PM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
>
> On 25 Aug 2014 12:44, "Jeroen Demeyer"  > wrote:
>
> > I think Sage-on-Cygwin is fay more realistic than a pure native (even 
> stripped down) version of Sage. I you care about Windows, concentrate your 
> efforts on the Cygwin port.
>
> Why has so much time been spent on it, without success?
>
> William wrote in 2007 Sage would probably never be built on Cygwin
>
> http://markmail.org/message/fapx25o3kqipdeg2
>
> Then in 2010 described how he got it to build
>
> https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w
>
> and while I can't find the post,  I think William later expressed some 
> doubt whether it would ever work properly. 
>
> I am on my mobile phone now,  so not too easy to browse the web, but I 
> pretty sure that the Cygwin port was due to be finished before the Solaris 
> port. 
>
> Maybe there's a case for a fresh start with more modest aims and a cleaner 
> interface. 
>
> Dave
>

-- 
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: How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Aug 2014 12:44, "Jeroen Demeyer"  wrote:

> I think Sage-on-Cygwin is fay more realistic than a pure native (even
stripped down) version of Sage. I you care about Windows, concentrate your
efforts on the Cygwin port.

Why has so much time been spent on it, without success?

William wrote in 2007 Sage would probably never be built on Cygwin

http://markmail.org/message/fapx25o3kqipdeg2

Then in 2010 described how he got it to build

https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w

and while I can't find the post,  I think William later expressed some
doubt whether it would ever work properly.

I am on my mobile phone now,  so not too easy to browse the web, but I
pretty sure that the Cygwin port was due to be finished before the Solaris
port.

Maybe there's a case for a fresh start with more modest aims and a cleaner
interface.

Dave

-- 
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: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 12:27, Jean-Pierre Flori  wrote:

> PARI/GP is definitely not native.
> It is Cygwin or MinGW.
>

MinGW and Cygwin are two completely different things. I don't know what you
mean with "native", but MinGW is as native on Windows as, e.g., the Intel
compiler is.

-- 
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: How practical/useful would a native windows subset be?

[William A Stein]

On Mon, Aug 25, 2014 at 1:27 PM, Dr. David Kirkby (Kirkby Microwave
Ltd)  wrote:
>
> On 25 Aug 2014 12:19, "Julien Puydt"  wrote:
>
>> I don't understand why people insist on trying to build the windows port
>> on windows with cygwin ; it's also possible to cross-build windows ports
> I was mainly thinking of a C++ version with its own parser. If that used Qt
> or wxWidgits it would be multi platform.  It does need to use Python at all
> initially -  if ever.
>
> I guess there is more than one way to approach it, but if one set out with
> the aim of nothing much more than a decent scientific calculator,  one would
> not need to worry about porting things that are hard.
>
> I would not think it too hard to generate a parser which is linked to the
>
> * GMP
> * MPFR
> * GNU scientific library
>
> which I would expect would compile with Qt or WxWidgets without too many
> changes. If it used Qt, the code could be developed on virtually any
> platform.  Producing executables for many mobile phones, including Android
> and Apple iPhone and iPad, Linux etc.
>
> By only linking to code and not calling external command-line tools, it
> should be possible to create a uniform interface,  which is one of the
> criticisms of Sage.

This reminds me of Michael Abshoff.  He was supposed to port Sage to
Windows, and was also complaining about how horrible every component
of Sage was, and wanting to remove them.  At one point,  I wondered if
his eventual port would be something like:

int main(void) {
printf("sage: ");
/* etc., -- a simple REPL that does nothing */
}

More seriously, what you're describing definitely isn't Sage at all...

 -- William


-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
wst...@uw.edu

-- 
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: How practical/useful would a native windows subset be?

[William A Stein]

On Mon, Aug 25, 2014 at 12:44 PM, Jeroen Demeyer  wrote:
> On 2014-08-25 11:33, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:
>>
>> I think people  been working on it for years and despite a lot of time
>> and effort spent on it, it has never been completed. I think there are a
>> number of reasons it has not been completed,  but lack of effort is not
>> one of them.
>
> I think Sage-on-Cygwin is fay more realistic than a pure native (even
> stripped down) version of Sage. I you care about Windows, concentrate your
> efforts on the Cygwin port.

+1

And we actually did spend *months* of very hard work on such a "mini
sage" fully native approach to sage on windows, a few years ago (when
it was easier).It was a complete and total waste of time.   Once
you understand the architecture of Sage, you see that even the most
basics parts of Sage are so intertwined that the amount of
dependencies (e.g., PARI, etc.,) that you need, make this approach
incredibly difficult.Really IPython + Sympy (say) *is* this "mini
sage", but to get from that to full native windows Sage is at least a
million dollar project

> > The download size of such a subset would be smaller than the full version 
> > and MUCH smaller that a virtual machine image, as one doesn't need to 
> > include a complete operating system too.

That's not true.  E.g., Puppy Linux is around 50MB, and is a complete
useful operating system.  In fact, I used to build the Sage VM
(targeted at windows) using Puppy Linux years ago.

 -- William

>
>
> --
> 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.



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
wst...@uw.edu

-- 
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: How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Aug 2014 12:19, "Julien Puydt"  wrote:

> I don't understand why people insist on trying to build the windows port
on windows with cygwin ; it's also possible to cross-build windows ports
I was mainly thinking of a C++ version with its own parser. If that used Qt
or wxWidgits it would be multi platform.  It does need to use Python at all
initially -  if ever.

I guess there is more than one way to approach it, but if one set out with
the aim of nothing much more than a decent scientific calculator,  one
would not need to worry about porting things that are hard.

I would not think it too hard to generate a parser which is linked to the

* GMP
* MPFR
* GNU scientific library

which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform.  Producing executables for many mobile phones, including Android
and Apple iPhone and iPad, Linux etc.

By only linking to code and not calling external command-line tools, it
should be possible to create a uniform interface,  which is one of the
criticisms of Sage.

Dave

-- 
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: How practical/useful would a native windows subset be?

[Jeroen Demeyer]

On 2014-08-25 11:33, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:

I think people  been working on it for years and despite a lot of time
and effort spent on it, it has never been completed. I think there are a
number of reasons it has not been completed,  but lack of effort is not
one of them.
I think Sage-on-Cygwin is fay more realistic than a pure native (even 
stripped down) version of Sage. I you care about Windows, concentrate 
your efforts on the Cygwin port.


--
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.

[sage-devel] is_prime slower than prime_range (#16878)

[Vincent Delecroix]

Hello,

Curiously, for small integers, it is faster to use prime_range rather
than is_prime... this is now #16878 which needs review.

Vincent

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Jean-Pierre Flori]

On Monday, August 25, 2014 11:49:49 AM UTC+2, mmarco wrote:
>
> IIRC, GAP and Pari/GP do have a native windows version. Singular has a 
> cygwin version.
>
> El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pasechnik escribió:
>>
>> On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <
>> drki...@kirkbymicrowave.co.uk> wrote: 
>> > --089e01537eba8a9d2805016fca81 
>> > Content-Type: text/plain; charset=UTF-8 
>> > 
>> > It seems Sage really could do with a native windows port. I am 
>> wondering 
>> > how practical it would be to make a version which is a subset of Sage, 
>> with 
>> > something like Qt which runs on Windows,  Linux,  OSX and Solaris and 
>> has 
>> > the look and feel of those platforms. 
>>
>> Sage components such as GAP, Singular, PARI/GP do not have native Windows 
>> ports. 
>> Without them you'd better run IPython directly, it will provide you 
>> better 
>>
> PARI/GP is definitely not native.
It is Cygwin or MinGW.
And PARI/GP was one of the big issues when Tim Abbott (? or someone else, I 
don't really recall the discussions here) was aatempting to build Sage on 
Windows.
Indeed they have some sizeof(long) = sizeof(void*) constraint which is more 
than painful for a Windows port.

If you dig through the archive here, you may find that post and also get an 
idea of what the other big obstacles were.

-- 
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] sage make fail @ ntl

[Volker Braun]

Fix for the misleading "help" at http://trac.sagemath.org/ticket/16877 
 (needs review)

On Monday, August 25, 2014 8:17:14 AM UTC+1, Jori Mantysalo wrote:
>
> $ ./sage -i ntl 
> Package ntl-6.1.0.p0 is already installed. 
> Use 'sage -f /home/jm58660/sage-6.3/upstream/ntl-6.1.0.tar.bz2' to force a 
> reinstallation. 
>
> $ ./sage -f /home/jm58660/sage-6.3/upstream/ntl-6.1.0.tar.bz2 
>   . . . 
> /home/jm58660/sage-6.3/src/bin/sage-spkg: line 601: cd: ntl-6.1.0.tar.bz2: 
> No such file or directory 
>
>

-- 
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: How practical/useful would a native windows subset be?

[Julien Puydt]

Hi,

Le 25/08/2014 11:04, Dima Pasechnik a écrit :

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) 
 wrote:

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8

It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows,  Linux,  OSX and Solaris and has
the look and feel of those platforms.


Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.


I don't understand why people insist on trying to build the windows port 
on windows with cygwin ; it's also possible to cross-build windows ports :

http://wiki.ekiga.org/index.php/Building_Ekiga_for_Windows

Of course, that requires some sanitization of build systems, clean 
sources, etc...


Snark on #sagemath

--
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] sage make fail @ ntl

[Volker Braun]

Thats not how it works. Try "sage -f ntl"

On Monday, August 25, 2014 8:17:14 AM UTC+1, Jori Mantysalo wrote:
>
> $ ./sage -f /home/jm58660/sage-6.3/upstream/ntl-6.1.0.tar.bz2 
>

-- 
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Pierre]

> At this point, the fact that abstract types could be instantiated was seen 
> as a limitation compared to OOP. And somehow, it is. Except at the same 
> time, the type system does many new things. 
>

typo : read "could NOT be instantiated". 

-- 
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Pierre]

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. 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". 

At this point, the fact that abstract types could be instantiated was seen 
as a limitation compared to OOP. And somehow, it is. Except at the same 
time, the type system does many new things. Apples and oranges, really.

Mistake (2): taking types for sets. This little discussion about names 
reveals another mistake of mine: thinking of types as sets. I thought ZZ <: 
QQ for example. That's not even consistent with the previous mistake. In 
Sage say, i'm guessing QQ is of type Field or something, which inherits 
from a type Ring or something -- but not the other way around! So mistake 
(1) should have led me to believe QQ <: ZZ. Oh well. 

Mistake (3): thinking about Sage too much. To my discharge, ZZ in Sage is 
an object, like 1/2, not a type or anything. This has unconsciously 
contributed to my confusion greatly. Also the fact that there is a coercion 
from ZZ to QQ, and somewhere I must have taken A <: B to mean "there is a 
coercion from A to B".

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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[mmarco]

IIRC, GAP and Pari/GP do have a native windows version. Singular has a 
cygwin version.

El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pasechnik escribió:
>
> On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <
> drki...@kirkbymicrowave.co.uk > wrote: 
> > --089e01537eba8a9d2805016fca81 
> > Content-Type: text/plain; charset=UTF-8 
> > 
> > It seems Sage really could do with a native windows port. I am wondering 
> > how practical it would be to make a version which is a subset of Sage, 
> with 
> > something like Qt which runs on Windows,  Linux,  OSX and Solaris and 
> has 
> > the look and feel of those platforms. 
>
> Sage components such as GAP, Singular, PARI/GP do not have native Windows 
> ports. 
> Without them you'd better run IPython directly, it will provide you better 
> experience and roughly the same functionality. 
>
>
>

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Aug 2014 10:37, "maldun"  wrote:
>
> Hi!
>
> Python XY ( https://code.google.com/p/pythonxy/ )and WinPython (
http://winpython.sourceforge.net/) do this for years now and are working
properly. Maybe one can use this as a start since many of the needed
prequisites are there.

Yes, maybe.

> but why not concentrate on a working cygwin port,

I think people  been working on it for years and despite a lot of time and
effort spent on it, it has never been completed. I think there are a number
of reasons it has not been completed,  but lack of effort is not one of
them.

Dave

-- 
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.

[sage-devel] Re: William Stein says "Sage has overall failed"

[maldun]

And I forgot: It is defenitely better than the 5th M, namely MatCAD! 

-- 
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.

[sage-devel] Re: William Stein says "Sage has overall failed"

[maldun]

Sage has definietly not failed! I use it as alternative to Matlab and 
Mathematica for years now, and what the true strength of Sage is not, that 
it is better than one of the 4M's, but is doing a equivalently good job in 
all those areas, which each of this programs is speciallized in!

The one thing I have personally to criticize about sage is that the 
scientific computing/numeric community is quite weak here. Of course thanks 
to scipy that part is very well covered, and the scipy ecosystem is part of 
sage, but it still has the feeling of 'beeing on board' instead of beeing 
fully integrated.
 

On Thursday, August 21, 2014 12:17:43 PM UTC+2, Harald Schilly wrote:
>
> Surprisingly, sometimes Reddit contains actual discussions: 
>
>
> http://www.reddit.com/r/math/comments/2e3qla/william_stein_says_sage_has_overall_failed/
>  
>
> -- H 
>

-- 
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Bill Hart]

On Monday, 25 August 2014 09:48:12 UTC+2, Pierre wrote:
>
> > 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.
>>
>
> I guess to me the only names that would really make sense would be 
> ZZElement <: RREelement <: RingElement (or else rename the builtin types to 
> something else: it's "Integer" that's not the same of a set!! Rename it 
> Integers and everything makes sense). Anyway, I probably need to learn to 
> think differently about this.
>

Integer is an abstract type in Julia. For example, Int <: Integer.

Int is a concrete type (actually, it's a typealias for either the concrete 
type Int32 or Int64, depending on what sort of computer you have). Note 
it's not IntElement! And Integer is not a concrete type, despite Integer 
being the name of an element of the ring of Integers. There is no Integers 
in Julia.

You are probably being confused by the fact that the <: notation in Julia 
can be used with either concrete types or abstract types on both sides.

This is to prevent needing

Level 1: values
Level 2: types
Level 3: typeclasses
Level 4: typesuperclasses
Level 5: typesupersuperclasses
Level 6: typesupersupersuperclasses
...
etc.

All types, no matter what level in Julia are just DataType's. It's just 
that some can be instantiated and some are just abstract. The abstract ones 
serve the purpose of typeclasses, mostly. But they can be arbitrary levels 
in your hierarchy. It's up to you what interpretation you put on your 
abstract types.
 
The only thing that can't go on the left side of <: is an actual value, 
like 1. (There's an argument that it should be possible since types can be 
parameterised on Int's, but that's another story.)


> I do wonder about one thing. Since it is not possible in Julia to have 
> instances of abstract types, and you have ZZ <: RR with the possibility of 
> doing ZZ(3) as well as RR(3), does it mean that you've created 
> supplementary concrete types, say ZZ_concrete <: ZZ and RR_concrete <: RR 
> or similar, together with a bunch of constructors to hide everything?
>

ZZ is not an abstract type. It's a concrete type. Concrete doesn't mean 
system defined. It means it has values. A ZZ in Nemo is nothing more and 
nothing less than a flint fmpz_t integer. So it is very concrete. I could 
very easily have called it fmpz_t if I wanted. I'd have used Integer to 
name the type, actually, but that was already taken. As was Int, BigInt and 
numerous other things. So ZZ was what I decided to use.

I used ZZ because fundamentally, a type is a set of values. ZZ is the name 
of a set of values. Int is the name of a set of values. It's just a name. I 
used the first sensible name that popped into my head. Sage uses ZZ for the 
same purpose roughly, though in Sage there is supposedly a separation 
between types and mathematical domains. And ZZ is technically a 
mathematical domain (called a parent in Sage) which has an underlying 
representation whose values have types.

Aldor is another language that conceptually distinguises mathematical 
domains from their representations.

On the other hand, you can think of ZZ as being blackboard bold Z, and Z 
stands for Zahl (number) in German.
 
There is no RR type in Nemo yet. But it can just as well stand for Real if 
you want, instead of Reals. After all Real is already used for the name of 
a typeclass in Julia.


> If so, I find this quite complicated. Here good old OOP treats this much 
> more elegantly. But perhaps I am mistaken?
>

How can you even express traits elegantly in good old OOP? It's a template 
metaprogramming nightmare in C++! You have to model traits yourself in 
Python. In fact, name one "good old OOP" language that supports traits 
smoothly. Maybe Scala? Good luck fighting with the type checker though.

Now I will admit that after you first brought this up, I have begun to 
think that FField should be FFElem. This comes about because we don't have 
a special name for an element of a finite field, like Polynomial for an 
element of a Polynomial Ring, or Integer for an element of the ring of 
Integers or Real Number for an element of the Reals. 

I might change that one. But this has nothing to do with how elegant Julia 
is or how smooth it's OOP paradigm is. It's just a name I made up. I could 
have called it anything, including Fred!

And given that I was essentially forced to use ZZ instead of my preferred 
Integer for a bigint, I think there is no great harm done in using FField 
instead of FFElem. It's just a name.

I certainly won't be ch

[sage-devel] Re: How practical/useful would a native windows subset be?

[Dima Pasechnik]

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) 
 wrote:
> --089e01537eba8a9d2805016fca81
> Content-Type: text/plain; charset=UTF-8
>
> It seems Sage really could do with a native windows port. I am wondering
> how practical it would be to make a version which is a subset of Sage, with
> something like Qt which runs on Windows,  Linux,  OSX and Solaris and has
> the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.


-- 
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.

[sage-devel] Re: SageMathCloud / closed source / GPL / Spirit of Sage??

[maldun]

I don't think it's a bad idea to make something partly commercial. 

>From the moral point of view I may cite Richard Stallmann ( 
http://www.gnu.org/philosophy/selling.html ):

> Many people believe that the spirit of the GNU Project is that you should 
> not charge money for distributing copies of software, or that you should 
> charge as little as possible—just enough to cover the cost. This is a 
> misunderstanding.
>
> Actually, we encourage people who redistribute free software 
>  to charge as much as they 
> wish or can. If this seems surprising to you, please read on.
>

 Making money of opensource is not a bad thing. One can sell service, 
support and simple methods to work everything out of the box and maybe some 
nice extras.
The people who don't need this fancy stuff and are able to type 'make' in 
their shell can still download the source and get everything working on 
their own.

That's the way many commercial Open Source projects like Red Hat 
Enterprice, Android, or even Numpy work.

What should be avoided is of course making parts of the 'core' sage closed 
source. This should only maybe affect maybe some webapp stuff. (Why not 
sell a nice app on Google play?)
Sage is made from volunteer work, and taking money for service is fine, as 
long active developers who spend their freetime in making sage better
still have the right to get their software free of charge, and don't have 
drawbacks in using it.
 

On Friday, August 15, 2014 10:42:14 AM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> As I understand it, the SageMathCloud is closed source. Yet it is 
> making extensive use of open-source code. Maybe the closed source bits 
> don't link to the open-source bits, though I find it a bit hard to 
> believe. If it did not link, it would not that be against the GPL? Or 
> I guess if the code is not distibuted, but only kept on a server, it 
> probably gets around the GPL. 
>
> If not against the GPL, this certainly seems to be going against the 
> *spirit* of the Sage project. It looks as though the intention is to 
> charge for access to a web service which makes use of open-source code 
> developed by many - myself included. 
>
> One might argue it is the same with any web service making use of 
> Apache for example, although I still think a closed-source 
> SageMathCloud is pushing the limits of what some (myself included), 
> find morally acceptable. 
>
> The only comment on the Wikipedia talk page 
>
> http://en.wikipedia.org/wiki/Talk:SageMathCloud 
>
> says "Unfortunately, some part of it is becoming closed source. And, 
> they will charge for the many of the services..." I don't know who 
> wrote that, but it was not me. 
>
> Maybe it is legal. I don't think it is morally right. 
>
> Dave 
>

-- 
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.

[sage-devel] Re: How practical/useful would a native windows subset be?

[maldun]

Hi!

Python XY ( https://code.google.com/p/pythonxy/ )and WinPython 
(http://winpython.sourceforge.net/) do this for years now and are working 
properly. Maybe one can use this as a start since many of the needed 
prequisites are there.

but why not concentrate on a working cygwin port, and bundle everything to 
a working standalone executable? This would avoiding rewriting and 
spliiting the code in several parts which would also need to be maintained 
seperately.

On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> It seems Sage really could do with a native windows port. I am wondering 
> how practical it would be to make a version which is a subset of Sage, with 
> something like Qt which runs on Windows,  Linux,  OSX and Solaris and has 
> the look and feel of those platforms. 
>
> It could make a Google Summer of Code project. 
>
> If a small subset could be implemented,  the chances are reasonable that 
> others might port more bits. If it could do more than a scientific 
> calculator,  that would probably be enough to get people using it.  Call it 
> "Mini Sage" or something similar to indicate it is not the full version. 
>
> I believe that there are some are some bits of Sage that uses fork and has 
> have no Windows equivalent, so those bits could be left out. Perhaps at a 
> later date a complete rewrite of such bits could form other GSOC projects. 
>
> The download size of such a subset would be smaller than the full version 
> and MUCH smaller that a virtual machine image, as one doesn't need to 
> include a complete operating system too.
>
> Wolfram Research did at one point offer a subset of Mathematica, which i 
> think was called Calc Centre, but I think it was a bit of a flop, so I 
> don't think that they sell it any more. That might be an argument for not 
> doing a partial native port. 
>
> If a partial port was done, avoiding the need for a browser, one could use 
> its own parser and provide a more confident interface.  Although many are 
> critical of Mathematica's interface,  it is more consistent than that of 
> Sage.
>
> Dave
>

-- 
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.

[sage-devel] How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows,  Linux,  OSX and Solaris and has
the look and feel of those platforms.

It could make a Google Summer of Code project.

If a small subset could be implemented,  the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator,  that would probably be enough to get people using it.  Call it
"Mini Sage" or something similar to indicate it is not the full version.

I believe that there are some are some bits of Sage that uses fork and has
have no Windows equivalent, so those bits could be left out. Perhaps at a
later date a complete rewrite of such bits could form other GSOC projects.

The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.

Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.

If a partial port was done, avoiding the need for a browser, one could use
its own parser and provide a more confident interface.  Although many are
critical of Mathematica's interface,  it is more consistent than that of
Sage.

Dave

-- 
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: About docs (and code) of poset

[Jori Mantysalo]

On Mon, 25 Aug 2014, Travis Scrimshaw wrote:


In my experience, most people read the documentation in Sage using `?`
rather than the reference manual. So it's not a matter of where the method
is defined (you can think of the category like an ABC in this case).


OK. I have used to using html docs, but this of course varies.

Neither way, at least .show() function for poset does not tell about 
figsize-option etc.



 The short version why is_lattice is in the category is that
*every* finite poset can check if is a lattice (if it has implementations to
check if it's a join and meet semilattice). In fact, I would argue that
there are many methods of the current implementation of FinitePoset (with no
's', i.e., not the category) that could be moved into the category because
all objects of the category of finite posets should have them.


Trying to understand... mathematically there is kind of diamond inclusion 
of classes:


finite lattices \subset lattices
finite lattices \subset finite posets
lattices \subset posets
finite posets \subset posets

Which means that, for example, every function for finite lattice is 
available for finite poset, but not necessarily other way. On C++ 
this could be modelled with multiple inheritance.


But how come categories to this picture?

This is still quite confusing (or I am dumb, or both). To get posets of 
size 5 one can say


Posets(5)

which internally does something like

[x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()]

To get lattices of size 5 one says

[sage.combinat.posets.lattices.FiniteLatticePoset(x) for x in Posets(5) if 
x.is_lattice()]


Because a) FiniteLatticePoset is not available on global namespace and b) 
there is no ready method to get lattices of given size.


Am I right on this?

--
Jori Mäntysalo

--
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.

[sage-devel] Re: On scientific computing, Python and Julia

[Pierre]

> 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.
>

I guess to me the only names that would really make sense would be 
ZZElement <: RREelement <: RingElement (or else rename the builtin types to 
something else: it's "Integer" that's not the same of a set!! Rename it 
Integers and everything makes sense). Anyway, I probably need to learn to 
think differently about this.

I do wonder about one thing. Since it is not possible in Julia to have 
instances of abstract types, and you have ZZ <: RR with the possibility of 
doing ZZ(3) as well as RR(3), does it mean that you've created 
supplementary concrete types, say ZZ_concrete <: ZZ and RR_concrete <: RR 
or similar, together with a bunch of constructors to hide everything?

If so, I find this quite complicated. Here good old OOP treats this much 
more elegantly. But perhaps I am mistaken?

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.

Re: [sage-devel] sage make fail @ ntl

[Jori Mantysalo]

On Fri, 22 Aug 2014, Mark ODell wrote:


no default access control that I am aware of
though I do little with ACLs 
a specific command you would like run for output ?


cp -p tries to preserve ACL's. It gives warning, not error, when it can't.

So, it seems that ACL's are not problem. However, debugging stops quite 
early:


$ ./sage -i ntl
Package ntl-6.1.0.p0 is already installed.
Use 'sage -f /home/jm58660/sage-6.3/upstream/ntl-6.1.0.tar.bz2' to force a 
reinstallation.

$ ./sage -f /home/jm58660/sage-6.3/upstream/ntl-6.1.0.tar.bz2
 . . .
/home/jm58660/sage-6.3/src/bin/sage-spkg: line 601: cd: ntl-6.1.0.tar.bz2: No 
such file or directory

So sorry, no helps.

--
Jori Mäntysalo

--
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.

[sage-devel] Re: About docs (and code) of poset

[Travis Scrimshaw]

Hey Jori,
   The short version why is_lattice is in the category is that *every* 
finite poset can check if is a lattice (if it has implementations to check 
if it's a join and meet semilattice). In fact, I would argue that there are 
many methods of the current implementation of FinitePoset (with no 's', 
i.e., not the category) that could be moved into the category because all 
objects of the category of finite posets should have them.
   Now why is_distributive_lattice only a part of the Hasse diagram, I'm 
not quite sure. The antichains in the category is an abstract method (note 
the decorator for the method).

In my experience, most people read the documentation in Sage using `?` 
rather than the reference manual. So it's not a matter of where the method 
is defined (you can think of the category like an ABC in this case).

Best,
Travis


On Monday, August 25, 2014 3:23:30 PM UTC+9, Jori Mantysalo wrote:
>
> Let us imagine a person reading 
>
>
> http://www.sagemath.org/doc/reference/combinat/sage/combinat/posets/posets.html
>  
>
> It starts saying "implements finite partially ordered sets", so there is 
> no support for infinite posets. 
>
> This page tells a reader about has_bottom() and has_top(), and there is 
> also is_bounded() already. But for is_join_semilattice() ja 
> is_meet_semilattice() there is no is_lattice(). 
>
> Well, there is. It is here: 
>
> http://www.sagemath.org/doc/reference/categories/sage/categories/finite_posets.html
>  
>
> So, why is part of code in categories/*.py? 
>
> Then, how about is_distributive_lattice()? There it is: 
>
> http://www.sagemath.org/doc/reference/combinat/sage/combinat/posets/hasse_diagram.html
>  
> 
>  
> But how to call it? 
>
> And last, why is there antichains() documented in two places, 
> /combinat/posets/posets and /categories/finite_posets? 
>
> Confused am I. 
>
> -- 
> Jori Mäntysalo 
>

-- 
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.