integration algorithms

[Ralf Stephan]

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 know about this.

I propose to make the default "try all algorithms in a specific order".

It will return as soon as one library returns a result. An additional

advantage could be that the fast methods can be used first.

Any objections?

[Michael Orlitzky]

It's a good idea (and we have the same situation with "solve" and the
"to_poly_solve" argument).

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)

To work around THAT problem, I would suggest that we try SymPy first,
because it's more fickle. However, that would introduce a new problem: a
lot of doctest output will change, because SymPy will return an answer
before we fall back to the 'maxima' algorithm.

To fix the doctest issue, maybe it makes sense to update all of the
existing doctests to use algorithm='maxima' at first. Then, afterwards,
we could go back and change them a few at a time to use the new default
algorithm. It all depends on how much stuff breaks, or whether someone
else can find a clever way to tell if Maxima actually integrated the thing.

[Ralf Stephan]

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 recognize that:

sage: _.operator()
integrate

[Nils Bruin]

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 brushed over in Calculus, so many users seem to have problems with it.

Using `fx = function('f')(x)` or `f = function('f')` (and then use `f(x)` explicitly) may help in driving home the difference (or at least give examples that people can mindlessly mimic and learn useful habits). It might even be worth going through the docs and fixing those accordingly.

[rjf]

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 uniprocessor  (or many but with shared memory)

If you can start up N processes,  they interfere, so you might have

a result that takes N X the shortest process.  Or one that runs out

of memory and they all fail.

3. Almost always people figure out which algorithm is likely to be

fastest most of the time, deflating this tactic.

4.  If you wanted to implement multiple integration tactics, you would

likely be better off if they were all inside Maxima  (or some other

program that "knows about integration" )  rather than some try-and-fail

testing harness.  After all, some results that look like 

h(x)+integrate(rest_of_stuff,x)  might be just what is needed.

By the way, testing whether the lead operator is "integrate" will

not really work on this.

Another advantage of trying to put it all in one program... some subproblems

are solvable by different methods, and those should be considered

instead of solving the whole problem repeatedly.

5. Albert Rich's integration code should probably be first in line, if

you can figure out how to run it.

6. If you try all the routines in some order, you vastly increase

the chance that you will encounter a bug.  But maybe that

doesn't bother people using Sage.

7. Rather than changing the default behavior, add another

program if you wish ..  "integrate_using_all_methods()". perhaps.

Have fun. 

[Ralf Stephan]

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.

[Michael Orlitzky]

On 02/26/2017 04:59 PM, Nils Bruin wrote:
> 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 brushed over in Calculus, so many users
> seem to have problems with it.
>

I tried the thing that makes more semantic sense,

sage: f = function('f',x)

and it told me to

DeprecationWarning... Use function('f')(x) instead.

[Emmanuel Charpentier]

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 (yet ?) implemented in Sage.
3. The current sympy integration routines tend to drop into (what seems to be) infinite loops, nort returning after long times (many minutes).
2. Fricas has been mentioned as an interesting subcase, since its implementation is (supposed to) find any primitive using only "elementary" functions (polynoms, log/exp/trig) if such a primitive exists.
   
3. ISTR that porting Rubi to Sage has been proposed as a GSOC project a couple of years back, but that one of the conclusions was that:
1. This intensely used pattern-matching, not really compatible with Maxima's abilities, whose implementation was a non-trivial task in itself.
2. No suitable couple of (mentor - trainee) emerged of the process.

Nevertheless, implementing Rubi is probably a good idea. I wonder if a specialized pattern matcher woldn't be a better idear than monkeying Mathematica's. ISTR to have toyed with RJF's suggestion of extending hois Mo

[Ralf Stephan]

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 of 2F1.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
To unsubscribe from this group and all its topics, 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.

[Emmanuel Charpentier]

Sorry : I've been interrupted at the wrong omment...

his "MockMMA" pile of syntactic sugar around Maxima. To no avail...

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 translate it in Sage; in order to test
 

