Using text as condition in a while loop - matlab

Im having some trouble with using text as an condition for a while loop, currently the basic coding is:
result=struct('val','yes');
while result.val=='yes'
result.val=input('more digits?');
end
So as you see, what Im trying to do is keeping the loop going as long as the user types in 'yes'. But thats one of the probelmes I am having; Is there a way to get rid of the need to write the ''(e.g yes instead of 'yes')? Secondly, when I run the code it gives me the error message "Error using == ,Matrix dimensions must agree.". I realise this have to do with the word yes being longer than no, but I don't know how to fix it. It's not really an issue though considering its the the program ends anyway, but it is an annoyance I would like to get rid off.

To compare strings, use strcmp, or strcmpi to ignore case. It will handle comparison of different length strings. For example:
strcmpi(result.val,'yes')
If you want to search for a substring, such as just a 'y', at the beginning of the input, consider strncmpi (strncmpi(result.val,'y',1)) or just check the first character (result.val(1)).

Related

Should I use FIND function or use For Loop to search matching record

I am writing a function to search a record from sheet2 and return value to sheet1. I use the Find function and it works for most of the case. However, I encounter below issus.
The FIND function only support one matching key only. If I have more than one value to match, it didn't work.
Sometime, the search value may have space like "Key1 ". Then, if I search the word by "Key1", no record return. I can't use the wildcard search as I need exact match except the space.
To solve this, should I simply use a For loop to search the result instead of FIND? I have to loop through every row. I am not sure the performance is okay or not.
No related to FIND. As I need to copy the value as well as the backgroup color. I use the return cells.interior.colorindex to set the field. But the color is a little bit different. For example, the original is light green but it turn out to become darken color. I check both field has same colorindex. Any idea?
goodfit
Thanks,
see anyone has idea how to resolve it.

MIJ: execute imageJ (Fiji) macro until end in Matlab

I am using MIJ to execute an ImageJ macro within Matlab. The macro has to be executed multiple times in a "for" loop. The problem is that Matlab does not wait until the macro ends. Initially I solved the problem with a "while" loop, checking if the "Results" table generated from the macro was empty or not. However, it only solves the problem the first time, then from the second time the "Results" table is not empty anymore.
I also thought about generating a variable at the end of the macro and use it to check if the macro finished, but I don't know how to read it in Matlab.
Do you have any suggestion about how I can solve the problem?
Thanks a lot in advance,
Alessia
Here is an example of my code:
javaaddpath 'C:/Program Files/MATLAB/R2019a_x64/java/ij.jar'
javaaddpath 'C:/Program Files/MATLAB/R2019a_x64/java/mij.jar'
MIJ.start('C:/fiji-win64/Fiji.app/plugins');
IJ=ij.IJ();
macro_path=...
'C:/Macro_waterinoil.ijm';
for pos=1:16
im = mijread(strcat('E:/droplets.tif'));
figure(1)
imshow(im,[0 255])
IJ.runMacroFile(java.lang.String(macro_path));
res_Hough=0;
res_Hough=MIJ.getResultsTable();
while res_Hough==0;
res_Hough=MIJ.getResultsTable();
end
im_res=MIJ.getCurrentImage();
MIJ.run('Clear Results');
MIJ.run('Close All');
end
Edit: Ignore the below, I was on the right track but wasn’t paying as much attention as I should have been. I think this issue is the line right after you set res_Hough to 0 (i.e. res_Hough=MIJ.getResultsTable();). Try deleting it so that the next line is the while loop, then we can check the output and see if the below might also apply
If I am understanding correctly, you are using the while loop to continuously ping until the table is full, then store those values in res_Hough, right? I'm wondering if this is a limitation inherent to ImageJ/FIJI. The reason I think this might be the case is that a very simple explanation for your issue is that the table retains the previous values, and so will always be full after the first loop unless cleared manually somehow. Do you think that could be the case? Perhaps add a print statement after the while loop and see if it prints the same values for the duration of the for loop.
I suppose the next thing to do is for me to actually try to offer a solution regardless of the above. My idea is to try having the while loop check against the previous iteration's table values until they are different, then stash the updated values. Does that make sense? Something like:
while (res_Hough[i]==0) or (res_Hough[i-1]==MIJ.getResultsTable());
res_Hough[i]=MIJ.getResultsTable();
Where i is incremented by the for loop

