Re: [sage-devel] Make JupyterLab a standard package

2018-03-14 Thread Jeroen Demeyer

On 2018-03-13 23:26, Samuel Lelièvre wrote:

What would it mean to make it an optional package?


Exactly the same as making it a standard package, except that the type 
is "optional" instead of "standard".


Once you do that, it will be trivial to make it a standard package by 
just changing the type.


--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Make JupyterLab a standard package

2018-03-14 Thread Jeroen Demeyer

On 2018-03-14 02:08, John H Palmieri wrote:

I feel like we need another class of package: "pending" (or perhaps some
other name) = those which we propose to make standard soon.


I agree with Vincent: the build system doesn't need to know that.

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Make JupyterLab a standard package

2018-03-14 Thread Jeroen Demeyer

On 2018-03-13 23:26, Samuel Lelièvre wrote:

My view is that since it's pip-installable, it's as though it were
already an optional package.


I have a very different view of that. "optional" implies a level of 
official support in SageMath. In particular, it should actually build 
and work properly on all supported systems.


--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] zero problem

2018-03-14 Thread Ralf Stephan
Hi,
Is the symbolic ring the only one where equality is polymorphic?

Comparison in SR can mean 1. "try to prove with certainty" or 2. "check if 
numeric zero".
Other rings may have different features. But are there other such 
constructs?

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Potential bug multiplying permutations from subgroups

2018-03-14 Thread Andrew
Is this me or is it a bug?

sage: S3 = SymmetricGroup(3)
sage: A3 = S3.subgroup([(1,2,3)])
: for x in S3:
: print('{:>7}: left coset  = {}'.format(x, [x*h for h in A3]))
: print('   : right coset = {}'.format([h*x for h in A3]))
:

 (): left coset  = [(), (1,2,3), (1,3,2)]
   : right coset = [(), (1,2,3), (1,3,2)]
  (1,2): left coset  = [(1,2), (1,3), (2,3)]
---
TypeError Traceback (most recent call last)
...
TypeError: unsupported operand parent(s) for *: 'Subgroup of (Symmetric 
group of order 3! as a permutation group) generated by [(1,2,3)]' and 
'Symmetric 
group of order 3! as a permutation group'
> /Users/andrew/Downloads/sage/structure/coerce.pyx(1168)sage.structure.
coerce.CoercionModel_cache_maps.bin_op (build/cythonized/sage/structure/
coerce.c:10861)()

I threw this into a sage notebook with the view to showing my students the 
virtues of normal subgroups...

Andrew

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Potential bug multiplying permutations from subgroups

2018-03-14 Thread Jeroen Demeyer

This is https://trac.sagemath.org/ticket/24612

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] zero problem

2018-03-14 Thread Vincent Delecroix

Yes QQbar.

On 14/03/2018 11:19, Ralf Stephan wrote:

Hi,
Is the symbolic ring the only one where equality is polymorphic?

Comparison in SR can mean 1. "try to prove with certainty" or 2. "check if
numeric zero".
Other rings may have different features. But are there other such
constructs?



--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

2018-03-14 Thread kcrisman
I recall discussions about this quite a few years ago, and the consensus 
was to be careful what you wish for.  Too many typos would then 
mysteriously become variables.  So (even though I certainly think it is a 
very useful facility in many case) the potential for confusion was pretty 
great.  I think a nice use case of it is at the top of a worksheet prepared 
by an instructor who is not a 100% novice.

By the way, there was a similar method (perhaps the same one) that allowed 
methods to be functions, e.g. you could do foo(x) instead of x.foo() for 
simplicity.

Anyway, certainly it should (in principle) be *implemented* for any Sage 
interface, including Jupyter.  I just don't know about it becoming the 
default.

- kcrisman

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Make JupyterLab a standard package

2018-03-14 Thread kcrisman


On Tuesday, March 13, 2018 at 1:33:19 PM UTC-4, Samuel Lelievre wrote:
>
> Let me try to make the case for making JupyterLab a standard package.
>
> (1)
>
> According to a recent post on the Jupyter blog [0],
>
> - JupyterLab is ready for daily use.
> - JupyterLab will eventually replace the classic Jupyter Notebook.
>

