MathGroup Archive 1998

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: processing {x,y,z} data
  • Next by Date: kernel problem
  • Previous by thread: Re: processing {x,y,z} data
  • Next by thread: Re: Re: declaring integers