[NLRS] Who's the computer programmer in the bunch?
John P. Toscano
tosca005 at tc.umn.edu
Sat Jul 1 17:15:23 EDT 2006
Scott wrote:
>
>
> I wrote my own logging program, but I'm running into a bit of a snag.
> It's written in qbasic. I'm trying to dimension an array A$(x,y,z) and
> the largest number I can get to work for x is 99...so it can only log
> 100 calls (zero to 99) and then the subscript goes out of range. After
> the June contest, it is inadequate to only be able to log (and
> automatically dupe check) 100 calls! :) Ideas???
Scott:
I don't have a user manual for QBASIC around here, but I dug up a little
info by GOOGLEing for it.
It *SHOULD* be possible for an array dimension to exceed 100, based on
some tutorials I found that dimensioned an array to 3000 elements. I
didn't find anything that spelled out limits on mult-dimensional array
subscript size.
How big are "y" and "z" ? Since QBasic is an old DOS program, its
memory capacity is going to be limited to 640K total, and there are
other limits as well. The critical thing is (most likely) the total
amount of memory that the array requires. This will be x * y * z * the
number of bytes per array element. Since this is an array of strings, I
believe that the minimum size per array element is 5. If the product of
x, y, z, and 5 exceeds 64K (i.e., 65,536), there is a high likelihood of
failure. The following quote from a web site suggests a possible
work-around...
<------ begin quote ------
The huge memory model is nearly identical to the large model, the only
significant difference being that the huge model permits individual
arrays to exceed 64K in size. Although the huge model lifts the limits
on arrays, some size restrictions do apply. To maintain efficient
addressing, no individual array element is allowed to cross a segment
boundary. This has the following implications:
* No single element of an array can be larger than 64K. An array can
be larger than 64K, but its individual elements cannot.
* For any array larger than 128K, all elements must have a size in
bytes equal to a power of 2. If the array is 128K or less, its
elements can be any size, up to and including 64K.
...QuickBasic uses the medium memory model within conventional memory.
Huge arrays are enabled by the /AH option which permits both the IDE and
the compiler to use far addressing.
------ end quote ------>
I'm curious on what aspect of a logging program requires or benefits
from a 3-dimensional array. I suppose callsign, band, and gridsquare
could be the three dimensions, because any particular call could have
multiple occurrences in the log from different grids and on different
bands. But I'm not sure why you'd need to store that 3-dimensionally in
an array except possibly for rapid lookup of dupes. The waste of memory
probably doesn't justify the extra speed. Even if a particular station
appeared in your log 64 times (8 bands x 8 grids), for example, a search
of 64 records should be pretty quick, especially if the data were
organized properly.
You might therefore be better off using the TYPE construct (similar to
the C language's typedef of a struct)...
TYPE LogEntryType
LogDateAndTime as double
LogBand as string
LogMode as string
LogFromGrid as string
LogToGrid as string
END TYPE
DIM ContestLog(1000) AS LogEntryType
I chose a double for the date and time because I would probably convert
the calendar & clock on-the-fly to a double-precision floating point
number in the fashion of Microsoft Excel, where the integer portion
counts the number of days since January 1, 1900, and the fractional part
counts the fraction of a day (e.g., 12:00 Noon = 0.5, 6:00 AM = 0.25,
etc.) This makes it real easy to compare one date&time to another, or
to compute elapsed time.
Good luck on the project. I fear that QBasic might not be up to the
task you have in mind, but I've often been amazed by the programs that
some really skilled programmers have managed to turn out. You might
want to try converting the program to Visual Basic, since that's a true
Windows program and can be compiled into pretty efficient machine code,
not just interpreted P-code.
73 de W0JT
More information about the NLRS
mailing list