"JupyterLab 1.0 will eventually replace the classic Jupyter Notebook. 
Throughout this transition, the same notebook document format will be 
supported by both the classic Notebook and JupyterLab." 

So do we have to yet *again* reimplement notebook interactivity?  How 
different are they?  How does that affect people wanting to upgrade their 
notebooks - let alone from sagenb?  What about the CoCalc .sagews format? 
 And the CoCalc Jupyter notebooks?  I feel like there are some interesting 
unanswered questions here.

Certainly optional package is fine, though, as long as it works properly on 
all supported platforms.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

2018-03-14 Thread Erik Bray
On Wed, Mar 14, 2018 at 12:52 PM, kcrisman  wrote:
> I recall discussions about this quite a few years ago, and the consensus was
> to be careful what you wish for.  Too many typos would then mysteriously
> become variables.  So (even though I certainly think it is a very useful
> facility in many case) the potential for confusion was pretty great.  I
> think a nice use case of it is at the top of a worksheet prepared by an
> instructor who is not a 100% novice.
>
> By the way, there was a similar method (perhaps the same one) that allowed
> methods to be functions, e.g. you could do foo(x) instead of x.foo() for
> simplicity.
>
> Anyway, certainly it should (in principle) be *implemented* for any Sage
> interface, including Jupyter.  I just don't know about it becoming the
> default.

Certainly nobody's talking about turning it on by default--just that
the feature exists, people do use it, and there's no reason it should
be exclusive to the sage notebook.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Potential bug multiplying permutations from subgroups

2018-03-14 Thread Dima Pasechnik


On Wednesday, March 14, 2018 at 11:03:36 AM UTC, Andrew wrote:
>
> Is this me or is it a bug?
>
> sage: S3 = SymmetricGroup(3)
> sage: A3 = S3.subgroup([(1,2,3)])
> : for x in S3:
> : print('{:>7}: left coset  = {}'.format(x, [x*h for h in A3]))
> : print('   : right coset = {}'.format([h*x for h in A3]))
> :
>
>  (): left coset  = [(), (1,2,3), (1,3,2)]
>: right coset = [(), (1,2,3), (1,3,2)]
>   (1,2): left coset  = [(1,2), (1,3), (2,3)]
> ---
> TypeError Traceback (most recent call last
> )
> ...
> TypeError: unsupported operand parent(s) for *: 'Subgroup of (Symmetric 
> group of order 3! as a permutation group) generated by [(1,2,3)]' and 
> 'Symmetric 
> group of order 3! as a permutation group'
> > /Users/andrew/Downloads/sage/structure/coerce.pyx(1168)sage.structure.
> coerce.CoercionModel_cache_maps.bin_op (build/cythonized/sage/structure/
> coerce.c:10861)()
>
> I threw this into a sage notebook with the view to showing my students the 
> virtues of normal subgroups...
>
> In case, the following (yes, a bit ugly) works:

sage: S3 = libgap.SymmetricGroup(3)
sage: A3 = S3.Subgroup([libgap.eval("(1,2,3)")])
sage: for x in S3.Elements():
:print('{:>7}: left coset  = {}'.format(x, [x*h for h in 
A3.Elements()]
: ))
:print('   : right coset = {}'.format([h*x for h in 
A3.Elements()])
: )
:
 (): left coset  = [(), (1,2,3), (1,3,2)]
   : right coset = [(), (1,2,3), (1,3,2)]
  (2,3): left coset  = [(2,3), (1,2), (1,3)]
   : right coset = [(2,3), (1,3), (1,2)]
  (1,2): left coset  = [(1,2), (1,3), (2,3)]
   : right coset = [(1,2), (2,3), (1,3)]
(1,2,3): left coset  = [(1,2,3), (1,3,2), ()]
   : right coset = [(1,2,3), (1,3,2), ()]
