Comments and Ratings

No! There is no reason to cause help to fail, forcing the user to use type instead! I never suggested that. When did I ever recommend an idea like that?

All that you need to do to enable lookfor is to include ONE MORE LINE, at the very beginning of the help block!!!!!!!!!!! The comment block should be contiguous, to enable both help and lookfor.

Look at EVERY MATLAB function that MathWorks provides. Read the help for lookfor,

As far as the use of your function goes and the help itself, all that I have asked is that you make the help clear, explaining what it does, rather than forcing the user to divine exactly what you mean when you say the word "tuple". While you may feel this is obvious, other users will not have the same background. So make your help clear. Is this really difficult to do? Tell the user what happens when they pass in a vector, don't make them guess that the only piece of information that you take from that vector is the length of the blasted thing!!!!!!!

Good code is friendly to the user. Bad code makes the user make wild, unsupported guesses, and then returns arbitrary results when they lack the ability to read the mind of the author.

Hey guys how does this file work ? I have a file which is split in to two columns time with pressure I want to do the FFT on this within Matlab but im a little lost. Anyone guide me in the right direction please?

Kind Regards,
Bhavik

About plotting the results:

Jaclyn, if you just want bars plotted for the pairwise densities of two variables (i.e., a plot with x and y axes corresponding to values of your variables, and vertical bars on the x,y grid, corresponding to the counts for each 2D bin), you can get that with hist3().

Will, if you want to plot weights for 3 variables as varying sizes of bubbles on an x,y,z grid, you can do something like this:

% get the histogram
[count edges mid loc] = histcn(vals);

% make a grid for plotting
[X Y Z]=ndgrid(edges{1}, edges{2}, edges{3});
X=X(:); Y=Y(:); Z=Z(:);

% calculate sizes so the most dense cell gets a value of 100
% also convert from volume to "area" (as if drawing a sphere with
% the right volume and cross-sectional area s)
s_scale = 100/(max(count(:))^(2/3));
s = count(:).^(2/3) * s_scale;
% convert any zeros to small numbers for scatter3
s(s==0)=realmin;

% plot the densities
fh=figure();
set(fh, 'Renderer', 'OpenGL'); % faster drawing
scatter3(X, Y, Z, s, 'filled');

hi sir, ur work is really good.
i am too trying to implement the same as a part of my academics, so like to know more about the subject. can u please help me ?
i did like to know about the different steps involved in character recognition. can u provide me with some pdf documents which i can depend to complete my project.

I am NOT proposing anything. I merely tried to read the help for your own function, then tried to convince you that your code needs documentation when used in a way that your help says is possible. Here are a couple of lines, written by you!

% Usage 2: x = nsumk(1:5,2)
%
% n: vector

Exactly how should your code work? What is the behavior of your code when it is passed a vector input for n? You need to define that. And to this point, I have seen no definition, no explanation. I've seen multiple references to nchoosek, that your code is related in some way to nchoosek. Therefore I assumed that when I call it in a way that I would call nchoosek, I might get a similar result. If this is false, then you need to document your own code properly. I am not suggesting any new functionality for this code. Merely that you document the EXISTING functionality so that a person who might want to use it can do so.

John, Thank you for your response.
I will cite as you advised me to.

I'll try to have a look at De Boor's book.
I just wanted the solid math behind the tool.
Hopefully I'll get from there.

One day, If you do write an article or notes about it I'd be happy to read and learn.

Thank you.

Yes, but if you will argue that this code is in any way consistent with nchoosek, then it must be so. In the example I posed,

nsumk(1:3,5)

yields numbers that are not in that set! Zero is not in the set. 4 is not in the set. 5 is not in the set.

So clearly your code is not consistent with nchoosek, despite multiple statements that it is. You say what your code does and doe not require, but no place do you state that in the help. If you do not state what your code does, then how will anybody else ever find it of value?

Next, if you have lost the code before, then this is even a better reason to enable lookfor. Use an H1 line. Use a help style that at least tries to follow the style of help that the MathWorks uses. This makes your code more useful to others. Otherwise, it is of no use to anybody but you.

John,

   Thanks for the extremely speedy feedback.

   Zero is a non-negative integer, and we do not require the integers here to be less than the number of variables. In generally accepted parlance the term tuple usually means an ordered list of elements, so I think the intent is clear. Sorry for my brevity. FYI it is a natural way to list polynomials in n variables of degree precisely k.

    As is evident from the code this is little more than syntactic sugar for nchoosek, but since I've lost it once before I'm sticking it here!

Peter

