From: Steven Lord on

"Merciadri Luca" <Luca.Merciadri(a)student.ulg.ac.be> wrote in message
news:87eiiyc2h2.fsf(a)merciadriluca-station.MERCIADRILUCA...

*snip*

> Let's take another example on a function that I cannot modify
> directly. I use somewhere in my code
>
> ==
> [minim, min_subst_index] = min(subst)
> ==
>
> where subst is a matrix whose elements are the results of
> substractions between numbers. Okay, everything is fine, but I simply
> do not use minim in my code. If I use
>
> ==
> [min_subst_index, min_subst_index] = min(subst)
> ==
>
> M-Lint tells me that `The value assigned here to variable
> 'min_subst_index' is never used.' That is complete nonsense, as
> min_subst_index _is_ used later. However, if I use

Read the message very carefully. The message does NOT say "The value
assigned to min_subst_index is never used". It says something like "The
value assigned ***here*** [emphasis mine] to variable min_subst_index is
never used", right? That _is_ correct -- you never use that value before
it's overwritten by the value assigned to the second output of MIN. Perhaps
that subtle difference should be made less subtle ... maybe I should create
a request in our enhancement database for this.

> ==
> [minim, min_subst_index] = min(subst)
> ==
>
> it tells me that `The value assigned here to variable
> 'minim' is never used.' What can I do to get rid of minim?

That's one of the reasons we introduced the ~ operator in release R2009b.

http://www.mathworks.com/access/helpdesk/help/techdoc/rn/br5fo8o-1.html#br65zmd-1

I know you said you're using an older version and so that won't work. In
this case, if you're sure that the coding pattern about which M-Lint is
complaining is appropriate, you can suppress the M-Lint message for that
line with the %#ok pragma. Depending on just how old a version you're
using, you may even be able to suppress that specific warning on that
line -- check the documentation installed with your version to learn if your
version supports that.

--
Steve Lord
slord(a)mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ


From: Merciadri Luca on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Steven Lord" <slord(a)mathworks.com> writes:

> "Merciadri Luca" <Luca.Merciadri(a)student.ulg.ac.be> wrote in message
> news:87eiiyc2h2.fsf(a)merciadriluca-station.MERCIADRILUCA...
>
> *snip*
>
>> Let's take another example on a function that I cannot modify
>> directly. I use somewhere in my code
>>
>> ==
>> [minim, min_subst_index] = min(subst)
>> ==
>>
>> where subst is a matrix whose elements are the results of
>> substractions between numbers. Okay, everything is fine, but I simply
>> do not use minim in my code. If I use
>>
>> ==
>> [min_subst_index, min_subst_index] = min(subst)
>> ==
>>
>> M-Lint tells me that `The value assigned here to variable
>> 'min_subst_index' is never used.' That is complete nonsense, as
>> min_subst_index _is_ used later. However, if I use
>
> Read the message very carefully. The message does NOT say "The value
> assigned to min_subst_index is never used". It says something like "The
> value assigned ***here*** [emphasis mine] to variable min_subst_index is
> never used", right? That _is_ correct -- you never use that value before
> it's overwritten by the value assigned to the second output of MIN. Perhaps
> that subtle difference should be made less subtle ... maybe I should create
> a request in our enhancement database for this.
>
>> ==
>> [minim, min_subst_index] = min(subst)
>> ==
>>
>> it tells me that `The value assigned here to variable
>> 'minim' is never used.' What can I do to get rid of minim?
>
> That's one of the reasons we introduced the ~ operator in release R2009b.
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/rn/br5fo8o-1.html#br65zmd-1
>
> I know you said you're using an older version and so that won't work. In
> this case, if you're sure that the coding pattern about which M-Lint is
> complaining is appropriate, you can suppress the M-Lint message for that
> line with the %#ok pragma. Depending on just how old a version you're
> using, you may even be able to suppress that specific warning on that
> line -- check the documentation installed with your version to learn if your
> version supports that.

Thanks for your answer. I will use the %#ok pragma in most of the
cases, for clear reasons. Evidently, my aim is not to fool the M-Lint.

- --
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- --

You never miss your water until your well runs dry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAku1EpUACgkQM0LLzLt8MhzmbACgo5/adiUGlGFoKTZvqHdeKgov
o4QAmwRtG7tNVWF02xI0UOdTXcLvMofg
=zd2a
-----END PGP SIGNATURE-----
From: Merciadri Luca on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dpb <none(a)non.net> writes:

