I've added a rude implementation of the Ioan "bilinear-final i" solution in my custom functions plugin... seems quite fast, someone can test it?

function: InterpBilinear(row X,column Y,matrix M,number x,number y)

BTW to improve the margin() performances on large matrices, if we assume that the X and Y vectors are both sorted, a way could be to use a "divide and conquer" algorithm (basically, a bisection through the vectors indices)

Thank you all!

Wrote

1. length(x) is used 4 times; it's preferable to introduce it from the beginning into a variable

Actually, this function is used at most two times, at least zero times. If the function is executed on an evenly distributed data, it will be absolutely no difference in my and your variants: my zero invocations when extrapolating left will be compensated by two invocations when extrapolating right, and when interpolating, exactly one invocation will be anyway. In your variant, it will always be invoked exactly once (or maybe it should be eval'ed for this?). So, your variant will win on data that tends to right, while mine will do better on data shifted to the left.

Wrote

2. eval function seems not indispensable (?)

Well, while eval() in index function seems to slow things down, this specific eval() proves to speed thing up (I must confess that not that much, though). Attached is your file with my speed test. When two functions are compared side-by-side in series of 3150+ invocations, doing 40 tests, the resulting numbers show on my computer: 3150 invocations of my function are faster than equal count of the modified one by ~0.14 s. The data I used for testing is left-shifted, so I also used your variant without length() optimization, then testing my function is still faster by ~0.09 s (~3%). It's up to implementer to decide if this worth it. I only describe it because I need to maximize speed by all means.

Wrote

3. column vector is used to intercept line position in the line matrix; so the matrix indices must be transposed.

Well, I seem to make things cumbersome.
In my initial version, it was convenient (to me) to specify column first, then row. This matched the underlying formula order, so I used it.
Then I sent it here without changing things, and then you corrected me in your proposals. I agreed with you, because it's a common thing to cpecify row first, then column, when working with matrices. So when posting my "final" variant, I fixed this. But I named the params X and Y (x and y respectively). And thus, it seems that I introduced another problem: using these indices, I imply then the matrix is treated as a carthesian coordinates, where X is usually horizontal coordinate, and Y is vertical one.
Excuse me for overly-complicating things. I don't know which order is "better" (more intuitive), but anyway, the naming of params surely must reflect the order: X and Y are suitable only if X is horizontal (column index), otherwise they must be Row and Col to make things clear.

Wrote

yet another index function

Unfortunately, this one is oversimplified variant of ioan92 "k1", and this variant is incorrect (fails at extrapolating right), in addition to being not optimized for corner cases. Also, it requires about twice as much additions. I haven't tested your other proposal (I cannot use Matlab plugin), but being very elegant, I doubt it will be more efficient than ioan92's one: it will need to traverse matrices twice.

w3b5urf3r_reloaded, I'll try to test your plugin ASAP. Thank you!

---

bilinear-final i+test.sm (82 КиБ) скачан 71 раз(а).

Wrote

I've added a rude implementation of the Ioan "bilinear-final i" solution in my custom functions plugin...

It's 3+ times faster than "bilinear-final i". Great!

Binary search could of course be used in cases where the indices are ~evenly spaced...

Well, as I noted earlier, I don't consider first Martin's suggestion efficient enough. It's beautiful, though, but it requires two passes of length(X): first to create matrix with ones, and second to sum them up.
Ioan's last variant improves it somewhat, but it still requires one full pass. In what sense is it superior to Ioan's initial k1()? It has no double logic.

OK, as exotic variants are considered here, I post my own, that I made after Ioan suggested his initial version of k1(). It is based on Ioan's, but removes doubling of logic. It won't have to iterate through all the vector, only the first part that is less (more) than lookup value. Still, it's less efficient than final version used in my post 7, because it uses extra function call.

---

margin.sm (4 КиБ) скачан 43 раз(а).

A test through the Margin() solutions... BTW IMHO is preferable a test with less iterations but bigger matrices...

[edit 1] file updated (previously missing xx and yy values on the canvas)
[edit 2] screenshot updated using the file above

---

Hello Ryan,

I can confirm the bug, really dangerous o_o

Win7 x64, SMath Studio 0.97.5154 (Desktop)


Best regards,

Davide

---

end file.sm (1 КиБ) скачан 48 раз(а).

I think should be moved in the bugs section, before losing it...