Also, the help needs to be explicit about whether the pair of integers {2,3} is distinct from the pair {3,2}. I would argue that is an extremely important distinction. This code seems to count them both.

Yet another brilliant piece of code from you Abbas! Thank you very much for posting that.

Hi Hils, could you tell me how did you decide the initial parameter value as input ? Thank you very much!

I wish I had written a paper on this topic years ago when I wrote the first version of this tool. I did not do so then, although I have given a few talks on the underlying modeling philosophy of these tools.

The basic idea is simply that of a least squares spline, augmented by a smoothness penalty like a smoothing spline. The smoothness penalty solves the problem of arbitrary (poor) knot selection in many cases.

General least squares splines are covered in depth in the literature, as are smoothing splines. For these fundamental ideas, de Boor is of course the classic reference, a book worth reading for any user of splines.

What the SLM tools add though is something that I've never really seen written about in the literature. This is the idea that intelligently chosen constraints on the curve shape can act as a strong, useful regularizer on your result. They allow you to build your own knowledge about a system into the model, using a simple vocabulary to describe the desired shape of that curve.

I wrote these tools after some years of seeing people using strange nonlinear regression models to fit curves, just because they needed a curve with a given shape. So the user picks some nonlinear sigmoidal form, a Gaussian, etc., for no better reason than that it fits some fundamental desired shape. And of course, nonlinear regression has its own problems, like poor starting values, lack of convergence, etc. Worse, the user finds that the curve shape they chose is not really the correct shape, so they end up with significant lack of fit. Once a viable tool becomes available to fit those curves, I find that far fewer people end up using nonlinear regression models for the wrong reasons.

There are a couple of files that discuss some of these ideas "slm_tutorial.html" and "shape prescriptive modeling.rtf" in the zip file, but that is all I can offer. We also suggested a citation format for tools from the file exchange, if you do need an explicit reference. You can find our recommendations here:

http://matlabwiki.mathworks.com/Citing_Files_from_the_File_Exchange

% Input data SHOULD be meteological wind data coming from
% ie. 0 deg=North, 90 deg=East, 180 deg=South, & 270 deg=West
% if 'dtype' is 'ocean'; to do coversion mod(-90-D,360) and
% to plot wind direction from meteolocal convention
% (coming from) to oceanographci convention (going to)
% if 'dtype' is 'meteo'; to do coversion mod(90-D,360) and
% to plot wind direction in meteolocal convention
% In case, input data are in oceanographic convention. Without 'dtype'
% option, wind_rose will plot wind going to. It is same results when
% 'dtype' is 'ocean' using wind data coming from (meteological convention)

it's great work! thanks

what about "the old metod" s function??

Hi, do you have some simple example about how to use it ?

The program is great and lets the user to avoid the trouble of dealing with the original Fortran CONTIN program. The program works great, although I have just a couple comments:
- The "s" array fed to rilt is actually a tau array (s = 1/tau).
- "rilt.m" should be called "rlm.m" because it is actually the forward transform by the majority of definitions I've ever seen. L[f(t)] = F(s) = F(1/tau) is the forward transform.

That said, I want to say thank-you to the programmer. This routine has helped me out with an aspect of my thesis.

Hello,

Toolbox looks nice, but

feats = openSurf(randn(49,285));

errors:

??? Index exceeds matrix dimensions.

Error in ==> FastHessian_isExtremum>FastHessian_getResponse at 44
an=a.responses(fix(scale*row) * a.width + fix(scale*column)+1);

Error in ==> FastHessian_isExtremum at 25
candidate = FastHessian_getResponse(m,r,c,t);

Any ideas?

Cool. How can I set meshscale independently for rho and theta?

*Petter
I have optimized the Matlab code, replacing all for-loops by 1D and 2D indexing. This version takes less then 1 sec for the example picture.
The original C# version is only 2x as fast for large images.
Of course a mex file is faster, but this Matlab code is easier to study, debug, and doesn't need external libraries or compilers.

(Tomorrow a new version wil be online were I fixed a small bug in the image display function)

If you are really interested in the downside risk Steiner's version is the best. Then you have more insight about the tail. This is very important when looking at regimes.

What a perfect work~~~ I try it and foud that the gradient of the image is calculated as [My,Mx]=gradient(M); But why you want to inverse the x and y? Since normally we use [Mx,My]=gradient(M); Maybe it is related to your 'Movepixels' function?

Your implemntation is based on the additive Demons, do you have any idea to add a compositive Demons? How do we calculate the composition of fields in Matlab? Thanks.