You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A different type of question, what should the formatting be for help information?
First, matlab help info of built-in functions is generally summary first, then multiple function signatures (really, using different optional arguments) with explanations interspersed. The current cifti-matlab help has function signatures first (and includes the function keyword), and then the description immediately below that, then options, and examples (when present) at the bottom.
Examples:
>> help unique
unique Set unique.
C = unique(A) for the array A returns the same values as in A but with
no repetitions. C will be sorted.
C = unique(A,'rows') for the matrix A returns the unique rows of A.
The rows of the matrix C will be in sorted order.
...
>> help cifti_read
function outstruct = cifti_read(filename, ...)
Read a cifti file.
If wb_command is not on your PATH and you need to read cifti-1
files, specify "..., 'wbcmd', '<wb_command with full path>'".
>> cifti = read_cifti('91282_Greyordinates.dscalar.nii');
>> cifti.cdata = outdata;
>> cifti.diminfo{2} = cifti_diminfo_make_scalars(size(outdata, 2));
>> write_cifti(cifti, 'ciftiout.dscalar.nii');
How closely do people want this to match matlab builtin help formatting and order?
optional inputs
Some of the functions (generally lower-level) still have optional arguments that don't use varargin, so if we don't change them to use varargin, how should the help info look? Some ideas:
no notation, and expect people to read the help down to where it says what is optional (this is what is currently implemented):
%function outmap = cifti_diminfo_make_scalars(nummaps, namelist, metadatalist)
...
% Only the nummaps argument is required.
optional outputs
Some functions also have multiple outputs, and in matlab all outputs are automatically optional (a function can be coded to check the number of output arguments and manually throw an error, or even change its behavior, but there is no reason to do that here). Can we expect users to be aware of this, or do we need some notation for that also? Example:
The help info for unique starts with the 4 combinations of single vs multi output, and single versus multiple arguments, but discontinues that method as soon as it reaches more advanced options. So, some options:
like matlab help info on unique, start with a few combinations, then any further optional arguments use only the all-outputs notation:
A different type of question, what should the formatting be for help information?
First, matlab help info of built-in functions is generally summary first, then multiple function signatures (really, using different optional arguments) with explanations interspersed. The current cifti-matlab help has function signatures first (and includes the
function
keyword), and then the description immediately below that, then options, and examples (when present) at the bottom.Examples:
How closely do people want this to match matlab builtin help formatting and order?
optional inputs
Some of the functions (generally lower-level) still have optional arguments that don't use varargin, so if we don't change them to use varargin, how should the help info look? Some ideas:
optional outputs
Some functions also have multiple outputs, and in matlab all outputs are automatically optional (a function can be coded to check the number of output arguments and manually throw an error, or even change its behavior, but there is no reason to do that here). Can we expect users to be aware of this, or do we need some notation for that also? Example:
The help info for
unique
starts with the 4 combinations of single vs multi output, and single versus multiple arguments, but discontinues that method as soon as it reaches more advanced options. So, some options:The text was updated successfully, but these errors were encountered: