Thread Subject: end of code error

I have a set of .dat files that I am processing. Some of them have a d on the end of the name. I have this coded in to find that, and treat them in a different way.

if isempty(findstr('d',n))==0;
        dupecheck2
end

Where n is the name of the sample

This works great, except that no it always tries to run the last sample through dupecheck2 even though there is no d in the name. It crashs, and I can put in the same code I entered above, and it does nothing. I have tested it on 2 different end files with the same result. Putting a sample with a d in the name at the end is not an option.

"Travis"
> I have a set of .dat files that I am processing. Some of them have a d on the end of the name. I have this coded in to find that, and treat them in a different way.
> if isempty(findstr('d',n))==0;
> dupecheck2
> end
> Where n is the name of the sample
> This works great, except that no it always tries to run the last sample through dupecheck2 even though there is no d in the name...

note: your check will result in TRUE for every file that has a d anywhere in its name, eg,
     foodfoo

one of the solutions

if ~isempty(regexp(n,'d&'))
% ...
end

us

"us " <us@neurol.unizh.ch> wrote in message <gqa7k5$e1s$1@fred.mathworks.com>...
> "Travis"
> > I have a set of .dat files that I am processing. Some of them have a d on the end of the name. I have this coded in to find that, and treat them in a different way.
> > if isempty(findstr('d',n))==0;
> > dupecheck2
> > end
> > Where n is the name of the sample
> > This works great, except that no it always tries to run the last sample through dupecheck2 even though there is no d in the name...
>
> note: your check will result in TRUE for every file that has a d anywhere in its name, eg,
> foodfoo
>
> one of the solutions
>
> if ~isempty(regexp(n,'d&'))
> % ...
> end
>
> us

I realize it will run if there is a d anywhere, but when n = gr11154s10 or gr11154s20, which are the files that have been at the end of the list, it has run on them.

"Travis"
> > one of the solutions
> > if ~isempty(regexp(n,'d&'))
> I realize it will run if there is a d anywhere, but when n = gr11154s10 or gr11154s20, which are the files that have been at the end of the list, it has run on them...

did you bother at all to look at the solution...

     n='gr11154s10';
     ~isempty(regexp(n,'d&'))
% ans = 0 % <- FALSE...
% thus, it would NOT run the code...

us

"us " <us@neurol.unizh.ch> wrote in message <gqaog5$c4v$1@fred.mathworks.com>...
> "Travis"
> > > one of the solutions
> > > if ~isempty(regexp(n,'d&'))
> > I realize it will run if there is a d anywhere, but when n = gr11154s10 or gr11154s20, which are the files that have been at the end of the list, it has run on them...
>
> did you bother at all to look at the solution...
>
> n='gr11154s10';
> ~isempty(regexp(n,'d&'))
> % ans = 0 % <- FALSE...
> % thus, it would NOT run the code...
>
> us

In fact no I didn't have time to run the code before I left this morning (I am at work now and I will try it), but the issue remains the same. There is no d in either of the n's i posted before, and yet it STILL ran them. there are many other samples that similarly do not ahve d's which it properly skips, yet the last sample, even though there is no d in the name, is run as if there was.

"Travis"
> > did you bother at all to look at the solution...

> In fact no I didn't have time to run the code before I left this morning...

so why do you waste the time of CSSMers
- you do not have the time to look at what others did for you spending their time
- you do have the time to come back and ask all over again

your behavior in this NG is not boding well...

us

"Travis" <sinusoid2@hotmail.com> writes:

> "us " <us@neurol.unizh.ch> wrote in message <gqaog5$c4v$1@fred.mathworks.com>...
>> "Travis"
>> > > one of the solutions
>> > > if ~isempty(regexp(n,'d&'))
>> > I realize it will run if there is a d anywhere, but when n =
>> > gr11154s10 or gr11154s20, which are the files that have been at the
>> > end of the list, it has run on them...
>>
>> did you bother at all to look at the solution...
>>
>> n='gr11154s10';
>> ~isempty(regexp(n,'d&'))
>> % ans = 0 % <- FALSE...
>> % thus, it would NOT run the code...
>>
>> us
>
> In fact no I didn't have time to run the code before I left this
> morning (I am at work now and I will try it), but the issue remains
> the same. There is no d in either of the n's i posted before, and yet
> it STILL ran them. there are many other samples that similarly do not
> ahve d's which it properly skips, yet the last sample, even though
> there is no d in the name, is run as if there was.

There is more to your problem than you are sharing. Clearly
findstr('abc', 'd') will return empty, which means the code will not
execute. If you are claiming that the code indeed does execute
sometimes, then something is very wrong with your code. Either the
contents of your test string are not what you think they are, or your
loop is structured in a way that does not match what you posted, and the
function is being called from some other place, or... It is impossible
to tell from the code you have posted, which I guarantee will not find a
"d" where none exists.

