From help-octave-request at bevo dot che dot wisc dot edu  Sat Jan 13 03:26:35 2001
Subject: Re: dot.m
From: Paul Kienzle <pkienzle at kienzle dot powernet dot co dot uk>
To: fabian at tu-cottbus dot de
Cc: help-octave at bevo dot che dot wisc dot edu
Date: Fri, 12 Jan 2001 11:24:26 +0000

Rolf,

I must point out that using preference variables to silently change the
return value of a function is bad.

Consider the situation where you are developing your own minimizer using
the 'theory' definition of dot, so you change the preference variable
to dot_conj_arg_pref = 2.  You want to compare your results with
the results of an alternative minimizer, which happens to rely on the
'numeric' definition of dot.  But now the definition of dot has changed
out from under it, and the alternate minimizer returns the wrong answer.
Okay, you can get around this problem by writing all the minimizers with
unwind_protect blocks which set the preference to what they need, but what
if the function evaluator called from within the minimizer uses dot and
assumes that dot is evaluated with the 'numeric' definition?  Again, you
could require that the function wrap its call to dot in unwind_protect
as well, or alternatively, you could reset dot_conj_arg_pref back to
the default after you call dot but before you call the function evaluator.

Wouldn't it be simpler if you just acknowledge that the two definitions
are different and call them by different names?  Or better yet, in
this case, just reverse the arguments to dot if you want the 'theory'
definition, or leave them as they are if you want the 'numeric'
definition.  Then this problem can be resolved in the function help by
pointing out that the algorithms given in 'theory' books may need to
reverse the parameters to dot, but otherwise there is no need to change
the function.

Note that any preference variable which silently changes the numeric
results is just as bad.  That includes "prefer_zero_one_indexing"
(which is insidious, since in most cases the results are identical
regardless of how the preference is set --- fortunately octave 2.1.x has
proper booleans so it is no longer necessary).  "prefer_column_vectors"
is not so bad since most bad code will break if it assumes the wrong
value and good code doesn't rely on automatic resizing for arrays.
"whitespace_in_literal_matrix" can bite you, too, unless you are careful
to separate all columns in [ ... ] with ',' and avoid spaces between the
array name and '(' (too bad the default Octave coding style is to include
a space after the array name, which means that you have to remember
to remove it when building a literal matrix from submatrices).  Other
preference variables are just annoying, such as "do_fortran_indexing",
"implicit_str_to_num" and "empty_list_elements_ok".  Changing their
value will not silently change the results of a functions unless that
function is not doing proper argument checking in the first place AND
it is being called with bad arguments.

Paul Kienzle
pkienzle at kienzle dot powernet dot co dot uk



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------