MathGroup Archive 2009

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

Search the Archive

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

On Mar 1, 9:56 am, David Bakin <david... at> 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=
> is small comfort to a user, especially one new to Mathematica, who doesn'=
> 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". =
> meanwhile, "xy" instead of "x y" is sitting there obvious as hell to all =
> 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=
> Then you have the proper conditions:  The user typed something, he didn=
> get the answer he wanted, he suspects it may be to his input being "not w=
> 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=
> "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> wrot=
> > 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 =
> > 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=
> > 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=
> > would be a waste of time for Mathematica to flag this as an error every=
> > it occurs.
> > 3) NIntegrate, for instance, can only work if all variables and paramet=
> > are numeric, and you already get an error message if they're not. Integ=
> > on the other hand, can work with symbolic variables and numeric paramet=
> > 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=
> > going to integrate the thing you're trying to integrate, no matter WHAT=
> > do.
> > DWIM is impossible, even in theory.
> > Bobby
> > On Sat, 28 Feb 2009 05:42:20 -0600, David Bakin <david... at>
> > wrote:
> > A few days ago I posted that Mathematica should have a "DWIM" feature -=
> >> 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=
> >> environment using some rules to describe common error situations and i=
> >> would uncover user errors and offer to correct them.  Many of the er=
> >> 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=
> >> in the environment.
> >> Mathematica could benefit from this, and in fact, we at mathgroup coul=
> >> supply the rules (and framework) as a useful group project.
> >> If some guru would write the framework - trapping error messages someh=
> >> perhaps when they were written to the $Messages channel (by replacing =
> >> 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=
> >> common errors we see puzzling Mathematica newbies on this list.
> >> I would suggest that the rules provide messages, hopefully with hyperl=
> >> to the documentation.
> >> A true DWIM might also offer to rewrite the current expression and try=
> >> 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=
> >> 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=
> >> explain the problem and offer to rewrite expression and try again.
> >> 2.  Some expression using a user-defined function causes an error wh=
> >> evaluating, or doesn't evaluate.  Looking at the function, a rule fi=
> >> function calls where the function arguments' patterns include "_Intege=
> >> or
> >> similar but the arguments given to it are not integers.  Rule points=
> >> documentation describing argument types required by the called functio=
> >> 3.  Similar to 2 above, but it finds function calls that do numeric
> >> evaluation only or are optimized for numeric evaluation but the argume=
> >> 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=
> >> explaining about machine precision, and/or singularity, and offers to
> >> retry
> >> the expression with more digits of precision, rewriting the expression=
> >> 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=
> >> but
> >> only cause (wholly or partially) unevaluated expressions.  So maybe =
> >> user
> >> could be trained to type a word, like "Explain[]" after he didn't get =
> >> 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=
> >> up
> >> to writing the framework.  Hopefully one of the gurus here will find=
> >> interesting (and possible) and provide a framework.  Then the rest o=
f us
> >> could contribute rules that would improve the Mathematica experience f=
> >> all
> >> newcomers.  (AES, I'm looking at you! :-) )
> >> -- David
> > --
> > DrMajor... at

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).

  • Prev by Date: Re: Delayed function does not behave as original input
  • Next by Date: find the maxima in a function
  • Previous by thread: Re: "Do What I Mean" - a suggestion for improving
  • Next by thread: Re: "Do What I Mean" - a suggestion for improving