Re: Mathematica daily something or other

*To*: mathgroup at smc.vnet.net*Subject*: [mg115001] Re: Mathematica daily something or other*From*: Daniel Lichtblau <danl at wolfram.com>*Date*: Tue, 28 Dec 2010 06:48:43 -0500 (EST)

----- Original Message ----- > From: "kj" <no.email at please.post> > To: mathgroup at smc.vnet.net > Sent: Sunday, December 26, 2010 3:02:12 AM > Subject: [mg114985] Re: Mathematica daily WTF > In <if1o3h$p60$1 at smc.vnet.net> Bill Rowe <readnews at sbcglobal.net> > 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). Is it common for other languages to have such things as Attributes, UpValues, and the like which might interact in complicated ways? I'm not sure the model you describe really exists. To be sure, I'm also not sure it does not exist. Just pointing out that these are complex semantics under discussion, and there might not be common analogous constructs in other languages. > 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". I am not convinced this qualifies as a serious reduction in functionality. More on that later. > 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. No, this simply means that Set has uniform semantics. That much is a good thing. Whether the semantics are expected and/or desirable is another question. > 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. In a block-like setting it can be done in an undocumented way. See below. > 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. > Here is what I get. Block[{Sin = Sin}, Print[N[Sin[Pi/4]]]; Print[Messages[Sin]];] Sin[0.7853981633974483] {} Offhand I do not know why you obtain that message stuff. One can in fact pass the usual Sin inside a block as below. Internal`InheritedBlock[{Sin}, Print[N[Sin[Pi/4]]]; Print[Messages[Sin]];] 0.7071067811865475 {} I will discuss some of this at the end. > 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 Behavior of Set, in particular in regards to (not) passing along attributes, is described in documentation for Set. It might be mentioned in the documentation pages for Attributes as well as the localization constructs such as Block and Module. Is that important? I don't know. I think this is the first time the issue has been brought up on MathGroup. As to the semantics of Set, are they not passing Attributes for a good reason? I don't know. Should there be perhaps a FullSet that does pass them? Same response: I simply do not know. I will again mention that if you think such things are warranted, you can make your opinion known through the various channels pointed out by myself or John Fultz. I think there is also a support at wolfram.com email address. You may wish to latch onto the fact that we have this magical undocumented Internal`InheritedBlock in order to show that WRI developers themselves are not happy with Block. I think such a view would be somewhat of an exaggeration. As best I could tell, it was introduced around version 4.2, it is used maybe a dozen times, and is most heavily utilized within some MathML/XML conversion code. Block, by way of contrast, is used hundreds of times in the code for Mathematica. This does not mean InheritedBlock is unworthy of promotion to a System` function. It simply means we've not seen much reason to do so as yet. You recently mentioned having been a user of Mathematica since the late 80's, yet quite frequently not understanding key details and frustrated by shortcomings in documentation. Me, I have studied parts of differential geometry since about that time, and have never gotten much of it to sink in. Suffice it to say that I do not blame the textbooks. It's just the way we are. I do wonder as to whether the examples you show are representative of the work you do, that is to say, of your actual programming needs. They strike me as being on the contrived side. Which is not to say that they can never arise in real practice, but it does seem that they are rare needs. In some ways the Block[{Attributes=Attributes},...] example strikes me as being outside the intended/expected usage of Mathematica. Again, that does not make it necessarily bad or wrong, but does help to explain why the actual behavior is not heavily documented, and why unexpected things can happen. Indeed, I am not sure anyone at WRI has given this scenario much thought (though of course I might be wrong about this). In many language reference manuals one might see phrases like "uses other than those indicated are undefined". Your examples at the very least seem to approach this classification. What I am trying to say, among other things, is that you would get more traction if you gave solid reasons for how and why the current underdocumented behavior of this rare scenario is obstructing your actual work. Making yourself less anonymous would likewise add to the credibility of the posts. Subject titles that do not reference profanity would be nice too, by the way. Daniel Lichtblau Wolfram Research