Re: OO versus RDB
Date: Sat, 08 Jul 2006 15:30:55 GMT
Message-ID: <PcQrg.1282$Th7.572_at_trnddc05>
Responding to Parker...
>>Obviously porting would be a pain because of the data structures since >>most FPLs don't support state variables at all. Thus a port effectively >>ends up being a rewrite. However, I was talking about original development.
>
>
> Doesn't matter. Original development for, say, a pseudo random number
> generator, is built on top of prior work for, say, root solving, and
> its too much trouble to redo all of the numerical research that was
> done during the seventies (when it was better funded.)
But for original development, that's what FP composition is for. Once one has developed a solution for root solving one can cobble that solution into other solutions. So long as the requirements for root solving don't change over time or with context, composition works quite well for that sort reuse in a hierarchical structure.
In addition, most FPLs I've seen provide simple syntax for substituting the low level solutions in case there is more than one way to do it (e.g., passing the low level root solving function de jour to the high level random number generator function as an argument).
>>Typically an FPL program will be integer factors smaller than a >>corresponding program in traditional languages like C and FORTRAN. In >>addition, the FPL use of functions and composition leads to a very >>direct and intuitive representation of algorithmic functional >>decomposition hierarchies.
>
>
> I'm not sure what the "algorithmic functional decomposition
> hierarchies" would be for, say, a matrix LP decomposition problem.
> Textbook mathematical problems that have a recursive structure can
> sometimes be represented very cleanly in an FPL, but solutions with
> good numerical properties are often much less clean, and are more
> easily attacked with imperative techniques.
I've written an LP package so trust me that there is a lot of code beyond basic matrix operations like transpose. For example, many such packages use heuristics to find an initial basic feasible solution and that is nontrivial. There's also infrastructure code for things like switching between Primal/Dual solutions. The real meat of the algorithm lies in deciding which matrix operations to do and when to do them. Performance demands that those decisions be kept simple, but there is still a lot of stuff going besides text book matrices operations.
[There is an analogy in practical Quicksort implementations. The basic text book Quicksort algorithm can probably be encoded in roughly a dozen lines of C. However, any commercial grade library Quicksort implementation will likely have a hundred lines or so (e.g., to use a more efficient sort once partitions are small).]
There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman
hsl_at_pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Received on Sat Jul 08 2006 - 17:30:55 CEST