[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [CHANGESET] gmres (Last review of PROJECTS file before release)
From: |
c. |
Subject: |
Re: [CHANGESET] gmres (Last review of PROJECTS file before release) |
Date: |
Thu, 10 Feb 2011 19:57:02 +0100 |
On 10 Feb 2011, at 19:33, John W. Eaton wrote:
> It's not necessary to enumerate every possible combination of input
> and output arguments. Just write the ones that are significantly
> different. The following description can say what inputs get default
> values if they are omitted, and users are expected to know that they
> can omit outputs, so we only need to document cases where this is not
> true (for example, with svd: s = svd (a) vs. [u, s, v] = svd (a)).
>
> So I think you just need
>
> | +## @deftypefn {Function File} address@hidden, @var{flag}, @var{relres},
> @var{iter}, @var{resvec}] =} pgmres (@var{A}, @var{b}, @var{m}, @var{rtol},
> @var{maxit}, @var{M1}, @var{M2}, @var{x0})
> | +## @deftypefnx {Function File} address@hidden, @var{flag}, @var{relres},
> @var{iter}, @var{resvec}] =} pgmres (@var{A}, @var{b}, @var{m}, @var{rtol},
> @var{maxit}, @var{P})
>
> Or am I missing something about the way behavior changes based on
> nargin and nargout?
no you are right, I think the approach Ben suggested is the one usually taken
by Matlab,
but I agree we don't need to follow that here.
I just separated the case of multiple outputs from the other two in order to
avoid wrapping the long lines.
> jwe
c.
mgorth_gmres_take3.changeset
Description: Binary data