Comments and Ratings

Matlab programming requires different approach and style than C programming. I suggest the OP to consider seriously the two comments the code has received and I hope he will improve his code.

Speed is decent, but still cannot beat another more generic histogram submission:

>> tic; [Hout xbins ybins] = hist2d(x); toc
Elapsed time is 0.282145 seconds.

>> tic; [count xbins ybins] = histcn(x,xbins,ybins); toc
Elapsed time is 0.218104 seconds.

http://www.mathworks.com/matlabcentral/fileexchange/23897-n-dimensional-histogram

Let alone an even faster mex implementation
http://www.mathworks.com/matlabcentral/fileexchange/3957

So I would change the implicit speed claim in the title.

Bruno

I wish James could do a treatment for SPARSE matrix, because initialize an intermediate matrix with EYE is sometime not an option with large (sparse matrix).

Thank you David for pointing out the bug. I better workaround IMO is change the line #257 to:
dS = realmin(class(S));
while the new version of ISMEMBERF is submitted.

What mathworks are waiting to incorporate this package into Matlab?

Good coding

It is also puzzling this can work

a=int64([0 1; 2 3])
b=int64([4 5 6 7]')
a+b

- Computing the minimum distances for all pair of points is not a good way to compute nearest neighbor, and it's certainly not a fast one when the set of given points is large.

- As the author has warned, this method cannot handle large size data.

- The mfile miss the H1 line. When user type "help compute_nearest_neighbour' he/she would not know how to call the function, unless he is the author.

This function can accomplish with an equivalent stock function, which performs much faster. Here is the demo using new stock class in 2009A which is 10 time faster. For older Matlab version similar Delanay technique can be used to accomplish the same task as well.

% Data
n = 5000;
canditate_points=randn(n,3);
given_points=randn(n,3);

tic
nearest_neighbour=nearestNeighbor(DelaunayTri(canditate_points),given_points);
toc % Elapsed time is 0.322600 seconds.
clear idx

tic
[nearest_neighbour]=compute_nearest_neighbour(canditate_points,given_points);
toc % Elapsed time is 3.445318 seconds.
clear

To Oleg: you could probably "simulate" the recursion algorithm by managing an artificial stack, which can be expanded when the limit is reached

I still do not function understand what the function does:

X = [ 8 8 9 3 7 1 2 4 5 1 ]
Y = [ 7 6 6 10 2 7 9 4 1 1]

[D, dist, aLongestString] = LCS(X,Y)
D = 0.6000
dist = 4
aLongestString = [ 7 2 4 1]

% Furthermore what is the limit of the function?

>> X=ceil(10*rand(1,1e4));
>> Y=ceil(10*rand(1,1e4));
>> [D, dist, aLongestString] = LCS(X,Y)
??? Out of memory. Type HELP MEMORY for your options.

Error in ==> LCS at 20
b = zeros(n+1,m+1);
  

I'm no longer allowed to rate the submission, but I appreciate Oleg for his open mind (change the engine) for the benefit of the user community.

Useful but this implementation runs slow for large and deep nested cell:

function benchflatcell

% Nested level
N = 100;
% Generate nested cell, the final size is N*(N+1)/2 = 5050
c={};
for i=1:N
    c = {num2cell(1:i) c};
end

tic
f1 = fcellrecurse(c); % receurse engine
toc % Elapsed time is 0.083139 seconds.

tic
f2 = flatcell(c); % FEX engine
toc % Elapsed time is 13.151985 seconds.

isequal(f1,f2) % OK

end

function c=fcellrecurse(c)
if iscell(c)
    c = cellfun(@fcellrecurse, c, 'UniformOutput', 0);
    c = cat(2,c{:});
else
    c = {c};
end

end % fcellrecurse

A small bug at line 70. It should be (transpose, not conjugate transpose in the second kron)
M = kron(eye(n),A) - kron(k*A.',eye(n))

Two words: excellent job!

Impressive running speed. I have tested against Matlab Delaunay/dsearch nearest point for 2 x 10^5 points and the code won hand down in speed. Very good work. I would like to see the author to provide mean/worse complexity of his algorithm, which is always necessary step when integrating in reliable software project.

Darren, thank you for the suggestion. I'll add an example of usage. Functions with more efficient engine will be soon upgraded.

Originally the WORKSPACE was developed under Matlab 2008B.
I (the author) have upgraded and tested the new version of the package (27 Jan 2009) for backward compatible to 2006B (tested under 2006B, 2007A, 2008B, and 2009A-prerelease). The workspace used the object-oriented programming (OOP) introduced officially by The Mathworks since 2008A. The file uses undocumented OOP feature and Java hashing for backward compatible.
I will be graceful if users of this package can report any eventual incompatible issue with previous versions.

Hi us,

Thank you for your comment. In depth, despite of your note, there are two advantages of the code and it is totally fair to compare WORKSPACE with EVAL IMHO:

First: Within the WORKSPACE methods evalin is used for the sole purpose of retrieving the value of variable(s) from the workspace. Never evalin is evaluated with the RHS (statement with '=' sign').

Second: From the user point of view, he/she does not to worry about building EVAL with full statement. Expressions are evaluated directly, and no longer through string (except for the variable name) as with EVAL.

Bruno