Hi
I have to disagree re speed.

Matrix handling of arrays is orders of magnitude faster than dynamic arrays.
Particularly in the case in point where large amounts of data are to be
handled. Consider the work involved; for those who remember Cobol moves,
the first chunk has to be moved to a new position large enough to hold the
altered record , the change has to be concatenated, then the remaining chunk
has to be concatenated. The further down an item one goes the more time it
takes to find the limit of the first chunk. Therefore changing more than
one element is always going to be slower for a dynamic array. The time lost
on the read is made up everywhere else. Also one should never keep
redimensioning an array as it will crucify the system. The worst example of
this is where some junior got at the Dos to Pick transfer program and
wrecked it back in the 1980's. A further benefit of matrices is that an
element less than 10 bytes long will be altered in situ and an element
longer will be identified by an exact address from the initial 10 byte
position without having to count through the entire record.

However there is a far greater reason to use matrices when handling normal
data. This is the use of the equate. I hate to think of how often I have
seen systems messed up by people using offsets in dynamic arrays because
they were quite certain that it was field 17 or whatever that needed
altering. The best way to access is always to name the field and alter the
named item. Then at least the next programmer will know what you meant to
alter. I have never been lucky enough to fall across a site apart from my
own that kept file definition documentation up to date. I forced the issue
by using a generator that goes to the documentation to produce the program.

Peter McMurray

"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote

Don't compare the old COBOL with Pick for functionality under the hood.
I've done some cursory (sp?) speed checks and with a small amount of code
for reading and writing items the difference in working with 10,000 items
with 50 attributes the difference in speed was less than a second.


You can still use equates with dynamic arrays! And it can make the program
more understandable and can be used with dynamic or dimensioned arrays,
albeit there is more typing to generate the code.

eg.

equ name.attr to 5

read cust.rec from...

print cust.rec<name.attr>
....
or

equ name.attr to 5
dim cust.rec(10)
read cust.rec from...

print cust.rec(name.attr)

Both work and I find this way there is no mixup in where the data is coming
from or going.

Add some programming standards to ensure that attribute definitions and item
names don't get intermixed and you get far easier code to read.

I've run into code which used dimensioned arrays and equating of each
element of the array to a symbol name. Because of no standards the arrays
get passed to subroutines where another programmer used their on different
symbol names.

Let's face facts... poor code can and does get written. Good standards
makes life easier in the long run.


Dale

Hi
My reference to speed was particularly concerned with handling large arrays.
I agree a 50 element array could not be timed accurately because of the
latency of the clock function. I still believe it to be more efficient. I
used the cobol method to explain how it happens, and yes this is still the
only way that I have ever found described of building an item. Modern
methods are still the same. In fact if one looks at low level code one will
also find that the much maligned GOTO is a mjor player although I doubt that
many people today will build an instruction on the fly at say spot zero and
then GOTO it for execution. This sort of code was essential when limited to
16K bytes.

However when dealing with large amounts of data as frequently occurs with
transferring flat files from disparate systems the matrix method is vastly
more efficient.

I agree that one can equate to an offset however that requires all the
attendant move/shuffle of the dynamic array, losing the speed advantage of
the exact positioning of the matrix element.
Peter McMurray

"Dale Benedict" <dale_knowspam_benedict (AT) flightcraft (DOT) ca> wrote

Tedd:

Maybe I missed something here but this is the D3 documentation:

A "dim" statement without the number of elements specified, such as in the
case: "dim a()", may only be used in a subroutine. FlashBASIC run-time
determines the number of elements after a "matread".

An array must be dimensioned prior to being referenced within a program.
After an array has been dimensioned, it may be redimensioned later within a
program. When the dimensioning parameters are changed, the new array will:

- retain those elements with the same indexes that were in the old array;

- have any new elements initialized to a unassigned state;

- lose any unreferenced elements (those elements in the old array with
indicies not present in the new array).

Bill

"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote

Aye, I read that part too.

Bill H wrote:
This seems to be the point that the book says I can do that I cannot
get to work. The only way I've seen it work is when a dimensioned
array is sized in the calling program passed in tne subroutine
arguments (or the commons?).

I'd love to see an example of a matread actually sizing the dimensioned
array it uses to read the record into. The D3 "book" certainly alludes
to that being a possiblity. What about other PICK flavors?

Tedd:

I couldn't either. I used D3NT Flashed/Unflashed and D3Linux
Flashed/Unflashed. So much for good ideas. :-)

Bill

"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote