Re: ordered indexing for integers

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:
> I guess you're really describing something like floating-point
> representation, except our exponents are always positive.

A mixture and floating point and DER, I suppose.  I've hardly looked
inside a floting-point number for decades.  Fixed length like you say
and "exponent" = "length it would have if represented exactly", as with
floating-point.  But with a lenght-of-length component and counted in
octets, not bits, as in DER.  And I don't see much point in doing the
base-10 multiplication or division needed for true floating point.
Unless floating-point hardware is sufficiently magical nowadays that
it's an advantage to make use of it.  I don't have a clue myself.

I don't know if anyone uses huge enough integers in LDAP that it's a
gain to avoid base10 conversion, but I don't know they don't either.
Probably a bad idea now that I think of it, in case one later moves to
an an LDAP/X.500-server with ASN.1 encoding, which will then have to
convert between binary and decimal anyway.


Another point with huge integers is that one might store a group of them
with small differences, and want an equality index to tell them apart.
For that an index of <length, first digits, last digits> could be
useful.  Then the inequality index and inequality filter for a huge
value would need to generate different index keys though.  (The filter
would need to replace the "last digits" part of huge values with
0x00... or 0xff...)  I don't know if OpenLDAP's indexing supports that.

In any case, for similar reasons it might be an idea to keep supporting
the old hash(decimal value) index format.

-- 
Hallvard