MathGroup Archive 2010

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

Search the Archive

Re: Mathematica daily WTF

  • To: mathgroup at
  • Subject: [mg115032] Re: Mathematica daily WTF
  • From: David Bailey <dave at>
  • Date: Wed, 29 Dec 2010 05:55:56 -0500 (EST)
  • References: <ifcnhn$bai$>

On 28/12/2010 13:09, Murray Eisenberg wrote:
> Copying attributes seems to be simple (or am I missing something?):
>     mysin = Sin;
>     Attributes[mysin]
> {}
>     SetAttributes[mysin, Attributes[Sin]]
>     Attributes[mysin]
> {Listable, NumericFunction, Protected}
> But subsequent removal of attributes can require another step, as here,
> where Protected is one of the attributes.
>     Unprotect[mysin]
> {mysin}
>     Remove[mysin]
> On 12/26/2010 4:02 AM, kj wrote:
>> In<if1o3h$p60$1 at>   Bill Rowe<readnews at>   writes:
>>> Adding more layers of abstraction won't change this behavior.
>>> Additional layers of abstraction simply obscures the fact that
>>> Set doesn't pass on attributes.
>> Our brains, yours and mine, are clearly deformed in very different
>> ways...
>> Mine has been deformed by programming languages other than Mathematica,
>> in which assignment does transfer everything, and where one common
>> way to exploit localization in a dynamic scope involves starting
>> out by copying the global value to the local value (which is
>> subsequently modified, with the knowledge that all these modifications
>> will be effectively rolled back at the end of the dynamic scoping
>> construct).  Hence, it is definitely surprising to someone with
>> this experience to learn that one can't do this with Mathematica's
>> so-called "dynamic scoping" construct, namely Block.  Why?  Well,
>> it's ***logically obvious***, isn't it:  Mathematica's "initialization"
>> doesn't transfer most of a symbol's values to the LHS of the
>> "assignment".  (Why would anyone be surprised, I wonder...)  In
>> fact, this limitation severely reduces the usefulness of dynamic
>> scoping in Mathematica to the case where localization equals "clean
>> slate".
>> The fact that these limitations of Mathematica's so-called "assignment"
>> are true not only of the initialization clause of a Block statement,
>> but actually true *everywhere* in Mathematica is only more WTF-worthy,
>> not less.
>> In fact, I don't know of any simple way to fully copy one variable
>> to another in Mathematica.  It can be done, I'm sure, but not
>> succinctly, AFAIK.
>> Here's another hilarious bit:
>> Block[{Sin = Sin},
>>    Print[N[Sin[Pi/4]]];
>>    Print[Messages[Sin]];
>> ]
>> Sin[0.785398]
>> {HoldPattern[Sin::usage]:>Sin[z] gives the sine of z. }
>> Indeed, as described already, assigning Sin to Sin in the Block's
>> initialization clause gets me nothing useful, the local Sin is dead
>> as a doornail, and yet it still carries around its now totally
>> inaccurate, hence useless, usage message!  That's touching.  (To
>> be precise, the initialization shown above is not responsible for
>> the persistence of the messages; one would get exactly the same
>> results if the initialization clause had been {Sin} instead of
>> {Sin=Sin}.)  The utility of keeping the messages around when
>> everything else about the symbol has been stripped away is beyond
>> me.
>> Bottom-line: the meanings that Mathematica puts on of bread-and-butter
>> programming terms like "="/"assignment", "value", and "dynamic
>> scope" are entirely sui-generis, and therefore the Mathematica
>> documentation should at least show the user the courtesy of making
>> this perfectly clear, rather than let him/her figure all this out
>> through hard knocks (in the form of "things that *should* work but
>> don't").
>> ~kj


I can't see why programmers would assume that the attributes of a symbol 
would, or would not, get copied with an assignment, because languages 
like C++ or Fortran don't have any equivalent of attributes. LISP does 
have property lists, and as far as I can remember, these also don't get 
copied with assignment.

More generally, I don't think any language as powerful as Mathematica 
can be totally free of quirks, and once a language is well used (as 
Mathematica undoubtedly is!), it is rather antisocial to change these 

Copying attributes and usage messages would undoubtedly take additional 
machine cycles - even if neither was present - and does it really make 
sense to use those cycles on every assignment just to clean up contrived 
examples of this sort?

David Bailey

  • Prev by Date: Re: typesetting problems or bugs? need a professional stylesheet
  • Next by Date: Re: Solve : missing elims in the Mathematica 8 version
  • Previous by thread: Re: Mathematica daily WTF
  • Next by thread: Re: Mathematica daily WTF