Re: A numerical methods viewpoint on OO/FP/Relational

Richard MacDonald wrote:

[snip]

> The punchline:
> The relational world and the OO world correspond to the Z | H(Z)=0
 form
> The functional world corresponds to the Y=F(X) form.

Another way to look at functional programming is this. When you apply a function to a value, you get the Y = F(X) form, but when you _define_ a function, you use something similar to Z | H(Z)=0 form, i.e. least fixed points. The form of a least fixed point would be something like:

minimum { Z | H(Z) = Z }
for some definition of minimum.

If squares and rectangles are ubiquitous in OO examples, the lowly factorial is ubiquitous as a functional programming example.

fact 0 = 0
fact n = n * (fact (n-1))

In this definition, it is fact that plays the role of Z in your form above. Now the factorial function is a fixed point of these equations, but so is the function that always returns an error. If functions are ordered by their information content, and an error is treated as "so much information that it is inconsistant", i.e. the top of the hierarchy, then the factorial function is the least fixed point, as well as _a_ fixed point.

> Relational model:
 

> The relational model is declarative. It defines the variables
> and defines the constraints that the variables must satisfy.
> It doesn't say how these constraints must be satisfied.
> It simply accepts or rejects values for the variables depending
> on whether these values satisfy the constraints or not.
 

> Note, however, that the relational model also has a
> provision for explicitly defining dependent variables as
> functions of other variables.
 

> Functional model:
 

> The functional model says that the function is fundamental.
> This is F. The function accepts input X and produces output
> Y. The functional model "subsumes" variables by making them
> the identity function, i.e., X=F(X). So everything can be
> thought of as functions.

I'm not sure where the idea that in the functional paradigm, everything can be thought of as functions, comes from. I've seen that idea expressed a number of times, but it goes against my view of FP. Of course it is trivially true. For every value, there is a constant function that returns that value. But I don't see what this has to do with FP. A more important relationship between functions and values is that in FP, functions are first class values.

> Object model:
 

> The object model says that the variable is fundamental. An
> object is a collection of one or more variables (sometimes
> zero, but never mind that). The object model "places" the
> functions and/or constraints on those variables within the
> same object. In some sense, we can think of Z|H(Z)=0
> as looking at the variables Z and "hiding" the H(Z)=0
> requirement behind the objects.
 

> (Note that I use quotes around "places" because
> sometimes the constraints are directly contained within the
> object, and sometimes the constraints are elsewhere, but are
> still within the control of the object, e.g., the Strategy
> pattern. Sometimes these functions/constraints are totally
> outside the object, but I would suggest that this is where
> the object language is being used to write non-object code.)
 

> Caveat:
 

> Of course, there is much overlap between these three. One
> can use principles from one paradigm in another. Its possible
> to write functional code in OO. Its possible to write relational
> code in OO.
 

> The reason I thought this worth posting is that there is such
> a "mental difference" between Y=F(X) and Z|H(X)=0 in the
> numerical methods world. Its all "the same thing", but that
> difference in perspective/viewpoint is a basic and important
> aspect.
 

> I don't know how it applies to programming, however in
> the numerical methods world, the form Z|H(Z)=0 is King.
> The reason is that it is sometimes impossible to separate
> the independent variables from the dependent ones, e.g.,
> writing X=Y*sin(Y) in terms of its inverse Y=F(X).
> A simple "polymorphic" transformation to H(Z)=0
> eliminates this problem. Thus, the mathematical
> developments and the solution engines
> are written with this more general "interface" in mind.
 

> I'm definitely not going to claim this as evidence that
> the functional model is inferior. (I would like to know
> how the functional folks handle it, though.)

IMHO, one of the weaknesses of many FPLs is lack of explicit relational support. The experimental language Machiavelli, is in my opinion, a step in the right direction. From another angle, Functional-Logic programming languages like Mercury allow functions and constraints to be used in the same language.

> I'm more interested in how we can use this mathy perspective to
> understand OO better. It seems to me that "Variable Z
> such that all constraints on Z are satisfied" is an
> OO-friendly idea. I don't think OO handles general
> constraints all that well. Sometimes the constraints
> can all be organized into the "proper" objects, and
> sometimes they cannot. The more they cannot (read:
> general numerical methods problems where any variable
> can be constrained with any other variable), the more
> one's attempts to find the "right" "real-world" OO
> model are in vain. Instead, one has to define an OO
> model in mathy terms, i.e., X, Y, H, and G are all
> first-class objects, as are the constraint solvers.

I'm not sure where to go with this, but one though occurs to me. Input into a system with constraints is quite different from finding a value satisfying constraints. IOW, it is easier to check that H(Z)=0 for a given Z, then it is to find such a Z. With every language, the programmer has some intuitive model for how her program will be evaluated. We might consider declarative and procedural to be opposite poles, but no program is entirely one or the other. The trade-off of going too far in the declarative direction is that we don't capture important information that might greatly reduce the effort needed for evaluation. Going too far in the procedural direction and we lose sight of what we _want_ to accomplish in the mountain of details of _how_ it will be done. Thus, I wouldn't argue that either one of Y=F(X) or Z | H(Z) = 0 is necessarily better. Often the specifications of problems are in the form Z | H(Z) = 0, but to get an efficient solution we transform them into Y = F(X).

> Well, this hit me as a sudden thought and I thought I
> would vent it. Poorly formed, but I hope an interesting
> viewpoint, nonetheless. Tear it up:-)

My thoughts were probably as poorly formed as yours. It is an interesting topic, but like many interesting topics our ancestors have not provided us with definitive results ;-/

--PeterD Received on Fri Jul 06 2001 - 00:16:43 CEST