Comments and Ratings

This is a nice function, thanks bruno for sharing it. You all may check out my NUMCMP function too.

http://www.mathworks.com/matlabcentral/fileexchange/21190-numcmp-m

Cheers, Carlos

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.

Thanks! It is very useful!

Marcello,

Do you have MEX setup? If not, type he following in command line:
>> mex -setup

If it's already installed you have to locate mexopts.bat file somewhere under the directory $MATLABROOT (where the Matlab is installed), then modify OPTPATH variable in line #8 and line #12 of GETMEXOPTS.

then try installation again.

Bruno

Nice program. Users might also be interested in a looped solution using the function "nextwhile" in the NextVector toolbox <pre class="link">http://www.mathworks.com/matlabcentral/fileexchange/24757&lt;/pre&gt;. If the entire matrix of combinations is needed then Bruno's version is faster (because row concatenation is slow) otherwise the looped solution is faster.

Works nicely with ILOG CPLEX 11 at least

Sorry about that.... I think that the following code does the trick
 
A_global = setspvalmex(A_global, Ic, Jr, X,@plus);

To Matt's comment #2: 2D error checking is introduced in KRON in recent Matlab version. KORNECKER is designed to replicate the same behavior (desirable?).

A workaround (beside delete the error checing line) is:

A = reshape(A,size(A,1),[]);
B = reshape(B,size(B,1),[]);
C = kronecker(A,B);

Mayowa,

Indeed that is faster for smaller A,B. However, for larger A and B, kronecker is several times faster.

To Bin Zhang:

The way HISTCN is design: If user supply m-edges [e1, e2, ..., e_m] then there are m-1 bins:

bin1 : e1 <= X < x2
bin2: e2 <= X < x3
...
bin-{m-1}: e_m-1 <= X < e_m

The Bin #m does not exist, unless if there is point hitting the right border:

X == e_m

You can indeed force the number of output bins to m by changing the line #66. to

sz(d) = length(ed)-1

Thanks,

Bruno

Very nice: smartly coded, fast, well implemented.

At last someone has implemented this functionality. Excellent!
I would only suggest that an example of usage and output could be helpful in the SetPartition file and that the first few lines of Bell and Stirling2nd could be rearranged to give meaningful H1 lines.

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

This would be useful to anyone implementing an interpolant in one dimension, or for those writing an interpolation in higher dimensions on a regular lattice. For example, a tensor product interpolant would benefit from this code as the first step, as would some other methods.

I won't offer a rating since I cannot test this without a c-compiler, and without the presence of the compiled version, it just calls interp1 as the engine. It looks well done to me from a quick read through of the code though. I won't make any claim about the c code, since I have no skills in that respect.

I'm not sure about the speed claim though, since if the author has based the claim of speed to a comparison to interp1, I can achieve a 55% reduction in time over interp1 just by a simple call to histc.

xgrid = (0:.1:10);
xi = rand(1,10000)*10;

tic,dx=diff(xgrid);[junk,B]=histc(xi,xgrid);B=B+(xi-xgrid(B))./dx(B);toc
Elapsed time is 0.010040 seconds.

tic,B = interp1(xgrid,(1:length(xgrid)), xi);toc
Elapsed time is 0.022428 seconds.

Both code fragments generate the same outputs, yet the histc one is considerably faster, and written in basic matlab. Any comparison of time should use this as the reference, not interp1.

A slick solution to this problem, that uses an elegant recursive code for its work.

Good help, error checks, defaults for arguments where they apply. One minor flaw that I'll hope the author fixes. There is no H1 line. An H1 line is the first line of help. It should be a descriptive line that the function lookfor keys on, including all reasonable keywords that you might search on.

Lookfor is useful when you need to find this function in a year. Will you remember the name "allVL1" next year? No, probably not. But lookfor will find this function for you, if you supply an H1 line.