octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clearing intermediate variables at end of functions?


From: Daniel J Sebald
Subject: Re: clearing intermediate variables at end of functions?
Date: Sat, 30 Aug 2014 00:26:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 08/29/2014 06:36 PM, Rik wrote:
On 08/29/2014 02:53 PM, Daniel J Sebald wrote:
On 08/29/2014 11:35 AM, Rik wrote:
8/29/14

All,

I was just cleaning up nchoosek.m and I came across this construct at the
end of the function:

--- Begin Code ---
      clear cA b;
      C = C.';
    endif

endfunction
--- End Code ---

Is there any reason why it should be necessary to clear the intermediate
variables cA and b manually?  They are local to the m-file and as soon as
the endfunction is hit they will go out of scope and the memory should be
reclaimed.  I thought maybe, just maybe, it was because they were large and
the original programmer was worried that the transpose operation was going
to create an intermediate copy of C.  But this shouldn't be the case,
should it?  Don't we do something intelligent like simply reverse the row,
column attributes on the existing C matrix rather than creating a full
blown copy?

Yes, I think so.  That clearing of local variables inside a function
looks like it is cruft.


The following error statement doesn't exactly match what all those
conditionals are doing:

     error ("nchoosek: args are non-negative integers with V not less than
K");

There is also a test in there for non-integers, for which this algorithm
doesn't apply as stated in the documentation.


The following warning call doesn't appear to be the correct format:

       warning ("nchoosek", "nchoosek: possible loss of precision");

It just returns "warning: nchoosek":

octave-cli:4>  nchoosek(500,300)
warning: nchoosek
ans =   5.0549e+144


I'm not sure the conformity of the output makes sense in terms of k and
size of v, i.e., all these different scenarios.  Let me know when you are
done editing this file, and I'll have another look.


Dan,

It was that incorrectly issued warning that got me started overhauling the
function.  Since at least two people (you + me) think the clear statement
is unnecessary I deleted it.  The changeset is 83b88e20e9c1 checked in a
few minutes ago.

--Rik

OK, I just downloaded the update... You reworded the error message in the "contrapositive" to avoid having to cover all cases; that's good.

What I didn't quite understand before, I now understand. So, for the most part I agree with the results. However, there's one result that could possibly change.

This case

  elseif (k > n)
    C = zeros (0, k, class (v));

produces this:

nchoosek([4 5],8)
ans = [](0x8)

while here's the result in a case which has a similar problem:

nchoosek(5,8)
error: nchoosek: N must be a non-negative integer >= K
error: called from:
error:   /octave/nchoosek.m at line 101, column 5

Those two really are the same problem, so it might make sense to have a similar error. I don't see the sense of giving an empty set result "ans = [](0x8)" when there is in fact an error in the premise, i.e., K can only range from 0 to N (which in this case is N=2).

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]