SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 4 Jan 2004 09:32:52 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Peter Skye writes:
"And I disagree. My own financial optimization software is all
written high-level and specifically avoids doing calculations
which take "a lot of time", and it does this by splitting numeric
values into components and then doing the calculations with
the components. It's a lot faster this way and couldn't have
been done without an understanding of the hardware
instruction set. ..."

Peter,

Without giving away the secrets of your financial software
wizardry you might give us a clue as to what you mean by
"components" of a numeric value. To the best of my
knowledge to have components means having at least two. I
feel somewhat confident you exclude components of floating
point variables as splitting them into mantissa and exponent
makes no sense. The only remaining values which have two
components are decimal and binary reals with integer and
fractional components. Unless you use COBOL or PL/I which
support them as data types you can't even express them in a
HLL. Even using them they offer no means except in a picture
clause and overlays to split the integer from the fractional
portion.

I have some confidence that your use of the term
"components" doesn't apply to any of the previous. You could
help us somewhat with one of your "a picture is worth a
thousand words" illustrations of what you mean. Then maybe
we can understand how you can do it in a HLL only with
knowledge of the instruction set of the machine without the
knowledge of how the software translates the HLL into
machine instructions.

"...But this is "Hello World" stuff, Bob. Yes, there are plenty of
simple programs. And then there are the ones which college
students shouldn't be assigned to, no matter _what_ language
they are using. (As for the few hot-shot college students
who _can_ handle such robust programs, the ones I've known
_did_ know the hardware instruction set.)"

Well, I hate to bring up the example of Remex, an account I
converted from IBM 1130 Fortran to IBM 370 DOS/VSE, COBOL,
CICS, and DL/I. To do it I invented a "structured development
approach", allowing them in a stepwise manner to learn as
they earned.

I had them first to define all the outputs expected from the as
yet undesigned applications. With these I had them define the
DL/I databases. With that I had them define all the inputs into
the applications. In short I had them define all the input,
output, and stored, i.e. persistent, data of the proposed batch
and online application systems.

We then did a structured analysis and design. We used the
data definitions with their flow from input to output through
intermediate datastores, i.e. persistent data, to define the
processes. We then used the standard structured design
heuristic to convert the dataflow processes to structure
charts. They then proceeeded successfully to code the
modules expressed in the structure charts.

Then because we ran it on a machine IBM deemed too small to
support batch and online applications using a shared DL/I
database, I won't bother you with the number of calls
nationally and internationally wanting to know how we did it.

While there's a little boasting here and one of the few
moments when IBM paid me extra for pulling their coals out of
the fire, the account did it without clue one of the instruction
set of the IBM 370. So there.

One of the reasons for going to an HLL instead of using
symbolic assembly lay in achieving machine independence, in
not having to know the instruction set of a machine. In the
PL/I and COBOL world we referred to this machine
independence of data and operations as "portability".
Unfortunately K&R claimed a different portability relating to
ease of writing a compiler, which due to the need for a
third-part library support and an implementation defined "int"
and "float" had neither data nor source portability as the UNIX
community discovered later to its chagrin.

The other myth, aside from the prostitution of the meaning of
portability, in C comes from believing that it's closer to the
instruction set than other HLLs. That's a load a crap when a
language doesn't even support the all the data types used by
the instructions.

So, Peter, how about coming clean on what you mean by
components?

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 04 | January | 2004 ]

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.