octave-maintainers
[Top][All Lists]
Advanced

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

Re: `argn' ? … still part of Octave ?


From: Ben Abbott
Subject: Re: `argn' ? … still part of Octave ?
Date: Wed, 05 Oct 2011 20:42:39 -0400

On Oct 5, 2011, at 8:11 PM, Carnë Draug wrote:

> On 5 October 2011 13:28, Ben Abbott <address@hidden> wrote:
>> On Oct 5, 2011, at 12:07 AM, John W. Eaton wrote:
>>> On  4-Oct-2011, Ben Abbott wrote:
>>> | I noticed in the doc string for "whos" that "argn" is mentioned ...
>>> |
>>> | "Automatic variable.  An automatic variable is one created by the 
>>> interpreter, for example `argn'."
>>> |
>>> | Is "argn" still a part of Octave, and if so, what is its function?
>>> 
>>> It's like inputname, but it can return something even if the argument
>>> was an expression.
>> 
>> Thanks. I asked because of the bug reported below.
>> 
>>        https://savannah.gnu.org/bugs/?34478
>> 
>> Apparently, "argn" isn't working for the private functions for @-style 
>> objects.
> 
> Hi
> 
> I found this because I wanted to implement a new class and was trying
> to mimic the obj.method type of API (for matlab compatibility). The
> idea is to use arg (or inputname) to get the name of the variable in
> the caller and change its value with assignin('caller',...)
> 
> 
>> Playing a bit, I noticed some unexpected behavior (I was curious how argn 
>> compared with inputname())
> 
> By the way, since inputname just evals args in the caller, it has the same 
> bug.
> 
>> function varargout = fubar (varargin)
>>  varargout{1} = argn(1:nargin);
>>  for n = 1:nargin
>>    varargout{2}(n) = {inputname(n)};
>>  endfor
>> endfunction
>> 
>> a = 1; b = 2; c = 3; d = 4;
>> 
>> [args, inputs] = fubar(a, b, c, d)
>> args =
>> 
>> a
>> b
>> c
>> d
>> 
>> inputs =
>> {
>>  [1,1] = a
>>  [1,2] = b
>>  [1,3] = c
>>  [1,4] = d
>> }
>> 
>> [args, inputs] = fubar(a, b, a*b, c, d)
>> args = abacd
>> inputs =
>> {
>>  [1,1] = a
>>  [1,2] = b
>>  [1,3] =
>>  [1,4] = c
>>  [1,5] = d
>> }
> 
> I don't think so. In the second example, inputname behaves correctly
> because arguments that don't have an identifier, should return an empty
> string. The third argument does not have a corresponding variable on
> the caller workspace (a*b) so inputname returns an empty string for
> those cases.
> 
> Carnë

Ok, you're right, inputname() is obviously working correctly. But the "args" in 
the second example is incorrect?

Ben



reply via email to

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