10/5/15
All,
The inclusion of ode45 and the necessary support functions into core Octave
is going well, but there are some remaining issues questions.
Questions:
1) If the user provided option name to odeset and odeget matches multiple
options then the functions drop into an interactive mode and use input() to
ask the user which name was intended. Does Matlab do this? I propose
eliminating this code and just issuing an error.
2) The functions still assume that they are part of OdePkg and they
subclass their errors that way. For example,
error ("OdePkg:InvalidArgument", "Error Message").
Most functions in the core do not subclass their error messages and report
error ("function_name: Error Message")
What do we think should be done for these functions?
3) nargin/nargout and input checking for private functions.
Functions in a private directory are helper functions that are only meant
to be called from the user-facing functions in the directory above. It is
usually not necessary to extensively check that the helper function has
been called correctly. If the calling function has got it wrong then it
needs to be fixed and that is the end of the story. As an example, here is
the beginning of fuzzy_compare.m
## check on output arguments
if (nargout > 1)
error ("OdePkg:InvalidArgument", "too many output arguments");
endif
## check on input arguments
if (nargin < 2 || nargin > 3)
error ("OdePkg:InvalidArgument", "wrong input arguments number");
endif
I propose eliminating these checks which will speed up the functions.
4) There are instances of CamelCase in the code, such as AbsRel_Norm.m,
which is frowned upon in the core. I propose switching all such instances
to lowercase.
5) Can we eliminate fuzzy matching of property names?
According to the documentation, " It is only necessary to type the leading
characters that uniquely identify the property name. Case is ignored for
property names."
This can be done simply with
strncmpi (option_name, {cellstr_of_options}, length (option_name))
Instead there is an entire helper function fuzzy_compare.m which itself
depends on an oct-file levenshtein.cc just to calculate whether a property
name has matched.
6) It seems like almost all variables have the letter 'v' prepended to
them. Is that really necessary? I would propose dropping that convention
since it is not used anywhere else in the core.
Please come back with comments on these proposals. Thanks,
Rik