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


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

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #8321, comment 13

    initial v1  
    1414> Using `fast_callable()` for `mp_f` could help improve the speed.
    1515>
    16 Ok I will try this+do some tests in the next time!
     16Ok I will try this + do some tests in the near future!
    1717
    1818> Does anyone know of good examples to add as tests for numerical integration?
    1919>
    2020I think I should find some, since I did/do a lot of work with finite element, spectral methods,
    21 and boundary elements. I hope I can do this in the following weeks.
     21and boundary elements. I hope I can do this in the coming weeks.
    2222
    2323> > > 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...
    … …  
    2525> 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?
    2626>
    27 I personally would highly recommand this. Consider for example highly oscillating integrals like
    28 \int_0^pi f(x) sin(n*x) dx for large n's or the example from Runge:
     27I personally would highly recommend this. Consider for example highly oscillating integrals like
     28`\int_0^pi f(x) sin(n*x) dx` for large `n`'s or the example from Runge:
    2929http://en.wikipedia.org/wiki/Runge%27s_phenomenon.
    30 I would also suggest to take scipy into consideration to provide indiviual data points.
    31 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)
    32 If you would like I could work on this   
     30I would also suggest to take !SciPy into consideration to provide indiviual data points.
     31On 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).
     32If you would like I could work on this.
    3333
    34 > 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.
     34> 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.
    3535>
    3636> 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.
    3737
    3838That's true. I think we should provide, like mentioned above, method parameters.
    39 But I don't think we have to fear compability problems, because if I understood the doku of
    40 mpmath correctly it only evals the function on a data grid, and returns the \sum weigth_i * data_i
     39But I don't think we have to fear compability problems, because if I understood the documentation of
     40mpmath correctly it only evals the function on a data grid, and returns the `\sum weigth_i * data_i`.
    4141
    4242greez maldun