Numerical Methods or Calculus: integration, differentation, interpolation, etc

[spencerstith]

I have been browsing this repo and noticed there doesn't seem to be any functionality for numerical methods for integration, derivatives, interpolation, etc. Is that needed in this repository? I would love to start on that unless it is beyond the scope of this library.

[Madanaa]

@spencerstith Euler method, Second-order Runge-Kutta methods

[m93a]

Hey Spencer,
Thanks for getting in touch! I think that numerical methods are not out of scope – we already have a symbolic derivative and a feature request for symbolic integration (#1015). Numerical integration/derivative would be a great fallback for functions that we can't handle symbolically.

By interpolation I assume you mean something like numpy.interp. In this regard, I like the idea of creating a new type SampledFunction which would represent points like [f(0), f(0.1), ... f(1)] for some function f. This would make a clear distinction between vectors and sampled functions (which is missing in numpy). Then, interpolation would take a SampledFunction and return another, more densely populated SampledFunction. This would work nicely with FFT (#46) too.

I can imagine that ODE iterators like Euler and Runge-Kutta, which Madan mentions, would also be useful in math.js. But maybe after we have a solver for algebraic equations, so that we can make a consistent API? 🤔 Not sure about this, I'd love to hear your thoughts!

Anyway, starting a new issue about a specific feature would be a great start. Then you (or anyone else) can propose an API and later follow up with a PR :)

[m93a]

@josdejong Any thoughts about this, Jos?

[josdejong]

Yes, I would love to have numerical implementations to do integration, differentiation, etc 👍 . Thanks for bringing this up.

Related: #227

[jjram20]

Could I take this issue? I can help to implement a Runge-Kutta or maybe some integration algorithms.

[josdejong]

Sounds good, thanks for your offer @jjram20 👍 .

Before you work out new functions in detail, please keep us up to date on what exactly you plan to implement and how, so we can discuss where needed.

[jjram20]

I could start creating a new folder for numerical methods for calculus inside of /src/functions including a function for numerical integration using the trapezoidal rule, the function would include as parameters the functions that will be integrated as a string and it will be evaluated using the method evaluate of this library, the other parameters will be the limits of integration and the size of increments. The idea is to evaluate using for cycles.

If I am not considering anything, am not being clear, or anything else please let me know.

[josdejong]

Yes it makes sense to introduce a new category, "numerical" or "calculus" (what would be the best name?), and create a folder in /src/function. What functions do you exactly have in mind? numerical integration, numerical differentiation, ...?

[jjram20]

For now I would like to start including numerical differentiation (using the definition (f(x+h)-f(x))/h) and numerical integration using trapezoidal rule, and later the next step could be to add other algorithms as Runge-Kutta, but step by step, what do you think about it?

[josdejong]

That sounds like a good and realistic plan (not too much at once). Do you have any preference for the name of the category? Ie. "numerical" or "calculus" or something else?

[jjram20]

The name of the folder can be "numerical".

[josdejong]

Yes I like that best too 👍

[dvd101x]

This is a comparison of most parameters as an object vs optional parameters as an object

solveODE(f, {tStart:0, tEnd:4, initialState:1, step:1, method:'RK4'})
# vs
solveODE(f, [0, 4], 1, {step:1, method:'RK4'})

I was thinking about the possibility of including a default method with variable step and default tolerance if no options are available thus this would also be possible

solveODE(f, {tStart:0, tEnd:4, initialState:1})
# vs
solveODE(f, [0, 4], 1)

This is emulating some other solvers that I know, like matlab ode45(f, xspan, y0); or scipy solve_ivp(f, xspan, y0).

You are making some valid points regarding the mix of unnamed, named, arrays, functions, etc. If it's more inline with the rest of the library for most parameters to be as an object that's ok for me, just please review, there might be some merits in this form.

[josdejong]

An example like solveODE(f, [0, 4], 1) is indeed nicely compact and readable. I was triggered when first looking at your examples in #2676 (reply in thread), I couldn't see the trees from the forest with all the commas and brackets and was wondering what variable is what.

Having three parameters like ode45(f, xspan, y0) look very clear. With JavaScript and in mathjs we can put that in an object, like ode45({ f, xspan, y0 }), making it all named parameters, and opening up space to introduce extra optional (named) arguments without making it confusing. It think it will be best to use a single object (matching what is common in JS and in mathjs), but we can think through how to pass start, end, and optional step in a good way (array? range? individual parameters?).

solveODE({
  f,
  xspan: [start, step, end],  // or [start, end, step], or {start, step, end}, or or start:step:end
  y0
})

On a side note: we should really implement object literal property value shorthand in the expression parser, I use that extensively in JS. I've opened a discussion here: #2953

[dvd101x]

Sorry about the confusion, I've been tweaking the nomenclature over time, specially after I saw I could make a variable step method.

I can work on a concept based on other functions that can take an object as an argument like: derivative, rationalize, resolve, simplifyConstant, simplify, simplifyCore and symbolicEqual. I will review those an try to come up with something.

It sounds very nice to implement #2953, I recently learned about it in js.

[josdejong]

Sounds good!

[dvd101x]

Hi Jos,

Here is an initial PR for your review

#2958