Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62987] Re: Types in Mathematica
- From: Sseziwa Mukasa <mukasa at jeol.com>
- Date: Sat, 10 Dec 2005 06:02:56 -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> <-4qdnaBC0M37OgTeRVn-uQ@speakeasy.net>
- Sender: owner-wri-mathgroup at wolfram.com
On Dec 9, 2005, at 10:48 AM, Steven T. Hatton wrote: > > Sseziwa Mukasa wrote: >>> 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. You're right it's not exactly the same because Complex is an atom and a list is not. > expression/symbol with the head Complex. Only an expression can have the head Complex, a symbol has the head Symbol and to prevent confusion I think we should agree to keep that straight. > 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. Of which the abstraction is what? > 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. I don't think I agree with this, we know several things about Part with respect to expressions: Part cannot take anything beyond the 0th (head) element of atoms, Part returns a Message when the index is greater than the depth of the expression being taken apart, Part returns the expression corresponding to an argument of the larger expression when 0 < the second argument to part <= Depth[first argument]. If you consider the arguments to be internal structure then the behavior of Part makes it necessary that you treat expressions as if you know something about their internals. It also makes clear what an atom is: a Depth 0 object. > You cannot extract the components of an expression with head > Complex using > Part[]. Because by definition you cannot do that to any atom and an expression of the form Complex[_,_] is an atom. > You have to "ask nicely". For Lists, I believe that Part[] /is/ > "asking nicely". I don't consider this exceptional, all you have to do is distinguish the behavior of Part between things that are atoms and things that are not, all the rest follows logically. > 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/ Thank you for the pointer, I'll read it. > What determines (holds) the value of Arg[1+I]? The value of Arg[1+I] is Arg[1+I] there are also rewrite rules for equivalent expressions where equivalence is defined by expr1==expr2 being congruent to True eg: In[54]:= FullForm[Arg[1 + I]] Arg[1 + I] == Times[1/4, Pi] Out[54]//FullForm= Times[Rational[1,4],Pi] Out[55]= True. > Where does it "live"? In the space of arguments to the evaluator. Since there are rewrite rules associated with Arg one has to be careful about when they look at an Arg expression depending on what they want to do with it. Since all the rewrite expressions for Arg have the same value with respect to N[Arg[_]] then if one is concerned with the value the head is irrelevant, when one is interested in the Head though a Hold or Unevaluated must be used to prevent the expression from being rewritten. > You might find this interesting: > http://www.nomic.net/~nomicwiki/index.php/GameOfNomic I've run across it but it's been a while since I read Hofstader, thanks for the link. > 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. There are actually some very interesting theoretical on relations and how then end up being implemented in RDBMSes (short version, poorly). While we continue on our tour of programming languages the logic languages would be appropriate examples for reasoning about relations. And they too bear a strong relationship (pun not intended) to LISP like languages. > UpValues > DownValues > OwnValues > SubValues These things are side effects of the evaluator, like In and Out, not fundamental. They are very useful though because they describe expressions we can use to interact with the rewrite rules used by the evaluator itself. > Arguments (elements) > Dr. Mader describes options as named arguments (implying order > independence). > Options > > Head > Attributes Attributes are definitely an interesting beast, I'm not sure but I suspect they can be considered a special set of rules used by the evaluator. > internal data I'm not sure internal data is any more worth worrying about to a Mathematica programmer as a naked quark is to a nuclear engineer. > messages Message are just expressions, which is why you can trace on Message [___] to stop evaluation at a point a message is issued. Messages are not atomic. > Context (symbol is probably best understood as a fully qualified > name.) Likewise a Context is just another expression whose value is a side effect of the evaluator (in particular of Get[] and Needs[] expressions). To reason about these things is to reason about the rewrite rules of the evaluator, but is aside from the idea of types. Regards, Ssezi