[parisse]

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 algorithm. It is completely different from these thousands *rules* (if chapter 1.2.1 is representative of all the rules) : I mean that in an algorithm you compute, and that reduces the number of cases drastically. I'm really not convinced that it is worth adding these kind of rules to Giac/Xcas, but of course I don't speak for other CAS authors.

[mmarco]

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 translate it in Sage; in order to test
 

I played a bit with that idea, and wrote a toy proof of concept. See https://groups.google.com/d/msg/sage-devel/t-fYDsiFvxw/mGnnyl3FAgAJ 

[Nils Bruin]

(split from original thread because this is a separate topic)

On Monday, February 27, 2017 at 5:38:17 AM UTC-8, Michael Orlitzky wrote:

I tried the thing that makes more semantic sense,

  sage: f = function('f',x)

and it told me to

  DeprecationWarning... Use function('f')(x) instead.

Ah, OK. And this made more semantic sense to you because you wanted f to be a function called 'f' in the variable x? Or because you wanted f to be the result of evaluating a function called 'f' at x?

You get the result corresponding to the second interpretation. You might hope for the first, but that's not currently possible in sage: the arguments don't have names, only positions. You can specify the *number* of arguments via function('f',nargs=1), but that's all (and will confuse back-and-forth conversion to maxima and many other interfaces, so it's not reliable either).

It's been more than a year, so perhaps it's time to take out the deprecation and just raise an error.

[Michael Orlitzky]

On 02/27/2017 06:18 PM, Nils Bruin wrote:
>
> Michael Orlitzky wrote:
>>
>> I tried the thing that makes more semantic sense,
>>
>> sage: f = function('f',x)
>>

>> ...

>
> Ah, OK. And this made more semantic sense to you because you wanted f to be
> a function called 'f' in the variable x? Or because you wanted f to be the
> result of evaluating a function called 'f' at x?
>

The first; f = function(...) should give me a function, naturally. I see
that you're right about what actually happens:

sage: f = function('f',x)

sage: f
f(x)

Oops. I expected the map x |--> f(x) instead. But it fills my heart with
joy that I can fix things by doing

sage: f(x) = f(x)
sage: f
x |--> f(x)

[Nils Bruin]

On Monday, February 27, 2017 at 5:56:44 PM UTC-8, Michael Orlitzky wrote:

But it fills my heart with
joy that I can fix things by doing

  sage: f(x) = f(x)
  sage: f
  x |--> f(x)

But only after you've declared f to be a function. If you want to do it in one line, you'd have to spell out:

f(x) = function('f')(x)

which the preparser changes to:

'__tmp__=var("x"); f = symbolic_expression(function(\'f\')(x)).function(x)'

so the full syntax to obtain your desired result is:

 f=function('f')(x).function(x)

which would probably not fill you with joy ... I'm not so sure if we want function('f',x) to be a shorthand for that. It would be a close approximation of what the user would probably expect, but it's a rather inefficient construct.

[Michael Orlitzky]

On 02/27/2017 09:25 PM, Nils Bruin wrote:
>
> But only after you've declared f to be a function. If you want to do it in
> one line, you'd have to spell out:
>
> f(x) = function('f')(x)
>

> ...
>
> f=function('f')(x).function(x)

Well that's no fun.

> which would probably not fill you with joy ... I'm not so sure if we want
> function('f',x) to be a shorthand for that.

Is there a better way to obtain x |--> f(x)? In any case, there was a
bug in my example, and I won't be suggesting "f = function('f',x)" in
the future (at least until I forget how it works again).

[Ralf Stephan]

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 Maxima while it seems that Axiom implements the more general algebraic Risch algorithm. It is completely different from these thousands *rules* (if chapter 1.2.1 is representative of all the rules) : I mean that in an algorithm you compute, and that reduces the number of cases drastically. I'm really not convinced that it is worth adding these kind of rules to Giac/Xcas, but of course I don't speak for other CAS authors.

