Re: Mathematica 8 and Alpha integration....
- To: mathgroup at smc.vnet.net
- Subject: [mg114006] Re: Mathematica 8 and Alpha integration....
- From: John Fultz <jfultz at wolfram.com>
- Date: Sat, 20 Nov 2010 06:14:47 -0500 (EST)
Understanding some of the internal divisions of the feature implementation
would, I think, be instructive. The == feature, in the big picture, is capable
of doing any of the following things, depending upon your input...
* Parse your input, return a matching W|A result. We might call this an
informational query.
* Parse your input, return a matching Mathematica input. I'll refer to this as
a programming query.
* Parse your input and your Mathematica session information, return a matching
Mathematica input. This could be a contextually aware programming query.
Clearly, informational queries are pretty simple, and there's not much to
discuss there. Programming queries are, I think, in a pretty strong state right
now, although I've certainly come across cases where I could wish for better.
Contextually aware programming queries are, by far, the hardest problem, and
it's the one where our efforts are the least mature. And Stephen basically says
this in his blog. But the lack of maturity is all server-side development. The
infrastructure is completely in place on the Mathematica side, so as the
server-side infrastructure improves, you'll see better and better contextually
aware programming queries.
Even now, it turns out that there's a sufficient amount of stuff working that
it's already a significant aid to the documentation. I.e., in quite a number of
cases, I can go more quickly from intention to code by using even the least
mature method of contextually aware programming queries than by using the help
system often enough that it's definitely worth my effort to try. I certainly
wouldn't categorize that as a "failure", but you're certainly free to your
opinion.
As for the Ctrl+== feature...it's not a local feature, but it is true that it
doesn't do as much as the == feature does. Many results returned by == would be
totally senseless if they were allowed to return in a Ctrl+== environment. Not
just the default results, but all of the possible results you can select by
expanding the view to see all of the possible pods. So the current system uses
what we internally call the "fast parse", or what the documentation for the
WolframAlpha function refers to as "MathematicaParse". Basically, it only goes
as far as the W|A parser to determine whether there's an equivalent Mathematica
expression. So, instead of getting the richness of W|A query results, you're
getting a simpler parse result which is sometimes going to be a miss.
In my own use, I'm not using the Ctrl+== feature so much except for data paclet
queries (it also works well for math, but I don't find that compelling). I've
always found it frustrating to find the exact bits of information I wanted from
data paclets, and this is a big help. But I hope that, as we learn about the
functionality, we can find ways to make Ctrl+== more useful.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Fri, 19 Nov 2010 05:07:27 -0500 (EST), Jason Ledbetter wrote:
> First, I'm excited about this integration. I'm excited about the natural
> language capabilities.
>
> I'm not sure how this practice mixes with reality, however.
>
> 1) Taking the first example from Wolfram's blog, one can ask alpha "==plot
> x
> sin^3x" then follow that up with "==add black frame". Yet it can't
> comprehend
> "remove black frame"....
>
> So I try "change frame to blue" and alpha returns an input interpretation
> of
> "Show[%, Frame->True, FrameStyle->Pink]". Pink? Really? I guess it made up
> an answer because it stated Alpha doesn't yet know how to respond to the
> query.
>
> I'm beginning to wonder if I don't need documentation on what "natural
> language" Mathematica 8/Alpha actually knows....
>
> 2) I can ask Mathematica 8/alpha "==average 1,2,3,4,5" and get
> Mean[{1,...}] back with a
> result of 3. Great.
>
> However, one can't say "a=={1,2,3,4,5}" and "==average a".
>
> There seems to be this line drawn in the interaction between notebook and
> it's variables and what is passed to alpha.
>
> Are the details of this interaction and the capabilities documented
> anywhere?
>
> Is there something one needs to do to "convert a" to something Alpha can
> understand other than just using the raw input numbers again?
>
> 3) I'm not sure CTRL== does anything.
>
> Entering "average 1,2,3,4,5" does give me a result that I'd expect simila=
r
> to #2 but entering "average a" as defined in #2 gives me "no mathematica
> translations".... i'm under the (potentially false) impression that CTRL=
==
> is
> more "local" than just ==.
>
> I'm thinking that "natural language" is a good idea, but not if the
> speaker
> has to reduce his vocabulary and the expectations of that vocabulary to
> meet
> what the product does.
>
> Two possibilities I see:
>
> A) I'm expecting too much.
> B) It will get there sometime later.
>
> Which results in:
>
> Expecting to use Alpha integration for anything more than pulling data
> from
> their curated databases is going to be a failure in the current version.
>
> thoughts?
>
> -jbl