I tried addressing this a few weeks ago by making the fill_into_edit value be the query (2 * 2). But I ran into some issue with how it was getting deduped with the WTY match, the details of which I can't recall now. I'll take another swing at this soon.

krb: assigning this to you to see if you can make it work since you were just addressing an issue in the dedupe code. Grab me some time and I can provide a bit more info on how I attempted to implement this earlier.

If you look at the URL they give us:

https://www.google.com/search?q=4&oq=2*2&...

it appears that there is little we can do, unless we want to re-write the URL. If you agree, I'll open a bug against Search.

Re comment #5:

The suggest server isn't giving Chrome a URL.  It's giving us a query, a type (CALCULATOR), and that kind of stuff.  We write it into a URL.

What additional information do you want them to provide?

I tracked down where we construct the search URL, and tried swapping the query and original query. The new URL indeed takes us to the Google calculator page, but unfortunately, this result doesn't show up any more. It is deduped away because the URL matches the WYT result, despite the addition of "oq=4". It's score is only 1250 vs 1300. Some of this, Justin mentioned before.

Carving out an exception for calculator types while deduping is possible, but not elegant. (I verified it works.)

I suspect we don't want to fiddle with scores.

The last thing I can think of is tweaking which terms that this template URL considers relevant. It seems cleanest but I don't know what's involved there. (The idea doesn't sound quite right to me though. The issue is in Chrome, not Search, so it seems the fix should be in Chrome, not Search's template URL. It seems like the problem could repeat if other providers give us calculator results.)

Thoughts?

I am okay putting into the place the policy that calculator matches are never marked as a duplicate of anything else.  I think it makes sense.
// A calculator match is an alternate presentation of the user's input.  Its value is in its visual display.  Hence, it should not be duplicate-eliminated against that match or any others.  

I agree that the alternatives sound worse.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cbe8e92f21c2ac2cea90badf3362f94e84d60d02

commit cbe8e92f21c2ac2cea90badf3362f94e84d60d02
Author: Kevin Bailey <krb@chromium.org>
Date: Thu Sep 06 19:00:59 2018

[omnibox] Swap Calculator terms in URL to search correctly

The current URL generated from a Calculator suggestion searches for
the result e.g. "4", not the calculation e.g. "2+2". This CL swaps
the terms (actually, it clears the original query) and, further, treats
the suggestions as distinct from non-calculator suggestions, so that
they don't dupe against other WYT suggestions.

Bug:  873666 
Change-Id: I006f9754ee7e48d0a21a1f149c4ef76b3ca509fd
Reviewed-on: https://chromium-review.googlesource.com/1197342
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589228}
[modify] https://crrev.com/cbe8e92f21c2ac2cea90badf3362f94e84d60d02/components/omnibox/browser/autocomplete_result.cc
[modify] https://crrev.com/cbe8e92f21c2ac2cea90badf3362f94e84d60d02/components/omnibox/browser/autocomplete_result.h
[modify] https://crrev.com/cbe8e92f21c2ac2cea90badf3362f94e84d60d02/components/omnibox/browser/base_search_provider.cc
[modify] https://crrev.com/cbe8e92f21c2ac2cea90badf3362f94e84d60d02/components/omnibox/browser/match_compare.h