Google Calculator implementation?
Author
Anyone happen to know of any good links (or inside info) regarding the google calculator? All the sites I find are how it rocks and is the best thing since sliced bread. I'm more curious about how it is implemented (languages/libraries/approaches) so that it can kick so much ass.
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.
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.
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.
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 AntheusSure, but my point was that Microsoft's calculator soundly *pwns* Google's, apparently. :-)
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.
Author
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...
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)
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)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement