Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC

#11

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Quote:

As a side issue - would it
be any more/less efficient to OPEN the workfile as the default -
without a file variable?

There is absolutely no difference. The compiler looks for a file variable
and if it doesn't find one, it will use the "default", which actually has a
name, FV. On D3, at least, you can stop a program with debug and use /* to
see all fariables. If you open a file to the default file variable (ie,
open 'md' else abort) you'll see a variable called FV. Beyond that, the
compiler converts all var names into descriptor table offsets; at which
point that all become brothers and sisters.

Mark Brown

#12

Ancient history in terms of the redim - I believe it works as
advertised now (when used with caution - note NON-use in shared
labelled common)

Not so much Visage.Reporter, but certainly this is what Visage.BIT does
for breakfast.

We are currently specing out a project that will see us "digesting"
around 2Gb of transactional data a day, with a minimum 5 years worth of
history, so we are going to end up with a database of around 5Tb
(hopefully ... anyone have anything this size ?)

Peter McMurray wrote:

Quote:

Hi Ross
Please never even dream of suggesting re-dimension on the fly. Somebody at
Pick systems destroyed the transfer from Dos to Pick when this was first
implemented. What was really sad was that particular program was one of the
best implemented and best documented programs from Pick until that amateur
got at it.
As a thought surely your Visage reporting tool would do everything this guy
is talking about without re-inventing the wheel.
Peter McMurray

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote in message
news:1151798944.637770.178800 (AT) m38g2000cwc (DOT) googlegroups.com...
Depends on the environment you are in. D3 and UV both allow you to
re-dimension arrays on the fly (NB: do NOT put them in common unless
they are in their own labelled cmmon block, and even then ...)

I'm sure that CacheMV guys can probably go much better (and deeper)

SteveB wrote:
Hi all,

Having used other languages heavily in conjunction with mvbasic for six
years now, I often feel serious limitations inherent in pick basic.

While I am running a process I want to build up a variable *unknown*
number of two dimensional STATIC arrays. I need the arrays to be STATIC
for performance because they are quite large (often about 1000x50) and
the process is furiously building them up from scratch.

mvbasic only allows you to acquire memory for storage at the point of
dimensioning static arrays or by building strings. Object orientated
programs are quite happy for you to create a kind of floating array
that can be stored within.

A lot of people think OO is a design process. Well its much more than
that. In this case its about the freedom for variables to contain
"things", in this case arrays.

Cheers,
Steve

#13

frosty wrote:

Quote:

GVP wrote:
Hi,
I don't know what for need arrays with dimensions 1000x50. For
report?...

SteveB wrote:
Yes its a large paged tabulation. I explained it earlier on in the
thread. Actually the 1000x50 is only one report of many that is going
to be built up.

GVP wrote:
I think that better to use rarefied arrays (If You don't need use
each element of array). This technology saves memory and more
effectively than dynamic arrays.

SteveB wrote:
Where can I get rarefied arrays in mvbasic?

I've always known them as "sparse" arrays, and implement them
with temporary or "work" files. (Thank you, Mark Brown.)

----------------------------------------------------------------
ArrayCnt = 50000
DIM MyDimArray(ArrayCnt)
MAT MyDimArray=''
*
** Build both arrays
CRT "Dimensioned Load Start-: " : TIMEDATE()
FOR X = 1 TO ArrayCnt
MyDimArray(RND(X)+1) = "DimDimDim"
NEXT X
CRT "Dimensioned Load Stop--: " : TIMEDATE()
*
CRT "Workfile Load Start-----: " : TIMEDATE()
EXECUTE 'CREATE.FILE STEVEB_TEMP 1 1 DYNAMIC' CAPTURING JUNK
OPEN 'STEVEB_TEMP' TO TEMP.FV ELSE STOP
FOR X = 1 TO ArrayCnt
WRITE "DynDynDyn" ON TEMP.FV,RND(X)+1

Something else has just occurred to me... Maybe the records themselves
could be nulls (empty strings) with the Id being the random number (or
maybe two or more random numbers with delimiter(s)). Then, when you do
the SELECT...READNEXT... you wouldn't have to actually READ them - the
values you're after would be right there in the Id.

Quote:

NEXT X
CRT "Workfile Load Stop------: " : TIMEDATE()
*
** Read both arrays
CRT "Dimensioned Read Start-: " : TIMEDATE()
FOR X = 1 TO ArrayCnt
dummy = MyDimArray(RND(X)+1)
NEXT X
CRT "Dimensioned Read Stop--: " : TIMEDATE()
*
CRT "Workfile Read Start-----: " : TIMEDATE()
SELECT TEMP.FV
LOOP
READNEXT ID ELSE EXIT
READ DUMMY FROM TEMP.FV,ID ELSE CONTINUE
REPEAT
CRT "Workfile Read Stop------: " : TIMEDATE()
----------------------------------------------------------------

Dimensioned Load Start-: 14:31:07 JUL 01 2006
Dimensioned Load Stop--: 14:31:07 JUL 01 2006
Workfile Load Start-----: 14:31:07 JUL 01 2006
Workfile Load Stop------: 14:31:08 JUL 01 2006
Dimensioned Read Start-: 14:31:08 JUL 01 2006
Dimensioned Read Stop--: 14:31:08 JUL 01 2006
Workfile Read Start-----: 14:31:08 JUL 01 2006
Workfile Read Stop------: 14:31:08 JUL 01 2006

Tried bumping ArrayCnt from 50000 to 500000 to get useful
timings, but that crashes uniData(!) -- at least for the
DIMensioned side; the workfile side will continue to
function just fine, thank you.

--
frosty

#14

SteveB wrote:

Quote:

Mike Preece wrote:

Something else has just occurred to me... Maybe the records themselves
could be nulls (empty strings) with the Id being the random number (or
maybe two or more random numbers with delimiter(s)). Then, when you do
the SELECT...READNEXT... you wouldn't have to actually READ them - the
values you're after would be right there in the Id.

Since the id is usuall stored right before the record in hashed files
frames it wouldnt make any difference. OpenQM, at least, has a default
limit of 64 bytes on keys which could problems in some cases.

Cheers,
Steve

Do you have "select to listname" or "readlist" on your system?

While I think of it... is there any noticeable difference in using an
index on the id/key as opposed to an attribute/field - say field one?

#15

Bill H wrote:

Quote:

John:

Isn't it great how the dbms can be brought into the mix, instead of
attempting to manipulate memory?

Bill

I think it's great, yes. Others might see a hammer+nail situation.

--
frosty

#16

Mike Preece wrote:
[snip]

Quote:

Very strong possibility of overwriting at least some records - and
therefore reading fewer than 50,000 records later.

Absolutely:

COUNT STEVEB_TEMP
25075 record(s) counted

But I just wrote the code, not the design!

Quote:

Maybe not the clean
potato. Also - if the requirement is for two (or more) dimensional
arrays we might want to use READU...LOCATE...INS to create an
attribute list (maybe with multivalues and maybe subvalues). This
satisfies the requirement if the dimensions are totally variable.

That is SOP in the 'real' workfiles I use in real applications, yes.

Quote:

You
could possibly go further and use MATREADU/MATWRITE... MATREAD.

Don't know how much that buys with small records, but yes.

Quote:

I
still want to know more about the actual requirements though.

Something about "large paged tabulation." Easy to SSELECT the workfile
and process it with another BASIC program to produce the report. We use
this technique a lot in our web-deployed enterprise application.

--
frosty

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC

comp.databases.pick comp.databases.pick

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-02-2006 , 06:45 AM

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-02-2006 , 06:49 AM

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-02-2006 , 08:11 AM

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-03-2006 , 10:03 AM

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-03-2006 , 10:07 AM

Re: Arrays of Arrays is useful, a hallmark of OO, and missing in MVBASIC - 07-03-2006 , 10:17 AM