MathGroup Archive 2005

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

Search the Archive

Re: Types in Mathematica

  • To: mathgroup at smc.vnet.net
  • Subject: [mg62296] Re: Types in Mathematica
  • From: John Doty <jpd at whispertel.LoseTheH.net>
  • Date: Sat, 19 Nov 2005 23:18:25 -0500 (EST)
  • References: <200511120833.DAA19252@smc.vnet.net> <43762529.7060603@math.umass.edu> <dl8s4g$n41$1@smc.vnet.net> <dl980q$r2a$1@smc.vnet.net> <200511140805.DAA00041@smc.vnet.net> <dlc96b$m81$1@smc.vnet.net> <dlhibt$5ki$1@smc.vnet.net> <dlkc76$pq0$1@smc.vnet.net> <dln160$geq$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Steven T. Hatton wrote:
> John Doty wrote:

>>Functional programming is not really built into the Mathematica
>>*language* at all: it is a matter of convention. For example:
>>
>>In[10]:= x_[s] ^:= Sin[x]
>>
>>In[11]:= Pi[s]
>>
>>Out[11]= 0
>>
>>Try defining an "argument" that operates on its "function" in any other
>>language.
> 
> 
> I can pass a function object to another function object in C++.  The passed
> functor (argument) can certainly modify the state of the object to which it
> is passed.
> 
> 

That's not what happens here. s is never "passed" to Pi: no 
transformation associated with Pi ever sees s. Instead, the evaluation 
engine recognizes a transformation, associated with s, that it can apply.

Analogies are only useful within bounds. The caloric theory of heat is 
perfectly good for some problems, but it is folly to push it too far: in 
the end you have to understand heat on its own terms, not by analogy 
with a fluid.

In the end, you have to understand a tool like Mathematica on its own 
terms: pushing analogies too far will simply mislead you. And if you 
insist on understanding by analogy, you'll never know what "too far" is.

-jpd


  • Prev by Date: Re: Types in Mathematica
  • Next by Date: Re: Random Normal deviates within compiled function?
  • Previous by thread: Re: Types in Mathematica
  • Next by thread: Re: Types in Mathematica