Re: [sage-devel] Re: integration algorithms

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

Re: [sage-devel] Re: integration algorithms

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 implementations are good enough whatever you choose in Maxima, Axiom flav

Re: [sage-devel] Re: integration algorithms

On Mon, Mar 20, 2017 at 10:01 PM, rjf wrote: > People have been working on computer programs for integration since about > 1961. There are > at least 8 PhD theses on the topic. > > If you think there is "low hanging fruit" like writing a better > simplification program, or > using binary search

[sage-devel] Re: integration algorithms

People have been working on computer programs for integration since about 1961. There are at least 8 PhD theses on the topic. If you think there is "low hanging fruit" like writing a better simplification program, or using binary search instead of pattern matching, or something else you just

[sage-devel] Re: integration algorithms

> > ...In principle there can be fast progress if the first version only > implements general fallback rules like the mentioned 2F1 solutions. Many > Rubi rules only specialize 2F1 solutions, a sort of > simplify_hypergeometric() if you want. But then, with only the > hypergeometric (H) rules

[sage-devel] Re: integration algorithms

On Monday, March 20, 2017 at 3:38:01 AM UTC+1, saad khalid wrote: > > ... Also, Sage often gives solutions that are not as simple as possible, > in the sense that they look ugly often. I think this would help with that. > Note that an alternative for this could be to implement special smplificat

[sage-devel] Re: integration algorithms

My guess is that Mathematica added more special functions and integration methods using them mainly for advertising, not because some researchers needed them, otherwise some of them would probably work on this in an open-source CAS. About step by step, I cover some cases, for example http://www-

[sage-devel] Re: integration algorithms

I think it's not a relevant question to ask "when we'd want student to pull out their smartphone to do integrals." The fact is that students already Can do this, whether or not this should be integrated into the curriculum has nothing to do with what functionality Sage offers. Also, I'm more co

[sage-devel] Re: integration algorithms

Le samedi 4 mars 2017 11:39:59 UTC+1, Dima Pasechnik a écrit : > > > > On Saturday, March 4, 2017 at 10:24:19 AM UTC, parisse wrote: >> >> >> >> Le samedi 4 mars 2017 09:09:17 UTC+1, Dima Pasechnik a écrit : >>> >>> >>> Why isn't xcas on Android Play store (so that the installation really >>> go

[sage-devel] Re: integration algorithms

On Saturday, March 4, 2017 at 10:24:19 AM UTC, parisse wrote: > > > > Le samedi 4 mars 2017 09:09:17 UTC+1, Dima Pasechnik a écrit : >> >> >> Why isn't xcas on Android Play store (so that the installation really >> goes as it is normally done with Android apps)? >> > > Because the HTML5 version

[sage-devel] Re: integration algorithms

Le samedi 4 mars 2017 09:09:17 UTC+1, Dima Pasechnik a écrit : > > > Why isn't xcas on Android Play store (so that the installation really goes > as it is normally done with Android apps)? > Because the HTML5 version of Xcas is not an android app. You can run it on any web browser (it's optimi

[sage-devel] Re: integration algorithms

On Saturday, March 4, 2017 at 7:19:41 AM UTC, parisse wrote: > > > > Le vendredi 3 mars 2017 23:20:42 UTC+1, rjf a écrit : >> >> If you were teaching calculus, at what point would you want >> your students to take out a smartphone and do integrals? >> >> > At least as soon as they are at level n+

[sage-devel] Re: integration algorithms

Le vendredi 3 mars 2017 23:20:42 UTC+1, rjf a écrit : > > If you were teaching calculus, at what point would you want > your students to take out a smartphone and do integrals? > > At least as soon as they are at level n+1 if integration is teached at level n. At level n, make 2 kinds of exam: o

[sage-devel] Re: integration algorithms

Calculus classes today do not typically teach the Risch algorithm, in my experience. However, you shouldn't design calculus courses at most places based on experiences with MIT students. I think it is an interesting question about how much time we should spend teaching *how* to compute integral

[sage-devel] Re: integration algorithms

If you were teaching calculus, at what point would you want your students to take out a smartphone and do integrals? How much time would you allocate to teaching the syntax of the CAS, what to do with error messages, how to download the latest copy, etc.? And what benefit would this be to the st

[sage-devel] Re: integration algorithms

