MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: PS.

  • To: mathgroup at
  • Subject: [mg29711] Re: PS.
  • From: "John Doty" <jpd at>
  • Date: Wed, 4 Jul 2001 03:08:35 -0400 (EDT)
  • References: <9guo4t$nt8$> <9h1b0v$rki$> <9hc899$40j$> <9hetm2$6ka$> <9hh50i$91t$>
  • Sender: owner-wri-mathgroup at

In article <9hh50i$91t$1 at>, "Jens-Peer Kuska"
<kuska at> wrote:

> There is a sharp difference between *numerical* and *mathematical*
> computing. Numerics in *not* mathematics. It is some kind of black
> magic.

But working numerics emerge from mathematical reasoning. Mathematica is
extremely effective at assisting in the reasoning process and at trying
out the resulting numerical method.

Here's a bit of C code I wrote a few years ago:

	logsun = log((double)suns);
	r.isc = 1.898399927658386*suns;
	r.voc = 136.7551119851344 - 0.2353679113586623*t + 
	r.imp = 1.789978134324972*suns + 0.00088600441170817*suns*t - 
	r.vmp = 138.7101438236847 + 1.673177670210234*logsun + 
		0.1216245287529764*logsun*logsun - 
		0.2855568437726207*t + 0.004974628272084181*logsun*t + 
		0.00005564339736132346*t*t - 2.0*r.imp;	

These represent approximate solutions to a set of equations. Where did
this code come from? How did I know that the particular forms would work?
Where did the coefficients come from? Why, Mathematica, of course! There's
a rather large Mathematica notebook behind those few lines of code. I used
a mixture of symbolic and numeric techniques. There may be a "sharp
difference", but the ability to use both kinds of computation in the same
calculation is very powerful.

> I can't see any  application of "rule based" or "logic" programming in
> numerics. The rule search take a sufficient amount of time and it is not
> a good idea to add this overhead to an numerical subroutine.

One might not think AWK (a string pattern recognition and transformation
language) would be applicable to embedded image processing either. I once
had the problem that an embedded code (assembly language) and an offline
reference code (C) gave different answers when reducing the same image.
This was what the reference code was for, of course, but there was no
proof the reference code was correct, and the assembly language
programmers had great confidence in their own work. I cooked up a 5 line
AWK program that could produce the output in question, although it took 10
minutes to reduce a single video frame (associative arrays are powerful
and inefficient). Everyone agreed that this simple code must yield the
correct result. It agreed with the reference code: the assembly guys had
some digging to do. A ten minute run was a trivial price for this result.

Choosing tools isn't a matter of broad-brush categories like "numerics":
it's a matter of whether the chosen tool's specific capabilities match the
specific needs of a specific problem. There are no universal tools, but
because isomorphism is so common in technical problems, tools are often
far more versatile than their designers intended.

> I don't like FORTRAN very much but if it keeps the students away from
> OOP-plague it is the best argument to use FORTRAN more often !

There's a lot of really crummy OOP around, but OOP has its place. NeXT
Computer's appkit in Objective-C was really very simple and
straightforward to use, a triumph of OOP. I don't think the problem is
really OOP, but the idolatry of abstraction that CS professors
indoctrinate their students with. The hiding of irrelevant details is a
worthy goal, but the hiding of *relevant* details is obfuscation. Too few
programmers understand the difference.

| John Doty		"You can't confuse me, that's my job."
| Home: jpd at
| Work: jpd at

  • Prev by Date: Re: Swiftest code to turn list of ordered pairs into Markov matrix
  • Next by Date: Re: Swiftest code to turn list of ordered pairs into Markov matrix
  • Previous by thread: Re: newsgroup use
  • Next by thread: Section numbering