Re: "Do What I Mean" - a suggestion for improving Mathematica experience
- To: mathgroup at smc.vnet.net
- Subject: [mg96997] Re: "Do What I Mean" - a suggestion for improving Mathematica experience
- From: David Bailey <dave at removedbailey.co.uk>
- Date: Sun, 1 Mar 2009 04:57:31 -0500 (EST)
- References: <gob7uh$g7p$1@smc.vnet.net>
David Bakin 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 > Wow - that sounds a very challenging project! I wonder if it would be better to start with a slightly more modest idea, and write a CommentOn function that would have attribute HoldFirst, and take any expression as an argument, and apply as many heuristics as possible, looking for possible mistakes - such as your xy example. Another such function might be WhyNoMatch that would take a function call and attempt to explain why it did not match the definition. The problem is, I suspect beginners write arguments as x_ rather than x_Integer - but having said that, they sometimes write them as x - which can waste a lot of time. As it happens, I have just released an experimental debugger (see my post of the other day). I guess that could look for certain things going wrong - such as the problem you cite of a numeric routine ending up doing a symbolic calculation. I think the real challenge might be to raise the success rate high enough that people felt it was worth running the code. David Bailey http://www.dbaileyconsultancy.co.uk