[
https://issues.apache.org/jira/browse/LUCENE-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227121#comment-13227121
]
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...
{quote}
With those methods in place we just gonna cast around which should be done by
the user of the API.
{quote}
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: https://issues.apache.org/jira/browse/LUCENE-3862
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
