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: Rik
Subject: Re: clearing intermediate variables at end of functions?
Date: Fri, 29 Aug 2014 16:36:20 -0700

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




reply via email to

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