It's the second step that concerns me.
MESA 2 has a large body of builtin functions. I have no idea
which are of greater concern to the group. That's when I came up
with the idea a generic introduction to programming relative to
spreadsheets, relational databases (SQL), and APL.
The intent is not to scare people, but make them aware that use of
formulas, particularly greater use, puts them into maintenance
mode which has been the bane of programming historically. It's
not related to having complicated spreadsheets which deals with
the number of things, but with having complex ones which deal the
interconnection among the things.
Thus you can have complicated spreadsheets with very little
complexity and uncomplicated ones with considerable complexity.
Moreover with a spreadsheet a referenced cell may contain either a
data value or a formula. In programming terms if a formula it
constitutes a function reference. A series of such interconnected
references constitutes a logical hierarchy, the same as in a
program.
More to the point is the issue of names. MESA 2 offers a 3
dimensional cell structure, qualified in terms of layer, column,
and row in that order. Layers and columns have alphabetic names
while rows have numeric. A cell name is the concatenation of a
column name followed by a row name, e.g. B || 17 -> B17. To
reference a cell in a different layer, which is also alphabetic,
means prefixing a name surrounded by brackets to the cell name,
e.g. [CD]B17.
Interestingly enough a rectangular range designated by two cell
names, upper left and lower right, within a layer corresponds to
an array cross-section in programming parlance. Apparently you
can only describe cross-sections (ranges within a layer) and not
in the other dimension, i.e. across layers. This latter you can
do in programming.
Now in a database you have column and not row names. Thus unlike
in a spreadsheet you do not have to keep track of ranges
regardless of any change up or down in the number of rows.
Whereas you can have duplicate rows in a spreadsheet you cannot in
a database, which is required in practice (implementation) but not
in the (set) theory on which it is based.
I don't intend really to introduce any of this with the possible
exception of the naming convention at this Saturday's meeting.
The group itself will determine the topics within formulas. It's
simply that there is a natural (to me) relationship in the use of
functions in a spreadsheet, database query, and programming. I
see no reason not to offer a means of selecting which one is most
appropriate to a need.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-sundialsig".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 16 |
April |
2001 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.