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

**Re: Mathematica 8: first impressions**

**Re: Mathematica 8 and Alpha integration....**

**Mathematica 8 and Alpha integration....**

**Re: Mathematica 8 and Alpha integration....**