# Changes between Initial Version and Version 1 of Ticket #8321, comment 13

Ignore:
Timestamp:
Sep 6, 2020, 10:13:59 AM (2 years ago)
Comment:

### Legend:

Unmodified
 initial > Using fast_callable() for mp_f could help improve the speed. > Ok I will try this+do some tests in the next time! Ok I will try this + do some tests in the near future! > Does anyone know of good examples to add as tests for numerical integration? > I think I should find some, since I did/do a lot of work with finite element, spectral methods, and boundary elements. I hope I can do this in the following weeks. and boundary elements. I hope I can do this in the coming weeks. > > > Also, you might as well leave the GSL stuff in as comments, as in the patch you posted above, or even as an optional argument, though that may not be compatible with _evalf_ elsewhere... > Unfortunately, ATM, the numerical evaluation framework for symbolic expressions doesn't support specifying different methods. This could (probably, I didn't check the code) be done by changing the interpretation of the python object we pass around to keep the algorithm parameter and the parent, instead of just the parent. Is this a desirable change? Shall we open a ticket for this? > I personally would highly recommand this. Consider for example highly oscillating integrals like \int_0^pi f(x) sin(n*x) dx for large n's or the example from Runge: I personally would highly recommend this. Consider for example highly oscillating integrals like \int_0^pi f(x) sin(n*x) dx for large n's or the example from Runge: http://en.wikipedia.org/wiki/Runge%27s_phenomenon. I would also suggest to take scipy into consideration to provide indiviual data points. On friday, I and a colleague of mine had a simple example of a piecewise function, that only scipy could do properly while mpmath failed, (even matlab had problems) because I handled individual data points.(mpath also provides different quadrature rules) If you would like I could work on this I would also suggest to take !SciPy into consideration to provide indiviual data points. On Friday, I and a colleague of mine had a simple example of a piecewise function, that only !ScipPy could do properly while mpmath failed, (even MATLAB had problems) because I handled individual data points (mpath also provides different quadrature rules). If you would like I could work on this. > I guess this is based on a comment I made in the context of orthogonal polynomials and scipy vs. mpmath. Instead of a general policy, I'd like to consider each function separately. > I guess this is based on a comment I made in the context of orthogonal polynomials and !SciPy vs. mpmath. Instead of a general policy, I'd like to consider each function separately. > > Overall, I'd lean toward using mpfr if it supports the given function. Otherwise, choosing between pari, mpmath, etc. can be difficult, since on many examples one implementation doesn't beat the other uniformly for different precision or domains. That's true. I think we should provide, like mentioned above, method parameters. But I don't think we have to fear compability problems, because if I understood the doku of mpmath correctly it only evals the function on a data grid, and returns the \sum weigth_i * data_i But I don't think we have to fear compability problems, because if I understood the documentation of mpmath correctly it only evals the function on a data grid, and returns the \sum weigth_i * data_i. greez maldun