#8321: numerical integration with arbitrary precision
-------------------------------+--------------------------------------------
Reporter: burcin | Owner: burcin
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.5.3
Component: symbolics | Keywords: numerics,integration
Author: Stefan Reiterer | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-------------------------------+--------------------------------------------
Comment(by maldun):
Replying to [comment:12 burcin]:
> Thank you for the patch Stefan. This was much needed for quite a while
now.
>
> Replying to [comment:10 maldun]:
> > Replying to [comment:8 kcrisman]:
> > > Thanks, Maldun, this is a good addition to have. I don't have time
to review this immediately, but it would be helpful to know if you
detected any errors, compared this with symbolic integrals and their
evaluation, etc. Basically, that the results from this really are as
accurate as advertised.
>
> I agree. I like how the patch looks overall. It would be good to see
comparisons on
> * error margins
> * speed
>
> Maybe Fredrik can comment on this as well.
>
> Using `fast_callable()` for `mp_f` could help improve the speed.
>
Ok I will try this+do some tests in the next time!
> 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.
> > > 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:
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 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
greez maldun
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8321#comment:13>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