> Merciadri Luca wrote:
> ...
>>
>> ==
>> [min_subst_index, min_subst_index] = min(subst)
>> ==
>>
>> M-Lint tells me that `The value assigned here to variable
>> 'min_subst_index' is never used.' That is complete nonsense, as
>> min_subst_index _is_ used later. However, if I use
>>
>> ==
>> [minim, min_subst_index] = min(subst)
>> ==
>>
>> it tells me that `The value assigned here to variable
>> 'minim' is never used.' What can I do to get rid of minim?
>>
>> I have other examples of such problems, but with personal functions. I
>> absolutely need a (clean, if possible) solution to this.
> ...
> The parser of m-lint is smart enough to be able to tell the two apart
> syntactically in the first case, apparently, and minim _isn't_ used
> elsewhere in the second.
I _do_ agree with you, but the problem is that I was adviced here to
use the

==
[var1 var1] = myfunction(stuff)
[stuff2]
== [same file]

structure, assuming that myfunction(stuff) outputs two different
variables var1 and var2. As I understood it, it should help me in the
case where var2 that `myfunction' returns is not used later in my
code, i.e. in [stuff2]. But M-Lint did not stop showing the message,
and the trick was consequently not working, if I understand it well.

- --
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- --

Pleasure in the job puts perfection in the work. (Aristotle)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAku1E3YACgkQM0LLzLt8MhxHbgCeNlex13nuJrj8PVDW4XoI/54T
I4IAniIlUfS+0EJs/7z3AgVOQWd4fuiF
=cicN
-----END PGP SIGNATURE-----
From: Jan Simon on
Dear Merciadri!

> [var1 var1] = myfunction(stuff)
> [stuff2]
>
> structure, assuming that myfunction(stuff) outputs two different
> variables var1 and var2. As I understood it, it should help me in the
> case where var2 that `myfunction' returns is not used later in my
> code, i.e. in [stuff2]. But M-Lint did not stop showing the message,
> and the trick was consequently not working, if I understand it well.

After this:
[var1, var1] = myfunction(stuff)
var1 has the value of the 2nd output. So better call it:
[var2, var2] = myfunction(stuff)
The first var2 is never used, because it is immediately overwritten. This is not an error, but MLint should warn the user to control this manually. After this has been controlled, the MLint message can be suppressed with %#ok without any danger. This is not squeezing MLint, but it is the simple consequence from the fact that some programmers are still more intelligent than MLint.

Jan
From: Merciadri Luca on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> writes:

> Dear Merciadri!
>
>> [var1 var1] = myfunction(stuff)
>> [stuff2]
>>
>> structure, assuming that myfunction(stuff) outputs two different
>> variables var1 and var2. As I understood it, it should help me in the
>> case where var2 that `myfunction' returns is not used later in my
>> code, i.e. in [stuff2]. But M-Lint did not stop showing the message,
>> and the trick was consequently not working, if I understand it well.
>

> After this:
> [var1, var1] = myfunction(stuff)
> var1 has the value of the 2nd output. So better call it:
> [var2, var2] = myfunction(stuff)
> The first var2 is never used, because it is immediately overwritten. This is not an error, but MLint should warn the user to control this manually. After this has been controlled, the MLint message can be suppressed with %#ok without any danger. This is not squeezing MLint, but it is the simple consequence from the fact that some programmers are still more intelligent than MLint.
Thanks. This is the same point of view as mine. However, I think that,
for clarity's sake, using %#ok without replacing variables that are
not desired by desired variables, is better.

Another question naturally arises: I have a function which defines an
ODE system. I then pass a handle to this function in the ODEsolver
args. However, my function which defines the ODE system takes the
integration variable (t, the time), as an argument. That is normal,
but it is not directly used in the function which defines the ODE
system (and that is normal). Is it a good idea to simply %#ok the
resulting line?

Thanks.

- --
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- --

We are what we repeatedly do. (Aristotle)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAku1vCMACgkQM0LLzLt8MhyWWwCfc8MmdZD1MjvV+5irx2MupU96
Yr8An3Abpyz4U9EHpIPyAvxFxhXb9WE9
=gJ0O
-----END PGP SIGNATURE-----