(1,3,2): left coset  = [(1,3,2), (), (1,2,3)]
   : right coset = [(1,3,2), (), (1,2,3)]
  (1,3): left coset  = [(1,3), (2,3), (1,2)]
   : right coset = [(1,3), (1,2), (2,3)]

This is basically GAP called with Python syntax :-)

 

> Andrew
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

2018-03-14 Thread Dima Pasechnik
On Wednesday, March 14, 2018 at 6:42:33 AM UTC, vdelecroix wrote:
>
> As mentioned on the ticket, this big-endian incompatibility does not 
> prevent the inclusion of primecount as an "experimental package" that I 
> still aim to achieve (the type of the package "experimental", "optional" 
> or "standard" is simply a flag). In practice "experimental" means "not 
> officially supported" and "less tested". 
>
> And as Dima mentioned, it would be simpler for SageMath to have 
> primecount supporting big-endian. We certainly do not want that a single 
> library prevents using SageMath on big-endian architecture. 
>
> Now, three questions for Sage developers: 
>
> - Who is testing a big-endian architecture? 
>
> - Are all optional packages big-endian compatible? 
>
> - Is it reasonable to ask for big-endian compatibility for 
>optional packages? 
>

The current status of big-endian Sage is that it sort of works on SPARC 
Solaris 11 (thanks to Jeroen and your humble servant),
but more work is needed. I  underestimated how much effort it would be, 
when I started this back in January. :-)
Interesting (and not so interesting) upstream bugs emerged in many 
packages...

see https://trac.sagemath.org/ticket/24596

The machine is a VM (Solaris "zone") hosted at Warwick University, and we 
would be able to run a patchbot there,
once the port iis in reasonable shape.

I understand that there are other big-endian architectures out there 
capable of running Sage.
(they are often able to do both big- and little-endian, though)

Dima



> Vincent 
>
> PS: to discuss these kind of issues related to development, it is better 
> to use the other google group sage-devel. 
>
> On 13/03/2018 23:11, Dima Pasechnik wrote: 
> > 
> > 
> > On Tuesday, March 13, 2018 at 9:41:50 PM UTC, Kim Walisch wrote: 
> >> 
> >> Hi, 
> >> 
> >> We all know that the big-endian CPU architecture is slowly dying, 
> >> some people even state that "Big-Endian is effectively dead". 
> >> 
> >> So my question is: Does sagemath still support big-endian CPU 
> >> architectures like e.g. 32-bit Sparc? 
> >> 
> > 
> > We have recently more or less revived a SPARC Solaris 11 port of 
> Sagemath. 
> > So yes, please, make it both-endian... 
> > 
> > 
> >   
> > 
> >> 
> >> I am asking because there is a ticket 
> >> (https://trac.sagemath.org/ticket/24966 
> >> <
> https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F24966&sa=D&sntz=1&usg=AFQjCNHvco5SWFB7CiS50MxgtC2P8g3mxA>)
>  
>
> >> to integrate my primecount 
> >> library into sagemath and primecount currently only supports 
> >> little-endian CPUs. I could support big-endian CPUs but I want to 
> >> make sure this is required by sagemath. 
> >> 
> >> Thanks, 
> >> Kim 
> >> 
> > 
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

2018-03-14 Thread Jean-Pierre Flori
I have (or used to have) access to a power 7 machine and so did Francois 
Bissey IIRC.
Things were in quite good shape there.

On Wednesday, March 14, 2018 at 1:52:07 PM UTC+1, Dima Pasechnik wrote:
>
> On Wednesday, March 14, 2018 at 6:42:33 AM UTC, vdelecroix wrote:
>>
>> As mentioned on the ticket, this big-endian incompatibility does not 
>> prevent the inclusion of primecount as an "experimental package" that I 
>> still aim to achieve (the type of the package "experimental", "optional" 
>> or "standard" is simply a flag). In practice "experimental" means "not 
>> officially supported" and "less tested". 
>>
>> And as Dima mentioned, it would be simpler for SageMath to have 
>> primecount supporting big-endian. We certainly do not want that a single 
>> library prevents using SageMath on big-endian architecture. 
>>
>> Now, three questions for Sage developers: 
>>
>> - Who is testing a big-endian architecture? 
>>
>> - Are all optional packages big-endian compatible? 
>>
>> - Is it reasonable to ask for big-endian compatibility for 
>>optional packages? 
>>
>
> The current status of big-endian Sage is that it sort of works on SPARC 
> Solaris 11 (thanks to Jeroen and your humble servant),
> but more work is needed. I  underestimated how much effort it would be, 
> when I started this back in January. :-)
> Interesting (and not so interesting) upstream bugs emerged in many 
> packages...
>
> see https://trac.sagemath.org/ticket/24596
>
> The machine is a VM (Solaris "zone") hosted at Warwick University, and we 
> would be able to run a patchbot there,
> once the port iis in reasonable shape.
>
> I understand that there are other big-endian architectures out there 
> capable of running Sage.
> (they are often able to do both big- and little-endian, though)
>
> Dima
>
>
>
>> Vincent 
>>
>> PS: to discuss these kind of issues related to development, it is better 
>> to use the other google group sage-devel. 
>>
>> On 13/03/2018 23:11, Dima Pasechnik wrote: 
>> > 
>> > 
>> > On Tuesday, March 13, 2018 at 9:41:50 PM UTC, Kim Walisch wrote: 
>> >> 
>> >> Hi, 
>> >> 
>> >> We all know that the big-endian CPU architecture is slowly dying, 
>> >> some people even state that "Big-Endian is effectively dead". 
>> >> 
>> >> So my question is: Does sagemath still support big-endian CPU 
>> >> architectures like e.g. 32-bit Sparc? 
>> >> 
>> > 
>> > We have recently more or less revived a SPARC Solaris 11 port of 
>> Sagemath. 
>> > So yes, please, make it both-endian... 
>> > 
>> > 
>> >   
>> > 
>> >> 
>> >> I am asking because there is a ticket 
>> >> (https://trac.sagemath.org/ticket/24966 
>> >> <
>> https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F24966&sa=D&sntz=1&usg=AFQjCNHvco5SWFB7CiS50MxgtC2P8g3mxA>)
>>  
>>
>> >> to integrate my primecount 
>> >> library into sagemath and primecount currently only supports 
>> >> little-endian CPUs. I could support big-endian CPUs but I want to 
>> >> make sure this is required by sagemath. 
>> >> 
>> >> Thanks, 
>> >> Kim 
>> >> 
>> > 
>>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: GitHub authentication is live on trac.sagemath.org

2018-03-14 Thread Erik Bray
On Wed, Mar 14, 2018 at 12:33 AM, Dima Pasechnik  wrote:
> Perhaps it's a silly suggestion, but what does prevent trac from using an
> external git server, as opposed
> to the internal one? Does it need to do git calls which are not possible to
> do remotely?
> If this is possible (perhaps there is even a trac plugin for this?) then it
> would be possible to use, say, github to
> hold branches, and not git.sagemath.org...)

This is something I am working on *in addition to* the existing
git.sagemath.org.  I am also investigating using GitLab for this
purpose.  The use of GitLab has a couple motivations:
1) Julian Rüth's work on a new continuous integration system for Sage,
particularly using GitLab in nice ways:
https://trac.sagemath.org/ticket/24655
2) Being possibly more politically acceptable to some, at least as
middle-ground (it's all open-source; can move to self-hosted if need
be).

This would not be as a *replacement* to Trac mind you--just a
companion.  We might pursue more GitHub integration in addition to
GitLab; I haven't ruled it out (e.g. opening Trac tickets for pull
requests from GH).

More on this as more of the details come into focus.

