Re: Types in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg62986] Re: Types in Mathematica*From*: "Steven T. Hatton" <hattons at globalsymmetry.com>*Date*: Sat, 10 Dec 2005 06:02:55 -0500 (EST)*References*: <dn22fb$kum$1@smc.vnet.net> <200512081442.jB8EgCda002721@ljosalfr.globalsymmetry.com> <F44AB4A1-92CA-49D7-ABDD-E94D8270B8EC@jeol.com> <200512081419.17348.hattons@globalsymmetry.com> <dnbmt9$5qf$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Sseziwa Mukasa wrote: > > On Dec 8, 2005, at 2:19 PM, Steven T. Hatton wrote: [...] > But of what use is that knowledge when compared to similar facilities > in other languages (Java Collections, Ada Generics (or rather Ada > libraries using Ada Generics), etc)? In my opinion it's better to > understand the model than the implementation. And yes, I'm aware > that Java Collections and Ada Generics do not map directly to the > STL, but the STL is a particular implementation of a more general > idea of which collections and generics are also a part. In Java you don't need to have a very deep understanding of the runtime structure for most purposes. But then again, Java is not a high performance language - regardless of silliness you will find comparing "C++" "malloc" to Java. Such blather is exceptionally silly when one stops to consider that Java is implemented in C and C++. I don't want to go too far off topic, so just let me say, C++ was designed to be, and is "close to the metal". If you don't understand the runtime structure of STL collections, you will eventually shoot yourself in the foot. Something will move out from under your reference, and you will find yourself accessing something you have no business accessing. >> But a Complex will always have a real and an imaginary component. >> A Rational >> will always have a numerator and a denominator. > > And a List always contains zero or more expressions. I don't see that to be containment in the same sense as a Complex contains its values. I don't know about the physical implementation, but it seems more meaningful to compare the value returned by Length[list] to the data held in an expression/symbol with the head Complex. Even if we do view an expression with the head List as a data structure containing elements (often called arguments), we are still able to describe it in terms of the functions which can operate on it, as well as the data abstraction it represents. When using expressions to represent ADTs we usually don't want to simply extract values using Part. We want to treat it as if we do not know the internal structure. We only know the interface. >> The point is that knowing that an atom has head Complex tells me what >> kind of thing it is at the user level. > > I guess I don't understand why this is any different from things with > head List. You cannot extract the components of an expression with head Complex using Part[]. You have to "ask nicely". For Lists, I believe that Part[] /is/ "asking nicely". >> I'm not sure it's meaningful/useful to assign a type to an atom >> beyond what is >> already implied. > > I meant that I can assign a type to things that aren't atoms like > Integer[1] or {1,2,3}. Conceptually, perhaps, but when I talk about assigning a type in this context, I usually mean making an actual assignment (declaration). I just found this and have only glanced at it, but I believe it will give a good context for further discussion on this matter: http://library.wolfram.com/infocenter/Conferences/4680/ >> Certainly a valid observation worth considering when using Complex >> numbers. >> Even more surprizing to the uninitiated might be Head[Arg[1+I]]. > > I still consider cases like this to be artifacts of the evaluator. > That the evaluator rewrites the expression for Arg[1+I] doesn't make > its head surprising. What determines (holds) the value of Arg[1+I]? Where does it "live"? >> I am coming to realize there is another dimension worth considering >> when >> trying to identify the essential abstract nature of Mathematica. >> We have >> expressions which have a head and zero or more "arguments", and we >> have >> symbols capable of holding transformation rules applicable to the >> symbol. > > I prefer to think of the rewrite rules as just being given in the > same way as axioms are just given, symbols aren't necessary. > Similarly creating new rules can be thought of as stating theorems > (but significantly not proving them) and they just get added to the > preexisting axioms. This analogy is unintentionally wandering a > little to close to some of the New Kind of Science ideas but it was > the first that came to mind. I don't know about the analogy of axioms, but I certainly agree that they are simply put there. You might find this interesting: http://www.nomic.net/~nomicwiki/index.php/GameOfNomic My point in talking about multiple dimensions is to try to categorize the kinds of stuff that can be associated (attached to) a symbol. These might be viewed similarly to how domains in relational databases are viewed. Values seem to from a 2D axis with axis representing OwnValues at the origin between UpValues and DownValues (though OwnValues seem to take precedence over UpValues,) and SubValues describing an axis orthogonal to the first. UpValues DownValues OwnValues SubValues Arguments (elements) Dr. Mader describes options as named arguments (implying order independence). Options Head Attributes internal data messages Context (symbol is probably best understood as a fully qualified name.) >> The four types of values that I know of which can be associated >> with a symbol >> are UpValues, OwnValues, DownValues, and SubValues, all of which are >> expressions of one form or another. The behavior of Mathematica >> seems to be >> the Cartesian product of the value dimension, if you will, and the >> expression >> dimension. > > Or perhaps a breadth first search along a kind of tree structure (or > perhaps it's more properly a directed graph) formed by this product. Expressions certainly have a tree structure in as much as the part specifications can be viewed as addresses into a tree. It does seem that a symbol can appear multiple times in this tree. I'm not sure if the evaluator will jump from one subtree to another without following a strict traversal. It seems to be rewriting the expression tree as it evaluates it, but does it ever jump to a location that is not an ancestor or descendent of the current location? -- 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/