Re: "Do What I Mean" - a suggestion for improving

*To*: mathgroup at smc.vnet.net*Subject*: [mg96991] Re: [mg96961] "Do What I Mean" - a suggestion for improving*From*: DrMajorBob <btreat1 at austin.rr.com>*Date*: Sun, 1 Mar 2009 04:56:23 -0500 (EST)*References*: <200902281142.GAA16641@smc.vnet.net>*Reply-to*: drmajorbob at bigfoot.com

> Please reconsider my suggestion with this clarification in mind. No thanks. Artificial intelligence is NECESSARY in the long run, but it's very far off. Bobby On Sat, 28 Feb 2009 13:09:57 -0600, David Bakin <davidbak 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 > means" > 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 comments > 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 > expected. > 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 > what > 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 > that > "DWIM" is a tongue-in-cheek name, not to be taken literally. It is just > 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 <btreat1 at austin.rr.com> > wrote: > >> 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 isn'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 >> parameters >> are numeric, and you already get an error message if they're not. >> Integrate, >> on the other hand, can work with symbolic variables and numeric >> parameters. >> 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 >> need a >> new Method, other times a new WorkingPrecision, and often, you're >> simply 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 <davidbak 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 it >>> would uncover user errors and offer to correct them. Many of the >>> errors >>> were simple spelling errors and it would correct a misspelled variable >>> name >>> if it found an unbound variable but a similarly spelled variable was >>> bound >>> in the environment. >>> >>> Mathematica could benefit from this, and in fact, we at mathgroup could >>> supply the rules (and framework) as a useful group project. >>> >>> If some guru would write the framework - trapping error messages >>> somehow, >>> 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 >>> hyperlinks >>> 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 >>> expression >>> 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 would >>> explain the problem and offer to rewrite expression and try again. >>> >>> 2. Some expression using a user-defined function causes an error when >>> evaluating, or doesn't evaluate. Looking at the function, a rule finds >>> function calls where the function arguments' patterns include >>> "_Integer" >>> or >>> similar but the arguments given to it are not integers. Rule points to >>> documentation describing argument types required by the called >>> function. >>> >>> 3. Similar to 2 above, but it finds function calls that do numeric >>> evaluation only or are optimized for numeric evaluation but the >>> arguments >>> 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 documentation >>> 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 >>> messages, >>> 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 >>> yet >>> up >>> to writing the framework. Hopefully one of the gurus here will find >>> this >>> interesting (and possible) and provide a framework. Then the rest of >>> us >>> could contribute rules that would improve the Mathematica experience >>> for >>> all >>> newcomers. (AES, I'm looking at you! :-) ) >>> >>> -- David >>> >>> >> >> >> -- >> DrMajorBob at bigfoot.com >> -- DrMajorBob at bigfoot.com

**Re: "Do What I Mean" - a suggestion for improving**

**Re: "Do What I Mean" - a suggestion for improving**

**Re: "Do What I Mean" - a suggestion for improving**

**Re: "Do What I Mean" - a suggestion for improving**