Re: Re: declaring integers
- To: mathgroup at smc.vnet.net
- Subject: [mg13112] Re: [mg13063] Re: declaring integers
- From: David Withoff <withoff>
- Date: Tue, 7 Jul 1998 03:44:16 -0400
- Sender: owner-wri-mathgroup at wolfram.com
I didn't understand your discussion here, and the parts that I think I
understand don't seem to be correct. Perhaps if I describe my concerns
you can offer some clarifications.
> When one types "a + b" in most languages (e.g. Fortran, C, Lisp "(+ a
> b)"), one is referring to a mechanical procedure where some item, named
> a, will be added to another item, named b. The nature of that procedure
> will depend on whether a and b are small-sized integers or
> floating-point numbers, or rational numbers, or large-sized integers.
> It also doesn't make much sense if a is a string and b is a number.
> I.e., it matters what "type" the "variables" are.
That is what happens in Mathematica too. If you enter a+b, that invokes
a mechanical procedure that will depend on what a and b are.
> In Mathematica, one actually is specifying a "pattern" Plus[a,b], which,
> if a and b are *patterns* which ultimately represent numbers, the
> result of the pattern "substitution" will eventually invoke the
> internal "Plus routine" of Mathematica to calculate the sum of the two
> numbers. The different numbers occur in different flavors, but that
> matters only inside the internal routine, and essentially is
> inaccessible to the user.
Perhaps I have misunderstood this too, but this doesn't seem right to
me. In Mathematica, an expression is a pattern only if it is used as a
pattern. For example, the expression on the left-hand side of a rule is
a pattern, the second argument in MatchQ is a pattern, and so forth.
The expression a+b isn't a pattern unless it is used in one of those
positions.
> One particularly notable result of this pattern-matching behavior is
> that cited in the reference section of Wolfram's book, regarding Apply:
>
> Apply[Plus, g[a,b]] --> a + b
>
> When I read this example, I was somewhat amazed, because this is quite
> different from the semantics of function application. In fact, I could
> no longer understand what Apply was actually "doing", and it took me
> about 45 minutes of experimenting to find out what was going on.
I'm not understanding your concern here either. Although the Apply
function in Mathematica and, for example, the "apply" function in Lisp
or Scheme, aren't identical, they are certainly similar, and the
differences don't represent anything fundamental. For example,
(apply + '(2 2))
in Scheme is equivalent to
Apply[Plus, {2, 2}]
in Mathematica.
One of the differences is that the Apply function in Mathematica
replaces the head of the expression (the "car" in Scheme), while the
"apply" function in Scheme includes the "car" as one of the arguments.
That is, (apply + `(g a b)) becomes (+ g a b) while in Mathematica
Apply[Plus, g[a, b]] becomes Plus[a, b]. Additional arguments are also
treated differently, but not in a way that reflects fundamental
differences between the languages.
> Note that the reference does not mention the *important* detail that
> this is true *only* if g[x_,y_] or some similar pattern is not defined.
> If g[x_,y_] *is* defined, then the result of this calculation is
> different--if the pattern results in a list of items, than those items
> are fed to Plus: Plus[item1,item2,.....], and perhaps that will
> eventually result in addition.
>
> This is quite different from the behavior of "apply" in a functional
> language like Lisp or Scheme, where the g[a,b] would refer to some
> computation to do, and would *always* be done (or cause an error)
> before trying to apply the function Plus. The pattern matching behavior
> of Mathematica causes its Apply to differ in a quite surprising way.
Again, unless I have misunderstood something, I don't think this is
true.
While it is correct that (g a b) in (apply + (g a b)) will refer to a
procedure g that will be evaluated before applying +, the same is true
of Mathematica. That is, the g[a, b] in Apply[Plus, g[a, b]] refers to
a procedure g that will be evaluated in Mathematica before Plus is
applied. This evaluation order is used by all of the programming
languages that you mentioned, and is described for Mathematica in the
section 2.5 and appendix A.4 of the reference manual.
Also, since (g a b) might be quoted, as in (apply + `(g a b)), it isn't
entirely true that this procedure will always be evaluated in Scheme.
The purpose of quoting in Scheme is to inhibit evaluation. A similar
effect can be achieved in Mathematica using Unevaluated. That is,
Apply[Plus, Unevaluated[g[a, b]]] will apply Plus to the arguments a
and b even if g[a, b] might otherwise evaluate to something other than
itself.
> I think the desire to "declare variable types" arises from an
> underlying desire to program Mathematica in a procedural or functional
> way. However, Mathematica is, at its heart, a pattern-matching system.
> Whether that is better or worse than a functional or procedural style
> depends on both the particular problem you are trying to solve, and on
> your particular aesthetic approach to problem solving.
Actually, Mathematica at its heart is a functional language, much like
Lisp or Scheme. Pattern matching is the mechanism that is used for
locating procedures, but it isn't used in any non-trivial way in the
examples that you mentioned. Your comments seem to be about evaluation
order rather than about pattern matching, but evaluation order is
essentially the same in Mathematica as it is in most other languages,
and the connection between these things and variable typing escapes me.
Regarding:
> I often find its
> behavior puzzling or frustrating.
could you give some other examples of things that you find puzzling?
Some specific examples might help to eliminate any ambiguity.
Dave Withoff
Wolfram Research