[sage-devel] Re: integration algorithms

The hidden goal with this is, of course, prepare for an incremental Rubi implementation which would come first. Since Rubi returns *optimal solutions and is rule-based (always returns) most of rjf's arguments don't bite. -- You received this message because you are subscribed to the Google

[sage-devel] Re: integration algorithms

Well known strategy for many tasks, probably never implemented. Why? 1. The first algorithm in the list might not terminate, so no alternative will be tried. (Serial processing...) 2. setting all alternatives going "in parallel" might work if you actually can do that with hardware; on a

Re: [sage-devel] integration algorithms

On Sunday, February 26, 2017 at 8:17:05 AM UTC-8, Michael Orlitzky wrote: > > > sage: f = function('f')(x) Please consider to stop using such assignments. It propagates a confusion between the *function* f and the *expression* f(x). The distinction is significant in sage and generally

Re: [sage-devel] integration algorithms

On Sunday, February 26, 2017 at 5:17:05 PM UTC+1, Michael Orlitzky wrote: > > It might not be easy to tell whether or not you got a real result back > from e.g. Maxima. The following "works", > > sage: f = function('f')(x) > sage: integrate(f,x) > integrate(f(x), x) It's easy to

Re: [sage-devel] integration algorithms

On 02/26/2017 01:52 AM, Ralf Stephan wrote: > Users of integrate() usually don't care which "algorithm" is used, > just that the thing is solved. At the moment the default behaviour > is calling Maxima only, and you have to know/read that you can > try other algorithms too. Many beginners don't

[sage-devel] Re: Why is "TERM" removed when spawning something?

On 2017-02-26, Volker Braun wrote: > There are comments in the code about that, do they not answer your question? The tickets do not explain why it is done unconditionally for all interfaces. So, I guess when implementing a polymake pexpect interface, I'm going to add an

Re: [sage-devel] SageNB -> Jupyter conversion needs testers

I was never a big user of the old notebooks but I had several lying around. This conversion worked pretty well for me. The only things I noticed were the following (which are maybe known): @ macros such as \QQ and \ZZ in (mathjax) text blocks were not recognised. The Sage notebook must have

[sage-devel] Re: Why is "TERM" removed when spawning something?

There are comments in the code about that, do they not answer your question? On Sunday, February 26, 2017 at 2:22:23 PM UTC+1, Simon King wrote: > > Hi! > > Trying to create a pexpect interface to Polymake, I came accross the > following problem: > > In sage.interfaces.expect.Expect._start,

[sage-devel] Re: KaLP - Karlsruhe Longest Paths

An now, successful results from KaDraw : draw graph to a PDF or PNG picture file. > 1. Use web browser to download kadraw from http://algo2.iti.kit.edu/kadraw/ > > - Indeed : not easy to visualize result of kalp, for the newbie in > specific tool graph representation > > tar tzvf

[sage-devel] Why is "TERM" removed when spawning something?

Hi! Trying to create a pexpect interface to Polymake, I came accross the following problem: In sage.interfaces.expect.Expect._start, there are two environment variables that are removed before spawning: 'TERM' and 'COLUMNS'. Why is that? The problem is that Polymake won't start unless TERM is

[sage-devel] Re: SageNB -> Jupyter conversion needs testers

We have trying in my university some solutions usingy jupyterhub; we have some ideas about sharing and we still do not know how safe it is. El sábado, 25 de febrero de 2017, 15:01:38 (UTC+1), kcrisman escribió: > > > At https://trac.sagemath.org/ticket/22433 there is a ticket implementing >> a

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

On 2017-02-26 10:57, Ralf Stephan wrote: The travis build failed. Usually git maintainers expect the PR submitter to check and fix all such failures. I know, but that's not the issue. They didn't say "yes we like your patch but you need to fix it". They said "why not do Y or Z instead" and I

[sage-devel] Re: KaLP - Karlsruhe Longest Paths

> > I will try Kadraw soon : http://algo2.iti.kit.edu/kadraw/ > for a graph drawing, in the same spirit than Christian Schultz's work Dominique -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: KaLP - Karlsruhe Longest Paths

Some tests today in SMC (maybe my comments need to be moved out from current google forum)... Install Kalp1.0 in the sagemath cloud... I use one way to test new package : build it in sagematch cloud. Other way (not checked by me) : sagemath local (without network) install 1. Read manual -

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

The travis build failed. Usually git maintainers expect the PR submitter to check and fix all such failures. On Sun, Feb 26, 2017 at 10:38 AM Jeroen Demeyer wrote: > On 2017-02-26 08:39, Francois Bissey wrote: > > That’s because python doesn’t do c++ compilation properly

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

On 2017-02-26 08:39, Francois Bissey wrote: That’s because python doesn’t do c++ compilation properly out of the box. That's true but that has nothing to do with Sage using -std=c99 for C++ extensions. I know how to fix this but it needs https://github.com/cython/cython/pull/466 which

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

On Sunday, February 26, 2017 at 7:27:45 AM UTC, Isuru Fernando wrote: > > Anybody know why some python extensions with C++ as the language are > compiled with -std=c99? I'm using sage-7.5.1 > > Log is below > > https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669 > wow, I didn't