Igor Tandetnik <itandetnik-fh9draxc...@public.gmane.org> writes:
> It doesn't matter. The whole point is that the key is constructed in
> such a way that both procedures would arrive at the same result.
That's really what was at the heart of my question: If separate
value-by-value was necessary, then I would conclude that the
concatenated key would /not/ yield the corrected result by comparing the
whole thing in one operation.
I was having trouble convincing myself that the single comparison would
always work. I was looking for a counterexample, where a shorter value's
end and the beginning the following value could be mistakenly compared
against a single longer value. The language used in the referenced Wiki
page added further to my confusion, so I thought it best to ask for
clarification. Studying the encoding more carefully, I see that the end
of one value will always sort earlier than any intermediate byte in
another value. That numbers can never contain a zero byte is an
easy-to-miss detail.
A couple more nits on that page: In the second paragraph, we find:
,----
| until a difference if found
`---- ^
|
+------------------+
|
s/if/is/
The seventh paragraph reads as follows:
,----
| The first byte of a key past the table number will be in the range of
| 0x05..0x0f if ascending or 0xf0..0xfa if descending. This leaves large
| chunks of key space available for other uses. For example, the
| three-byte key 0x00 0x00 0x01 stores the schema cookie for the database
| as a 64-bit big-endian integer.
`----
The part that says the first byte will be valued between 5 and 15
(decimal) for ascending values doesn't agree with the table at the end,
where we see leading bytes in the range 0x05 to 0x25, or 5 to 37
decimal. Am I comparing different things here?
Finally, to restate an inquiry from my earlier message, which I had some
trouble sending properly:
I don't understand why the example entries for values 99.0, 99.01, and
99.0001 have first bytes of 0xb4 and 0xb5, respectively.
If we take 99 and use it as "X" in the "2*X+0" formula, shouldn't we
wind up with 198, or 0xC6? Likewise, for the second two examples, I'd
expect 2*99+1 to yield 199, or 0xC7. (The later entry for 9999 has bytes
0xC7 and 0xC6, which match my expectation.)
--
Steven E. Harris
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
