Re: declaring integers

*To*: mathgroup at smc.vnet.net*Subject*: [mg13063] Re: declaring integers*From*: jaoswald at fas.harvard.edu (Joseph Oswald)*Date*: Sat, 4 Jul 1998 16:45:04 -0400*Organization*: Harvard University, Cambridge, Massachusetts*References*: <199806280651.CAA24297@smc.vnet.net.> <6nc6oe$7oe$1@dragonfly.wolfram.com>*Sender*: owner-wri-mathgroup at wolfram.com

In article <6nc6oe$7oe$1 at dragonfly.wolfram.com>, Sean Ross <seanross at worldnet.att.net> wrote: In response to Carlos Wexler's question >> How can one declare m to be integer? There has to be a way! In Maple it >> is rather easy and the expected behavior is obtained. I cannot believe >> that it is not possible to accomplish the same in Mathematica as well. > In short, you can't. There is no variable typing in mathematica. The >only way are work around patern matchings and transformation rules that >are specific to each problem. For example, you can define n/;Sin[n ... >Certainly the variable typing that you (and I) are after is radically >different from the variable typing done by Fortran or C++, which is for >purposes of memory allocation and interpretation. I think this response is pretty much accurate. I think it might be more instructive to go further, and to recognize that the idea of "variable typing" is the product of a different school of design than the "pattern matching" approach of Mathematica. 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. 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. I have been somewhat vague in my terms, as the internals of Mathematica are not well exposed to the user. But I think I have, at least in an operational sense, described this accurately. 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. 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. 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. Pattern matching is obviously better for some things, but, I think, also obviously not better for *all* things. One has to watch out when trying to use Mathematica in a way contrary to its design. For the things I do, pattern matching is rarely what I want. I want to use Mathematica for the numerical methods and special functions, which I hope are written better in Mathematica than I could write myself. However, numerical computation is only the last stage of what Mathematica does when you type something in, so I often find its behavior puzzling or frustrating. I hope this is somewhat enlightening. --Joe Oswald