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-Programming Mailing List Archives

Return to [ 21 | February | 2003 ]

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


Date: Fri, 21 Feb 2003 01:42:59 PST8
From: "Gregory W. Smith" <gsmith@well.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: In retrospect

Content Type: text/plain

> Gregrory and Steven,
>
> I wondered if and when the two of you would weigh in on the
> subject. You have great faith in bug tracking systems
> where I wonder how the bug managed to get "out there" to
> begin with. Therein lies the difference between what occurs
> today and what need not occur at all.
>
>
>
> If you have any faith in Deming's approach to quality control,
> you know that the goal lies in the earliest detection of an
> error and correction at its source. To be honest with you we
> covered the three types of errors that a programmer can
> make: syntax, semantics, and logic. To be even more honest
> all these consist of writing errors. The final leap of honesty
> here lies in admitting that all writing errors occur at data
> entry, i.e. during the editing process.

Now rounding second... I get to disagree with Steven and Lynn
at the same time.

First, in another post Steven said that "faith" has nothing to
do with it--I disagree strongly. In school, my introduction
to formal mathematical proofs started with the basic axioms of
geometry. Some things you accept without proof to get things
started--you take it on "faith" that some things are true. If
you don't like the word faith, find an acceptable synonym.

Second, Lynn has let slip a MAJOR semantic error. (I can't
blame him though, he does not have a suitable editor to
catch it.)

I will take a SWAG that the second error may arise because of
fundamental differences between typical engineering/scientific
problem sets and typical system/business-application problem
sets. So, as I see it, Lynn has made a semantically incorrect
binding between "faith" and "bug tracking systems". Binding
"faith" to "Deming's approach to quality control" is also a
major semantic error.

In other words, I work with physical systems so my tenent
of "faith" is the scientific paradigm. (I like those words,
it sounds profound.) In other words, I assume that my
understanding of the situation is not complete (Axiom 1).
I assume that my theory (e.g., computer model) must be tested
against reality (e.g., regression test data) (Axiom 2). I also
assume that peer review (e.g., beta testing) will help me
improve my understanding of the situation (Axiom 3--now
iterate back to Axiom 1).

Very simply, I do not believe that "all writing errors occur
at data entry, i.e. during the editing process". As I see it
a lot of errors occur in the thinking about the problem before
it ever gets to data entry (Axiom 4). Even when we have a
complete theory for our system (e.g., the Navier-Stokes
equations for fluid flow), it is not mere data entry of the
equations to solve the problem. How do we represent the fluid
properties? There are two ideal limiting cases for the density:
a constant density incompressible fluid or an ideal gas. We
also have an exact model for any real fluid in the virial
equation of state, but where do we truncate the infinite
series of the virial equation? And once we decide on how to
deal with the density, what do we do for the other fluid
properties such as viscosity? Finally, how do we represent
the continuous differential equations as a discrete set of
difference equations. How many points do we use -- and how
do we approximate the equations at each point: centered
difference, upwind difference, Taylor expansion, collocation
polynomial, ... ?

I may have lost a few people with my fluid mechanics example,
but I think that I have made clear my starting point with
Axioms 1 through 4. Alternate axioms are welcome.
-------
Off topic: pick one of the following geometries and run
with it for your fun and enjoyment.

Axiom (Euclid): Given a line and a point not on the line,
there is one and only one line through the point parallel
to the given line.

Axiom (Alternate #1 to Euclid): Given a line and a point
not on the line, there are no lines through the point
parallel to the given line.

Axiom (Alternate #2 to Euclid): Given a line and a point
not on the line, there are many lines through the point
parallel to the given line.
--
Gregory W. Smith (WD9GAY) gsmith@well.com

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

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".

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


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

Return to [ 21 | February | 2003 ]



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.