WS FULL 
Author Message
 WS FULL

WS FULL seems to be motivating some of the expressed need for additional
control structures.    I was just wondering, would a 100 megabyte workspace
prevent almost all of the WS FULL cases you folks experience, or will you
just keep tackling problems requiring larger arrays?

Speaking for myself, since I've been in the happy state of getting a 100 meg
workspace at will, I very seldom encounter WS FULL.   Therefore, I haven't
needed GOTO enough for it to be much of an issue.

Jack Rudd



Sun, 16 Feb 1997 12:34:05 GMT  
 WS FULL
Jack Rudd:
. I was just wondering, would a 100 megabyte workspace prevent almost
. all of the WS FULL cases you folks experience, or will you just keep
. tackling problems requiring larger arrays?

Hmm...

[A] I deal with a system with something like 50 Gigabytes (and
growing) of storage.  I'm writing database code which accesses some or
all of that at some point or another -- so there are going to be
control structures at some level.

[B] The system usually has about 100-150 users on, any number of which
would be running my code or equivalent.

[C] That said, most people are running in 3 meg workspaces, and the
operating system itself can only address something like 16 megs...  So
any significant improvement would eliminate some significant amount of
looping.

Obviously, I'm not running the latest and greatest apl interpreter
here, by the way...

In general, I'd like my "workspace" to use whatever storage I'm
working with, and not be limited to some sort of architectural
phenomena (like directly addressable ram).  As computer systems evolve
and improve there are going to be countless changes in the underlying
architectures -- I think it's a mistake to tie a high level language
like APL to something so mechanical.

On the other hand

[D] I use sparse array techniques for my selection vectors -- for the
typical case I get much better memory usage than a flat bit array.

[E] Did I also say that I'm treating multiple files (in multiple
libraries) as a single logical entity.  I'm really having to get into
the structure of the machine I'm working with to get my job done.
There is no "logical" reason for me to have to be messing with
multiple files or libraries -- but a given user can only own 2 GB of
storage, and when a file gets up in the hundreds of megabytes it
starts taking a real long time to back up (on this system).  So, I get
into the low-level grunge of the system.

Ideally, I could package my routines up so they looked like "real
apl", which would make the system much more portable and ease some of
the constraints on upgrading the system.  Unfortunately, when you've
gone this far beyond what APL is designed to do that ceases to be
easy.

Now, add to that that the in many cases the only spec for the system
is the existing code, and that some of that is buggy...

Well, when it comes down to it, I see a lot of this control structure
stuff moving in directions that won't make scaling problems any
easier.  [If I can't stuff it in a variable and pass it as an
argument, it doesn't scale.]

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Sun, 16 Feb 1997 13:59:15 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. EACH and WS FULL (was: Manugistics control strux example)

2. Fw: Re: ws full

3. ws full

4. ws-to-ws transfer

5. Compile, NCAL Link and Full Link v Compile and Full Link

6. Pferdemarkt.ws informiert! Newsletter 03/2003 http://www.pferdemarkt.ws

7. .WS and .SF encryption

8. Loading ws for APLX

9. Looking for good APL encrytion algorithms for WS proctection

10. UN: ISIAPL WS UTILITIES

11. evaluate deselects in ws - possible to disable?

12. APL Transliteration & WS Transfer

 

 
Powered by phpBB® Forum Software