Closed albop closed 6 years ago
Hi @albop Thank you for doing that. Code looks great! I'll be able to review it more thoroughly after class today.
Just removed the limit d<=2 for nonuniform multilinear interpolation.
Code looks great Pablo! Very keen to try it out.
Thanks @albop! Sorry to be late to the party. I was tied up with a few short deadlines and my inbox was left to go crazy.
I'm super pleased to have these new routines. I'm teaching dynamic programming at NYU this fall and I'll get all the students using these routines so they get a good workout.
The other thing is that we'll now start to numba-fy the dynamic programming part of the QuantEcon lectures:
https://lectures.quantecon.org/py/index_dynamic_programming.html
The previously missing pieces of the puzzle were jitted optimization and jitted interpolation...
@QBatista It would be great if we could work on this together while you are in NYC.
PS @chrishyland and @spvdchachan started thinking about how to jit compile some of the DP lectures and might be willing to share their thoughts when we get started.
Cool. Now there should be updated versions both on pip and conda. In the near future my plans look a bit like yours, with more work on interpolation and some on optimization. I have some ideas there and will expose them before starting.
@chrishyland, @spvdchachan, @jstac I implemented a first version of the multilinear routines we talked about in https://github.com/EconForge/interpolation.py/issues/22 . There are call examples in https://github.com/EconForge/interpolation.py/blob/albop/interp/examples/example_mlinterp.py and some tests in https://github.com/EconForge/interpolation.py/blob/albop/interp/interpolation/multilinear/tests/test_multilinear.py
@denfromufa: you might be interested too as you requested it in issue #7 . @JeppeDruedahl
It would be great if you could have a look and see whether it fits your needs and/or gives consistent results. Any help with the tests or the documentation would be really appreciated (an example notebook is also a good idea).
If nobody finds a bug in the next days, I plan to merge in master and do a release soon. Additional docs and tests can then be done as PR on mastr.
Random remarks:
interp
andmlinterp
. They differ by the api they accept:interp
as a flat api likeinterp(x1,x2,y,u1,u2)
, whilemlinterp
always take three argumentsmlinterp((x1,x2),y,u)
. I personnally the latter version but don't mind keeping an alternate api. In principle it could be possible to fuse both in one function accepting all types of calls, but prefer to stay future-proof by trying both separately.interp
regarding ordering in 2d. In scipy version,interp2d(x,y,z)
represents a function such thatz[i,j]
isf(x[j],y[i])
. which is not what I would expect. (I guess it makes sense in the context of image processing). I am not totally sure as to whether we want to mimmick scipy here or warn users about it. I would so much like to ignore that problem... Any thought or opinion ? Same is true for cartesian evaluation, i.e. interp2d(x,y,z)(_x,_y): it uses an image consistent ordering.f(g(x))
whenf
is trivial notg
. This is a bit of an issue and might be a reason to rewrite some of the code using straight code generation.interp
andmlinterp
should keep the same exact behaviour though.