Re: Which behavior should I expect when using inputParser?

[Juan Pablo Carbajal]

On Thu, Jul 3, 2014 at 12:32 PM, Damian <address@hidden> wrote:
> Ok, I just run into the same problem with Octave 3.8. It seems that
> parameter parsing depends on the order of the arguments. The following
> ode snippet illustrates this:
>
> varargin = {'pval0', 0, 'pval1', 1, 'pval2', 2};
>
> varargin1 = {'pval0', 0, 'pval2', 2, 'pval1', 1};
>
> p = inputParser;
> p.CaseSensitive = true;
> p.KeepUnmatched = true;
> p = p.addParamValue('pval0', 0, @isnumeric);
> p = p.addParamValue('pval2', 0, @isnumeric);
>
> res = p.parse(varargin{:})
>
> res = p.parse(varargin1{:})
>
> In the first case, only 'pval0' will appear in the 'Results' field of
> 'res'. However, if the order in which the arguments are passed is
> swapped, then both 'pval0' and 'pval1' are stored in 'Results'. The
> latter is the behavior I'd expect.
>
> To me this seems like a bug (in Matlab the order of the arguments does
> not alter the parsing results). But maybe I'm overlooking something.
>
> Any ideas?
>
> On Wed, Jun 18, 2014 at 4:00 PM, Juan Pablo Carbajal
> <address@hidden> wrote:
>> On Wed, Jun 18, 2014 at 2:41 PM, Damian <address@hidden> wrote:
>>>> So using addParamValue is enough. If you want to check whether the
>>>> parameter was given or not you can check the UsingDefaults field.
>>>> Would that be a workaround?
>>> Yep. That's exactly what I'm currently doing.
>>>
>>> I just upgraded Octave to version 3.8.1, and now I have to see if the
>>> problem persists.
>>
>> It has nothing to do with Octave, it is the general package that
>> provides inputParser.

Looks like a bug. could you please add it to the bug tracker?

Thanks