Re: issue with user preferences (was "problem with column specification in matrices")

[John W. Eaton]

On  1-Nov-2002, Paul Kienzle <address@hidden> wrote:

| On Thu, Oct 31, 2002 at 08:16:35PM -0600, Mike Miller wrote:

| > I'll vote for the most sensible.
| 
| A number of people have come to octave with existing scripts written for
| Matlab because they have heard that it is the most Matlab like of the
| free numerical environments.  They then contribute missing functions and
| patches which make Octave even more Matlab like, which serves to attract
| more people who want to eliminate the remaining differences, even if the
| Octave approach is more sensible.  After all, when they download 15,000 
| lines of a wavelet package, do they really want to scan through every 
| line to make sure that all uses of white space within [] are unambiguous?

Right, and even though there are many things about Matlab that I don't
like, I think that unless the Matlab behavior really looks like a bug,
it is probably best for Octave to be compatible.  I know that I have
argued differently in the past, but now I think this is our best
option.

If you want to argue for sensible behavior, then I think we need to
start some kind of Matlab/Octave language standardization effort.  But
it is likely to be a difficult process, and I think the MathWorks
would put a lot of effort into ensuring that the standard be whatever
the current behavior of Matlab is.

| The current idiom is the following:
| 
|       dfi = do_fortran_indexing;
|       unwind_protect
|         do_fortran_indexing = 1;
|         code which requires do_fortran_indexing == 1
|       unwind_protect_cleanup
|         do_fortran_indexing = dfi;
|       end_unwind_protect
| 
| It is kind of ugly, but it works if everyone follows the rules.  

Yes, I agree that this is ugly, and I'd like to see the need for most
of these things disappeear by getting rid of most of these built-in
variables.  Long term, I think that doing that will be less painful
than continuing to try to support them.  Here's how I see it:

If you have played by the rules, then your code either works for all
possible values of the built-in preference variables or it uses them
as above, so it is not hard to find the places where you temporarily
reset the values (as in the example above).  In the former case, you
don't need to do anything to your code if we change the default.  In
the latter case, you can easily find all the places that might be
affected, and then you only need to make real changes to your code if
you selected something that is different from the new default (chances
are good that you actually wanted the force the Matlab-like behavior
anyway, so probably you will simply get to remove the unwind-protect
kluge).

If you haven't followed the rules, then your code was going to break
anyway if someone wanted to use it with values of the preference
variables that were different from the ones you chose.

| This problem might be alleviated if preference flags would only
| affect the current script.  The values would have to be temporarily
| restored whenever another script is called, and completely
| restored when the function ends.  If there were some way to
| differentiate matlab-style scripts from octave-style scripts
| (e.g., by calling the octave scripts .os files, or by putting the
| matlab scripts on a separate load path) then the right
| thing would usually happen.  However, this might raise as many
| problems as it solves --- sometimes you set a preference because
| of its effect on the function you are calling.

Yes, I now think that this would be more complicated and cause more
trouble than simply doing away with the built-in preference variables
that affect the way code is interpreted.  We can keep the ones that
set things like the prompt or output appearance, since those will only
rarely cause trouble.

jwe



-------------------------------------------------------------
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
-------------------------------------------------------------