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

[Julian DeMarchi]

Hoorah!  Less maintenance = more fun.

Syntactical conniptions aside, Octave already provides several optimisations 
over the fundamental Matlab codebase.  Since Octave's growing popularity in 
particular is clearly a result of its Matlab-like behaviour (also at its roots, 
if I'm not mistaken), it makes sense to bring Octave into line with Matlab 
behaviour.

However, I also realise Octave has several very useful improvements over Matlab 
(even at the most mundane levels -- for instance, take the ++ operator).  There 
should be no reason to cut out these wonderful features, as optional features.  
The key discerning factor really only need be limited to ensuring that Octave 
will interpret and process Matlab-based scripts in the same way as Matlab 
handles them.  Whether or not Octave enhancements run in Matlab could be the 
kind of "competition", if you will, to push the Mathworks to update their 
syntax and feature set down the road.  In the meantime, who really cares?  
Someday, somebody may write o2m and m2o functions to handle this, if and when 
necessary (a bit of Perl wizardry may be all that's needed!).

So, my main concern originally was the desire that both 

  [n (1+1./n).^n]

and

  [n, (1+1./n).^n]

behave identically in Octave as they do in Matlab.  Whether n++ works the same 
in Matlab as in Octave is Mathworks' side of the coin, and while an advantage 
for us to support (o2m), less our concern in terms of tending to Octave support 
for Matlab converts.  Because, just as Paul points out, it is a HUGE advantage 
to be able to run the gazillions of lines of existing Matlab scripts in Octave, 
natively, with no translation required.  The stumbling blocks are, indeed, 
probably not worth the hassle.

So, I thank you for less hassle and more fun.

- Julian


-----Original Message-----
From: John W. Eaton [mailto:address@hidden
Sent: Friday, November 01, 2002 9:35 AM
To: help-octave mailing list
Subject: Re: issue with user preferences (was "problem with column
specification in matrices")


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




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