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

"peter_douglass" <baisly_at_gis.net> wrote in message news:3b44a4a2$1_at_tobjects.newsource.com...
>
> 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.

So the *definition* of a function is to "create" a variable that "is" this function? Pardon the quotes and/or clarify them.

>
> 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.

I'm interested, but how can Z have an argument n?

> 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.

Sigh. I'm completely overwhelmed by that paragraph. Do I need an "FP for dummies" or "FP in 15 days" book :-?

> > 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.

By "first class values", do you mean that functions *are* values? Can you say (should you say / is it useful to say) that in FP everything can be thought of as values of which functions are one kind. (Just fishing here.)

I know I have a naive understanding of FP so you can blame me for quoting the trivially true and missing the essence.

> > 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.

In your last sentence, the first aspect is a query and the second aspect is an
action. That doesn't jive with the previous sentence "input into a system with
constraints". I agree with your last sentence, of course, but I took your previous sentence to mean "altering the system of constraints is different from finding the solution that satisfies them". At some high level, its useful
to think of these as *not* different, but any practical implementation needs to separate them, at the very least to deal with transactions.

> 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).

Very nicely put. The difference between mathematicians (I'm done if I show it could be solved :-) and engineers (who have to solve it in this lifetime).

OTOH, I believe we'll steadily march in the direction of declarative, because
that's less work for us programmers -- the final bottleneck.

> > 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 Sat Jul 07 2001 - 08:26:02 CEST