So... you need to debug this. When the test is true, print the value of
the test string, along with some text that says "Found d -- running
dupcheck". Study the results, debug your code, and retest until it works.
If after you've gotten some detailed output you still don't understand
what is happening, repost with that detailed output, and the important
pieces of the code.

-Peter

"us " <us@neurol.unizh.ch> wrote in message <gqasa1$7mp$1@fred.mathworks.com>...
> "Travis"
> > > did you bother at all to look at the solution...
>
> > In fact no I didn't have time to run the code before I left this morning...
>
> so why do you waste the time of CSSMers
> - you do not have the time to look at what others did for you spending their time
> - you do have the time to come back and ask all over again
>
> your behavior in this NG is not boding well...
>
> us

I am sorry before posting before trying you code,, but in my eyes you missed the point. The code I have did essentially the same thing as the code you provided, and for some unknown reason it did not work. I ran my original code here at work and didn't have a problem. I am guessing that there was something getting stuck in the cache. While I had restarted MATLAB at home, a reboot might have worked to clear some cache.

May I ask how your solution differs from mine, I am not familiar the regexp command.

"Travis"
> May I ask how your solution differs from mine, I am not familiar the regexp command...

well, look at the code and TRY...
anyhow,

     nlst={
          'foo-d-foo'
          'foo-foo-d'
     };
for i=1:numel(nlst)
     n=nlst{i};
% your approach
     r1=isempty(findstr('d',n))==0;
% regexp approach (note the syntax: d$ := d must be LAST char)
     r2=~isempty(regexp(n,'d$'));
     disp(sprintf('file %s = %1d / %1d',n,r1,r2));
end
%{
% file_name = your / regexp
file foo-d-foo = 1 / 0
file foo-foo-d = 1 / 1
%}

us

Peter Boettcher
> There is more to your problem than you are sharing. Clearly
> findstr('abc', 'd') will return empty, which means the code will not
> execute. If you are claiming that the code indeed does execute
> sometimes, then something is very wrong with your code...

peter,
the OP reads
...I have a set of .dat files that I am processing. Some of them have a d on the end of the name. I have this coded in to find that, and treat them in a different way...

thus, i thought he/she were looking for a D at the END of the string (...to find that...), which clearly is not guaranteed to work with FINDSTR; hence, the hint at REGEXP(...,'d$')...

just a thought
us

Peter,
There is nothing more to my code than I am saying. I am guessing that there was other things happening on my computer that were affecting MATLAB. When I ran the code at work it worked fine the first time. I should have tried a reboot to clear the cache before posting.

us,
thank you for the explanation. The d at the end of the name is exactly what I am looking for. I will sub your code in for mine.

"us " <us@neurol.unizh.ch> writes:

> Peter Boettcher
>> There is more to your problem than you are sharing. Clearly
>> findstr('abc', 'd') will return empty, which means the code will not
>> execute. If you are claiming that the code indeed does execute
>> sometimes, then something is very wrong with your code...
>
> peter, the OP reads ...I have a set of .dat files that I am
> processing. Some of them have a d on the end of the name. I have this
> coded in to find that, and treat them in a different way...
>
> thus, i thought he/she were looking for a D at the END of the string
> (...to find that...), which clearly is not guaranteed to work with
> FINDSTR; hence, the hint at REGEXP(...,'d$')...
>
> just a thought

He certainly needs your change. But he was also asserting that names
without any 'd' in them whatsoever were still triggering the condition.

-Peter

Peter Boettcher <boettcher@ll.mit.edu> wrote in message <muyiqlyambk.fsf@G99-Boettcher.llan.ll.mit.edu>...
> "us " <us@neurol.unizh.ch> writes:
>
> > Peter Boettcher
> >> There is more to your problem than you are sharing. Clearly
> >> findstr('abc', 'd') will return empty, which means the code will not
> >> execute. If you are claiming that the code indeed does execute
> >> sometimes, then something is very wrong with your code...
> >
> > peter, the OP reads ...I have a set of .dat files that I am
> > processing. Some of them have a d on the end of the name. I have this
> > coded in to find that, and treat them in a different way...
> >
> > thus, i thought he/she were looking for a D at the END of the string
> > (...to find that...), which clearly is not guaranteed to work with
> > FINDSTR; hence, the hint at REGEXP(...,'d$')...
> >
> > just a thought
>
> He certainly needs your change. But he was also asserting that names
> without any 'd' in them whatsoever were still triggering the condition.
>
> -Peter

I put in us's suggestion, and it never even registered any hits, when there should have been 4. I don't know what happened, but a different computer with different programs running in the background, and a fresh reboot, fixed the problem. Stupid finicky programs

"Travis"
> I put in us's suggestion, and it never even registered any hits, when there should have been 4. I don't know what happened, but a different computer with different programs running in the background, and a fresh reboot, fixed the problem. Stupid finicky programs...

to be honest, this seems inconceivable as the REGEXP construct certainly(!) does not change its behavior...
a (wild) guess: the list of file names (you did not tell CSSM how you retrieve those at run-time) changes and does - at times - not contain what you think it should...
as peter boettcher suggested above, you really should print out your file names at run-time to see what happens...

