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

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