python language: infimum and supremum of integers

Alex Martelli aleax at aleax.it
Wed Apr 23 07:39:18 EDT 2003


<posted & mailed>

Grégoire Dooms wrote:

> Hi,
> I need a lower and higher integer for initializing lower and higher
> bounds in an algorithm.  I know integers have no limits(maximum and
> minimum) in python and infimum and supremum would do the job too.
> 
> I empirically discovered (Python 2.2.2) that None could be considered an
> infimum and any string could be considered a supremum.
> e.g "a">int(x) is always true and None<int(x) is always false
> 
> But this fact is not stated in the language reference.

Indeed, it's not a property of the language: it's a property of your
specific implementation (and, indeed, the results of comparisons between
different arbitrary types are even allowed to vary between runs).

If you ARE indeed talking about int (not about long, which IS indeed
unbounded), sys.maxint >= any int, and -sys.maxint-1 <= any int.  But
since int() itself IS now allowed to return a long, that may perhaps
be of little use to you.

> Citing http://www.python.org/doc/current/ref/comparisons.html :
> "The objects need not have the same type. If both are numbers, they are
> converted to a common type. Otherwise, objects of different types always
> compare unequal, and are ordered consistently but arbitrarily."
> 
> Could/should that order be hardcoded in the language ?

It surely COULD -- all comparisons could e.g. specialcase type None
to ensure it compares < any different type.  As for SHOULD, I dunno.

For your algorithm, why not just, for example:

class Infimum:
    def __cmp__(self, other): return -1
infimum = Infimum()

class Supremum:
    def __cmp__(self, other): return 1
supremum = Supremum()

as coded these have obvious anomalies, e.g. infimum < infimum -- but
those are easy to remove if they give problems to your algorithm.


Alex





More information about the Python-list mailing list