> On Friday, March 2, 2018 at 12:14:08 AM UTC, Erik Bray wrote:
>>
>> On Mar 2, 2018 01:00, "Erik Bray"  wrote:
>>
>> I'm not sure what "git trac config" does. If you've configured your SSH
>> key then there's nothing else to do but push branches. There's nothing to
>> use a username or password for.
>>
>>
>> Oh I see now. This is Sage's git extensions for creating tickets on Sage's
>> Trac server. I forgot about this since I haven't used it, but I can see how
>> it's convenient.
>>
>> The GitHub authentication doesn't know anything about your GitHub
>> password. You'll notice that you (probably, unless you needed to log into
>> GitHub) never provided your GitHub password. Instead you just authorize
>> Sage's Trac site to use your existing GitHub credentials to authorize you.
>>
>> So the "git trac" commands won't currently work with this I guess, though
>> I could make that work. In the meantime you can always create tickets
>> through the web interface and use the normal "git push" command to push
>> branches. The only thing "git trac" needs any additional credentials for is
>> creating and updating Trac tickets from the command line.
>>
>>
>> On Mar 1, 2018 10:21, "Dima Pasechnik"  wrote:
>>>
>>> AFAIK, github login only allows you to comment on tickets. Commit access
>>> to trac git repo needs to be obtained in the old way.
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To post to this group, send email to sage-...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: GitHub authentication is live on trac.sagemath.org

2018-03-14 Thread William Stein
On Wed, Mar 14, 2018 at 8:36 AM Erik Bray  wrote:

> On Wed, Mar 14, 2018 at 12:33 AM, Dima Pasechnik 
> wrote:
> > Perhaps it's a silly suggestion, but what does prevent trac from using an
> > external git server, as opposed
> > to the internal one? Does it need to do git calls which are not possible
> to
> > do remotely?
> > If this is possible (perhaps there is even a trac plugin for this?) then
> it
> > would be possible to use, say, github to
> > hold branches, and not git.sagemath.org...)
>
> This is something I am working on *in addition to* the existing
> git.sagemath.org.  I am also investigating using GitLab for this
> purpose.  The use of GitLab has a couple motivations:
> 1) Julian Rüth's work on a new continuous integration system for Sage,
> particularly using GitLab in nice ways:
> https://trac.sagemath.org/ticket/24655
> 2) Being possibly more politically acceptable to some, at least as
> middle-ground (it's all open-source; can move to self-hosted if need
> be).


Minor nitpick -- Gitlab is "open core", not open source:
https://about.gitlab.com/2016/07/20/gitlab-is-open-core-github-is-closed-source/


>
> This would not be as a *replacement* to Trac mind you--just a
> companion.  We might pursue more GitHub integration in addition to
> GitLab; I haven't ruled it out (e.g. opening Trac tickets for pull
> requests from GH).
>
> More on this as more of the details come into focus.
>
> > On Friday, March 2, 2018 at 12:14:08 AM UTC, Erik Bray wrote:
> >>
> >> On Mar 2, 2018 01:00, "Erik Bray"  wrote:
> >>
> >> I'm not sure what "git trac config" does. If you've configured your SSH
> >> key then there's nothing else to do but push branches. There's nothing
> to
> >> use a username or password for.
> >>
> >>
> >> Oh I see now. This is Sage's git extensions for creating tickets on
> Sage's
> >> Trac server. I forgot about this since I haven't used it, but I can see
> how
> >> it's convenient.
> >>
> >> The GitHub authentication doesn't know anything about your GitHub
> >> password. You'll notice that you (probably, unless you needed to log
> into
> >> GitHub) never provided your GitHub password. Instead you just authorize
> >> Sage's Trac site to use your existing GitHub credentials to authorize
> you.
> >>
> >> So the "git trac" commands won't currently work with this I guess,
> though
> >> I could make that work. In the meantime you can always create tickets
> >> through the web interface and use the normal "git push" command to push
> >> branches. The only thing "git trac" needs any additional credentials
> for is
> >> creating and updating Trac tickets from the command line.
> >>
> >>
> >> On Mar 1, 2018 10:21, "Dima Pasechnik"  wrote:
> >>>
> >>> AFAIK, github login only allows you to comment on tickets. Commit
> access
> >>> to trac git repo needs to be obtained in the old way.
> >>>
> >>> --
> >>> 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+...@googlegroups.com.
> >>> To post to this group, send email to sage-...@googlegroups.com.
> >>> Visit this group at https://groups.google.com/group/sage-devel.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > 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 https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
-- William Stein

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Elementary vector calculus with Sage

