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. On Saturday, February 25, 2017 at 10:52:26 PM UTC-8, 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 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? > -- 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.
