[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