[sage-devel] Re: The Sage Wiki

2017-03-21 Thread Matthew Rennekamp
Hi all. I've messed around with the wiki, too. Check out the expanded frontpage that I've taken to. Thoughts on that while I continue with it? I also have started removing some of the specific SPKG pages in order to keep it all on one wiki.sagemath.org/spkg page. That would help with trying to k

[sage-devel] Re: Name symbolic expressions

2017-03-21 Thread Eric Gourgoulhon
This is not what you are proposing but somehow related to it: provided you consider (x,y) as coordinates on a manifold, you may define g as a named function as follows: sage: M = Manifold(2, 'M') sage: X. = M.chart() # declares the chart X on M, with coordinates (x,y) sage: g = M.scalar_field

[sage-devel] Re: Default display for equations in notebook

2017-03-21 Thread Volker Braun
Instead of adding another %display option, why not fix the standard %display typeset? If mathjax can't display some object then it just shouldn't display using mathjax in jupyter. On Tuesday, March 21, 2017 at 12:31:08 AM UTC+1, Travis Scrimshaw wrote: > > Eric Gourgoulhon and I were discussi

Re: [sage-devel] Re: Default display for equations in notebook

2017-03-21 Thread William Stein
Hi, In case anybody cares, I'm doing a complete rewrite of the Jupyter frontend client from scratch (and also using nteract's node.js backend instead of the python backend). Thanks for mentioning some missing/desired features, e.g., customizability of a "typeset" checkbox. If anybody else has

[sage-devel] log(1+x).limit(x=-1) returns Infinity

2017-03-21 Thread Peleg Michaeli
Hi, log(1+x).limit(x=-1) returns Infinity, but should return -Infinity. It seems that the sympy algorithm solves this issue. Is this a known bug? Note also that `dir='+'` solves this, but the docs say that leaving `dir=None` should compute the two-sided limit (so perhaps a ValueError should b

Re: [sage-devel] Re: integration algorithms

2017-03-21 Thread rjf
On Monday, March 20, 2017 at 11:50:00 PM UTC-7, parisse wrote: > > I think that people who never wrote symbolic integration algorithms > underestimate the work required (this is also true in other areas, for > example simplification, UI, etc.). I believe that the current symbolic > integration

[sage-devel] Sage <-> Sympy conversion

2017-03-21 Thread mmancini
Hello to all, At the moment we need transform a symbolic expression from 'sage' to 'sympy', for explicit functions, sage works fine : sage: b = sin(x) sage: type(b) sage: type(sin) sage: a=b._sympy_() sin(x) sage: type(a) sin # this is strange! and viceversa import sympy sage: x=sym

Re: [sage-devel] Re: Default display for equations in notebook

2017-03-21 Thread Erik Bray
On Tue, Mar 21, 2017 at 1:26 PM, kcrisman wrote: > > > On Tuesday, March 21, 2017 at 7:00:56 AM UTC-4, Eric Gourgoulhon wrote: >> >> To add on Travis post, some rationale for having default LaTeX typeset >> outputs in the Jupyter notebook is >> - Jupyter is scheduled to be the default notebook in

[sage-devel] Re: Default display for equations in notebook

2017-03-21 Thread kcrisman
On Tuesday, March 21, 2017 at 7:00:56 AM UTC-4, Eric Gourgoulhon wrote: > > To add on Travis post, some rationale for having default LaTeX typeset > outputs in the Jupyter notebook is > - Jupyter is scheduled to be the default notebook in Sage 8.0 > - It is likely that users (especially beginner

Re: [sage-devel] Re: An "easy looking" computation in AA that sage can't do

2017-03-21 Thread Dima Pasechnik
On Monday, March 20, 2017 at 11:50:53 PM UTC, Nils Bruin wrote: > > On Monday, March 20, 2017 at 3:03:05 PM UTC-7, Dima Pasechnik wrote: >> >> >> surely you can do this, but it seems to be harder to certify if a number >> is zero or not. >> > > Exactly. That's the idea of Allan's approach: rathe

[sage-devel] Re: Default display for equations in notebook

2017-03-21 Thread Eric Gourgoulhon
To add on Travis post, some rationale for having default LaTeX typeset outputs in the Jupyter notebook is - Jupyter is scheduled to be the default notebook in Sage 8.0 - It is likely that users (especially beginners) who employ the notebook instead of the console are expecting to have "nice" outp

Re: [sage-devel] Warning, slow doctest vs. # long time

2017-03-21 Thread Jori Mäntysalo
On Tue, 21 Mar 2017, David Roe wrote: currently not stored anywhere.  The place you'll need to change is line 566 of sage/doctest/parsing.py, where you'll need to do something like Thanks for pointing right files. I opened #22661 for this and also put in some example code. -- Jori Mäntysalo

Re: [sage-devel] Warning, slow doctest vs. # long time

2017-03-21 Thread David Roe
Sure, but it will take some changes to the parser. Currently the #long tag only affects whether the test is added to the list of tests to be run. Once that has been decided, the fact that a test was marked with #long is currently not stored anywhere. The place you'll need to change is line 566 of

[sage-devel] Warning, slow doctest vs. # long time

2017-03-21 Thread Jori Mäntysalo
Is it possible to modify doctesting framework to have different time for tests marked with # long time? Something like sage --warn-long 1,10 could give warning for only doctests taking more than 10 seconds if they are explicitly marked as slow. -- Jori Mäntysalo