Re: PS.
- To: mathgroup at smc.vnet.net
- Subject: [mg29711] Re: PS.
- From: "John Doty" <jpd at w-d.org>
- Date: Wed, 4 Jul 2001 03:08:35 -0400 (EDT)
- References: <9guo4t$nt8$1@smc.vnet.net> <9h1b0v$rki$1@smc.vnet.net> <9hc899$40j$1@smc.vnet.net> <9hetm2$6ka$1@smc.vnet.net> <9hh50i$91t$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
In article <9hh50i$91t$1 at smc.vnet.net>, "Jens-Peer Kuska" <kuska at informatik.uni-leipzig.de> 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 + 0.00940125000000101*logsun*t; r.imp = 1.789978134324972*suns + 0.00088600441170817*suns*t - 2.861053683455669e-6*suns*t*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 w-d.org | Work: jpd at space.mit.edu