Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62956] Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Fri, 9 Dec 2005 05:10:36 -0500 (EST)
- References: <dn22fb$kum$1@smc.vnet.net> <200512081442.jB8EgCda002721@ljosalfr.globalsymmetry.com> <F44AB4A1-92CA-49D7-ABDD-E94D8270B8EC@jeol.com>
- Sender: owner-wri-mathgroup at wolfram.com
On Thursday 08 December 2005 11:48, Sseziwa Mukasa wrote: I hope it's OK that I put this back into mathgroup. It doesn't seem to contain anything of a personal nature, nor anything else inappropriate for the list. > On Dec 8, 2005, at 9:42 AM, Steven T. Hatton wrote: [...] Looks as if we've both lost the original point we were debating. > I'm not really concerned with what the machine representation of > Mathematica's structures are internally, I'm interested in a > representation that allows me to reason about programs correctly. I find it to often be the case that an understanding of internal representation is helpful in reasoning about how to use the language. It certainly helps me contemplate expressions in Mathematica to understand them as trees of pointers whose leaves are atoms. > Similarly were I using a LISP machine as my processor but writing > programs in C that are passed through a compiler written in LISP I > would be similarly uninterested in how the compiler represented C > structures, or what the machine native structures of the compiler > program looked like, as long as it behaved in a manner conforming to > the C specification. I will take that as in indication that you do not have a lot of C++ experience. Before I really focused on C++ I would have said the same thing. Now I realize that C++ requires a certain amount of understanding at the machine level. > > One might even draw a parallel to C++ and assembler > > where the generalized input form of Mathematica corresponds to C++ > > source > > code, and internal form corresponds to assembler instructions. > > Agreed, I think where we'd disagree is in the importance of the > mapping of C++ source code to assembly. I've never spent much time looking at the assembly code produced by compiling C++, but there are certainly times when understanding how the sourcecode is represented in the compiled result helps to solve problems and/or increase efficiency. As far as understanding the STL, I see no way to gain more than a vague notion of how it works without understanding the runtime structure of the realized collections. > > The point was that Atoms in C++ represent the fundamental units of > > data > > storage. > > C++ has atoms? This is a genuine question prompted by laziness in > not wanting to read through a specification document to find out. Sorry, that was my mistake. I meant to say Mathematica Atoms. > > The head of an atom is a means of identifying its type, but the > > "type" really has to do what "what's in it". > > Doesn't what's in it have to do with the physical machine, I believe > that Intel CPUs internally use some form of 80 bit floating point > format which is converted back and forth to 64 bit constructs when > doing double precision calculations. When you execute a program on > an actual machine then what's in it is really an 80 bit value, > regardless of what the head says. But a Complex will always have a real and an imaginary component. A Rational will always have a numerator and a denominator. I didn't intend the actual physical representation of the atom in memory. It really doesn't matter if, say, complex were stored as an angle and a magnitude, or or as a real part and an imaginary part, so long as I could recover the real and imaginary parts. The point is that knowing that an atom has head Complex tells me what kind of thing it is at the user level. > > That is to say, knowing that an expression has the > > head List does not tell us the nature of what is in the list. > > I know what's in a list, zero or more expressions. I can ask if the > expressions are atomic and if it is important I can assign types to > the atoms by their heads. In fact it's not even necessary that they > be atoms because I can still unambiguously assign a type. I'm not sure it's meaningful/useful to assign a type to an atom beyond what is already implied. > > Knowing that > > an expression has the head Complex, for example, tells us that we can > > extract exactly two meaningful values from it, and how to extract > > these > > values (assuming we know the Mathematica rules for Complex). > > Actually you don't know the types of the values from the head Complex > beyond that they belong to the Numeric class anymore than you know > the types of the elements of a List, if there are any, beyond that > they are of the class expression. > > In[117]:= > Head[5+6. I] > Head[Re[5+6. I]] > Head[Im[5+6. I]] > > Out[117]= > Complex > > Out[118]= > Integer > > Out[119]= > Real Certainly a valid observation worth considering when using Complex numbers. Even more surprizing to the uninitiated might be Head[Arg[1+I]]. > >> So what's the difficulty? > > > > Integer[1]===1 for starters. But I really quoted the statement to > > affirm my > > original position that Mathematica does have a rudementry type system. > > I still fail to see the problem Integer[1] is of the form Integer > [Integer[(something that's not very important)]] and 1 is of the form > Integer[(something that's not very important except that it behaves > as 1, whatever that is)]. But that is something learned from experience, not from reading A.9.2 > My larger point, which is yet another diversion from the point of the > thread was that because there is only one type of thing in > Mathematica and it is the same thing that the evaluator uses as what > the user reasons about then the ability to write self modifying code > in Mathematica itself is a necessary consequence. I didn't suggest > this was a good idea, merely that it was a hint as to the nature of > type in Mathematica. There are cases when one benefits by adding downvalues to a symbol during evaluation. The canonical example is "functions that remember values" in recursive algorithms. > > I do not agree with the assertion that there is only one type of > > thing in > > Mathematica. To say everything is an expression fails to address the > > distinct nature of atomic objects with distinct heads. It is > > meaningful > > and clear to consider atomic objects to have distinct types. > > To me it depends on your point of view. Viewed as system of rewrite > rules, there are only two things which compose Mathematica: > expressions of form Head[Argument....] and transformation rules which > map one value of Head[Argument...] onto another. 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. 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. Steven