MathGroup Archive 2008

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

Search the Archive

Re: Functional programming?

  • To: mathgroup at
  • Subject: [mg92173] Re: Functional programming?
  • From: John Doty <jpd at>
  • Date: Mon, 22 Sep 2008 05:27:46 -0400 (EDT)
  • References: <> <gal3dg$dql$> <gat9cl$ead$>

peter lindsay wrote:
> To a novice in these matters like myself it looks to me as if:1. Debugging
> FP code could be very challenging

It usually isn't. Good FP involves breaking down the problem into 
*simple* functions, often one-liners. Such functions are generally easy 
to informally "unit test" before use, so you get most bugs out as you write.

If you encounter a bug later, well, that must represent a case you 
didn't test. So, test your low level functions on it, working up until 
you find the problem. Usually pretty easy.

My usual approach to numerical analysis these days is to start in 
Mathematica using a functional approach because it is so easy to get 
something working that way, and because the design phase can involve 
mixtures of symbolic and numerical computation. Then, if need be, I can 
translate the resulting prototype into pure numerical C very easily. 
Bugs are few that way, and bugs in the C code can be quickly found by 
comparing intermediate results in the C with the results from my 
Mathematica functions.

On the other hand, starting in C and finding bugs by stepping through 
the code in a debugger seems to me an extremely inefficient process.

> 2. Although FP looks very concise and fast, there a lot going on that's not
> immediately apparent and its not clear [ to me ] how to get full hand-on on
> that code.

You *never* get "full hand-on on the code". Do you inspect the assembly 
language generated by your C compiler? Do you know the logical structure 
of your processor's multiplier? How about its physical structure. Can 
you compute the electron mobility in silicon from first principles? Are 
there really "first principles"?

In real life, you always draw a line and trust that you understand the 
effects of the stuff beyond it, without examining the details. Part of 
professionalism is drawing the line in the right place, but studying a 
lot so that if your customary place is unilluminating in a particular 
situation, you can move the line to where it needs to be.

Remember that in Mathematica, both procedural and functional codes are 
partly artful illusions. Mathematica's foundation is structural pattern 
matching and and replacement. This can have consequences that are 
unexpected and troublesome or very useful.

John Doty, Noqsi Aerospace, Ltd.
The axiomatic method of mathematics is one of the great achievements of 
our culture. However, it is only a method. Whereas the facts of 
mathematics once discovered will never change, the method by which these 
facts are verified has changed many times in the past, and it would be 
foolhardy to expect that changes will not occur again at some future 
date. - Gian-Carlo Rota

  • Prev by Date: mathematica 6.0.3 and mac os x 10.5.5 crashes?
  • Next by Date: Re: labeling axes in a ContourPlot
  • Previous by thread: Re: Functional programming?
  • Next by thread: Re: Functional programming?