Google Calculator implementation?

Maybe I'm not familiar with what you are talking about--I only know about the search "calculator" that will answer problems you type in the search box. What, specifically, is impressive about it, though? It seems to be fairly straightforward.

For what its worth, given this expression:

2x^2 + 4x + 2 = 8

Google gives no results, but live.com gives the following:

2x^2+4x+2=8 : x=-3, x=1

Similarly for the expression "x*sin(45) + 4 = 2", google gives no results, but live.com gives an answer.

I can only offer some "reverse engineering" attempts.

Calculator seems to break at 171!, but computes 170!.

Messing with "1020 choose 500" breaks at similar point.

Max double is: 1.7976931348623157 x 10^308

"5 USD in Euro" is valid, "5 USD in Euro x" isn't.

IMHO: every query entered into google search is ran through calculator (trivial parser). If expression parses, and doesn't throw a floating-point exception, result of the calculation is returned. Otherwise, search query is executed.

This would explain why double is used as type instead of higher precision libraries. Performing an extra lexical parse on each query is really cheap.

Various bonus features such as unit conversions however are trivial to integrate into such parser.

Quote:

For what its worth, given this expression:

Which would fall in line with my observations - calculator is "dumb", just checks if expression parses, it doesn't offer any advanced features, or those that would interfere with search itself.

Quote:

Original post by Antheus Which would fall in line with my observations - calculator is "dumb", just checks if expression parses, it doesn't offer any advanced features, or those that would interfere with search itself.

Sure, but my point was that Microsoft's calculator soundly *pwns* Google's, apparently. :-)

In particular, I'm looking at the unit of measurement workings. And by extension the conversion elements, which do not seem trivial to me; unless they convert everything to common units which I'd think would lead to float issues with very small or large units.

Key points are when/how an expression is aborted and how certain phrases are coerced into viable units.

2nd root of (4m^4) -> 2m^2
2nd root of (4m^3) -> err

4 usd in australian money -> 5.787...

Here's my first primitive guess:

1) Parser looks for operators that are specific to functional categories: mathematical (+, -, ..., root, cos, etc), conversion (in, to) ... if none are found, hand off to web search

2) Attempt to build an expression tree for math... becomes "trivial" after this

2B) For conversion, determine source and destination (source on right for "in", left for "to")

3) Attempt to parse quantity in source, and units in source and destination

With a defined set of possible conversions, it's easy to figure the units out... "australian money" tells you everything you need to know if you keep a lookup on the backend for that. Google lets you say "5 us money to australian money"... it just needs a noun whether it be pounds, inches, blah blah blah, and it allows "money" as a placeholder provided that the country is provided.

4) Invoke the conversion function for (SOURCETYPE, DESTTYPE, QTY)