Re: Re: Re: Types in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg62904] Re: [mg62872] Re: Re: Types in Mathematica*From*: Sseziwa Mukasa <mukasa at jeol.com>*Date*: Thu, 8 Dec 2005 00:04:45 -0500 (EST)*References*: <dn22fb$kum$1@smc.vnet.net> <200512070411.XAA23826@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

On Dec 6, 2005, at 11:11 PM, Steven T. Hatton wrote: >> Fair enough but Head[{1,2,3}] is not Symbol. > > I would say that we have to be clear about what we mean by "Head > [{1,2,3}]". I meant the value of evaluating the expression. > At one level, it is nothing but a sequence of characters. When > Head[{1,2,3}] is evaluated, a downvalue is added to In That's a side effect of the evaluator, and can be suppressed anyway. I don't consider In and Out to be fundamental to the operation of Mathematica. In fact their existences is one of the areas in which Mathematica breaks with being purely functional but that's another issue. Others like Jon Harrop probably have far more intelligent things than me to say on that subject. > A.9.2 in the 5.2 Mathematica Book says "A Mathematica expression > internally > consists of a contiguous array of pointers, the first to the head, > and the > rest to its successive elements." I find that statement very > incomplete. I don't know why, it simply betrays Mathematica's LISP like roots, and as Daniel Lichtblau pointed out is to be read more as a model for reasoning than as to how Mathematica is actually implemented. At any rate in the purest forms of LISP that's all one has an atom, which is defined as an indivisible S-expression and a list which is an S- expression of two parts the first is called the head or car and the second a pointer to the rest of the list. I believe I read somewhere that Mathematica's representations of expressions are called M- expressions and were actually the intended syntax for LISP but for some reason S-expressions ended up being preferred. > In any case, (I believe) the leaves of an expression will be atoms > of one > kind or another. The atoms are (AFAIK) the only entities in > Mathematica > which hold data. Heads have values too, an atomic expression is simply one which you can't take apart any further, but the atomic expression 1 has a head in Mathematica and the head has a value. The fact that we display and write 1 instead of Integer[1] is syntactic sugar as far as I'm concerned because at that point we are typically more interested in the interpreting Integer[1] as a value which is the result of some computation which is really what one is interested in. > there are clearly different types of atomic expressions. Especially if you consider the heads of atoms as defining their type, which is why I think that is a useful paradigm for reasoning about types in Mathematica. The fact that Head[Sqrt[2]] isn't Sqrt as Jon Harrop pointed out seems to me more an artifact of the evaluator than a problem with Mathematica. >> There are different kinds of statements in C++ of which expressions >> are but one class (http://cpp.comsci.us/syntax/). There are no >> different kinds of expressions in Mathematica all have the same >> structure Head[Arguments...]. > > How is that different from saying there are atomic expressions and > composite > expressions in Mathematica? Is 1 of the form Head[Arguments...]? However the expression Integer[1] is represented internally, and for efficiency's sake it's hard to imagine that it occupies multiple words of machine storage, is irrelevant as to how one should reason about Mathematica programs. It's also irrelevant that the Notebook Interface displays it as 1 instead of Integer[1]. The question is whether one can reason about a program correctly, it seems to me ambiguity can be best avoided by understanding 1 to be a) atomic and b) representing Integer[1]. >>> What confusion? >> >> The confusion over exactly what constitutes a type in Mathematica. > > Since there is no formal definition, it is strictly a matter of > opinion, > and/or convention. Since there seems to be little in the way of > commonly > agreed upon convention, we are stuck with relying on opinion. But as you pointed out yourself Wolfram documents exactly what everything in Mathematica is in A.9.2, it's an expression. Some expressions are atomic, and if you want to assign a "type" to the atoms other than expression the best candidate I can see is the head. >> You can't inspect the structure of the function in C++ because it's a >> function definition and there is no facility for programmatically >> inspecting the contents of a definition in C++. In Mathematica the >> contents are stored as an expression in the DownValues which can be >> modified as any other expression in Mathematica sans restrictions. > > But that really seems to rely on the fact that C++ is a compiled > language, > whereas Mathematica is interpreted. I don't think that matters. The distinction that's important is between statements and expressions, LISP like languages do not have a statement type and it is that fact that allows "functions" to be treated as a first class types. > I believe there are important distinction between the way C++ and > Mathematica > support operator overloading. I do too, but I don't think we agree on what the distinction is. >> For the sake of brevity and in the correct context clarity, it helps >> to refer to things like Plus[a_,b_] as a function or operator and For >> [...] as a statement but the truth is in Mathematica they are both >> expressions and equivalent in that sense. Making the distinction may >> be useful to thinking about problems from the programmer's >> perspective but there is nothing within Mathematica itself that >> forces that distinction unlike in C++ where function+(a,b) and for >> (...){} are different. > > I don't follow. I can write a function > > Vector3f plus(const Vecotr3f& v1, const Vecotr3f& v1) { > return Vector3f(v1.x + v2.x, v1.y + v2.y, v1.z + v2.z); > } > > and > > Vector3f operaotr+(const Vecotr3f& v1, const Vecotr3f& v1) { > return plus(v1,v2); > } > > Then write va + vb to add two Vector3f objects. How does that > compare to > overloading + in Mathematica? It's roughly equivalent except in Mathematica I can programmatically rewrite the rules for + whereas there is no such facility in C++. I suppose you can consider that an artifact of the fact that C++ is compiled (actually is that a requirement? http://root.cern.ch/root/ Cint.html) but I think the real reason for the difference is that operator+ is a statement in C++ and there are no facilities for programmatically altering statements. > When trying to represent an ensamble of interacting physical > objects, I find > it useful to be able to maintain state. In OOP that is fairly > straightforward. This is why I like development libraries such as > OpenSceneGraph. I've done similar things with Mathematica, but it > has not > been quite as easy. I've had similar problems, but usually I found that reorganization of the problem either allowed the writing of expressions that could compute a representation of state when necessary, and at no more expense than maintaining a state variable, or obviated the need altogether. When translating programs implemented in other languages or interacting with such programs I've found that naively trying to use that paradigm in Mathematica leads to difficult to maintain code and often it's better to just rewrite the algorithm in a different style. One example are divide and conquer algorithms for linear algebra problems. Typically they are implemented with state variables that keep track of indices of submatrices and operations like multiplying a matrix against a submatrix of a larger one. I've found that recasting the algorithm as functions which do basic operations and encasing them in structures like FoldList, Nest etc. which construct the final result from the submatrices leads to clearer, if not necessarily more efficient, Mathematica code. On the other hand, I've noticed a trend in OO graphics programs for defining 3 and 4D vectors and matrices as classes and then overloading +,-,* etc. which leads to inefficient code like t=a*b; d=c*t instead of d=a*b*c which is one of the problems that Blitz++ tries to address. As we've both noticed Blitz++ addresses this problem by using C++ templates (and the CPP) to effectively convert statements to expressions which can be optimized for efficiency similar to the fundamental difference between operator overloading in c++ and Mathematica. > Part of the problem is that I really didn't understand > Mathematica well when I started using things such as Dr. Maeder's > Classes > package. I have heard a lot about Dr. Maeder's package on this mailing list but I have not personally used it or investigated it much. Regards, Ssezi

**References**:**Re: Re: Types in Mathematica***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>

**Re: Re: Re: Types in Mathematica, a practical example**

**Re: Re: Types in Mathematica thread**

**Re: Re: Types in Mathematica**

**Re: Re: Re: Types in Mathematica**