Re: "Do What I Mean" - a suggestion for improving
- To: mathgroup at smc.vnet.net
- Subject: [mg97040] Re: "Do What I Mean" - a suggestion for improving
- From: Sebastian Meznaric <meznaric at gmail.com>
- Date: Tue, 3 Mar 2009 05:57:06 -0500 (EST)
- References: <200902281142.GAA16641@smc.vnet.net> <godm42$46k$1@smc.vnet.net>
On Mar 1, 9:56 am, David Bakin <david... at gmail.com> wrote: > DrMajorBob, > > I think you're missing the point here - and actually, this is exactly the > point that AES keeps banging on. "It's up to a user to write what he m= eans" > is small comfort to a user, especially one new to Mathematica, who doesn'= t > know how to express what he means. Not only do we see a lot of comment= s on > this list of the form "Why doesn't this work?" we see a lot of the form > "I've looked and looked and I can't figure out why this doesn't work". = And > meanwhile, "xy" instead of "x y" is sitting there obvious as hell to all = of > us who, in fact, do know what the user means. > > Perhaps you're hung up on the idea that I propose that DWIM be invoked > automatically. I didn't mean for everyone! Not you! And maybe not for > anyone: Just consider my idea that it is invoked by the user typing > "Explain[]" after an evaluation of something that didn't go as he expecte= d. > Then you have the proper conditions: The user typed something, he didn= 't > get the answer he wanted, he suspects it may be to his input being "not w= hat > he meant", so he takes a positive action to find out why. The Explain[= ] > rule inspects In[] and Out[] and the environment and offers suggestions. > > When you say "DWIM is impossible even in theory" perhaps you didn't get t= hat > "DWIM" is a tongue-in-cheek name, not to be taken literally. It is jus= t a > name for an meta-analysis feature that inspects the user's input and > proposes similar input forms that may be closer to what the user has in > mind, based on a database of common errors. > > Please reconsider my suggestion with this clarification in mind. > > -- David > > On Sat, Feb 28, 2009 at 10:12 AM, DrMajorBob <btre... at austin.rr.com> wrot= e: > > Sorry, but most (maybe none) of that can be done. Point by point: > > > 1) x/xy is NOT a syntax error, and it may be exactly what I mean. It's = up > > to a user to write what he means. > > > 2) There are no "functions" in Mathematica; only rules. If you defined > > f[x_Integer]:=x^2 and then tried to evaluate f[2.3] the first rule is= n't > > invoked because 2.3 doesn't fit the pattern, so Mathematica has no > > opportunity to match it (since it DOESN'T match) and then TELL you it > > doesn't match. This may be EXACTLY what I want and expect to happen, so= it > > would be a waste of time for Mathematica to flag this as an error every= time > > it occurs. > > > 3) NIntegrate, for instance, can only work if all variables and paramet= ers > > are numeric, and you already get an error message if they're not. Integ= rate, > > on the other hand, can work with symbolic variables and numeric paramet= ers. > > There are a lot of case-by-case situations. I don't see how Mathematica > > could guess whether you've tried what you meant to try. It only knows > > (sometimes) how successful it was. > > > 4) When FindMinimum or NIntegrate or NDSolve has precision problems, > > there's no way for Mathematica to know how to proceed. Sometimes you ne= ed a > > new Method, other times a new WorkingPrecision, and often, you're simpl= y NOT > > going to integrate the thing you're trying to integrate, no matter WHAT= you > > do. > > > DWIM is impossible, even in theory. > > > Bobby > > > On Sat, 28 Feb 2009 05:42:20 -0600, David Bakin <david... at gmail.com> > > wrote: > > > A few days ago I posted that Mathematica should have a "DWIM" feature -= "Do > >> What I Mean". > > >> In InterLisp, in the 80's, the DWIM facility was hooked into error > >> messages, > >> and when invoked on a user error would poke around on the stack and in= the > >> environment using some rules to describe common error situations and i= t > >> would uncover user errors and offer to correct them. Many of the er= rors > >> were simple spelling errors and it would correct a misspelled variable > >> name > >> if it found an unbound variable but a similarly spelled variable was b= ound > >> in the environment. > > >> Mathematica could benefit from this, and in fact, we at mathgroup coul= d > >> supply the rules (and framework) as a useful group project. > > >> If some guru would write the framework - trapping error messages someh= ow, > >> perhaps when they were written to the $Messages channel (by replacing = the > >> default $Messages channel with something that would hook into the DWIM > >> function), or perhaps with some other hook like redefining Message[] - > >> then > >> the rest of us could supply rules for the common errors. Especially= the > >> common errors we see puzzling Mathematica newbies on this list. > > >> I would suggest that the rules provide messages, hopefully with hyperl= inks > >> to the documentation. > > >> A true DWIM might also offer to rewrite the current expression and try= it > >> again, but I don't know if that can be done given the hooks into > >> Mathematica > >> that are currently available. > > >> Some situations that could be addressed are: > > >> 1. User writes "xy" instead of "x y". Rule could inspect the exp= ression > >> under evaluation and find (unevaluated) symbols like "xy" of the form > >> "<prefix><suffix>" where both "<prefix>" and "<suffix>" were either > >> symbols > >> used in the expression or symbols bound in the environment. Rule wo= uld > >> explain the problem and offer to rewrite expression and try again. > > >> 2. Some expression using a user-defined function causes an error wh= en > >> evaluating, or doesn't evaluate. Looking at the function, a rule fi= nds > >> function calls where the function arguments' patterns include "_Intege= r" > >> or > >> similar but the arguments given to it are not integers. Rule points= to > >> documentation describing argument types required by the called functio= n. > > >> 3. Similar to 2 above, but it finds function calls that do numeric > >> evaluation only or are optimized for numeric evaluation but the argume= nts > >> given to it are symbolic. > > >> 4. Result returned is machine precision very close to zero (that is= , > >> with large negative exponent), but an error message complained of > >> singularity, or other ill-conditioning. Rule points to documentatio= n > >> explaining about machine precision, and/or singularity, and offers to > >> retry > >> the expression with more digits of precision, rewriting the expression= to > >> achieve this. > > >> Actually, now that I think of it, the DWIM facility needs also to be > >> invoked > >> by the user because some of these situations don't cause error message= s, > >> but > >> only cause (wholly or partially) unevaluated expressions. So maybe = the > >> user > >> could be trained to type a word, like "Explain[]" after he didn't get = the > >> result he wanted and the DWIM facility would look at the In[] and Out[= ] > >> arrays to find out what he's been doing recently. > > >> I would be glad to contribute rules to the framework ... but I'm not y= et > >> up > >> to writing the framework. Hopefully one of the gurus here will find= this > >> interesting (and possible) and provide a framework. Then the rest o= f us > >> could contribute rules that would improve the Mathematica experience f= or > >> all > >> newcomers. (AES, I'm looking at you! :-) ) > > >> -- David > > > -- > > DrMajor... at bigfoot.com I think the framework for this already exists. It is the Mathematica's suggestion system when opening a notebook from an older version. It inspects every cell and it replaces the deprecated and obsolete functions and forms with the new ones. So I think your suggestions could be implemented similarly. I think it would be a good idea to create a DWIM panel or so where a user selects the offending cell and presses a button that scans the cell for standard errors. I think it's a good idea, especially for new users who may repeat the same errors. If this gets done, I would also suggest to add a feature that explains the errors made to the user (by say having a button "Tell me more" or something like that).