[Date Index] [Thread Index] [Author Index]

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