Il 05/10/2015 21:56, Rik ha scritto:
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
Dear Rik,
I agree with your suggestions.
Regarding the fuzzy string comparison my question would be if it
is better to discard completely this feature in all ode solvers
or to divide and go for a stricter version in the core (with
strcmpi) and leave the comparison as it is in the package (with
levenshtein).