FC>> and was wondering why it wasn't working.  It took me a 
FC>> while to twig on to the fact that the initial value of an 
FC>> unassigned numeric variable in a huge array was non-zero, 
FC>> unlike other array structures.
 > I'll be danged, but you're right.
Has anyone done any substantial work with huge arrays, especially double 
words?  I was trying to use them in a program and eventually gave up and went 
with a couple of "regular" arrays instead.  Use of huge arrays seemed to add 
some "flakiness" to the program that isn't there with the huge arrays gone.  
I didn't run across any specific bug, but it almost seemed to me that one of 
the array elements occasionally didn't "stick"; after it was assigned it 
didn't hold the value that was expected.  And when I tried to find out why 
the program wasn't working by sticking a bunch of print this-and-that into 
the loop, all of a sudden it did (sort of).  Then it didn't.  After a few 
rounds of this, I said "ARGGGH" and got rid of the huge arrays, plugged in 
some "regular" arrays, and carried on with developing the rest of the 
ogram.
Has anyone else that's tried to use huge arrays of double words or any other 
variable type?  Did they work "as advertised" for you?  It's possible that my 
problems here were due to the old "nut between the keyboard and the chair" 
syndrome too; all of those negative numbers can make a guy's eyes cross after 
a while.  But after I got rid of the huge arrays things seemed to move along 
much more efficiently....
The thought did cross my mind to use some sort of a VARPTR/POKE$ combination 
to insure that all of the unassigned values of record???() were 0 before I 
did anything else, to see if that did anything of value, but I got frustrated 
before I tried this.
Here's something interesting:
dim huge record???(-32768 to 32767)
for x%=-32768 to 32768
record???(x%)=0
next
print record???(32768)
This works, even though we exceed the maximum value of an integer variable.  
Notice that the last iteration of x% is also larger than the maximum element 
number of record???().  record???(32768)=0, by the way.  All other values of 
record???() are also 0 in this example.
dim huge record???(-32768 to 32767)
for x%=-32768 to 32767
record???(x%)=0
next
This locks up tight.  Notice that the last iteration of x% is equal to the 
maxumum element number of record???().
This was done with all error tests off.  Setting all error tests on gives me 
an overflow error.  But what's interesting here is that the last iteration of 
x% is larger than the maximum value of an integer variable in both cases, but 
the case where the violation is more "flagrant" (two violations) appears to 
work while the less "flagrant" violation (one violation) locks up.
You can't call this a bug because both examples are "illegal" anyway.  But it 
certainly qualifies as "strange behaviour".
--- Msgedsq 2.2e
---------------