Hi, In the ticket of Laplace transform (see trac ticket #22422) I have the same dilemma. One could: 1- do nothing (keeping the same behaviour as, say, `symbolic_sum`), expecting that the user asks for inline help, figures out there is an 'algorithm' argument that can be changed, and tries that.

[sage-devel] Re: integration algorithms

Le mercredi 1 mars 2017 22:58:48 UTC+1, rjf a écrit : > > As I have said before, the objective of most students taking calculus > is to pass the course so they never have to know any of this integration > stuff ever again. Thus computer systems are useful primarily to > help them do homework (ch

[sage-devel] Re: integration algorithms

Is "scientist" a job? see US statistics here https://www.bls.gov/ooh/ There are 780 hits on "scientist". The occupational outlook for "mathematician" https://www.bls.gov/ooh/math/mathematicians.htm is informative. The number of persons in this category (in 2014) was 3,500. computer scientist

[sage-devel] Re: integration algorithms

On Wednesday, March 1, 2017 at 9:58:48 PM UTC, rjf wrote: > > I think that if *students *are using Sage to access the integration > program in Maxima, they could just > use Maxima. > > If they are choosing an integration program based on speed, > they must have a very very old computer, since al

[sage-devel] Re: integration algorithms

I think that if *students *are using Sage to access the integration program in Maxima, they could just use Maxima. If they are choosing an integration program based on speed, they must have a very very old computer, since almost any student problem is done instantly. By almost any program. Imple

Re: [sage-devel] Re: integration algorithms

Maxima's version of Risch is about 13 pages of code, not counting some material that may reside in other files having to do with finding appropriate algebraic or transcendental extensions. I suspect no one has looked at it seriously in 40 years. On Wednesday, March 1, 2017 at 1:26:04 PM UTC-8

Re: [sage-devel] Re: integration algorithms

W dniu wtorek, 28 lutego 2017 09:03:52 UTC użytkownik Dima Pasechnik napisał: > > The problem with Risch "algorithm" is that's not very implementable. > No system ever had a complete implementation; it's true that results and > implementations by Manuel Bronstein >

[sage-devel] Re: integration algorithms

I think Sage's integration can't compare to Mathematica's. The output is not as clean and it doesn't solve as many integrals and it is not as fast. Sage is used by many students, and in my opinion, its profitability and sustainability in the future depends on classroom use, to a large extent. F

[sage-devel] Re: integration algorithms

On Wednesday, March 1, 2017 at 5:38:28 AM UTC, rjf wrote: > > It is possible that people interested in this thread would benefit by > reading > the PhD theses of Joel Moses, and also James Slagle. > > Briefly, Moses viewed the problem as 3 stages. A simple algorithm > (derivative-divides) >

[sage-devel] Re: integration algorithms

Le mercredi 1 mars 2017 06:38:28 UTC+1, rjf a écrit : > > Other than the academic interest in 'anti-differentiation' it is not > clear that this is such an important problem in (say) physics or > engineering. > Definite integration problems can be done by quadrature programs, > and of course th

[sage-devel] Re: integration algorithms

It is possible that people interested in this thread would benefit by reading the PhD theses of Joel Moses, and also James Slagle. Briefly, Moses viewed the problem as 3 stages. A simple algorithm (derivative-divides) which can be written very compactly if you have the right tools. 2. a patt

[sage-devel] Re: integration algorithms

Le mardi 28 février 2017 18:32:19 UTC+1, mmarco a écrit : > > If it makes sense to use integration by parts or not deppends heavily on > the actual expression. I suspect that, if you try to make a sane criterion > te decide when to apply it, you could end up with something very > complicated a

[sage-devel] Re: integration algorithms

If it makes sense to use integration by parts or not deppends heavily on the actual expression. I suspect that, if you try to make a sane criterion te decide when to apply it, you could end up with something very complicated as well. Ther is reason why there are so many rules in RUBI (although

[sage-devel] Re: integration algorithms

Le mardi 28 février 2017 15:57:53 UTC+1, mmarco a écrit : > > Many RUBI rules actually consist on applying that kind of algorithms. The > trick with those algorithms is that sometimes they help, and sometimes they > hurt (in the sense that you get something that is actually harder to > integra

[sage-devel] Re: integration algorithms

Many RUBI rules actually consist on applying that kind of algorithms. The trick with those algorithms is that sometimes they help, and sometimes they hurt (in the sense that you get something that is actually harder to integrate). One of the important things about RUBI that many people forget a

Re: [sage-devel] Re: integration algorithms

Fricas does some integrals very well (also, gives more compact form, as it does not introduce as many field extensions as other packages), and some pretty badly. IMHO one first has to classify the integrals and only then choose a good backend. On Tuesday, February 28, 2017 at 9:21:35 AM UTC, Ra

[sage-devel] Re: integration algorithms

My opinion is that it's better to add new algorithms for failures than rules. Of course adding rules will add a few success, but it's not like adding algorithms that can be combined together like integration by part and partial fraction decomposition or integration of rational fraction of x and

[sage-devel] Re: integration algorithms

> > > Back to the original proposal. Certainly rules can't catch all cases > either. Doesn't this call for a combined approach? As soon as we have rules > in Sage they should be called before the best algorithm we have. The > default then IMO should be "special rules + Maxima" instead of Maxima

Re: [sage-devel] Re: integration algorithms

Assuming the Fricas implementation is as good as Axiom's, would this alone not be enough reason to make Fricas a standard package (and call it first when integrating)? On Tue, Feb 28, 2017 at 10:03 AM Dima Pasechnik wrote: > The problem with Risch "algorithm" is that's not very implementable. >

Re: [sage-devel] Re: integration algorithms

The problem with Risch "algorithm" is that's not very implementable. No system ever had a complete implementation; it's true that results and implementations by Manuel Bronstein (this is a memorial page, for he died 12 years ago)

Re: [sage-devel] Re: integration algorithms

Fricas was forked from Axiom, according to https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system)#History and Axiom had the complete Risch algorithm implemented. On Tue, Feb 28, 2017 at 9:01 AM Thierry Dumont wrote: > Following https://en.wikipedia.org/wiki/Risch_algorithm ,the Risch > al

Re: [sage-devel] Re: integration algorithms

Following https://en.wikipedia.org/wiki/Risch_algorithm ,the Risch algorithm is able to find an antiderivative of: x |-> x/sqrt(x^4+10*x^2-96*x-71) but not of: x |-> x/sqrt(x^4+10*x^2-96*x-72) . What can do Sage? # fok(x)=x/sqrt(x^4+10*x^

[sage-devel] Re: integration algorithms

On Monday, February 27, 2017 at 9:50:45 PM UTC+1, parisse wrote: > > I have myself implemented symbolic integration in Giac/Xcas in a spirit > similar to Maxima or Axiom that is a few dozens *algorithms* for some > classes of integrands, then the Risch algorithm in the rational case, like > Maxi

[sage-devel] Re: integration algorithms

> > > > I think that it might be possible to wrile (in Python ?) a "Ruby rules > compiler" that could use our (rudimentary) wildcard facility to effect > those substitutions. A possible companion would be a "Mathematica compiler" > able to translate a Mathematica Integrate statement and transla

[sage-devel] Re: integration algorithms

I have myself implemented symbolic integration in Giac/Xcas in a spirit similar to Maxima or Axiom that is a few dozens *algorithms* for some classes of integrands, then the Risch algorithm in the rational case, like Maxima while it seems that Axiom implements the more general algebraic Risch a

[sage-devel] Re: integration algorithms

Sorry : I've been interrupted at the wrong omment... Le lundi 27 février 2017 18:13:33 UTC+1, Emmanuel Charpentier a écrit : > > A few points : > >1. Sympy has interesting answers in some cases. But : > 1. It often offers responses as conditional expressions (akin to > Mathematica

Re: [sage-devel] Re: integration algorithms

Rubi should rather be seen as a useful collection of knowledge that can be implemented in different ways. I encourage the Maxima authors to e.g. have a look at Rubi's chapter 1.2.1. They seem to have completely missed that the integral of (a+bx+cx^2)^p, p rational, has a general solution in terms o

[sage-devel] Re: integration algorithms

A few points : 1. Sympy has interesting answers in some cases. But : 1. It often offers responses as conditional expressions (akin to Mathematica's lists of tuples (expression, rule)), whic we don't (yet ?) know how to handle ; 2. It often uses special functions not (y

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

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