us

"us " <us@neurol.unizh.ch> wrote in message <gqb7ah$m5r$1@fred.mathworks.com>...
> "Travis"
> > I put in us's suggestion, and it never even registered any hits, when there should have been 4. I don't know what happened, but a different computer with different programs running in the background, and a fresh reboot, fixed the problem. Stupid finicky programs...
>
> to be honest, this seems inconceivable as the REGEXP construct certainly(!) does not change its behavior...
> a (wild) guess: the list of file names (you did not tell CSSM how you retrieve those at run-time) changes and does - at times - not contain what you think it should...
> as peter boettcher suggested above, you really should print out your file names at run-time to see what happens...
>
> us

The original names are imported from a structure array (complete with the .dat) and are trimmed

name=findstr(d(i).name,'.dat');
    n=d(i).name(1:name-1);

so that just the file name and not the extension remains. I still think the problem was something stuck in the cache (yes I am stubborn), is there a way to clear the cache mid for-loop, without clearing the variables, to avoid this?. I know there is a clearex command in the file exchange, but does that get the cache too?

on a completely seperate topic...us, do you think you can help me on another topic?
http://www.mathworks.com/matlabcentral/newsreader/view_thread/247093#636313
I haven't gotten any feedback on that one, and I continue to beat my head against the wall trying to figure out what I am doing wrong there. I promise to be less stubborn.

"Travis" <sinusoid2@hotmail.com> wrote in message <gqb7vn$afr$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <gqb7ah$m5r$1@fred.mathworks.com>...
> > "Travis"
> > > I put in us's suggestion, and it never even registered any hits, when there should have been 4. I don't know what happened, but a different computer with different programs running in the background, and a fresh reboot, fixed the problem. Stupid finicky programs...
> >
> > to be honest, this seems inconceivable as the REGEXP construct certainly(!) does not change its behavior...
> > a (wild) guess: the list of file names (you did not tell CSSM how you retrieve those at run-time) changes and does - at times - not contain what you think it should...
> > as peter boettcher suggested above, you really should print out your file names at run-time to see what happens...
> >
> > us
>
> The original names are imported from a structure array (complete with the .dat) and are trimmed
>
> name=findstr(d(i).name,'.dat');
> n=d(i).name(1:name-1);
>
> so that just the file name and not the extension remains.

% Why not use fileparts to strip-off the ext parameter:
[pathstr, name, ext, versn] = fileparts(file)
% and use fullfile to reconstruct it (without the ext parameter)
f = fullfile(pathstr,name)
% only if you need the path info.
% Your code will be more platform independent.

I still think the problem was something stuck in the cache (yes I am stubborn), is there a way to clear the cache mid for-loop, without clearing the variables, to avoid this?. I know there is a clearex command in the file exchange, but does that get the cache too?
>
> on a completely seperate topic...us, do you think you can help me on another topic?
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/247093#636313
> I haven't gotten any feedback on that one, and I continue to beat my head against the wall trying to figure out what I am doing wrong there. I promise to be less stubborn.

"Travis" <sinusoid2@hotmail.com> wrote in message <gqb7vn$afr$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <gqb7ah$m5r$1@fred.mathworks.com>...
> > "Travis"
> > > I put in us's suggestion, and it never even registered any hits, when there should have been 4. I don't know what happened, but a different computer with different programs running in the background, and a fresh reboot, fixed the problem. Stupid finicky programs...
> >
> > to be honest, this seems inconceivable as the REGEXP construct certainly(!) does not change its behavior...
> > a (wild) guess: the list of file names (you did not tell CSSM how you retrieve those at run-time) changes and does - at times - not contain what you think it should...
> > as peter boettcher suggested above, you really should print out your file names at run-time to see what happens...
> >
> > us
>
> The original names are imported from a structure array (complete with the .dat) and are trimmed
>
> name=findstr(d(i).name,'.dat');
> n=d(i).name(1:name-1);


% What if one of your files was named:

fname = 'mydata.dat.dat"

% (which is perfectly legal)?


>
> so that just the file name and not the extension remains. I still think the problem was something stuck in the cache (yes I am stubborn), is there a way to clear the cache mid for-loop, without clearing the variables, to avoid this?. I know there is a clearex command in the file exchange, but does that get the cache too?
>
> on a completely seperate topic...us, do you think you can help me on another topic?
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/247093#636313
> I haven't gotten any feedback on that one, and I continue to beat my head against the wall trying to figure out what I am doing wrong there. I promise to be less stubborn.

> > The original names are imported from a structure array (complete with the .dat) and are trimmed
> >
> > name=findstr(d(i).name,'.dat');
> > n=d(i).name(1:name-1);
>
>
> % What if one of your files was named:
>
> fname = 'mydata.dat.dat"
>
> % (which is perfectly legal)?

While that is legal it does not happen with any data that my program would be running.