Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 11 Sep 2008 16:27:24 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: "java-user@lucene.apache.org" <java-user@lucene.apache.org>
Subject: Re: Number to printable sortable string, including floating point
 numbers and negatives
In-Reply-To: <D8E6BD3AD2634843B58AFF6A94FE246202D7A5A404@msgint02.mogul.com>
Message-ID: <Pine.LNX.4.62.0809111618140.4907@radix.cryptio.net>
References: <D8E6BD3AD2634843B58AFF6A94FE246202D7A5A404@msgint02.mogul.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: Do you have any suggestions on how to solve this in a "neat" way? And is 

Have you looked at the NumberTools class?

As i recall it generates strings that are always printable, but as a 
result (of using fewer characters) are also always longer then the 
corrisponding value from Solr's NumberUtils.  

NumberTools only has methods for longs at the moment, but the same 
doubleToRawLongBits logic from NumberUtils could be usedto apply it to 
doubles as well.

: the interest in this really that low (judging from the poor search 
: result I got when searching for "lucene sorting negative numbers" and 
: similar)? I would have thought that the need for this functionallity was 
: quite fundamental, and that it was already part of Lucene core.

In my experience people the majority of people either:
  1) don't care about numbers in Lucene
  2) care about small ranges of numbers where simple padding or 
NumberTools is good enough.
  3) use Solr and don't care that the indexed value is non-printable, 
because Solr's IndexSchema and FieldType management ensures thatthe "real" 
numeric value is all they ever see.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org