Travis CI tests do not pass

[mcr222]

The new tests include: regression tests (dense and not dense), convergence tests (dense and not dense), interpolation polynomials convergence test and interpolation derivatives convergence test.

The regression tests for euler semi-implicit do no pass in Travis (in local machine they pass), concretely test 2 for dense output. I have seen sometimes that euler semi-implicit, when executing multiple times, can get slightly different results (maybe because finite arithmetic rounding errors). This might be the reason (as all other dense tests pass, even test 0 and 1 for euler semi implicit).

[ketch]

On my machine some other (non-dense-output) semi-implicit regression tests also fail.

It looks like the regression tests are examining whether the errors are the same as a reference amount of error. That seems strange to me; regression tests are supposed to simply compare the solution to a reference solution. The "reference" solution is not an exact or near-exact solution, but rather a solution obtained previously with the same code. I'm going to rewrite the regression tests to do that.

[mcr222]

If this avoids the issue of having slightly different results on different machines then the document in the wiki (https://github.com/numerical-mathematics/extrapolation/wiki/Tests-usage) should be modified too (specially comment IMPORTANT 1).

[ketch]

@mcr222 and @HumamAlwassel could you please update to the latest version of the code and run the tests? They seem to pass on both my machine and Travis, but I'd like a larger sample before revising the statement on the wiki.

Also, @mcr222 could you please add a docstring each for the functions test_interpolation_polynomial and test_interpolated_derivatives?

[HumamAlwassel]

All tests passed on my machine.

[mcr222]

All tests passed on my machine too. Added docstrings to functions too.

[mcr222]

A few convergence tests, for some methods and some problems show slight incorrect convergence orders. They currently pass because I added a hardcoded order correction (of +1 or -1 in those cases).

This should be checked, although I think it may be because higher order of convergence have a narrower linear behaviour. I say this because it fails just in some cases and usually with higher orders.

Look for TODOs:

TODO: this should be one order less of convergence (with lam=0 it works well)

    #if lam=0 then last check should be order+1 (as expected)

TODO: orderrs>7 not correct behavior

TODO: orderds>4 does not behave correctly (data type numeric error)

TODO: this should be zero, could be because 0.266 ~= 1 but doesn't pass the check

TODO: This should be zero all the time