[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
Prev by Date:
**Re: Types in Mathematica thread**
Next by Date:
**Re: Types in Mathematica**
Previous by thread:
**Re: Types in Mathematica**
Next by thread:
**Re: Types in Mathematica**
| |