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: Carnë Draug
Subject: Re: `argn' ? … still part of Octave?
Date: Thu, 6 Oct 2011 02:31:22 +0100

On 6 October 2011 01:42, Ben Abbott <address@hidden> wrote:
> 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.
>>
>
> Ok, you're right, inputname() is obviously working correctly. But the "args" 
> in the second example is incorrect?

I checked again and it's not incorrect. The problem was in the loop to
get argn in the cell array. The following works fine:

function fubar (varargin)
    disp(argn)
endfunction

a = 1; b = 2; c = 3; d = 4;

fubar (a, b, a*b, c, d)

On 6 October 2011 01:27, John W. Eaton <address@hidden> wrote:
> | idea is to use arg (or inputname) to get the name of the variable in
> | the caller and change its value with assignin('caller',...)
>
> OK, I guess you can try that, but it will be somewhat slow and
> it seems to me that it will definitely be clumsy.

I know. But the class I'm trying to implement (inputParser) already
exists in MatLab. It's for the sake of compatibility. And I'm learning
something new in the process too :)

Carnë


reply via email to

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