New Interpolate Linear Function

[Tetrachromat]

Hi @Toddimus

I suggest to use a sorted table before calling the function:

Code: Select all

...
table.sort( settings, function (m,n) return (m[1] < n[1]) end )
output = interpolate_linear( settings, input, true )
...

Catering for every possible order of entries would just make the function complex and slow.

EDIT:
No need to have a local t (it is just a reference to the settings table). The table is sorted "in situ". Do you use the table for other purposes than interpolating?

[Toddimus]

Thanks @Tetrachromat that makes sense but I was trying to figure out a way to make it backward compatible with the existing interpolate_linear function, which can handle either ascending or descending values with no other external helper functions required. Now that I know what's going on, I can easily make my table ascending and simply use your code. The problem was that I tried to use your code as a retrofit in my algorithm and it "blew up" because a while ago I had happened to make my settings table descending. Took me a while to track it down.

And the way I was thinking about it ... maybe I'm wrong ... is that even though I added a bunch of seemingly duplicate code with only a few things changed in the duplicated parts, it wouldn't really be that much more of a hit at execution time. Code doesn't execute the "else" part when the "then" part is called by the "if" statement, does it? If that's true then it only does one extra comparison between the first and last row of column index 1, and then runs the corresponding then or else branch.

I guess what I'm suggesting is that it somehow should be taken into account if your code replaces the existing function in AM4.1, as @Corjan suggested he would. If that's the case, it's not really backward compatible because the current version is direction agnostic. Doesn't really matter to me how it gets fixed code wise, I just proposed a solution that's the most efficient I could think of at the time. I'm sure it could be collapsed into more elegant if/then/else statements than I did in the example.

Really not trying to be a pain in the backside here, I'm just trying to help and save somebody else the troubleshooting I did last night to figure it out.

EDIT: I was just about to hit send and then I realized I'm 5 minutes late for a Zoom call! In the mean time, I see that you edited your previous post to add that you don't need to do the local t outside the function which is better but it still requires the external sort function. I was hoping there's a way to do it all internally to the function to maintain backwards compatibility. I'm sure you much more experienced Lua coders will figure something out, I'm just raising a flag and proposing a solution. That's my $0.02.

[Tetrachromat]

Your 2 cents are valid.

It did not come to my mind that someone could place the table entries in descending order. To me ascending is the natural order for numbers. This function is used in many instruments, on my research I always found ascending table. Maybe i missed that descending sample.

To me backwards compatibility is important. I will evaluate your suggestions.

[Toddimus]

Cool. Glad I didn't step on your toes.
I agree it would be maybe more intuitive for them to normally increase but I was working with some weird inverse (1-value) stuff while trying to get this to work so I was already thinking upside down. I guess it's good to be flexible of mind sometimes.

Seems like the algorithm wouldn't handle an input range that changes direction in the middle. That could/would lead to more than one possible answer. I don't really see a use case for that but interesting to think about, since I'm geeking out on it. The output, I suppose, could have a bump in it though and the function would work fine.

[Sling]

Good discussion guys. As I think you’ve concluded it should remain backwards compatible else someone’s code might break. I agree though that it’s logical to use increasing values. As far as I remember I personally have only ever created the table with increasing values.

Good work.

[Tetrachromat]

Hi @Toddimus

My preferred solution with the smallest impact is to 1) detect a reversed table. If the table is in revers order we clone it (to protect the original) and sort the clone.

This can be done as follows:

Code: Select all

  
  ...
  local input = value
  
  if settings[r][1] > settings[max][1] then
    settings = {table.unpack(settings)} -- cloned table
    table.sort( settings, function (m,n) return (m[1] < n[1]) end )
  end
  
  if cap then --
  ...

This way only a reversed table bears most of the additional impact. A naturally ordered table would not impacted much.

[jph]

Nice discussion guys.
Great work.

[Toddimus]

@Tetrachromat
That looks like it will work well. Maybe someone can add a note to the Wiki to get people to make it ascending (like it should be) would be a nice addition.

This was a good discussion.

[Corjan]

Done,

Corjan