2018-03-14 Thread Eric Gourgoulhon
Hi,

After demands from users (see e.g. 
https://ask.sagemath.org/question/40792/div-grad-and-curl-once-again/ 
and
https://ask.sagemath.org/question/10104/gradient-divergence-curl-and-vector-products/)
 
and a first attempt (see ticket #3021 
), a proposal to fully implement 
elementary vector calculus (dot and cross products, gradient, divergence, 
curl, Laplace operator) is ready for review at #24623 
.

In this implementation, Euclidean spaces are considered as Riemannian 
manifolds diffeomorphic to R^n endowed with a flat metric. This allows for 
an easy use of various coordinate systems, along with the related 
transformations. However, the user interface does not assume any knowledge 
of Riemannian geometry. In particular, no direct manipulation of the metric 
tensor is required.

A minimal example is

sage: E. = EuclideanSpace(3)
sage: v = E.vector_field(-y, x, 0)
sage: v.display()
-y e_x + x e_y
sage: v[:]
[-y, x, 0]
sage: w = v.curl()
sage: w.display()
2 e_z
sage: w[:]
[0, 0, 2]

It is possible to use curl(v) instead of v.curl(), via

sage: from sage.manifolds.operators import *
sage: w = curl(v)

This can be compared with the curl() already implemented (through #3021 
)  for vectors of symbolic 
expressions:

sage: x, y, z = var('x y z')
sage: v = vector([-y, x, 0])
sage: v
(-y, x, 0)
sage: w = v.curl([x, y, z])
sage: w
(0, 0, 2)


Note that [x, y, z] must be provided as the argument of curl to define the 
orientation. A limitation of this implementation is that it is valid only 
with Cartesian coordinates. With the #24623 
 implementation, we can do, in 
continuation with the first piece of code shown above:

sage: spherical. = E.spherical_coordinates()
sage: spherical_frame = E.spherical_frame()  # orthonormal frame (e_r, 
e_th, e_ph)
sage: v.display(spherical_frame, spherical)
r*sin(th) e_ph
sage: v[spherical_frame, :, spherical]
[0, 0, r*sin(th)]
sage: w.display(spherical_frame, spherical)
2*cos(th) e_r - 2*sin(th) e_th
sage: w[spherical_frame, :, spherical]
[2*cos(th), -2*sin(th), 0]


More detailed examples are provided in the following Jupyter notebooks 
(click on the names to see them via nbviewer.jupyter.org):

- vector calculus in Cartesian coordinates 

​- vector calculus in spherical coordinates 

- vector calculus in cylindrical coordinates 

​- changing coordinates in the Euclidean 3-space 

- ​advanced aspects: Euclidean spaces as Riemannian manifolds 

​- the Euclidean plane 


Needless to say, any feedback / review is welcome.

Eric.






-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

2018-03-14 Thread François Bissey
I haven’t done on a build on that hardware (power7) in some time. One of my 
limitation
is that I cannot install a more modern linux on those without breaking my
access to the GPFS file system. I have a beefy gentoo prefix on there though,
so I can technically test sage-on-gentoo on top.

> On 15/03/2018, at 02:32, Jean-Pierre Flori  wrote:
> 
> I have (or used to have) access to a power 7 machine and so did Francois 
> Bissey IIRC.
> Things were in quite good shape there.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Block TermOrder equality is broken

2018-03-14 Thread mwageringel
Hi all!

There appears to be a bug involving block orders. The equality for 
TermOrder does not take lengths into account, so two different block 
orderings are considered equal. As a result, trying to change the block 
sizes of a polynomial ring has no effect, as the ring is cached.

sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)")
sage: S = R.change_ring(order="lex(2),lex(4)")
sage: R.term_order() != S.term_order()
False
sage: R is S
True
sage: TermOrder("lex(1),lex(5)") == TermOrder("lex(2),lex(4)")
True

Although the source code for TermOrder mentions that lengths are not 
considered for equality, this seems to be incorrect behaviour in case of 
block orderings.

