bugGNU Octave - Bugs: bug #31352, interp2 broken for non-quadratic...

 
 

bug #31352: interp2 broken for non-quadratic matrices when using cubic interpolation

Submitter:  None
Submitted:  Sat 16 Oct 2010 05:16:07 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Gunnar Farnebäck Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 18 Sep 2011 02:15:08 AM UTC, comment #18: 

This seems to have been resolved, so I'm closing this bug.

If my inference is incorrect, it can be reopened.


Ben Abbott <bpabbott>
Group Member
Mon 14 Feb 2011 08:27:03 AM UTC, comment #17: 

Dear Thorsten,

sorry for my long delay. I successfully applied your changeset to 3.4.0 and passed all the tests. So, for me, your patch is fine.

Marco

Marco Caliari <caliari>
Group Member
Sat 12 Feb 2011 08:45:17 PM UTC, comment #16: 

attached is an update of the changeset below, that can be applied to the current mercurial sources.

Could someone please review this, as I am already forgetting what it was all about?

thanks

Thorsten

(file #22664)

Thorsten Meyer <tmeyier>
Thu 02 Dec 2010 09:22:27 PM UTC, comment #15: 

Hello all,

attached is a changeset containing a merged version of bicubic together with Marcos changes in interp2 and _splinen_, the tests by Gunnar and a few other tests. Also, I added to the documentation of the bicubic function.

bicubic will use Marcos algorithm for meshgrid data and my algorithm for scattered data. Also, there is an undocumented parameter to explicitly choose which algorithm to use.

As far as I can see, the results are accurate and do not differ by more than a reasonable numerical roundoff error.

However, as you suspected, Marco, in case of scattered xi and yi, your algorithm will only be slower than the other one for large x,y or xi, yi vectors. And I guess it will depend on details of the hardware, where the breakeven is. I would probably still stick to the simple choice of algorithm by meshgrid versus scattered.

Here is a script to compare the performance of the two algorithms for scattered data and different sizes of x,y,xi,yi:


# compare runtimes of bicubic algorithms
t1 = zeros (30,31);
t2 = zeros (30,31);
o = 1;
more off;
for m = logspace (1, 3.5, 30);
  p = 1;
  for n = logspace (1, 5, 31);
    x  = linspace (-100 * rand(1,1), 100 * rand (1,1), m);
    y  = linspace (-100 * rand(1,1), 100 * rand (1,1), m);
    xi = linspace (min(x), max(x), n);
    yi = linspace (min(x), max(x), n);
    Z = rand (length(y), length(x));

    try
      tic;
      Zi = bicubic(x,y,Z,xi,yi, nan, -0.5, 1);
      t1 (o,p) = toc;
    catch
      t1 (o,p) = nan;
    end_try_catch
#    try
      tic;
      Zi = bicubic(x,y,Z,xi,yi, nan, -0.5, 2);
      t2 (o,p) = toc;
#   catch
#      t2 (o,p) = nan;
#    end_try_catch

    p++;
    puts(".");
  endfor
  o++
endfor
more on;

h1=mesh(logspace (1, 5, 31), logspace (1, 3.5, 30), t1);
hold on;
h2=mesh(logspace (1, 5, 31), logspace (1, 3.5, 30), t2);
set(gca, "xscale", "log", "yscale", "log", "zscale", "log")
set(h1, "edgecolor", "blue");
set(h2, "edgecolor", "red");
xlabel ("n xi");
ylabel ("n x");
zlabel ("t(s)");
hold off;


regards

Thorsten



(file #22106)

Thorsten Meyer <tmeyier>
Tue 23 Nov 2010 09:16:35 AM UTC, comment #14: 

Dear Thorsten,

bicubic_tm.m is exactly what was missing in my implementation! Unless you can find an example in which scattered interpolation with bicubic_tm is slower (maybe for small vectors) or less accurate of bicubic.m (your comment 2. does not really count for me), I suggest that the final bicubic.m should use by default my implementation for meshgridded values and your implementation for scattered values. Moreover, I agree with your comment 1. and 3. and I will not consider to optimize my bicubic.m for the scattered case.
Can you write the merged version of bicubic.m? Then, we should collect all the tests proposed by us (Gunnar included) to check that everything is still working and finally submit a patch.

Cheers,

Marco

Marco Caliari <caliari>
Group Member
Tue 23 Nov 2010 08:23:43 AM UTC, comment #13: 

Dear Marco,

finally I have found the time to have a look at your latest version of bicubic.m. Thanks for your good work.

To answer your question: yes, I could still construct a test case, where bicubic fails but the old interp2 manages to deliver (on my machine):

  x = linspace (-3, 3, 8000);
  y = linspace (-5, 7, 9111)';
  A = (1/10000 y.^4 + 3 sin (y)) (x.^5 - 10 x.^3) - y cos (x) 10;

  xi = linspace (min(x), max(x), 19071);
  yi = linspace (min(y), max(y), 19071);

  Z1 = bicubic (x, y, A, xi, yi);

gives "memory exhausted" for me.

while
  Z2 = interp2_old (x, y, A, [xi; xi], [yi; yi], "cubic");
succeeds. Even this is possible:
  xi = linspace (min(x), max(x), 1907100);
  yi = linspace (min(y), max(y), 1907100);
  Z2 = interp2_old (x, y, A, [xi; xi], [yi; yi], "cubic");

I think the reason for this is that your bicubic function uses the same amount of memory for the intermediate matrix
(ZI = ZI * Cxy) as in the full meshgrid case.

Then, I couldn't resist and wrote yet another version of bicubic: see the attached file bicubic_tm.m. It is based on the bicubic code in the old interp2.m. Consequently, it can cope with the above example:
  xi = linspace (min(x), max(x), 1907100);
  yi = linspace (min(y), max(y), 1907100);
  Z1 = bicubic_tm (x, y, A, xi, yi);

However, in case of full meshgrid interpolation, it is much slower than your code:
  x = linspace (-3, 3, 8000);
  y = linspace (-5, 7, 1111)';
  A = (1/10000 y.^4 + 3 sin (y)) (x.^5 - 10 x.^3) - y cos (x) 10;

  xi = linspace (min(x), max(x), 1071);
  yi = linspace (min(y), max(y), 821)';

  tic; Z5 = bicubic (x, y, A, xi, yi); toc
Elapsed time is 0.1334 seconds.

  tic; Z6 = bicubic_tm (x, y, A, xi, yi); toc
Elapsed time is 3.118 seconds.

For interpolating vectors of points, bicubic_tm can be a lot faster:
  x = linspace (-3, 3, 8000);
  y = linspace (-5, 7, 9111)';
  A = (1/10000 y.^4 + 3 sin (y)) (x.^5 - 10 x.^3) - y cos (x) 10;
  xi = min(x) + rand(10000,1) * (max(x) - min(x));
  yi = min(y) + rand(10000,1) * (max(y) - min(y));
  tic; Z7 = bicubic (x, y, A, xi, yi); toc
Elapsed time is 3.193 seconds.
  tic; Z8 = bicubic_tm (x, y, A, xi, yi); toc
Elapsed time is 0.0745 seconds.

Maybe we should include two implementations in bicubic: one optimized for the full meshgrid case the other for interpolating vectors of points. They could be either chosen by an input parameter or selected automatically depending on the xi, yi input (depending on how well the results of the two implementations can be matched numerically).

A few additional details in the code:
1. bicubic_tm seems to be a bit more robust wrt rounding errors in the step size:
  x = linspace (-3, 3, 8);
  y = linspace (-5, 7, 11)';
  A = (1/10000 y.^4 + 3 sin (y)) (x.^5 - 10 x.^3) - y cos (x) 10;
  xi = linspace (min(x), max(x), 101);
  yi = linspace (min(y), max(y), 81)';

  Z1 = bicubic (x, y, A, xi, yi);
  Z2 = bicubic (x+100000*pi, y, A, xi+100000*pi, yi);
  Z3 = bicubic_tm (x, y, A, xi, yi);
  Z4 = bicubic_tm (x+100000*pi, y, A, xi+100000*pi, yi);
  max(max(abs(Z1-Z2)))
ans = 8.2191e-09
  max(max(abs(Z1-Z3)))
ans = 4.7962e-13
  max(max(abs(Z3-Z4)))
ans =  2.6484e-09
  I suspect this is due to the different calculation of the step size (as x(2)-x(1) in bicubic.m or effectively as (x(end)-x(1)/N in bicubic_tm.m).
 
2. on the other hand, bicubic_tm doesn't pass the accuracy tests in your interp2.m. E.g:
  Z = (1:4)' * (1:5);
  x = 1:5;
  y = 1:4;
  Xi = [1.2 4.7];
  Yi = [1.8 2.3 3.1];
  Zi = [2.16 8.46
        2.76 10.81
        3.72 14.57];
  assert(bicubic_tm(x, y', Z, Xi, Yi'), Zi, -5*eps);
maximum relative error 1.64477e-15 exceeds tolerance 1.11022e-15
I am not sure why this is so (or if it is really a problem).

3. in bicubic you don't test if xi, yi are really meshgridded in case they are equally sized matrices. I think this is good. So there will be the interp2 function with full input checking and the bicubic function that doesn't waste time with extended input checks.

4. in your bicubic.m you reuse several variable names for different purposes (ZI, Cxy, A, D). That made the code look rather confusing for me. Are you sure that you can save memory usage by this?

regards

Thorsten

(file #22084)

Thorsten Meyer <tmeyier>
Fri 05 Nov 2010 11:20:41 AM UTC, comment #12: 

Dear all,

here it is another version of my bicubic.m. I'm not sure the problem of 'memory exhausted' has completely gone (i.e., are still there cases that the old code can manage and the new one not?). Anyway, issues (2) and (3) by Thorsten are fixed. By the way, in comment (3) x is not equispaced: bicubic can only handle equispaced x and y, otherwise a spline approach has to be considered (this is automatically done by my interp2 called with the 'cubic' options).
I also improved the performance, even if the case with large scattered xi and yi is still better with the old code.

Please test it.

Marco

(file #21932)

Marco Caliari <caliari>
Group Member
Wed 03 Nov 2010 08:07:58 AM UTC, comment #11: 

Dear Thorsten,

thanks for all your useful comments.

(1) you are absolutely right about the relative test.
(2) that's the limit of my very simple implementation: it should be faster (or much faster) for large x and y and not so large xi and yi, but more memory consuming. I will think again about the implementation.
(3) the fourth case is fine with interp2 (x,y,B,xi',yi,'cubic') (lines 349++ in interp2.m), so easy to fix.
(4) Can you specify the values of xi and yi in the first two cases? The case with large xi and yi is more efficient with the old code, this I already observed. I will think again.

Thanks again,

Marco

Marco Caliari <caliari>
Group Member
Tue 02 Nov 2010 09:22:18 PM UTC, comment #10: 

Dear Marco,

here a few comments to your new implementation of bicubic:

 (1) I'm not sure about your test for equally spaced x and y vectors: you test for absolute difference > eps. However, is this a good idea? E.g.:
    x = linspace(0,100,1001);
    max(abs(diff(x)-diff(x)(1)))/eps
ans =  38.375
    x = linspace(0,10001,1001);
    max(abs(diff(x)-diff(x)(1)))/eps
ans =  7272

How about something like
    any(abs(diff(X)-diff(X)(1))/max(abs(X))) > eps
I.e., take relative differences instead.

Also, maybe it would be a good idea to care for the possibility of single precision data:
    any(abs(diff(X)-diff(X)(1))/max(abs(X))) > eps(class(X))

 (2) while testing your new function I came across the following error:

x=linspace(0, 100, 1000001);
y=[0, 1, 2]';
xi=100*rand(1000,1);
yi=2*rand(1000,1);
Z=y*x;
tic;zi=bicubic(x,y,Z,xi,yi);toc

error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt

Both the old bicubic implementations can handle this input. I think the problem is, that you generate very large intermediate matrices with size length(x) length(xi) and length(y) length(yi). In this respect, I think the old implementation within interp2 is quite clever, as it uses index magic to only use the neighbor points to xi, yi for the actual calculation. Could this approach be adapted for bicubic.m (especially in case of meshgrid xi, yi)?

 (3) comparing with matlab I find, that matlab treats the two cases where xi,yi are vectors equally, while the new bicubic.m fails in one of them:
    x=[0,1,4]+10;
    y=[-10,-9,-8];
    [X,Y] = meshgrid(x,y);
    B=X.^2 - 10 * (Y+9).^2 + X.*Y;
    xi=linspace(min(x),max(x),17);
    yi=linspace(min(y),max(y),17);
    size(bicubic (x,y,B,xi,yi))
ans =

    1   17
    size(bicubic (x,y,B,xi',yi'))
ans =

    17   1
    size(bicubic (x,y,B,xi,yi'))
ans =

   17   17
    size(bicubic (x,y,B,xi',yi))
error: bicubic: mx_el_or: nonconformant arguments (op1 is 17x1, op2 is 1x17)
error: evaluating argument list element number 1
error: invalid empty index list
error: called from:
error:   /home/thorsten/hg/octave/scripts/general/bicubic.m at line 86, column 66
error: evaluating argument list element number 1
(matlab gives the same interpolation result in the last two examples)

 (4) comparing the performance of the different implementations I see the following:
    x=linspace(0, 100, 1001);
    y=[0, 1, 2]';
    Z=y*x;
    tic;zi=bicubic(x,y,Z,xi,yi);toc
Elapsed time is 0.1061 seconds.

    tic;zi=bicubic_old (x,y,Z,xi,yi);toc
Elapsed time is 0.4106 seconds.

    tic;zi=interp2_old(x,y,Z,[xi, xi],[yi, yi],'cubic');toc
Elapsed time is 0.01675105 seconds.

With a more square matrix of data to interpolate I get:
      x=linspace(0, 100, 54);
      y=linspace(0, 33, 55)';
      Z=y*x;
     tic;zi=bicubic(x,y,Z,xi,yi);toc
Elapsed time is 0.00868 seconds.
     tic;zi=bicubic_old (x,y,Z,xi,yi);toc
Elapsed time is 0.388 seconds.
     tic;zi=interp2_old(x,y,Z,[xi, xi],[yi, yi],'cubic');toc
Elapsed time is 0.0151 seconds.

With a larger number of points at which to interpolate:
      x=linspace(0, 100, 54);
      y=linspace(0, 33, 55)';
      Z=y*x;
      xi=100*rand(100000,1);
      yi=2*rand(100000,1);
      tic;zi=bicubic(x,y,Z,xi,yi);toc
Elapsed time is 0.912 seconds.
      tic;zi=bicubic_old (x,y,Z,xi,yi);toc
error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt
      tic;zi=interp2_old(x,y,Z,[xi, xi],[yi, yi],'cubic');toc
Elapsed time is 0.512 seconds.

So from a performance point of view, the old implementation in interp2 seems to be comparable to the new bicubic.m

Regards

Thorsten

Thorsten Meyer <tmeyier>
Tue 26 Oct 2010 07:36:23 AM UTC, comment #9: 

Dear Gunnar,

of course the changed orientation in the tests is wrong, sorry for the noise. I fixed the orientation with the enclosed patch over _splinen_.m (it seems to me that is does not break anything else). I removed bc and sym_sub2ind in interp2.m. I'm enclosing the diff files wrt 3.3.53.

Marco

(file #21823, file #21824)

Marco Caliari <caliari>
Group Member
Mon 25 Oct 2010 07:32:17 PM UTC, comment #8: 

Overall it looks like a solid improvement over the current implementations.

The two subfunctions bc and sym_sub2ind at the end of interp2 are no longer used and should be removed.

Regarding the changed orientation in two of the tests I suggest you check that again. It's unreasonable that interp2(Z, Xi(1), Yi, 'spline') should give a result which has the opposite orientation to all other interpolation methods.

/Gunnar

Gunnar Farnebäck <gf>
Mon 25 Oct 2010 01:20:11 PM UTC, comment #7: 

Dear all,

I'm attaching my new versions of interp2.m and bicubic.m. Comments:

1) bicubic supports meshgridded X,Y, extrapval and spline_alpha (now called a)
2) for the cubic interpolation, interp2 does the following:
X and Y must be vectors of the same length or meshgridded
XI and YI vectors of different orientation (or meshgridded) or scattered (same dimensions)

if (X and Y not equispaced)
  if (XI and YI meshgridded)
    _splinen_
  else
    direct spline
  endif
else
  bicubic
endif
3) all the testcases suggested by Gunnar (and included in interp2.m) now pass, with some small modifications in the tolerance or in the orientation of the result (now the orientation is ml compatible).
4) Documentation could be improved.

Please check.

Marco

(file #21807, file #21808)

Marco Caliari <caliari>
Group Member
Fri 22 Oct 2010 07:49:30 AM UTC, comment #6: 

In fact, my newinterp2 uses _splinen_ when needed.
About newbicubic, meshgridded X,Y is just input parsing, extrapval and spline_alpha are quite trivial and I will add them.

I had some problems with the input parsing of existing interp2 (see item #30587) and I preferred to write from scratch (it is not complete, of course). I have chosen a wrong name "newinterp2": what I am really writing is a new cubic2 interpolation (using bicubic, _splinen_, spline, ...), to be merged in the existing interp2.

Best regards,

Marco

Marco Caliari <caliari>
Group Member
Thu 21 Oct 2010 07:07:01 PM UTC, comment #5: 

_splinen_ is the function used for the spline method in the existing interp2.

newbicubic seems to work well computationally and is simpler and faster than bicubic, as well as additionally supporting scattered interpolation points. It does miss a bit of flexibility (meshgridded X, Y), however, and some bells and whistles (extrapval and spline_alpha).

I haven't tried to run the latest newinterp2 yet but looking at the code it isn't clear to me why you rewrite the input parsing. That part of the code looks fine in the existing interp2. To me it seems easier to fix the shortcomings in interp2 than to rewrite from scratch.

I attach a patch adding testcases for interp2 when called with vector-valued Xi and Yi. A number of them are not currently passing.

/Gunnar

(file #21748)

Gunnar Farnebäck <gf>
Wed 20 Oct 2010 11:46:54 AM UTC, comment #4: 

Dear Gunnar,

thanks for all your comments!

1. I didn't know _splinen_, but it is the same and a little bit faster for meshgridded XI,YI (so, it should be used)
2. yes, it is
3. of course, I think it is fixed now
4. done, for the "not-equispaced X,Y, scattered XI,YI" case
5. done (newcubic.m)

Please test the new attached files,

Marco

(file #21731, file #21732, file #21733)

Marco Caliari <caliari>
Group Member
Tue 19 Oct 2010 09:39:58 PM UTC, comment #3: 

My comments on newinterp2:
1. Is there any difference in result between the meshgrid case and _splinen_ with the corresponding arguments? Which is faster?
2. The scattered data case looks like a generalization over _splinen_.
3. The nargin==3 special case is broken; XI and YI remain unassigned and Z has the wrong content.
4. The spline+ppval combination can be reduced to a spline call with three arguments.
5. Please fix the standard bicubic interpolation for equispaced data. When using interp2 on image sized data speed (and memory consumption) really matter.

/Gunnar

Gunnar Farnebäck <gf>
Tue 19 Oct 2010 09:17:50 AM UTC, comment #2: 

Dear all,

here is my first rewrite of cubic interpolation in interp2. Comments:

1) it uses spline interpolation instead of the more simple bicubic (it allows not equispaced meshgridded X and Y)
2) The function is still undocumented and without input checking.
3) Thorsten's patch https://savannah.gnu.org/bugs/download.php?file_id=21707 should be applied to spline
4) another patch should be applied to spline in order to manage in a default way the case

spline([0,1],[0,1])

5) issues 3) and 4) can be ignored if you use enough (> 3) points for X and Y
6) I could reduce the code to standard bicubic (as ml) if X and Y are equispaced (it is faster and the default in ml), i.e. I can rewrite the actual bicubic.m in a more accurate and faster way.

Comments?

Marco

(file #21716, file #21717)

Marco Caliari <caliari>
Group Member
Mon 18 Oct 2010 03:31:46 PM UTC, comment #1: 

I have applied your first changeset (as 78a6016875ed). Thanks for that and welcome to octave development :-).
When you provide a changeset next time: could you also include a Changelog entry, please?

About your second changeset: the reason why interp2 fails for vector arguments even with the first patch applied is that at the moment cubic interpolation using the separate function bicubic.m is deactivated (see bug #30587). I think, Marco Caliari is working on this.
Apart from that, in my opinion, it would be nicer not to have to blow up the x and y vectors with meshgrid for interpolation.

I'm not sure if your 2nd patch should be applied as a temporary fix (that do you think, Marco?).

regards

Thorsten

Thorsten Meyer <tmeyier>
Sat 16 Oct 2010 05:16:07 PM UTC, original submission:  

As shown below interp2 fails with a bogus error message when called with a non-quadratic Z argument and cubic interpolation.

octave:1> interp2([0 0 1;0 1 1], [1.5 2.5], [1.5 1.5], 'linear')
ans =

   0.25000   0.75000

octave:2> interp2([0 0 1;0 1 1], [1.5 2.5], [1.5 1.5], 'cubic')
error: interp2: X and Y size must match Z dimensions
error: called from:
error:   /tmp/octave/scripts/general/interp2.m at line 330, column 9

After applying the attached trivial patch interp2_fix1.diff a new failure appears:

octave:1> interp2([0 0 1;0 1 1], [1.5 2.5], [1.5 1.5], 'cubic')
error: interp2: mx_el_or: nonconformant arguments (op1 is 1x2, op2 is 2x1)
error: called from:
error:   /tmp/octave/scripts/general/interp2.m at line 357, column 8

This is maybe best fixed by duplicating the corresponding code from the linear case, although it begs the question why this code isn't shared between interpolation methods in the first place. Patch attached as interp2_fix2.diff.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #22664:  interp2_fix_caliari added by tmeyier (31KiB - application/octet-stream)
file #22106:  interp2_fix_caliari added by tmeyier (31KiB - application/octet-stream)
file #22084:  bicubic_tm.m added by tmeyier (7KiB - text/x-objcsrc)
file #21932:  bicubic.m added by caliari (6KiB - text/x-objcsrc)
file #21823:  interp2.m.diff added by caliari (9KiB - text/x-patch)
file #21824:  __splinen__.m.diff added by caliari (417B - text/x-patch)
file #21807:  bicubic.m added by caliari (4KiB - text/x-objcsrc)
file #21808:  interp2.m added by caliari (20KiB - text/x-objcsrc)
file #21748:  interp2_testcases.diff added by gf (4KiB - text/plain - Tests for interp2.)
file #21731:  testnewinterp2.m added by caliari (2KiB - text/x-objcsrc)
file #21732:  newbicubic.m added by caliari (2KiB - text/x-objcsrc)
file #21733:  newinterp2.m added by caliari (1KiB - text/x-objcsrc)
file #21716:  newinterp2.m added by caliari (512B - text/x-objcsrc)
file #21717:  testnewinterp2.m added by caliari (581B - text/x-objcsrc)
file #21695:  interp2_fix1.diff added by None (728B - text/plain - Patches for interp2.)
file #21696:  interp2_fix2.diff added by None (971B - text/plain - Patches for interp2.)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by gf (Posted a comment)
  • -email is unavailable- added by caliari (Updated the item)
  • -email is unavailable- added by tmeyier (Posted a comment)
  • -email is unavailable- added by tmeyier
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-18 bpabbott StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2011-02-12 tmeyier Attached File- Added interp2_fix_caliari, #22664
    2010-12-02 tmeyier StatusNone Ready For Test
    2010-12-02 tmeyier Attached File- Added interp2_fix_caliari, #22106
    2010-11-23 tmeyier Attached File- Added bicubic_tm.m, #22084
    2010-11-05 caliari Attached File- Added bicubic.m, #21932
    2010-10-29 dbateman Dependencies- bugs #30587 is dependent
    2010-10-26 caliari Attached File- Added interp2.m.diff, #21823
        Attached File- Added _splinen_.m.diff, #21824
    2010-10-25 caliari Attached File- Added bicubic.m, #21807
        Attached File- Added interp2.m, #21808
    2010-10-21 gf Attached File- Added interp2_testcases.diff, #21748
    2010-10-20 caliari Attached File- Added testnewinterp2.m, #21731
        Attached File- Added newbicubic.m, #21732
        Attached File- Added newinterp2.m, #21733
    2010-10-19 caliari Attached File- Added newinterp2.m, #21716
        Attached File- Added testnewinterp2.m, #21717
    2010-10-18 tmeyier Carbon-Copy- Added -email is unavailable-
    2010-10-16 None Attached File- Added interp2_fix1.diff, #21695
        Attached File- Added interp2_fix2.diff, #21696

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code