Interesting problem comparing strings with integer values...
clspence at one.net
Thu Jan 16 01:19:06 CET 2003
The comparison will not be done inside of a Python interpreter, but in
an SQL statement. ie...
select blah from table where value>"999" and value<"3432";
We're storing arbitrary data in text blobs, so we can't make "value" above an
As I mentioned in my first post, while the above SQL statement would be
incorrect, the below SQL code WOULD.
select blah from table where value>"00000999" and value<"00003432";
This just seems incredibly hack-y to me. It means that we'd have a hardcoded
limit for padding values with zeroes. It gets even more fun when I talk
floating point values...But one step at a time.
Note that this works as well:
select blah from table where value>"1111100111" and value<"110101101000";
However, I've not been able to find an equivalent to hex() or oct() that would
turn integers into binary string representation. If there IS such a beastie,
please let me know.
On Wed, 15 Jan 2003 16:02:59 -0800, you wrote:
>On Wednesday 15 January 2003 15:23, Chris Spencer wrote:
>> Due to certain design constraints, I must be able to store both
>> integers and floating point numbers as strings. These strings must
>> be able to be compared correctly, so things like: "999"<"3432" are
>> not possible. One option we thought of was padding the strings with
>> zeros, so things like: "00000999"<"00003432" would work. This seems
>> a bit hack-y to me. I was wondering if anyone has a more elegant
>> solution to the problem?
>If you must only store the numbers as strings, then you could easily
>convert them back to number types for comparisons, ie:
>float("999") < float("3432")
>A fancy method would be to try converting to floats, and if that fails,
>convert to longs for comparison. If this approach isn't workable, then
>you need to more clearly identify your needs. Is speed an issue? Is
>it really only an issue of storing data as strings, or must you operate
>directly on those strings as well, etc.? And will the numbers all be
>small (floats loose precision as they get to be very large, for example)
More information about the Python-list