I am using Sage 8.1 on OS X 10.13.

Markus

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Nauty as a default generator for graphs

2018-03-14 Thread Nicolas M. Thiery
On Fri, Mar 09, 2018 at 08:19:19AM +0200, Jori Mäntysalo wrote:
> It is much faster to say sum(1 for _ in graphs.nauty_geng(7)) than sum(1 for
> _ in graphs(7)), and after #19919 we have nauty as a standard package.
> 
> Will I break something if I change graphs(n) without any additional
> parameter to use nauty? A user really needing the old code could then say
> graphs(n, property=lambda x: True). I think that Sage documentation makes no
> promise at all about the order in which graphs are generated.

I am all for it. Nauty is sooo much faster. In fact, I'd be glad if
some of Nauty's arguments would be exposed, in particular to generate
acyclic graphs, ...

Cheers,
Nicolas

PS: +1 as well to Graphs(10), in particular to provide an easy access
point for computing the number of graphs using Pólya enumeration. Yes,
we need to settle for a definition of containment, but that should not
be too hard.

--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Workshop on interfacing (math) software with low level libraries

2018-03-14 Thread Nicolas M. Thiery
Dear SageMath developers,

This is a reminder of ODK's workshop on "Interfacing (math) software
with low-level libraries", April 30th-May 4th in Cernay near Paris:

https://github.com/OpenDreamKit/OpenDreamKit/issues/251

Registrations have started (see the web page).

Details:

(Math) Computational systems face a tension between using high level
languages (e.g. Python) for expressivity, ease of use and prototyping,
and low-level languages (e.g. C/C++) for power and speed, and also for
modularity (using existing libraries, or writing reusable ones). To
resolve this tension, many approaches have been explored in the recent
years, and the frontier between the two worlds is becoming
increasingly blurry.

The purpose of this workshop is to bring together developers to share
expertise, seek collaboration venues, and get into concrete action.
This is quite bold. The focus on math software should keep this
manageable, while providing a large enough variety of solutions and
use cases.

- Developers of "binding systems" such as cppyy, pybind11, Boost Python
- Developers of "compilers" such as Cython, Pythran, Numba
- Developers of interactive C++ environments (cling, xeus-cling, xtensor, ...)

- Developers of (math) libraries in a low level language that wish to
  make their code accessible to a variety of users (e.g.
  libsemigroups, or low-level combinatorics HPCombi, number theory and
  arithmetic FLINT; in general developers of C-level interfaces to
  various systems: libSingular, libgap, cypari, cypari2, giacpy,
  PyNormaliz, Linbox, meataxe;

- Developers of systems like GAP, SageMath, Oscar, Mathemagix, ROOT
  that make a heavy use of such technologies

- Developers of programming languages like Julia
- ...

Organizers:
- Vincent Delecroix, Serge Gelton, Florent Hivert, Nicolas Thiéry

Funding:

OpenDreamKit should be able to fund all the local expenses (as in
previous workshops in Cernay), the travel expenses of ODK members, and
the travel expenses of some invited people.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

- End forwarded message -
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

- End forwarded message -
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

2018-03-14 Thread Dima Pasechnik


On Wednesday, March 14, 2018 at 8:05:05 PM UTC, François Bissey wrote:
>
> I haven’t done on a build on that hardware (power7) in some time. One of 
> my limitation 
> is that I cannot install a more modern linux on those without breaking my 
> access to the GPFS file system. I have a beefy gentoo prefix on there 
> though, 
> so I can technically test sage-on-gentoo on top. 
>

I wonder whether you're running your power7 in little-endian mode there.
Naturally it would be more interesting to see whether a big-endian setup 
works.

Dima 

>
> > On 15/03/2018, at 02:32, Jean-Pierre Flori  > wrote: 
> > 
> > I have (or used to have) access to a power 7 machine and so did Francois 
> Bissey IIRC. 
> > Things were in quite good shape there. 
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

2018-03-14 Thread François Bissey


> On 15/03/2018, at 11:56, Dima Pasechnik  wrote:
> 
> On Wednesday, March 14, 2018 at 8:05:05 PM UTC, François Bissey wrote:
> I haven’t done on a build on that hardware (power7) in some time. One of my 
> limitation 
> is that I cannot install a more modern linux on those without breaking my 
> access to the GPFS file system. I have a beefy gentoo prefix on there though, 
> so I can technically test sage-on-gentoo on top. 
> 
> I wonder whether you're running your power7 in little-endian mode there.
> Naturally it would be more interesting to see whether a big-endian setup 
> works.
> 

big-endian, moving to little endian would mean getting some updates for
the thin layer hypervisor that sits on top of the hardware and that
would means paying some support money I don’t have.

While power always could technically be setup in any endianness, the 
support for little endian has only been forthcoming from IBM with
the arrival of power8. Way after we bought the hardware.

François

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Sage Days 100

2018-03-14 Thread Nicolas M. Thiery
Dear Sage developers,

With Sage Days 96 announced, we are getting close from Sage Days 100!

Time to celebrate :-)

