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/