[Date Index]
[Thread Index]
[Author Index]
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).
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**
| |