The question is if the known algorithms can catch all the cases, and it seems they cannot. While the 1.2.1 example is solved by Wolfram Alpha the Rubi page claims they catch only 60 per cent of all Rubi cases. And I presuppose that if there is an algorithm at all then it is implemented in Alpha.

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

Regards, 

[Thierry Dumont]

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^2-96*x-71)
fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
#
algs=["maxima","sympy","fricas"]
#
for alg in algs:
print alg,integral(fok,x,algorithm=alg)
#
for alg in algs:
print alg,integral(fnot_ok,x,algorithm=alg)
#---------------------------------------------------------

For fnot_ok no primitive is found (may be an other algorithm could find
it -it exists in terms of elliptic integrals-)

For f_ok, *only* *fricas* finds the primitive:

maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
10*x^2 - 96*x - 71) + 10001)

The wikipedia paper says that Risch algorithm was implemented in Macsyma
(and thus I think in maxima!). So, iffricas and maxima use Risch
algorithm, the implementation in fricas is better, or may be fricas uses
some other method.

What about maple and mathematica ? As far as I remember maple can
integrate f_ok. I have no more access to maple to look at this :-) .

t.

[Ralf Stephan]

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.

[Dima Pasechnik]

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

who authored a lot of results towards making Risch more practical, are most completely represented in Axiom.

[Ralf Stephan]

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

[mmarco]

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

Regards, 

I agree with that approach, specially because it allows adding rules incrementally. Even if we don't have all the set of RUBI rules, having a few of them could be an improvement.

[parisse]

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 sqrt(polynomial of degree 2). But perhaps I misunderstand Rubi, and it does that inside Mathematica?

[Dima Pasechnik]

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.

[mmarco]

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 about is that it not only is able to integrate more expressions than Mathematica/Maple/Maxima... (and usually does it faster), but that it also often produces "better" output (in the sense of more compact

expressions and/or fewer discontinuity problems). In general, each rule of RUBI turns the expression into something simpler, so even if you don't have the full set of rules, you can use the ones you have as a preprocessing step for other kinds of algorithms.

[parisse]

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

One of the important things about RUBI that many people forget about is that it not only is able to integrate more expressions than Mathematica/Maple/Maxima... (and usually does it faster), but that it also often produces "better" output (in the sense of more compact

expressions and/or fewer discontinuity problems). In general, each rule of RUBI turns the expression into something simpler, so even if you don't have the full set of rules, you can use the ones you have as a preprocessing step for other kinds of algorithms.

But what about using them in the middle of other algorithms? Because that is what you would want to do. For example if you have a generic expression with an inverse trig function, then it makes sense to do integration by part, and after that you might apply some nice and compact expression obtained by a rule on sqrt. Or maybe you should do a partial fraction decomposition somewhere. My main concern with what I looked at is that some rules should be grouped in one algorithm. There are too many rules in rubi...

[mmarco]

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 I heard that the author is considering reorganizing them in a decission tree, which might simplify things to some extent).

Anyways, even if being able to run several steps of simplification->partial integration->further simplification-> further partial integration... would possibly increase the number of cases that we can integrate, the first step would be to have some support for simplification rules. 

[parisse]

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 as well. Ther is reason why there are so many rules in RUBI (although I heard that the author is considering reorganizing them in a decission tree, which might simplify things to some extent).

The only reason I could see for that number of rules is that rubi works like a student who does not want to understand "the big picture" about integration but has a fabulous memory and remembers all the integrals from all known textbooks. But perhaps I'm wrong, that's why I was asking how it cooperates with classical methods, like partial fraction decomposition or integration by part, change of variables etc. I'm just not convinced by that number of rules and the fact that some of them are not grouped in an algorithm.

[rjf]

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 pattern-matching problem,  but only about 13 patterns,

each attached to an algorithm.

