[Date Index]
[Thread Index]
[Author Index]
Types in Mathematica thread
*To*: mathgroup at smc.vnet.net
*Subject*: [mg62708] Types in Mathematica thread
*From*: "Kris Carlson" <carlsonkw at comcast.net>
*Date*: Fri, 2 Dec 2005 05:53:06 -0500 (EST)
*Sender*: owner-wri-mathgroup at wolfram.com
Steve Hatton's post [mg62698] Re: Types in Mathematica:
I believe most people here will agree that Mathematica is not a strongly
typed programming language. In order for us to believe such a thing, we
have to have a notion, however vague, of a strongly typed variant of
Mathematica. What I really wanted to get at in starting this thread is
what that strongly typed Mathematica might be, and what strengths and/or
flaws it would have.
Rather than trying to address each of the items listed below right now, I am
going to post them as potential points of discussion. I really cannot
address the questions myself without further thought.
What would a type system in Mathematica be?
What might be gained by having a type system in Mathematica?
What might be lost?
To what extent /does/ Mathematica have a type system?
To what extent can a type system be implemented within Mathematica without
modifying the language?
How would a type system in Mathematica be similar to one in another
language?
How would a type system in Mathematica differ from one in another language?
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. Please correct me where I'm wrong. A long
post but I'm trying to be thorough.
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].
2. Where the appropriate head is built in to Mathematica, arguments can be
type-tested via x_Integer, x_Real, etc., and in general, x_head.
3. The language provides for the easy creation of our own heads, as simply
as writing head[expr] (no error message!), which we would commonly do when
creating a datatype. These can be tested with x_head or Head[expr].
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.
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.)
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)
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.)
Mathematica must evaluate special- or narrow-case functions before more
general ones or the more general ones would shadow the narrower ones and
they would never be seen. Because syntactically Mathematica evaluates from
the 'inside out', we wrap the more specialized definitions within broader
ones: f[ g[x] ], where f is broader than g. Now quoting from Maeder (and
pardon giving it in extenso but I assume most of you don't have access to
M220 if I give just a pointer):
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
In[1]:= 1.1 + 2/3
Out[1]= 1.76667
and expect it to work.
The standard arithmetic operations are overloaded: they work with data of
many different types and perform conversions as necessary.
A Template for Overloading. To extend standard operators, such as Plus,
Times, and Power, for a new data type with head h use an upvalue
h /: x_h + y_h := plusHH[ x, y ]
where plusHH[ x, y ] is either an auxilary function you wrote, or a simple
one-line expression.
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.
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.
Kris
Prev by Date:
**Re: 3D Plot of frequency data**
Next by Date:
**Re: intermittent crash on numeric solution of elliptic integral**
Previous by thread:
**Re: 3D Plot of frequency data**
Next by thread:
**Re: Types in Mathematica thread**
| |