MathGroup Archive 2005

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

Search the Archive

Re: Types in Mathematica thread

  • To: mathgroup at
  • Subject: [mg62781] Re: [mg62708] Types in Mathematica thread
  • From: Kristen W Carlson <carlsonkw at>
  • Date: Mon, 5 Dec 2005 03:37:46 -0500 (EST)
  • References: <dmp9na$hi2$> <>
  • Sender: owner-wri-mathgroup at

On 12/4/05, Steven T. Hatton <hattons at> wrote:
> <posted & mailed>
> OK, this is my third attempt to write a reply to this message.  There is
> something to be said for not using pre-release software for /everything/.
> :(

And I'm getting used to Google Gmail and sent the last post to you
directly, and in rich text format :(
> I wrote more in my previous posts on just about every point herein.
> Unfortunately, the latest (at your own peril) bits for my usenet client
> seem to be a bit buggy, thus I have lost my previous posts.
> Kris Carlson wrote:
> > My message:
> >
> > Hmmm, most of you know more than I do about Mathematica and programming
> > but it seems this thread missed some of the mark. I'm harking to Murray's
> > email because he gave the best answer.
> Do you have a usenet message ID for that?

Here is his post, which was in response to yours:

Every function you write can be made to type its variables.  E.g.,

   f[x_?NumberQ] := x^2

   g[lis_List] := Most[lis]

   normalize[v_ /; VectorQ[v, NumberQ]] := v/Norm[v]

use: the built-in NumberQ function to test a property of the input x,
and the pattern test for having a head of List, respectively.

Sections 2.3.4 and 2.3.5 of The Mathematica Book are two places to
find this subject discussed.

I don't understand why you don't have access to search in your Linux
installation: Whenever I've installed in Linux and selected to install
the documentation, the usual HelpBrowser becomes available, including
its search capability.

The difficulty is, of course, in figuring out what to search for.  To
find section 2.3.4, I searched for "Types" in the MasterIndex of the
HelpBrowser; the relevant entry was for "Types, using patterns to
constrain".  To find section 2.3.5, I looked for "Constraints"; the
relevant entry was for "Constraints, on transformation rules, Condition".

Murray Eisenberg                     murray at
Mathematics & Statistics Dept.
Lederle Graduate Research Tower      phone 413 549-1020 (H)
University of Massachusetts                413 545-2859 (W)
710 North Pleasant Street            fax   413 545-1801
Amherst, MA 01003-9305

> > 1. Everything is an expression, which is wonderful in its simplicity. Thus
> > since everything is of the form head[body], everything is typed in at
> > least one way via the head, and everything can be tested for its type, eg,
> > with Head[expr].
> How does that differ from type checking in such languages as C++?

I don't know C++; guessing: not as universal? Not as easy to check?
Not as flexible? Not as easy to convert via Apply[newhead, expr]?

But see comment at the bottom; we are not railing against C++, or
stressing the utility of Mathematica outside of the context of doing
mathematical science.
> > 4. There are other built in type tests that rely on other tests than Head:
> > NumberQ, NumericQ, IntegerQ, EvenQ, OddQ, PrimeQ; ArrayQ, VectorQ, MatrixQ
> > (for these there are nice element tests, too), PolynomialQ (element
> > tests). There are built in "structural" tests, and I mention these for the
> > reason mentioned next: SameQ, UnsameQ, OrderedQ, MemberQ, FreeQ, MatchQ,
> > ValueQ, AtomQ. With these, argument-testing syntax is f[x_?testQ]. q.v.
> > Section 2.3.5.
> RealQ?  Ironically that one seems to be missing.  Probably an intentional
> ommission.

Interesting question; here is relevant Helptext:

_Real can be used to stand for a real number in a pattern.

One way to find out the type of a number in Mathematica is just to
pick out its head using Head[expr]. For many purposes, however, it is
better to use functions like IntegerQ which explicitly test for
particular types. Functions like this are set up to return True if
their argument is manifestly of the required type, and to return False
otherwise. As a result, IntegerQ[x] will give False, unless x has an
explicit integer value.

& I tried:



Nobody home.





I can't think of why there is no RealQ predicate, but there is _Real,
a pattern test via the head.

> > 5. Mathematica excels in pattern-matching, which in one form or another
> > (little pun there), is what all these other tests do. There are many
> > built-in high level pattern matching functions and devices. Since we can
> > write our own pattern tests, data typing is limited only by our own
> > ingenuity. Thus, overall, the type-testing and automatic conversion
> > facility in Mathematica exceeds what I have seen rigidly implemented in
> > other languages (I hasten to say I am not broadly educated in other
> > languages.)
> What distinguishes Mathematica from compiled languages is largely that these
> mechanism are selfinflicted.  That is, Mathematica applies its pattern
> matching to Mathematica code as it is evaluated.  In C++ the only places
> where such a thing is applicable are in the CPP (the root of all C++ evil),
> and templates, but only at (pre)compile time.
> In a sense, Mathematica is like a scripting language along the lines of
> bash, JavaScript, Perl, etc.  All of these languages can generate and or
> modify code as they interpret code.  They all have pattern matching and
> substitution rules of one form or another.  And of course, Lisp must be
> mentioned in this context, though it is not generally considered a
> scripting language.
> > 6. Taking a statement from Maeder a bit out of context, "In general, such
> > [devices] are powerful tools for proving the correctness of an
> > implementation." He said it in regard to constructors and selectors acting
> > on datatypes. (M220 v1.1, Datatypes)
> Can you clarify what you mean by "M220 v1.1, Datatypes"?  I assume that
> relates to the Mathematica training course.  Are you referring to text
> distributed with the course?

Sorry, yes. Incidentally, the new Mathematica Indexer should imho also
return text from these courses' manuals & exercises; just a page or
two. Then that's informative and advertises the value of the courses.
> > 7. Downvalues are "default" function structures, or "common" functions, or
> > "built-in function" structures, or "broadest class" functions. Upvalues
> > are "special case" functions, or "user-defined" functions / modifications
> > of built-in or default functions, or "narrow-case" functions, or
> > "context-dependent" functions. (This latter is especially important for AI
> > and for a general understanding of the universe.)
> Upvalues are evaluated when the associated symbol is encountered as an
> argument.  This precedes the evaluation of downvalues of the function in
> which the argument appears.

 I am not sure of upvalues are ordered according
> to specificity in the way downvalues are.  I would expect them to be, but I
> really don't recall having read that they are.

To be clearer: Mathematica evaluates user-defined functions before
built-ins, on the principle / assumption that the built-ins are more
general than the user's. From 2.6.4:

"As discussed in Section 2.5.10, you can associate definitions with
symbols either as upvalues or downvalues. Mathematica always tries
upvalue definitions before downvalue ones."

But we can order upvalues and downvalues to be applied in the order we
believe efficacious (qv 2.5.13)
> > What is overloading? Mathematica does not provide functions such as
> > plusII[ i1_Integer, i2_Integer], plusRR[ r1_Real, r2_Real ], plusRI[
> > r_Real, i_Integer }, and so forth. You would not be using it if it did
> > [because it would be a big pain in the rear like we find in other
> > "strongly typed" languages--KWC]. You simply write
> C++ has a very powerful function and operator overloading mechanism. You
> certainly can overload, say, + for vectors.  You can overload it using
> templates which makes the overload definition apply to any abstraction
> which matches the template structure.

Maybe Maeder got the idea from what he saw in C++.
> >
> > In[1]:= 1.1 + 2/3
> >
> > Out[1]= 1.76667
> >
> >
> > and expect it to work.
> It depends what exactly you expect. C++ can be fairly tricky regarding
> numerical type conversions.  But so can Mathematica.  There are situations
> where you have to treat results as complex numbers, for example, when all
> your inputs are "real", and typical usage in math would suggest a real
> value result.
> > For automatic type conversion, use definitions like
> >
> >
> > h /: x_h + i_Integer := plusHI[ x, i ]
> >
> >
> > or reuse existing code,
> >
> >
> > h /: x_h + i_Integer := x + makeH[ i ]
> >
> >
> > where makeH[ i ] is a constructor (type converter) that turns in integer i
> > into a h data element.
> One thing you can't do (AFAIK) is type conversion based on accepted
> parameter types in a function call.  For example, in C++, you could create
> a Date class that automatically converts to a string when passed to a
> function taking an argument of type string.

Took a shot in my previous post at something like this you said. I
think this is exactly what Maeder is getting at. Maybe this, as a

makeString[arg1, arg2, datefunction[x_Integer, y_Integer, z_Integer]]
:= makeString[arg1, arg2, Map[ToString, List @@ dateFunction[x, y, z]]
> > 8. All the above being said, my conclusion is that Mathematica is a
> > superior language designed and implemented by superior intellects. As
> > Andrzej just said, post a problem to MathGroup before assuming Mathematica
> > can't do something.
> You really have to put that in perspective.  Almost every program I use, to
> include Mathematica is written in either C or C++.  Some have a
> considerable amount of additional code written in some form of an
> interpreted language.  For example Mozilla has a lot of JavaScript built
> in. Emacs is largely implemented in Lisp, but the Lisp interpreter itself
> is written in C.  Even Java is written in C and C++.  Mathematica is very
> specialized, and is not well suited to creating such facilities as user
> interfaces.  In many ways its graphics support is fairly limited in
> comparison to development environments such as OpenSceneGraph.

OK, I agree; overall; but I don't think people come to Mathematica to
do the type of GUI-driven Rapid Application Development that I did in
VB. ****Within the context of _doing mathematical science_ Mathematica
is open-ended and very high-level compared to any other
language/environment I've seen.**** A superior language, like C++.

Agree on the graphics capabilities; they are superb in one respect but
you're right, very specialized, and limited in others.
> In the C++ Standard Library there are 57 (IIRC) generic algorithms for
> operating on generic collections.  Many of these have direct parallels in
> Mathematica.  Also have a look at section 5.2.1 of
> As I've said, Mathematica is a very specialized language.  To compare it to
> C++ in terms of superiority would not make sense.  If every program written
> in C++ failed to function at the same time, the entire technological
> infrastructure of the planet would come to a screeching halt.  The same
> cannot be said of Mathematica.  OTOH, if I want to solve differential
> equations using familiar symbols and relatively easy to use constructs, I
> would not turn to C++.  If I wanted to write a program to do that, I most
> certainly /would/ use C++.

Meant "Mathematica"?

I hope nothing I said sounded like disparaging the C family. Civ would
come to a halt without it or something like it. And mathematical
science is pretty important, too. RED--"Rapid Experiment Design"--in
mathematical science is what Mathematica is designed for. And having
spent some hours the last few days attempting to parse the Lisp code
of a world leader in classifier systems (AI) (thankfully with his
help), this opinion is fresh in my mind. Before we assume Mathematica
can't do something _in that context_, I think we should let MathGroup
take a shot at it.

Onward and upward,

> --
> The Mathematica Wiki:
> Math for Comp Sci
> Math for the WWW:

  • Prev by Date: Re: Types in Mathematica thread
  • Next by Date: Re: How to draw elliptical curve
  • Previous by thread: Re: Types in Mathematica thread
  • Next by thread: Re: Re: Types in Mathematica thread