[ANN] FastInterpolations.jl — Fast & zero-allocation ND interpolation

Package Announcements
, ,
14

Thanks for the kind words and glad the package is working well for you!

Short answer: Replace myparticle.interp(2.4) with cubic_interp(myparticle.x, myparticle.y, 2.4) (or any other methods you’re using, like linear_interp(myparticle.x, myparticle.y, 2.4)) and drop the interp field from your struct. Details below.

Why the Interpolant Approach Doesn’t Work Here

When you create an interpolant via cubic_interp(x, y), the internal coefficients are precomputed from that specific x and y and frozen. Even if you later mutate y, the interpolant still returns values based on the original data from construction time.

# ⚠️ Gives stale results after y changes
itp = cubic_interp(x, y)      # coefficients baked from y at this moment
y .= new_values                # y changes...
itp(2.4)                       # still uses the OLD y

Use the One-shot API Instead

ptl = myparticle # This is just alias

# single query
val = cubic_interp(ptl.x, ptl.y, 2.4)

# multiple queries 
xq= [2.4, 3.0, 5.0]
vals = cubic_interp(ptl.x, ptl.y, xq) 

# advanced (in-place for zero-alloc)
vals = similar(xq) # pre-allocate memory
cubic_interp!(vals, ptl.x, ptl.y, xq)

This is just a function call—no object to manage, no interp field needed in your struct.

  • Whatever x and y you pass in is what gets used, so there’s no stale-data risk.
  • If the same x grid is reused across calls, the package internally caches the grid-dependent work, so you don’t need to manage that yourself.
  • Works the same whether x or y changes between calls or not.

When to Use an Interpolant Object

Only when both x and y are static—fixed once and queried many times without ever changing.

Feel free to reply here if anything else comes up, or open a GitHub issue if you’d like it tracked. Thanks!

1 Like