Re: Mathematica daily WTF
- To: mathgroup at smc.vnet.net
- Subject: [mg115327] Re: Mathematica daily WTF
- From: AES <siegman at stanford.edu>
- Date: Fri, 7 Jan 2011 04:13:13 -0500 (EST)
- References: <ig3pe5$jbc$1@smc.vnet.net>
I don't believe I asserted even half of the assertions Andrzej asserts I asserted in the 2nd part of the 2nd sentence of the 2nd graf below! But in any case I think his introducing the concept of algorithms in the third graf is very helpful and useful, and I'm entirely happy to go along with it. I can't speak with any knowledge at all about the difference (if any) between "algorithmic" and "procedural" programming. I do know however that numerical calculations or simulations of many physical problems are attacked by multi-step algorithms in which the procedural steps in the algorithm match up closely with physical steps in the problem itself. If a good, reliable, inexpensive, and easy to use "canned" program that implements this complete algorithm is available, many engineers and scientists will buy it and use it, often without even examining its procedural "innards". But if this is not the case, and I need answers, I'll probably write a Mathematica notebook which implements the multi-step algorithm step by step, using built-in Mathematica functions for individual steps where available, but guided at each step by physical insight and understanding of the problem. In article <ig3pe5$jbc$1 at smc.vnet.net>, Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote: > Well, personally I think this is a very nice example of eclectic > programming. By that I mean the way I normally program myself; not > caring about any "purity" of style but using functional, procedural > or rule based approaches whichever seems the most convenient at the > moment. Print, of course, works by side-effect and is something that I > also use for debugging all the time; most of the time it is much more > convenient than Trace etc. > > I certainly did not mean to create the impression that I was some sort > of "functional programming purist" or anything of the sort. My response > to AES's post was essentially "philosophical"; it seemed to me that he > was asserting that, in some sense, "real world" problems were by nature > "procedural" and functional programming was invented for reasons of > aesthetics and intended for some narrow circle of connoisseurs. This > assertion seemed to me to run counter to the basic experience of every > mathematician, that one of the most fundamental concept in mathematics > is that of a function and also to the famous "unreasonable effectiveness > of mathematics in science". If functions are fundamental to mathematics > how could they not be fundamental to mathematical sciences? > > Of course one could make an argument that "computational science" > is not quite the same as "mathematical science" and that algorithms > are in some basic way "procedural" while "the rest" of mathematics is > not. It is certainly true that when one looks in practically every book > on algorithms that presents them by means of some sort of "pseudo-code", > one will find that this pseudo-code is "procedural" (at least this is > true in every case known to me). This probably leads many to conclude > that "algorithmic" is almost synonymous with "procedural". While I am not > expert on this matter and so can't speak with full confidence, it seems > to me that this is more likely an "accident" caused by the original and > by now "traditional" design of the computer. I am not sure if a design > has even been tried or is even conceivable. However, for high-level > programming languages the physical issue is largely irrelevant. I do > not deny that one can come up with situations, like some that have > been described in this thread, which seems to be much harder to model > in a functional than a procedural way, but my own view is that the best > response to this situation is by "encapsulating" procedural code in new > "bui lt-in" functions, which then make it very easy to program in a > functional way tasks that used to seem impossible. > > This actually brings me to one issue that I have long wondered about. I > have never seen a Mathematica "functional" code that would perform what is > known as "backtracking". In the Combinatorica package there is a function > called "Backtrack", that is quite general and often very useful, but it > is inefficient because it is written in Mathematica's procedural style > and cannot be compiled because (if I remember correctly) it makes use > of list that are not tensors. For many years I have hoped that some for > some sort of efficient general backtracking built in in the Mathematica > kernel, but, although a lot of Combinatorica functionality has made its > way into the kernel, unfortunately this has not happened to "Backtrack". > > Andrzej Kozlowski > > > > > On 5 Jan 2011, at 11:54, Ingolf Dahl wrote: > > > Andrzej, > > Since you ask for "single examples", I would like to hear your opinion about > > my "Debugging code snippet" > > > > ((If[debug, Print["Place1 ", #]]; #) &)@ > > > > I have started with the functional identity operator # &@, and then added > > the global variable debug, which if set to True prints out the value of the > > variable as side effect. The code snippet can be used to monitor the values > > of sub expressions during debugging, without disturbing the flow of the > > program, and it does not necessarily need to be removed afterwards. > > Best regards > > > > Ingolf Dahl > > ingolf.dahl at telia.com > > > > This code snippet can be inserted into d > >> -----Original Message----- > >> From: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] > >> Sent: den 3 januari 2011 09:58 > >> To: mathgroup at smc.vnet.net > >> Subject: Re: Mathematica daily WTF > >> > >> I don't want to get involved in what is likely to turn out a "linguistic" > > dispute, but I think > >> your ideas about what constitutes "functional" and "procedural" are > > misconceived and do > >> not correspond to what other's mean by these terms. While there is some > > difference between > >> the meaning of "function" in mathematics and in programming, both concepts > > originate from > >> the same source. To quote Thompson's "Haskel. The craft of functional > > programming": "A > >> function is something that we can picture as a box with some inputs and an > > output:..." > >> followed by a picture which is exactly the same that I used to draw in m y > > lectures on > >> introductory set theory and analysis for many years before I heard of > > functional > >> programming. In this sense functions are ubiquitous in mathematics and > > science. "Procedural > >> programming", on the other hand, is programming by "change of state" or > > "side-effects", and > >> as the latter expression suggests, is less natural for the human mind even > > if it could be > >> claimed to c! > >> orrespond more closely to what goes on at "machine level". In any case, I > > cannot think of > >> any scientific or mathematical problems that can be more naturally > > formulated in terms of > >> "side-effects" than in terms of "functions". Perhaps they exist and I my > > bias is due to several > >> decades of doing mathematics but I seriously can't think of a single > > example. Can you > >> provide one? > >> > >> Andrzej Kozlowski > >> > >> > >> On 2 Jan 2011, at 10:55, AES wrote: > >> > >>> In article <ifmrvv$pim$1 at smc.vnet.net>, > >>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote: > >>> > >>>> > >>>> anyway, it does not matter as far as the point I was making is > > concerned, > >>>> which is that the C-like structure of Mathematica procedural programs > > is > >>>> helpful to people (somewhat) familiar with C or Fortran. > >>>> > >>> > >>> I'd argue it is also extremely helpful to people who _think_ physically, > >>> or if you like procedurally, and who are primarily focused on solving > >>> problems that have an inherently procedural character. > >>> > >>> The successive steps (lines, cells, expressions) in a procedural program > >>> will very often state or mimic or reproduce what happens as a function > >>> of time in a dynamic system, or as a function of distance as a wave > >>> propagates, or mimic the flow of control in a complex system, or . . . > >>> > >>> As such, they simplify the process of _coding_ these programs; they > >>> _document_ and make readable what the program is doing, step by step; > >>> they make it easy to _insert later refinements_ inside the procedure > >>> (e.g., tests for current values or for exceptional cases at points > >>> within the procedure). > >>> > >>> All of these things are much more valuable to some of us in our use of > >>> Mathematica than the speed at which the code executes, or the brevity > >>> with which it can be typed. And none of this is to argue that many > >>> basic functions within the language (things like Fourier transforms, > >>> finding matrix eigensolutions, many others) should not be provided and > >>> used as pre-coded non-procedural routines within larger programs. > >>> > >>> I make a lot of use of self-programmed Modules[] in my own programming. > >>> The active or working part of the completed program, where numerical > >>> results get asked fror and results displayed, can be quite briefly > >>> written, mostly just setting input variables, then calling these > >>> modules. But these modules themselves are heavily procedurally coded > >>> internally, and I think that makes a lot of sense. > >>> > >