Lucene的score打分策略的问题

    这段时间在项目中我们在使用lucene的时候发现一个问题，例如：
    有两个索引域的内容为：新浪微博spring、新浪微博，当我输入"新浪微博"进行搜索的时候，按照lucene的score计算公式，新浪微博的值应该要高，但是实际上两个值却是一样。通过分析源代码发现问题出现的原因是：
    lucene在计算lengNorm的时候本身没有错，但是它对lengNorm进行了编码，结果转码的时候会出现错误，比如计算出来的lengNorm为0.4472136，可是经过它内部的编码解码后值却变成了：0.4375，导致计算出来的score值出现误差，代码为NormsWriterPerField类中：

        if (fieldInfo.isIndexed && !fieldInfo.omitNorms) {
      if (docIDs.length <= upto) {
        assert docIDs.length == upto;
        docIDs = ArrayUtil.grow(docIDs, 1+upto);
        norms = ArrayUtil.grow(norms, 1+upto);
      }
      final float norm = docState.similarity.computeNorm(fieldInfo.name, fieldState);
      norms[upto] = Similarity.encodeNorm(norm);
      docIDs[upto] = docState.docID;
      upto++;
    }

编码解码代码为Similarity类中：

  /** Cache of decoded bytes. */
  private static final float[] NORM_TABLE = new float[256];

  static {
    for (int i = 0; i < 256; i++)
      NORM_TABLE[i] = SmallFloat.byte315ToFloat((byte)i);
  }
  /** Decodes a normalization factor stored in an index.
   * @see #encodeNorm(float)
   */
  public static float decodeNorm(byte b) {
    return NORM_TABLE[b & 0xFF];  // & 0xFF maps negative bytes to positive above 127
  }
  public static byte encodeNorm(float f) {
    return SmallFloat.floatToByte315(f);
  }

我想lucene的作者不会犯这种低级错误吧，应该是故意这样设计的吧，至于原因，目前还在分析中。。。。。
**********************************分界线×××××××××××××××××××××××
原因是因为作者将编码后的lengthNorm值转化成一个byte，而一个float是四个字节，导致了数据的准确性。作者这样设计估计是为了在保证不影响正常功能的情况下尽可能的提高性能吧。