While GUI-setting parameters for procedures working on one or both matrix dimensions a higher reliability of correspondence between matrix dimension and sequential parameter number is appreciated. In addition, a greater slider increases its sensitivity. Both conditions are met by SWIDDER, which matches matrix dimension with its output according to ML standard. A toggle for 'dataaspectratio' is supplied.
Works in integer or float modes, is easily handled for equal positive intervals, is valid for selection of two parameters from arbitrary intervals whose upper bounds may be overridden.
Sound functions O_O and CHEER included in .zip. UNIFRND in CHEER is replaced by RAND.
Less than 2nd rate. Why bother with this, if VP can't be bothered to make it easy to use? Not a uicontrol anyway. Just as easy to use use ginput if you must create a new figure window.
///First, I see that when the cursor drops outside the axes, you get a NaN when you go below the lower bound. But there is no constraint on the upper end. This seems inconsistent. Why do it this way? ///
SLIDDER is a part of a GUI which integrates several matrix-oriented procedures, all need NONNEGATIVE integer vertical and/or horizontal parameters. NaN means that corresponding procedure skips the processing in corresponding matrix dimension. This is a very convenient and clearly percepted convention.
Therefore I do not need to treat the upper bound in a similar way. Moreover, the filtering windows vary in the range from 10 to 100. The greater the upper bound, the more difficult is to catch wanted window. Therefore the option of overriding the upper bound really makes the users life easier. The thing is that the SLIDDER works in parallel to an editable text box which receives the output from the SLIDDER. If catching numbers with SLIDDER appears difficult, the user has to type the windows by hand. However, the probability of a conflict between x-y sequence convention and 1-st and 2-nd dimension convention increases, because not all the users eat wooden chips. This probability is minimized by the option of overriding upper bound: if my default is 31 31, I still can easily reach much greater values like 71 or so with the SLIDDER. Therefore accepting upper bound smaller than it finally appears to be necessary improves catching numbers and leads to no conflicts exactly due to overriding the upper bound.
Thus, what seems to be inconsistent in the West, can easily appear to be a life necessity in the East.
Because not always the parameters should be integer I have added the float mode. In my practice, I did never work with fixed steps < 1. However, if such a special case comes, then the continuous output can easily be quantified. However, should I add this option, any expert, not to speak about normal users, will be overloaded. Too good is again bad.
///The simple fix is to define the "CloseRequestFcn" as the same as clicking on the finish button in the window.///
This is a really useful and helpful remark, thanks. I shall try and probably resubmit the SLIDDER if not delete it. I personally do not lose anything.
The name SWIDDER does not mean SaintWIDDER. Another John informed me that my submission can not be accepted because it was compressed by .rar, not .zip. I had to resubmit, but it was too late and I was tired. In a couple of days many people come here to participate in the conference, and those who have seen the SLIDDER before coming (as well as MLIN, POWEL, LINPAT which are parts of the same GUI) will have more preliminary informations, therefore they will use their time here more efficiently.
I amend my previous review. I gave the submission a 1 star rating to counterbalance the 5 star rating by Shaun D. The resulting average of 3 stars is more appropriate for this particular submission.
I'm closer to Shaun here than to Duane. I could potentially see someone using this as a graphical input utility.
This code has its subordinate functions included. It has help, that makes some sense. I was able to read the help and figure out how to use the code with no difficulties.
I did find a few minor issues.
First, I see that when the cursor drops outside the axes, you get a NaN when you go below the lower bound. But there is no constraint on the upper end. This seems inconsistent. Why do it this way?
Next, in order to create an slidder that lives on an integer domain, you just use integers as endpoints. A floating point one happens when the endpoints are not integers. But suppose I wanted one that goes in steps of 0.5 on the y axis, and 0.25 on the x axis? Yes, I could shift/scale/transform the output, but that would be a kludge, since the axis labels would be all wrong. Better would be an optional step argument for the respective axes.
I also got the code to give an error when I closed the window instead of clicking on the finish button. The simple fix is to define the "CloseRequestFcn" as the same as clicking on the finish button in the window.
My final comment is a cosmetic one. I see that the web site description calls this "swidder" in several places, yet the code is named slidder. A mid-stream name change perhaps?
As for my rating, I was tempted to call this a 3 (fair). But I do think that Duane has been too severe in his review, so I considered giving it a 4 rating. I'll not assign a numerical rating at all at this moment, planning on returning to it later.
Another amazing program from V.P. I never understand your programs and they make me confused. 1 star for making me have to spend so much time trying to figure out what your programs do and for often requiring me to edit your code to get it to work, especially when the changes needed are only known through your file review responses.
Another amazing program from V.P. I never understand your programs, but they make me smile. 5 stars for making me smile.