Shall we take action and decide which upcoming Sage bears a special
meaning to us and should hold this symbolic number?

I suggest that anyone who cares nominates some Sage Days. I personally
would like to nominate the upcoming Women in Sage in Montreal
(currently SD95).

Cheers,
Nicolas

[1] in fact, we already are past 100 workshops, with all the .5 and
.25 workshops, not counting the bug days & such.

--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Block TermOrder equality is broken

2018-03-14 Thread Kwankyu Lee
Hi,

Which part of the output you consider wrong? Would you elaborate on the 
"incorrect behaviour"?


Kwankyu

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Block TermOrder equality is broken

2018-03-14 Thread Nils Bruin
On Thursday, March 15, 2018 at 12:44:39 AM UTC, Kwankyu Lee wrote:
>
> Hi,
>
> Which part of the output you consider wrong? Would you elaborate on the 
> "incorrect behaviour"?
>
>
sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)")
sage: S = R.change_ring(order="lex(2),lex(4)")
sage: S.term_order()

Block term order with blocks:
(Lexicographic term order of length 1,
 Lexicographic term order of length 5)

Clearly, the term order of S does not seem to be correctly set.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Block TermOrder equality is broken

2018-03-14 Thread Kwankyu Lee


On Thursday, March 15, 2018 at 9:59:44 AM UTC+9, Nils Bruin wrote:
>
> On Thursday, March 15, 2018 at 12:44:39 AM UTC, Kwankyu Lee wrote:
>>
>> Hi,
>>
>> Which part of the output you consider wrong? Would you elaborate on the 
>> "incorrect behaviour"?
>>
>>
> sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)")
> sage: S = R.change_ring(order="lex(2),lex(4)")
> sage: S.term_order()
>
> Block term order with blocks:
> (Lexicographic term order of length 1,
>  Lexicographic term order of length 5)
>
> Clearly, the term order of S does not seem to be correctly set.
>

The two term orders are mathematically the same. We cannot say that this 
behavior is wrong.  What harm does this behavior make?

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Block TermOrder equality is broken

2018-03-14 Thread Simon King
Hi Kwankyu,

On 2018-03-15, Kwankyu Lee  wrote:
>> sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)")
>> sage: S = R.change_ring(order="lex(2),lex(4)")
>> sage: S.term_order()
>>
>> Block term order with blocks:
>> (Lexicographic term order of length 1,
>>  Lexicographic term order of length 5)
>>
>> Clearly, the term order of S does not seem to be correctly set.
>>
>
> The two term orders are mathematically the same. We cannot say that this 
> behavior is wrong.  What harm does this behavior make?

1. They are programmatically not the same, i.e., in some applications,
   one of the orders would be more efficient, in other applications, the
   other order would be more efficient.
2. In the following example, the orders of R and S are supposed to be
   mathematically different, yet the rings are identical in Sage:

   sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),degrevlex(5)")
   sage: S = R.change_ring(order="lex(2),degrevlex(4)")
   sage: R is S
   True

So, indeed it is a bug.
Cheers,
Simon

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.