From bug-octave-request at bevo dot che dot wisc dot edu  Thu Feb 19 08:53:20 1998
Subject: new global initialization
From: fabian at olymp dot Umwelt dot TU-Cottbus dot de (Rolf Fabian)
To: bug-octave at bevo dot che dot wisc dot edu
Date: Thu, 19 Feb 1998 15:53:59 +0100

Dear John W. ,

Within the brand new version 2.0.10 essential changes were made concerning
variables defined as 'global'. We're working with some programs 
using an octave-feature described as follows:

Imagine to have a script file which processes large matrices of data by 
application of large matrix-'operators', which have several parameters 
dependent on data features. While invoking the script, you don't know
which combinations thereof might be needed. Hence you're not able to 
globally declare them on the calling level!
And you don't want to calculate these operators every time they are called,
because this consums lots of ressources, especially time!. Up to now, with
octave 2.0.09 we've applied the following  program-strategy:
First define a global operator variable 'opname' within the script
with a name derived from requested parameters, called s,m,n,e :

	opname=sprintf("s%dm%dn%de%d",s,m,n,e);
	eval(sprintf("global %s",opname));
	if (!exist(opname))
		#... search in a operator-library with most common
		#... combinations of parameters ...
		load -force library opname
		if (!exist(opname))
			# operator not found in library
			# ... calculate ...
			# ... calculate ...			
		endif
	endif

When such a script was invoked multiple times, requested operators previously 
calculated or found in the library were remembered even on the calling level.
So, a previously already loaded/calculated 'opname' wasn't looked-up multiple
times in libraries or even multiply calculated in a lengthy fashion!

In summary, up to octave version 2.0.09, this strategy made 'opname' 
globally visible from within a script and available for further calls
(even by different program-scripts or manual operation on the calling level)
within the current octave session. This worked pretty fine!

Since 2.0.10, this changed dramatically and all these programs fail, since

	>>>  'exist(opname)'  now always returns TRUE=1   <<<<

in contrast to 2.0.09, where 0=FALSE was the result when a global variable was
simply DECLARED, but not yet DEFINED/INITIALIZED.

It seems, that from now on, pure declarations of global variables will be
impossible because they are ALWAYS DEFINED/INITIALIZED to be empty '[]' and 
it's pure logics that  'exist(...)' now MUST ALWAYS return TRUE. But you 
cannot differentiate between 'declared'-status and 'initialized'- status 
anymore. Following our example given above which takes advantage of exactly
this difference, we look at this new 'feature' as a severe drawback.

Matlab-compatibility is ONE argument, but do you really want to dismiss such
helpful advantages of octave on cost of simple compatibility to already 
existing programs?

Is there an option-switch or global octave-variable which controls this
feature and allows to retain the 2.0.9-treatment of global initialization ?
If not, it might be quit helpful. Please think about it.

Best wishes Rolf Fabian 
980219 fabian at umwelt dot tu-cottbus dot de