addressing #88

[pavelkomarov]

No description provided.

[pavelkomarov]

You can do latex math in the docs like this. It's quite neat.

[pavelkomarov]

No need to actually name the variable args. They can be passed in in order, and python will pair them up properly.

[pavelkomarov]

Rather than change a bunch of numbers in the unit tests to get this to pass, I'm reworking the unit tests in a separate PR. I'll follow with more PRs to move the other modules to the new testing philosophy. I'll pull those in after merge and run the tests locally to get a sense of whether these changes really make performance worse against analytic functions with known derivatives.

[pavelkomarov]

Looks like we're down to 2 failing tests, one in the TVR tests that haven't been moved to the new testing paradigm yet.

[pavelkomarov]

Okay, I've done some experimentation using the new tests, and it appears making this change to the first_value doesn't change the answers much, although I'd say they err on slightly better. Here are the error bounds for savgoldiff before the change:

[(1.1656999495180548e-08, 2.128271558987649e-09), (1.6915870458531817e-14, 3.33066907387547e-15), (0.11427042032772938, 0.06978352987915692), (0.7710396958181257, 0.41508805349131617), .]
[(1.160334089871939e-08, 2.1184829446241338e-09), (6.720142459177474e-14, 1.9539925233402755e-14), (0.11427042033441277, 0.06978352987216518), (0.771039695818124, 0.4150880534913166), .]
[(0.04024016533923702, 0.01739019525062524), (0.13987551799466996, 0.0713313022140698), (0.11771046658202969, 0.06039990075908541), (0.7052405298297969, 0.34375675127724525), .]
[(0.26482559251197524, 0.08747573766827299), (0.8624482623950084, 0.22899952208125818), (0.3004799377727331, 0.0965533075427798), (1.1963728043243202, 0.4127453319059624), .]
[(5.561370683005278, 2.636993182387661), (39.985211365737534, 29.795682995529127), (5.615203394419651, 2.6588487766915705), (40.313345684682304, 29.995094475911465), .]
[(6.054091796859054, 4.857630926808305), (207.61977542176945, 204.22830815168524), (5.995741178231949, 4.829353688478447), (207.9694075767479, 204.64339620517654),.

And here is after:

[(1.1657010440876048e-08, 2.128273557389093e-09), (1.6915870458531817e-14, 3.33066907387547e-15), (0.1110011487174795, 0.06476481955299396), (0.7710396958181257, 0.41508805349131617), .]
[(1.1603329871946827e-08, 2.1184809462226895e-09), (6.720142459177474e-14, 1.9539925233402755e-14), (0.11100114871746548, 0.06476481955298574), (0.7710396958181239, 0.4150880534913166), .]
[(0.04279976172517854, 0.01712515936875858), (0.13987551799466996, 0.0713313022140698), (0.11105134245886775, 0.047632469690048085), (0.7052405298297969, 0.34375675127724525), .]
[(0.2659839474924401, 0.0868172340986576), (0.8624482623950084, 0.22899952208125818), (0.3046427778234579, 0.09703892583423479), (1.1963728043243202, 0.4127453319059624), .]
[(5.561321737098188, 2.63934938434984), (39.985211365737534, 29.795682995529127), (5.61597859610529, 2.661012044793159), (40.31334568468231, 29.995094475911465), .]
[(5.815083939621757, 4.901622691110093), (207.61977542176948, 204.22830815168524), (5.771454226854141, 4.873166282868055), (207.9694075767479, 204.64339620517654), .

This is difficult to parse, but the plots aren't visibly different, so I have to resort to the printouts. The tuples are ($\mathcal{L}_2$, $\mathcal{L}_\infty$) distances, for each pair of: (x,x_hat), (dxdt,dxdt_hat), (x,x_hat_noisy), (dxdt,dxdt_hat_noisy) across rows. Each new row is a new test function.

I'm seeing a similar pattern for iterated first_order, spectraldiff, and polydiff. So we can at least say this change doesn't hurt performance.

[pavelkomarov]

I've run another test, increasing dt to 0.5, which means there are only 7 total points in the test domain $[0, 3]$. This means the norms can get thrown off a bit more by erroneous first values. Again, they're printed as ($\mathcal{L}_2$, $\mathcal{L}_\infty$) distances, for each pair of: (x,x_hat), (dxdt,dxdt_hat), (x,x_hat_noisy), (dxdt,dxdt_hat_noisy) across rows, with each row being a new test function.

Running (iterated_first_order, {'num_iterations':5}) (which is actually mostly second order, #104) without the change from this PR, the table of norms is:

[(2.546980894069147e-06, 1.0398005958478507e-06), (0.0, 0.0), (0.08036778311150179, 0.061414594965114144), (0.11919118877659596, 0.08268290832670111), .]
[(1.5512027346296468e-06, 1.0458127981394227e-06), (1.0246618797955482e-06, 4.1831646235834796e-07), (0.08033199688530047, 0.06136331979552967), (0.11915355841516713, 0.0826624751626639), .]
[(0.6196085386283401, 0.403851844037467), (2.0871821773714765, 1.352547880838709), (0.5930064018734305, 0.4317954050221182), (2.0147366170186145, 1.3511628992060203), .]
[(1.6616693135516039, 1.115051751275924), (4.7279519526737745, 3.104078590462335), (1.6159763245308174, 1.0947648507099328), (4.747592650466271, 3.059642361297158), .]
[(6.410982392942246, 4.687742402367821), (71.01034873247902, 60.240521518709194), (6.3992074588137795, 4.712014160322724), (71.01119532207986, 60.23914719807989), .]
[(1.8652616587211697, 1.2882319788759977), (253.41809369061883, 253.2749590070259), (1.8908076765331914, 1.3084345227709966), (253.49851036247895, 253.35750964546187), .

and with the change from this PR, those numbers become

[(2.546980894069147e-06, 1.0398005958478507e-06), (0.0, 0.0), (0.07840504319366295, 0.06754328075616933), (0.11540794775600038, 0.08060231292668218), .]
[(1.551288488985115e-06, 1.04586718752131e-06), (1.0247059391773786e-06, 4.183344488595253e-07), (0.07858619593744096, 0.06772376968279037), (0.11553628137226037, 0.08067381094767612), .]
[(0.5947036445523115, 0.33279555719133924), (2.087182180394897, 1.3525857662486462), (0.565583259244268, 0.34940580977632685), (2.014530098689903, 1.349212648414758), .]
[(1.5444954361395629, 1.059145183310756), (4.744425643765162, 2.996724641230676), (1.508220478444731, 1.0314516216289806), (4.76840722651662, 2.989531723980846), .]
[(6.282329525917872, 4.555056386999501), (71.17344585207161, 60.541104427568285), (6.277812073650396, 4.570103886761279), (71.17404564886196, 60.53763094436056), .]
[(1.7876098152047277, 1.3635194975002567), (253.3314052469386, 253.18538618587368), (1.805330412034045, 1.3907302835651392), (253.40990244669806, 253.26600423614323), .

Still annoying to parse by eye, but these differences are a bit larger and more often than not favor the use of 0 as first_value, or at least prove this change doesn't hurt performance.

[pavelkomarov]

I don't love having to hack the tests, and I'm not sure why the changes I made affect these values enough to matter, but not any others. Still, this value is clearly ballpark the same as what it was, so I'm squinting and deciding it's fine. I'd rather put the TVR tests on the new standard, but I think TVR has bigger problems that will block me from being able to do that quickly. See #91.

[pavelkomarov]

Apparently this change results in a different optimal choice of order for the Butterworth filter, which is odd but too deep a dependency for me to be able to tease it apart fully quickly. Once all the modules are changed, I plan to overhaul the optimization code and its tests, which are also tautological. See #90.