SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-SundialSIG Mailing List Archives

Return to [ 16 | April | 2001 ]


Date: Mon, 16 Apr 2001 19:15:41 PST
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-sundialsig@scoug.com
To: Scoug Sundial Sig <scoug-sundialsig@scoug.com >
Subject: SCOUG-SundialSIG: Saturday's Agenda

Content Type: text/plain

It will be a challenge to say something that Mark can understand
while at the same time satisfy the real examples suggested by
Tony. I've not looked at a spreadsheet since the availability of
RBase in DOS, even though I have three of them (MESA 2, 1-2-3, and
StarOffice). I'm not going to attempt to pass myself off as some
kind of pro.

OTOH I've no idea the depth required to satisfy the general
request at our initial meeting of dealing with "equations" in
MESA. What people want may be far simpler than the general
approach I have in mind. I don't want to engage in overkill.

But I do want to engage in problem analysis, of offering ways for
people to make more progress on their own. Maybe in there fill in
the gaps between meetings with this mailing list and scheduling
some chat sessions on demand.

The point lies in being responsive in the broadest possible manner
to the needs of the group. Getting them to talk about "formulas"
instead of "equations" seemed like a reasonable first step.
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.