SCOUG-Programming Mailing List Archives

Date:	Mon, 5 Jan 2004 17:57:41 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Lynn H. Maxson writes:

> Now I come upon a man who creates tens of thousands of
> discrete cells, upwards of one hundred thousand. Each cell
> has to contain four distinct values. That's simple enough to
> specify: "dcl 1 cells (317,317), 2 values (4) dec float (x);".

OK

> Now he has to calculate 400,000 values to assign to the cells.

Huh? If I knew the values to assign the cells, then the problem
is solved and I have no need for a computer. The computer is
supposed to calculate what to put in the cells from the governing
equations.

> It makes no difference if he does it inside or outside the
> program, that's 400,000 statements.

Actually this requires ZERO statements if I have a direct solver
for the equations. Or I use one block transfer to zap all of
the cells with some arbitrary value if I use an iterative solver.

> Then he has to write
> differential equations with 100,000 variables (cells) with 4
> coefficients each.

No. Thirty-six equations. I apply the theorems of calculus and the
differential equations to any arbitrary cell(i,j) in the interior of
of my grid. I can derive a general ALGEBRAIC relation for the values in
cell(i,j) in terms of cell(i-1,j), cell(i+1,j), cell(i,j-1), cell(i,j+1),
cell(i-1,j-1), cell(i-1,j+1), cell(i+1,j-1), and cell(1+1,j+1).
(The differential equations are now gone, replaced by algebraic
equations.) I write ONE statement for value(1).cell(i,j); ONE
statement for value(2).cell(i,j); ONE statement for value(3).cell(i,j);
and finally ONE statement for value(4).cell(i,j).

That is FOUR statements iterated over 315*315=99,225 interior cells.

Likewise, there are FOUR statements that I have to derive for the
special case of cell(1,1); FOUR statements for cells(1,j=2 through 316);
FOUR statements for cell(1,317); and so on.

Thirty-six statements for thirty-six equations and a hand full of
control statements for iteration.

> Obviously I haven't interpreted what he has
> done correctly.

Here we agree.

> Otherwise he would not have time for this
> thread and maybe a grandchild might signal when all that
> writing is done.
>
> Now his question remains of what value logic programming has
> in this situation. We know from what he has said that he
> coded it in some language. Whatever that language we know
> he could have just as easily done it in SL/I.

The FORTRAN dusty deck that I inherited is long gone. Just as
well since there are much better commercial packages. And if I
have to put up with an employer or client that doesn't want to
spring $20K/yr for a single seat license, I will use a spreadsheet.
In which case I will do a less accurate calculation on a 30x30 grid.

> So at least there
> we have a wash until he gets to a situation more amenable to
> logic programming. It's value lies in like PL/I you don't need to
> learn anything else as you don't need to worry about the type
> of problem you want to solve.

FORTRAN, C, spreadsheets, or Octave in my case. PL/I never made it
to the VAXen or Cybers that were all over the engineering schools
in the past.

> The value of logic
> programming lies in that your specifications are your program,
> saving you from having to do analysis, design, and a separate
> construction. You get in in one step instead of four.

The specifications that interest me are conservation of mass,
conservation of energy, and conservation of momentum.

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

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

Return to [ 05 | 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.