3. a kind of Risch-like program  (prior to Risch's publications).

attaching more patterns and methods to stage 2 would be plausible.

Maybe Rubi.  

implementing a better stage 3  (or calling FriCAS!) would be plausible too.

One problem with Rubi "converted" to sympy or Maxima or ....   is that

(at least in the past) it relied, in non-obvious ways, on Mathematica semantics.

This resulted in loops.  I have read in and run parts of the Rubi rule-set in

Maxima; I think dozens if not hundreds of test cases.  But this was years ago.

Albert Rich promised, some time ago to (auto-?) write  Rubi-as-"if-then-else", 

for consumption by other systems. Still waiting.

Oh, about Slagle.

His program, earlier than Moses'  viewed integration as an AI

problem involving hill-climbing, breaking up problems into sub-problems,

etc.

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 the vast majority of symbolic integration problems

(from calculus texts) can be done by almost any reasonable computer

algebra system.

The more challenging (and fun) stuff is probably apparent to anyone

who has taken a course in complex variables/ conformal mapping/ special functions.

I am guess that this is not what most Sage fans have studied.

Probably pursuing these kinds of problems would involve mostly

Maxima  (and FriCAS if it is there)  and maybe sympy;  though that

last one may be wrong -- I don't follow sympy much.

RJF

[parisse]

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 the vast majority of symbolic integration problems

(from calculus texts) can be done by almost any reasonable computer

algebra system.

This is one reason why I said I would not try to implement something like rubi in Giac/Xcas : my current symbolic integrator is good enough, it's better to invest programming time in other areas. I'm not against adding a few rules, but not thousands...

[Dima Pasechnik]

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)

which can be written very compactly if you have the right tools.

2.  a pattern-matching problem,  but only about 13 patterns,

each attached to an algorithm.