Collision with two lines of code makes code does not work the way it is meant by me(?)

Try running the following code yourself, and you would notice that "/hello" changes to "/HELLO", but I want it to change it to "hi". On the other hand, I want to keep the 1.st line of code, which changes "hello" to "HELLO". How could I achieve this(?)
This code problem is very related to my last problem:
Collision with two lines of code make code does not work the way it is meant by me, what could I do different to get this work(?)
The soltuion for my last problem was good for that problem, but it is not working for the new above mentioned problem.
::hello::HELLO
::/hello::hi
That is interesting. I really expected it to work by removing / from the EndChars. But after looking at it for a while, it becomes obvious why it's behaving this way. When you type "/hello" it actually matches to both hotstrings, so AHK chooses the first one defined. Anyway, there are two solutions that I know of:
Reorder your hotstrings. Place ::/hello::hi above the other one and you'll always get the desired result. Additionally, you don't need to change the EndChars since / is the first character.
Use the asterisk option on the second hotstring. This will make it update immediately, which may or may not be desirable (I prefer it).

Can the MATLAB editor show the file from which text is displayed? [duplicate]

In MATLAB, how do you tell where in the code a variable is getting output?
I have about 10K lines of MATLAB code with about 4 people working on it. Somewhere, someone has dumped a variable in a MATLAB script in the typical way:
foo
Unfortunately, I do not know what variable is getting output. And the output is cluttering out other more important outputs.
Any ideas?
p.s. Anyone ever try overwriting Standard.out? Since MATLAB and Java integration is so tight, would that work? A trick I've used in Java when faced with this problem is to replace Standard.out with my own version.
Ooh, I hate this too. I wish Matlab had a "dbstop if display" to stop on exactly this.
The mlint traversal from weiyin is a good idea. Mlint can't see dynamic code, though, such as arguments to eval() or string-valued figure handle callbacks. I've run in to output like this in callbacks like this, where update_table() returns something in some conditions.
uicontrol('Style','pushbutton', 'Callback','update_table')
You can "duck-punch" a method in to built-in types to give you a hook for dbstop. In a directory on your Matlab path, create a new directory named "#double", and make a #double/display.m file like this.
function display(varargin)
builtin('display', varargin{:});
Then you can do
dbstop in double/display at 2
and run your code. Now you'll be dropped in to the debugger whenever display is implicitly called by the omitted semicolon, including from dynamic code. Doing it for #double seems to cover char and cells as well. If it's a different type being displayed, you may have to experiment.
You could probably override the built-in disp() the same way. I think this would be analagous to a custom replacement for Java's System.out stream.
Needless to say, adding methods to built-in types is nonstandard, unsupported, very error-prone, and something to be very wary of outside a debugging session.
This is a typical pattern that mLint will help you find:
So, look on the right hand side of the editor for the orange lines. This will help you find not only this optimization, but many, many more. Notice also that your variable name is highlighted.
If you have a line such as:
foo = 2
and there is no ";" on the end, then the output will be dumped to the screen with the variable name appearing first:
foo =
2
In this case, you should search the file for the string "foo =" and find the line missing a ";".
If you are seeing output with no variable name appearing, then the output is probably being dumped to the screen using either the DISP or FPRINTF function. Searching the file for "disp" or "fprintf" should help you find where the data is being displayed.
If you are seeing output with the variable name "ans" appearing, this is a case when a computation is being done, not being put in a variable, and is missing a ';' at the end of the line, such as:
size(foo)
In general, this is a bad practice for displaying what's going on in the code, since (as you have found out) it can be hard to find where these have been placed in a large piece of code. In this case, the easiest way to find the offending line is to use MLINT, as other answers have suggested.
I like the idea of "dbstop if display", however this is not a dbstop option that i know of.
If all else fails, there is still hope. Mlint is a good idea, but if there are many thousands of lines and many functions, then you may never find the offender. Worse, if this code has been sloppily written, there will be zillions of mlint flags that appear. How will you narrow it down?
A solution is to display your way there. I would overload the display function. Only temporarily, but this will work. If the output is being dumped to the command line as
ans =
stuff
or as
foo =
stuff
Then it has been written out with display. If it is coming out as just
stuff
then disp is the culprit. Why does it matter? Overload the offender. Create a new directory in some directory that is on top of your MATLAB search path, called #double (assuming that the output is a double variable. If it is character, then you will need an #char directory.) Do NOT put the #double directory itself on the MATLAB search path, just put it in some directory that is on your path.
Inside this directory, put a new m-file called disp.m or display.m, depending upon your determination of what has done the command line output. The contents of the m-file will be a call to the function builtin, which will allow you to then call the builtin version of disp or display on the input.
Now, set a debugging point inside the new function. Every time output is generated to the screen, this function will be called. If there are multiple events, you may need to use the debugger to allow processing to proceed until the offender has been trapped. Eventually, this process will trap the offensive line. Remember, you are in the debugger! Use the debugger to determine which function called disp, and where. You can step out of disp or display, or just look at the contents of dbstack to see what has happened.
When all is done and the problem repaired, delete this extra directory, and the disp/display function you put in it.
You could run mlint as a function and interpret the results.
>> I = mlint('filename','-struct');
>> isErrorMessage = arrayfun(#(S)strcmp(S.message,...
'Terminate statement with semicolon to suppress output (in functions).'),I);
>>I(isErrorMessage ).line
This will only find missing semicolons in that single file. So this would have to be run on a list of files (functions) that are called from some main function.
If you wanted to find calls to disp() or fprintf() you would need to read in the text of the file and use regular expresions to find the calls.
Note: If you are using a script instead of a function you will need to change the above message to read: 'Terminate statement with semicolon to suppress output (in scripts).'
Andrew Janke's overloading is a very useful tip
the only other thing is instead of using dbstop I find the following works better, for the simple reason that putting a stop in display.m will cause execution to pause, every time display.m is called, even if nothing is written.
This way, the stop will only be triggered when display is called to write a non null string, and you won't have to step through a potentially very large number of useless display calls
function display(varargin)
builtin('display', varargin{:});
if isempty(varargin{1})==0
keyboard
end
A foolproof way of locating such things is to iteratively step through the code in the debugger observing the output. This would proceed as follows:
Add a break point at the first line of the highest level script/function which produces the undesired output. Run the function/script.
step over the lines (not stepping in) until you see the undesired output.
When you find the line/function which produces the output, either fix it, if it's in this file, or open the subfunction/script which is producing the output. Remove the break point from the higher level function, and put a break point in the first line of the lower-level function. Repeat from step 1 until the line producing the output is located.
Although a pain, you will find the line relatively quickly this way unless you have huge functions/scripts, which is bad practice anyway. If the scripts are like this you could use a sort of partitioning approach to locate the line in the function in a similar manner. This would involve putting a break point at the start, then one half way though and noting which half of the function produces the output, then halving again and so on until the line is located.
I had this problem with much smaller code and it's a bugger, so even though the OP found their solution, I'll post a small cheat I learned.
1) In the Matlab command prompt, turn on 'more'.
more on
2) Resize the prompt-y/terminal-y part of the window to a mere line of text in height.
3) Run the code. It will stop wherever it needed to print, as there isn't the space to print it ( more is blocking on a [space] or [down] press ).
4) Press [ctrl]-[C] to kill your program at the spot where it couldn't print.
5) Return your prompt-y area to normal size. Starting at the top of trace, click on the clickable bits in the red text. These are your potential culprits. (Of course, you may need to have pressed [down], etc, to pass parts where the code was actually intended to print things.)
You'll need to traverse all your m-files (probably using a recursive function, or unix('find -type f -iname *.m') ). Call mlint on each filename:
r = mlint(filename);
r will be a (possibly empty) structure with a message field. Look for the message that starts with "Terminate statement with semicolon to suppress output".

CLUTO doc2mat specified stop word list not working

I am trying to convert my documents into vector-space format using doc2mat
On the website, it says I can use my specified text file where words are white-space separated or on multiple lines. So, I use some code similar to this one:
./doc2mat -mystoplist=stopword.txt -skipnumeric mydocuments.txt myvectorspace.txt
However, when I check the output .clabel file, it still has stop words that's in stopword.txt.
I really do not know how to do this. Someone help me out please? Thank you!
There's one important thing I should remember: I should include ALL the unwanted words in my stop list. This is somewhat difficult since there's always some variations available...
For example, if I want to exclude method I add it to my list. However, the resulting vocabulary may also contain method since there are words like methodist, methods, etc. Then doc2mat by default stems these words and I will still get method in the output.
Another thing is to make sure that "-nostop" option must be provided for user-specified stop list.