lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3862) DocValues getInt() returns long, getFloat() returns double
Date Sun, 11 Mar 2012 18:08:57 GMT


Robert Muir commented on LUCENE-3862:

Let me try to explain my line of reasoning... i dont know if it will work but...

Its been mentioned before on previous issues that it would be nice if people could have norms
impls that arent a huge byte[] or whatever.
Currently, all of our provided Similarities will not work if hasArray() is false. So if you
want to have an alternative norms data structure,
perhaps some space tradeoff, or based on something you know about your data, it currently
requires you to write a custom Similarity too :(

I've been curious to test: if the norms impl is really just a byte[], would scoring via the
docvalues apis (rather than hasArray) really
slow things down?

Because if we just had a getByte(int doc), I think its feasible it would cost nothing over
getArray() and byte[doc]... Then people could
make alternative implementations without also making custom Similarities.

But i'm nervous about all the casting of bytes to longs and such, I also feel the api is a
little confusing...

With those methods in place we just gonna cast around which should be done by the user of
the API.

But how are we not casting to long now (e.g. single-byte norms case) ?

> DocValues getInt() returns long, getFloat() returns double
> ----------------------------------------------------------
>                 Key: LUCENE-3862
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 4.0
>            Reporter: Robert Muir
> I think this is a bit confusing: especially for the case of something like norms
> where its really an 8 bit byte, a long is confusing.
> i think we should have the usual getFloat/getDouble/getInt/getShort/getByte instead?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message