Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62957] Re: Types in Mathematica
- From: Sseziwa Mukasa <mukasa at jeol.com>
- Date: Fri, 9 Dec 2005 05:10:37 -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>
- Sender: owner-wri-mathgroup at wolfram.com
On Dec 8, 2005, at 2:19 PM, Steven T. Hatton wrote:
> 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.
At some point it looks like the list got dropped from recipients. I
wonder how many stalwarts are still along on this journey anyway.
>> 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.
True
> I will take that as in indication that you do not have a lot of C++
> experience.
I have not done any major programming in C++, but I did do some C++
coding predating the STL. Incidentally Mathematica is not my primary
programming environment; which is much closer to C++ than Mathematica
in spirit.
> 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.
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.
> 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.
> 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.
> 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}.
> 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.
> 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.
> 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.
Regards,
Ssezi