3. a kind of Risch-like program  (prior to Risch's publications).

attaching more patterns and methods to stage 2 would be plausible.

Maybe Rubi.  

implementing a better stage 3  (or calling FriCAS!) would be plausible too.

One problem with Rubi "converted" to sympy or Maxima or ....   is that

(at least in the past) it relied, in non-obvious ways, on Mathematica semantics.

This resulted in loops.  I have read in and run parts of the Rubi rule-set in

Maxima; I think dozens if not hundreds of test cases.  But this was years ago.

Albert Rich promised, some time ago to (auto-?) write  Rubi-as-"if-then-else", 

for consumption by other systems. Still waiting.

Oh, about Slagle.

His program, earlier than Moses'  viewed integration as an AI

problem involving hill-climbing, breaking up problems into sub-problems,

etc.

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,

most interesting, in practice, definite integrals are multiple and depending upon parameters.

and often the problem is of asymptotic nature. This makes numeric quadratures

almost useless.

  

and of course the vast majority of symbolic integration problems

(from calculus texts) can be done by almost any reasonable computer

algebra system.

The more challenging (and fun) stuff is probably apparent to anyone

who has taken a course in complex variables/ conformal mapping/ special functions.

I am guess that this is not what most Sage fans have studied.

I would not be so sure.

[saad khalid]

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. For that reason alone, I think it is worthwhile to make integration cleaner and better, as that is what the majority of students do. I'm not sure what the  qualm against adding thousands of rules is. If it's more efficient and effective, why does it matter if its similar to a student who simply "memorizes the formulas." Also, saying that we can integrate better than mathematica is definitely a solid advertising point.

My main question is why this is so difficult to implement. Is the difficulty in implementing the "if-then-else"/binary-search-tree method? Or is it with converting the mathematica code to python? I have a hard time believing it's the latter. It's just that several people have said now that implementing Rubi is unfeasible, and I don't totally understand why. Could someone clarify this for me?

[heb...@math.uni.wroc.pl]

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 (this is a memorial page, for he died 12 years ago),

who authored a lot of results towards making Risch more practical, are most completely represented in Axiom.

 
In 2006 Axiom had "most complete" implementation.  But there were several holes.  Some missing parts
are implemented in FriCAS and there are extensions.  Currently more than 25% of integration code in
FriCAS is new.  AFAIK FriCAS is the only system which can reasonably claim to have full implementation
of transcendental part of Risch algorithm.  To complete what was in Axiom I had to add a sizable subsytem
to integration code.  Testing seem to indicate that commercial competion (Maple and Mathematica) did
not implement this part.  Maxima has part called Risch, but AFAIK this is heuristic using ideas from
early Risch papers (part may be original).  AFAIK Maxima Risch misses most of what is now considered
Risch algorithm.  To get some idea of scope of various implementations you may wish to look at
examples on:
http://axiom-wiki.newsynthesis.org/FriCASIntegration
or at FriCAS integration test suite:
https://sourceforge.net/p/fricas/code/HEAD/tree/trunk/src/input/integ.input

You may be also interested in extensions of Risch algorithm to special functions:
http://www.math.uni.wroc.pl/~hebisch/other/icms.pdf

[rjf]

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.

[rjf]

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.

Implementing Rubi is certainly feasible. "Converting" the Mathematica code

to python means writing a pattern matching program that parses the Rubi

code in python.  And figuring out what simplifications are inherent in it.

There is already such a pattern matching program in Lisp, so doing it

in python is not actually necessary.  But maybe someone has done

it anyway. Who can be sure?

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 (cheat?).  And for this work, Maxima is probably

sufficient.

Learning to do symbolic integration "by hand" is a useful test of

"can you do algebra".  Beyond that, it's not really a vital part of

most occupations in say, engineering.  The only job that I

can think of that really requires knowledge of these methods is

"calculus teacher".  

[Dima Pasechnik]

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 almost any student

problem is done instantly. By almost any program.

Implementing Rubi is certainly feasible. "Converting" the Mathematica code

to python means writing a pattern matching program that parses the Rubi

code in python.  And figuring out what simplifications are inherent in it.

There is already such a pattern matching program in Lisp, so doing it

in python is not actually necessary.  But maybe someone has done

it anyway. Who can be sure?

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 (cheat?).  And for this work, Maxima is probably

sufficient.

Learning to do symbolic integration "by hand" is a useful test of

"can you do algebra".  Beyond that, it's not really a vital part of

most occupations in say, engineering.  The only job that I

can think of that really requires knowledge of these methods is

"calculus teacher".  

Is "scientist" a job? If yes, then, well, perhaps you can have a look at papers on analysis of algorithms. E.g.

your humble servant had fun with integration (by hand or otherwise) here:

https://link.springer.com/article/10.1023/B:JOCO.0000038911.67280.3f

(https://pure.uvt.nl/ws/files/623688/onapprox.pdf)---Appendix 1 and Appendix 2.

[rjf]

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 scientists, 25,600.

dental hygienist 200,500.  

I have suggested to people that if they want to make money writing programs,

they should not have as a target audience "mathematicians".

Maybe they should pick some other occupation, e.g.  dental hygienists.

RJF

 

[parisse]

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 (cheat?).  And for this work, Maxima is probably

sufficient.

A reasonable CAS on a smartphone/tablet/calculator is sufficient for students learning calculus (at some point geogebra will certainly provide the CAS window on their app). Otherwise I believe that more symbolic integration is essentially interesting for benchmarks (beware that they may be biaised) and to make regression tests (compare output and check that the derivative of the antiderivative is the original function).

[mforets]

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.
2- print a message when the returned transform is unevaluated, saying something like "Hey, there are ... available algorithms!"
3- add a new algorithm='any' (that ships by default in Sage), which works by trial and error with the available ones.

El domingo, 26 de febrero de 2017, 7:52:26 (UTC+1), Ralf Stephan escribió:

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 know about this.

I propose to make the default "try all algorithms in a specific order".

It will return as soon as one library returns a result. An additional

advantage could be that the fast methods can be used first.

Any objections?

[rjf]

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 student who may still need to solve problems without

a CAS for a written exam?

Or do we assume that it is no longer necessary to teach

methods of integration,  just as it is no longer necessary

to teach how to compute square-roots, or how to

interpolate in a table of logarithms.

Having taught a calculus + computer lab many years

ago (1973! at MIT), the students were more interested

in the Risch algorithm (simple version) than "regular"

stuff.  Even today, calculus classes don't teach that, do they?

RJF

[John H Palmieri]

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 integrals vs. *when* to compute integrals. For the *how* question, how much by hand and how much by CAS?

But all of this is getting off-track, I think.

--
John

[parisse]

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: one with CAS and one without.

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

My own experience with Xcas on a desktop is that it takes less than 1h for 1st year students to be able to do basic CAS stuff (simplify, derive, integrate, plot, etc.) and a little more with CAS calculators. Running Xcas on a smartphone is really straightforward, just open the URL, while installing it locally for an exam takes a few more steps (install an unarchive app, run it and locate the HTML5 page on the device).

 And what benefit would this be to

the student who may still need to solve problems without

a CAS for a written exam?

I believe that CAS devices should be allowed for exam except for short interrogations where you check very basic stuff. That could be calculators, or smartphone/tablets with some way to disconnect them from the network.

Or do we assume that it is no longer necessary to teach

methods of integration,  just as it is no longer necessary

to teach how to compute square-roots, or how to

interpolate in a table of logarithms.

It depends. Integration by part for example should be teached. Or integrating simple rational fractions (say denominators of degree 2). But I believe it is not required anymore to teach how to compute by hand higher degree fractions like 1/(x^2-1)/(x^2+x+1)^2, today it's more important to know how to do it with a CAS and how to check that you did not make a typo.

Having taught a calculus + computer lab many years

ago (1973! at MIT), the students were more interested

in the Risch algorithm (simple version) than "regular"

stuff.  Even today, calculus classes don't teach that, do they?

Of course no, and there is one good reason for that: most colleagues do not even know what the Risch algorithm is about.

[Dima Pasechnik]

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+1 if integration is teached at level n. At level n, make 2 kinds of exam: one with CAS and one without.

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

My own experience with Xcas on a desktop is that it takes less than 1h for 1st year students to be able to do basic CAS stuff (simplify, derive, integrate, plot, etc.) and a little more with CAS calculators. Running Xcas on a smartphone is really straightforward, just open the URL, while installing it locally for an exam takes a few more steps (install an unarchive app, run it and locate the HTML5 page on the device).

Why isn't xcas on Android Play store (so that the installation really goes as it is normally done with Android apps)?

Note that I can run Maxima on Android, and it is installable this way.

https://play.google.com/store/apps/details?id=jp.yhonda&rdid=jp.yhonda

[parisse]

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 optimized for Firefox) on any device. Much easier for me, I don't have to provide an Android version, an iOS version, and several desktop versions. It's also easy for the user since no installation is required and it's easy to add it to your favorites like any favorite web page. Local install for exams requires a few more steps, once smartphones or tablets are allowed for exams, I'll certainly try to make local install more user-friendly.

Note that I can run Maxima on Android, and it is installable this way.

https://play.google.com/store/apps/details?id=jp.yhonda&rdid=jp.yhonda

 
Maxima on Android is not very user-friendly : the user is assumed to already know Maxima and there is not much help to enter commands (like parenthesis highlighting, syntax coloration, helpers for common commands, ...).

[Dima Pasechnik]

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 of Xcas is not an android app. You can run it on any web browser (it's optimized for Firefox) on any device. Much easier for me, I don't have to provide an Android version, an iOS version, and several desktop versions. It's also easy for the user since no installation is required and it's easy to add it to your favorites like any favorite web page. Local install for exams requires a few more steps, once smartphones or tablets are allowed for exams, I'll certainly try to make local install more user-friendly.

hmm, I don't understand - do you mean to say that you can have an android application that provides a server

to be used from android firefox locally, and this is what the local install of xcas on android is doing?

 

Note that I can run Maxima on Android, and it is installable this way.

https://play.google.com/store/apps/details?id=jp.yhonda&rdid=jp.yhonda

 
Maxima on Android is not very user-friendly : the user is assumed to already know Maxima and there is not much help to enter commands (like parenthesis highlighting, syntax coloration, helpers for common commands, ...).

as long as it works, it's better than nothing --- running Maxima in terminal does not provide anything what you listed either.

 

[parisse]

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 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 optimized for Firefox) on any device. Much easier for me, I don't have to provide an Android version, an iOS version, and several desktop versions. It's also easy for the user since no installation is required and it's easy to add it to your favorites like any favorite web page. Local install for exams requires a few more steps, once smartphones or tablets are allowed for exams, I'll certainly try to make local install more user-friendly.

hmm, I don't understand - do you mean to say that you can have an android application that provides a server

to be used from android firefox locally, and this is what the local install of xcas on android is doing?

No, it's not a client-server architecture and there is nothing native. Giac is compiled to a javascript file (giac.js, size 13M), and everything is executed inside the browser (and if I could better understand how browser cache works, a local install would not be required, re-opening the link could use the cached copy if network is disabled).
 

 

Note that I can run Maxima on Android, and it is installable this way.

https://play.google.com/store/apps/details?id=jp.yhonda&rdid=jp.yhonda

 
Maxima on Android is not very user-friendly : the user is assumed to already know Maxima and there is not much help to enter commands (like parenthesis highlighting, syntax coloration, helpers for common commands, ...).

as long as it works, it's better than nothing --- running Maxima in terminal does not provide anything what you listed either.

 

Of course it's better to have a port than nothing, but with the current UI, I don't believe that there are many people really using Maxima on their smartphone.

[saad khalid]

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 concerned with desktop/laptop use. Both Sage and Mathematica/WolframAlpha currently give access to integration. WolframAlpha is easier to access by a bit, simply because of the search bar functionality. However, it is often useful to see the steps involved in solving an integral. Currently, Sage can't do this. WolframAlpha can, but you have to pay a fee to see it. For this reason, I think it would be useful for Sage to have this function. Many students can't afford to pay money, but I think it's a useful educational tool to be able to see how to solve integrals instead of simply being given the solution. 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. If the main concern is that students don't need integration algorithms so advanced, well, I'm certain there are researchers that do. Clearly Mathematica thinks there are researches that need these algorithms, as they support much more integration than Sage does, which is good enough reason for me to support this for Sage. I don't understand why we would want to be mediocre, it makes sense to be cutting edge. And, as I said at the beginning of this message, there is ample reason for this integration method to be useful for students too, as it shows the steps to the solution (which is excellent for studying).

It also seems that my statement about making money was misunderstood. I'm not saying that Sage should have capitalizing off its users as a priority. Obviously the motive for Sage is not profit. However, considering there are costs to upkeeping Sage and its servers, I think money is an important thing to keep in mind. In line with that thought, I think that being able to advertise that Sage can perform integration better than Mathematica, and that it is more helpful for students in calculus class since it shows the steps involved, is an excellent thing to be able to advertise. In general, it is important for Sage to be as widely used as possible, and I think the biggest place we could reach out to is the classroom. Isn't this the main issue Sage faces? It must deal with both the desire to stay up to date, usable, relavent for mathematicians, but it must also have enough paying users to making sustaining it possible. Clearly, not all the time and effort can be put in to the former, effort must be put in functionality and usability for students. Personally, I think the biggest thing to be done in this direction is to update the documentation. Maybe I'll try working on that a little this summer. However, I think that this integration method is good as it provides cleaner output and it gives steps to the solution and it is easy to advertise. The fact that it also performs far more integrals than we currently can is also a great bonus.

As far as I can tell, real progress in converting Rubi to python will be possible once it is converted to using binary search instead of pattern matching, right?

[parisse]

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-fourier.ujf-grenoble.fr/%7eparisse/xcasen.html#+int(ln(x)%5E2%2Cx)&
Step by step is not that easy to implement, because a CAS and a human do not necessarily use the same methods.

[Ralf Stephan]

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 smplification algorithms to be applied after integration. Additional benefit of this would be that these are then available for any simplification task.

 

If the main concern is that students don't need integration algorithms so advanced, well, I'm certain there are researchers that do. Clearly Mathematica thinks there are researches that need these algorithms, as they support much more integration than Sage does, which is good enough reason for me to support this for Sage. I don't understand why we would want to be mediocre, it makes sense to be cutting edge.

+1

 

And, as I said at the beginning of this message, there is ample reason for this integration method to be useful for students too, as it shows the steps to the solution (which is excellent for studying).

... However, I think that this integration method is good as it provides cleaner output and it gives steps to the solution and it is easy to advertise. The fact that it also performs far more integrals than we currently can is also a great bonus.

As far as I can tell, real progress in converting Rubi to python will be possible once it is converted to using binary search instead of pattern matching, right?

I have looked a bit into this (with GiNaC C++) the last weeks. On first glance the main motivation for converting the Rubi rules into a decision tree is to avoid the big chunk of work on a sophisticated pattern matcher plus a catch-all rule converter in favor of sequential work on single parts of Rubi. 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 the output is ugly as well. You'll get more integrals solved than usual algorithms, however, so this low-hanging fruit would have a place *after eg Maxima returns an unsolved integral.

Full conversion to decisions of eg a single Rubi chapter like 1.2.1 (a+bx+cx^2)^p needs other chapters like 1.1.1, 1.1.2, 1.2.2, 1.3.1, 1.3.2 to get optimal results in the sense of "most simplified". Contrary to my own fears I think it would be straightforward after that to add step-by-step output in the sense of Rubi steps. They are well documented, even if I find that the accompanying code is more accurate, so beware.

Regards,

[Ralf Stephan]

...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 the output is ugly as well. You'll get more integrals solved than usual algorithms, however, so this low-hanging fruit would have a place *after eg Maxima returns an unsolved integral.

https://trac.sagemath.org/ticket/22650

[rjf]

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 thought up,

like running the differentiation program backwards  ---

there is a high probability that you are mistaken.

Of course you might be right, and all that stuff over the last 55 years is irrelevant,

and all you have to do is write some neat python program.

Check out the definition of "irony"

[William Stein]

On Mon, Mar 20, 2017 at 10:01 PM, rjf <fat...@gmail.com> 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 instead of pattern matching, or something else you just
> thought up,
> like running the differentiation program backwards ---
> there is a high probability that you are mistaken.

>
> Of course you might be right, and all that stuff over the last 55 years is
> irrelevant,
> and all you have to do is write some neat python program.

He meant "low hanging fruit" only in the sense of a making a specific
computer program slightly more useful, not in the sense of *research*.
They are completely different things.

William

>
> Check out the definition of "irony"
>
>
> On Monday, March 20, 2017 at 2:27:46 AM UTC-7, Ralf Stephan wrote:
>>>
>>> ...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 the output is ugly as well. You'll get more
>>> integrals solved than usual algorithms, however, so this low-hanging fruit
>>> would have a place *after eg Maxima returns an unsolved integral.
>>
>>
>> https://trac.sagemath.org/ticket/22650
>

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



--
William (http://wstein.org)

[parisse]

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 flavours or Giac. If someone can improve using rubi or something else, that's fine, but I don't believe this will be the reason why the vast majority of people will choose one or another CAS.

[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 implementations are good enough whatever you choose in Maxima, Axiom flavours or Giac. If someone can improve using rubi or something else, that's fine, but I don't believe this will be the reason why the vast majority of people will choose one or another CAS.

I agree.

I think one reason Macsyma Inc went out of business is that they spent

time improving parts of the system that made it look good on benchmarks

proposed by other vendors, rather than addressing important applications.

For example, polynomial factorization benchmarks.  I don't recall

integration benchmarks, but I would not be surprised.  

The Rubi benchmarks significantly include one measure of the quality of the

result  (how close to "optimal" in size) for integration.  Not just the

speed or coverage.