You would probably be better off using a plain mex-file rather than emlmex – which is meant for working with Simulink. There is a lot of information in the External Interfaces section of the MATLAB documentation for more information : http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/bp_kqh7.html

You *can* sometimes get substantial speedups, but you often can do close to as well using “well-written” MATLAB code too. That’s what I tend to focus on in this blog.

–Loren

I searched your blog and couldn’t find much with relevance to mex files.

I don’t really know how to code in C, but I stumbled across emlmex recently (when digging into the guts of polyval to try to speed it up). I wrote a simple and ugly for loop (loop over a vector and output the square of the sine of each element) and ran it as an m-file and then using emlmex to generate a mex file. The mex-file sped my code up by a factor of 2.

I’m currently working on an economics problem, used emlmex on an m-file I had, and it cut the execution time by 60%.

When I google emlmex, though, I find almost nothing on the internet about it. I’ve been using matlab for a few years, and have read a lot of different documents on various speedups. I’ve never seen emlmex mentioned, though. Do you know why this is?

I’m commenting here because it seems like it might be useful for other people to be able to get substantial speedups on things like loops without much effort.

For your reference, here’s the .m file I used:

—————————–
function tester=tester(param,data)

%%%%%%%%%%%%
b=data;
for i=1:50000
b(i)=param*sin(b(i)^2);
end

tester=sum(b);
————————————–
I ran it on a 50000×1 vector and timed it by running it 200 times with the m- and mex-files

I recommend you look at M-files we ship with MATLAB that seem similar in the idea of the extra inputs and see how the error checking is done there. One way that’s newer is to use an inputParser object for at least part of the work. Another tool is the function assert.

–Loren

I have a function I wrote that is very similiar to FREAD in terms of input arguements:

A = FREAD(FID,SIZE,PRECISION,SKIP,MACHINEFORMAT)

Here, SIZE and SKIP arguements are optional that is the function shows an intelligent behaviour when we type

a = fread(fid,precision,machineformat)

My function also has these optional arguements depending on the type of inputs. So, can you suggest basic methods/guidelines for distributing the input arguments properly, and a robust error checking inside the m-file?

Thank you!

Oktay

http://check.sourceforge.net.

When coding under Matlab I found no decent testing framework so I wrote my own.

One of the things I find about writing tests is not only do they provide regression error protection but they help me understand my own code and designs. I may come back to some obscure corner of an API I have written after a month and forget exactly how I intended it to be used. If I have a test case for it then more often than not it makes clear to me what I was up to.

http://xtargets.com/cms/Tutorials/Matlab-Programming/MUnit-Matlab-Unit-Testing.html

which you can download and use. It’s simple to get started with and integrates into the Matlab web browser for report generation and interactive testing.

Extend a function that works correctly for “small” input to the rest of the real line. What is “small”? Do you check for it and error if the input doesn’t meet the criteria? If so, you are okay. If you think you might need it later for a different range, it’s best to make that clear with documentation and an error, until you upgrade it. In this case, e.g., bessel functions with large input, I would prefer to make the function work correctly from the start. Then I can always rely on it. To me, this fits more closely into Make the code general and document ranges and exceptions.

Extend a function that works for real input onto the complex plane. And spend lots of time figuring out how to do the analytic continuation and defining appropriate branch cuts so inputs can be anywhere in the complex plane. Again, either error and document carefully, or implement. Is it worth implementing? Can you imagine using it that way, or is it just cool? If you don’t really see your way clear to a definite use case, even if you won’t need it for that right away, it might not be worth the effort right now. To me, this one fits more closely into Avoid speculative generality.

Avoid speculative generality.

Make the code general and document ranges and exceptions.

What is the difference between general code and “speculative generality”? Is there a line between the two?