Make Omnibox's HistoryQuickProvider's new scoring less aggressive

Make Omnibox's HistoryQuickProvider's new scoring less aggressive

This makes HQP's new scoring about as aggressive as old scoring.  In the old scoring, 30 typed visits corresponds to a 1200 relevance score.  This makes the new scoring similar.

BUG=
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=147333

[Mark P, 2012-07-16 19:51:01]

I know I should figure out a better way to tune.  I'm going to talk to one of my
old statistics colleagues soon.  In the meantime, I'm curious to see the effect
this change will have.

--mark

[mrossetti, 2012-07-16 22:47:50]

LGTM

I'm curious as to why we don't just make the HQP scores as aggressive and
similar to the HUP?

Be sure unit tests still pass, expecially those in
in_memory_url_index_unittest.cc.

[Mark P, 2012-07-17 13:51:17]

On 2012/07/16 22:47:50, mrossetti wrote:
> LGTM
> 
> I'm curious as to why we don't just make the HQP scores as aggressive and
> similar to the HUP?

That's what I want to do as well.  Well, actually HUP doesn't really have a
scoring range.  It's basically a boolean plus a sorting function.
- boolean: is this inlineable URL worthy of being given a score that lets it be
inlined?
- scoring function: for all URLs with the same boolean value, order them.

My original parameter setting for HQP (that I already reduced once after I found
out they were bad) tried to put the inlineable score boundary in the same place.
 It turned out to be too aggressive in the sense that (i) HQP results appeared
more often as inline suggestions than before annd (ii) people tended to selected
inline suggestions at a slightly lower rate than before.

Also, for what it's worth, the scoring function I've been trying for HQP put a
lot of emphasis on typed_counts and visit_counts.  This is because HUP's scoring
function basically orders by typed_count.  In HQP's new scoring, typed and visit
counts are the only feature with an unbounded range.  All the other features
(days old, matches in URL and title) are assigned bounded scores, meaning the
typed_count signal can overrule any other signal going in.

With this new tuning, I think HQP's new scoring will be about as aggressive as
old scoring.  (I'll measure this to make sure it's true.)  If so, new scoring vs
old scoring will tell me if something is flawed with the algorithm itself.

HUP seems to be mighty smart about whether things should be displayed inline. 
Independently, I should figure out if I can put some of that smarts in HQP
without explicitly imports its thresholds (if is raw hostname and typed_count >=
1 then ...).

> Be sure unit tests still pass, expecially those in
> in_memory_url_index_unittest.cc.

Done.  They pass.

--mark

[Mark P, 2012-07-18 18:21:17]

Adding sky as a reviewer for OWNERS rubberstamp.

Adding pkasting as a CC as an FYI.

--mark

[sky, 2012-07-18 21:00:07]

LGTM

[commit-bot: I haz the power, 2012-07-18 22:02:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mpearson@chromium.org/10782017/1

[commit-bot: I haz the power, 2012-07-18 23:20:23]

Change committed as 147333