Re: Types in Mathematica thread

*To*: mathgroup at smc.vnet.net*Subject*: [mg62778] Re: Types in Mathematica thread*From*: "Steven T. Hatton" <hattons at globalsymmetry.com>*Date*: Mon, 5 Dec 2005 03:37:32 -0500 (EST)*References*: <dmp9na$hi2$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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/. :( 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? > 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++? > 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. > 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? > 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. > 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. > > 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. > 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. 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 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf 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++. -- The Mathematica Wiki: http://www.mathematica-users.org/ Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html Math for the WWW: http://www.w3.org/Math/

**Re: Re: Types in Mathematica**

**Re: Types in Mathematica thread**

**Types in Mathematica thread**

**Re: Types in Mathematica thread**