This topic is 3473 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites
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.

##### Share on other sites
For what its worth, given this expression:

2x^2 + 4x + 2 = 8

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

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by AntheusWhich 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. :-)

##### Share on other sites
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...

##### Share on other sites
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)

• 17
• 11
• 15
• 9
• 49
• ### Forum Statistics

• Total Topics
631393
• Total Posts
2999774
×