Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20811 > unrolled thread

PyWart: Language missing maximum constant of numeric types!

Back to article view | Back to comp.lang.python

Contents

  PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 05:37 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-24 13:55 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 06:14 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Neil Cerutti <neilc@norwich.edu> - 2012-02-24 14:25 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:25 -0800
      Re: PyWart: Language missing maximum constant of numeric types! Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-24 12:32 -0500
      Re: PyWart: Language missing maximum constant of numeric types! Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-24 18:26 -0700
    Re: PyWart: Language missing maximum constant of numeric types! Miki Tebeka <miki.tebeka@gmail.com> - 2012-02-24 06:39 -0800
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:18 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Mel Wilson <mwilson@the-wire.com> - 2012-02-24 10:21 -0500
      Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-24 15:31 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:34 -0800
        Re: PyWart: Language missing maximum constant of numeric types! Michael Torrie <torriem@gmail.com> - 2012-02-24 09:23 -0700
          Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-24 22:45 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-24 16:59 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Michael Torrie <torriem@gmail.com> - 2012-02-24 16:16 -0700
        Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-25 11:09 +1100
        Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-25 00:35 +0000
          Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:25 -0800
        Re: PyWart: Language missing maximum constant of numeric types! MRAB <python@mrabarnett.plus.com> - 2012-02-25 00:37 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Serhiy Storchaka <storchaka@gmail.com> - 2012-02-25 17:32 +0200
    Re: PyWart: Language missing maximum constant of numeric types! Fayaz Yusuf Khan <fayaz.yusuf.khan@gmail.com> - 2012-02-25 06:52 +0530
      Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-25 01:50 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:29 -0800
          Re: PyWart: Language missing maximum constant of numeric types! alex23 <wuwei23@gmail.com> - 2012-02-26 18:32 -0800
            Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-27 03:51 +0000
              Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-27 14:59 +1100
              Re: PyWart: Language missing maximum constant of numeric types! alex23 <wuwei23@gmail.com> - 2012-02-26 22:49 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-25 09:18 +0100
      Re: PyWart: Language missing maximum constant of numeric types! MRAB <python@mrabarnett.plus.com> - 2012-02-25 17:54 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:35 -0800
          Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:16 +0100
            Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:38 +0100
              Re: PyWart: Language missing maximum constant of numeric types! Arnaud Delobelle <arnodel@gmail.com> - 2012-02-26 13:44 +0000
            Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 13:50 +0000
            Re: PyWart: Language missing maximum constant of numeric types! Neil Cerutti <neilc@norwich.edu> - 2012-02-27 12:25 +0000
          Re: PyWart: Language missing maximum constant of numeric types! Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-02-27 12:55 +0100
        Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 12:56 +0100
          Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-26 23:52 +1100
            Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:32 +0100
          Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 13:19 +0000

Page 1 of 3  [1] 2 3  Next page →

#20811 — PyWart: Language missing maximum constant of numeric types!

I get sick and tired of doing this!!!

if maxlength == UNLIMITED:
    allow_passage()
elif len(string) > maxlength:
    deny_passage()

What Python needs is some constant that can be compared to ANY numeric
type and that constant will ALWAYS be larger!

[toc] | [next] | [standalone]

#20812

On 24/02/2012 13:37, Rick Johnson wrote:
> I get sick and tired of doing this!!!
>
> if maxlength == UNLIMITED:
>      allow_passage()
> elif len(string)>  maxlength:
>      deny_passage()
>
> What Python needs is some constant that can be compared to ANY numeric
> type and that constant will ALWAYS be larger!
>
>
>

Do you want to test for something that is larger than infinity?

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#20823

On Feb 24, 7:55 am, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> Do you want to test for something that is larger than infinity?

Not exactly. I want to set a constant that has a value of infinity and
then do comparisons against the constant.

##################
# Hypothetical 1 #
##################

def confine(string, maxlength=INFINITY):
        return string[:maxlength]

py> confine('123')
'123'
py> confine('123', 1)
'1'

##################
# Hypothetical 2 #
##################

def confine(string, maxlength=INFINITY):
        if len(string) < maxlength:
            do_something()
        else:
            twiddle_thumbs()

[toc] | [prev] | [next] | [standalone]

#20813

On 2012-02-24, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
> I get sick and tired of doing this!!!
>
> if maxlength == UNLIMITED:
>     allow_passage()
> elif len(string) > maxlength:
>     deny_passage()
>
> What Python needs is some constant that can be compared to ANY
> numeric type and that constant will ALWAYS be larger!

What's the point of that?

The only time I've naively pined for such a thing is when
misapplying C idioms for finding a minimum value.

Python provides an excellent min implementation to use instead.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#20820

On Feb 24, 8:25 am, Neil Cerutti <ne...@norwich.edu> wrote:

> > What Python needs is some constant that can be compared to ANY
> > numeric type and that constant will ALWAYS be larger!
>
> What's the point of that?
>
> The only time I've naively pined for such a thing is when
> misapplying C idioms for finding a minimum value.

The best use case is for default arguments to constructors or func/
meths. If you set the argument to INFINITY instead of -1 (or some
other dumb string value to mean "unlimited") you can omit a useless
conditional block later. Observe:

if maxlength == -1 # unlimited length:
    keep_going()
elif len(object) < maxlength:
    stop() # because we reached the limit

I see tons and tons of old Python code that uses -1 as an "unlimited"
value, where positive numbers are meant to constrain dome value. I
have always found that to be intuitive; hence my question.

[toc] | [prev] | [next] | [standalone]

#20827

On Fri, Feb 24, 2012 at 9:25 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> The only time I've naively pined for such a thing is when
> misapplying C idioms for finding a minimum value.
>
> Python provides an excellent min implementation to use instead.

min can be a little inconvenient. As soon as anything complicated has
to be done during the min expression, you need to switch to using
something else for sanity's sake. In that vein, I do actually
sometimes use float('inf') (for numbers), or a custom max/min object.

----

Silly and completely nonserious addendum:

Forgive me, I have spoken in error! min is the one true way, for you
can still do it with a little wrangling, as follows:

    @operator.itemgetter(1)
    @min
    @apply
    def closest_object():
        for x in xrange(board_width)
            for y in xrange(board_height):
                try:
                    entity = board.get_entity(x, y)
                except EntityNotFound:
                    pass
                else:
                    yield distance(player.pos, entity.pos), entity


Please don't kill me.

-- Devin

[toc] | [prev] | [next] | [standalone]

#20848

On Fri, Feb 24, 2012 at 10:32 AM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Fri, Feb 24, 2012 at 9:25 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>> The only time I've naively pined for such a thing is when
>> misapplying C idioms for finding a minimum value.
>>
>> Python provides an excellent min implementation to use instead.
>
> min can be a little inconvenient. As soon as anything complicated has
> to be done during the min expression, you need to switch to using
> something else for sanity's sake. In that vein, I do actually
> sometimes use float('inf') (for numbers), or a custom max/min object.
>
> ----
>
> Silly and completely nonserious addendum:
>
> Forgive me, I have spoken in error! min is the one true way, for you
> can still do it with a little wrangling, as follows:
>
>    @operator.itemgetter(1)
>    @min
>    @apply
>    def closest_object():
>        for x in xrange(board_width)
>            for y in xrange(board_height):
>                try:
>                    entity = board.get_entity(x, y)
>                except EntityNotFound:
>                    pass
>                else:
>                    yield distance(player.pos, entity.pos), entity

Cute, but what's so terrible about:

    def all_entities():
        for x in xrange(board_width):
            for y in xrange(board_height):
                try:
                    yield board.get_entity(x, y)
                except EntityNotFound:
                    pass

    closest_object = min(all_entities,
        key=lambda e: distance(player.pos, e.pos))

Especially given that all_entities should be reusable in other contexts.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#20814

float('infinity') should be good enough.

[toc] | [prev] | [next] | [standalone]

#20818

On Feb 24, 8:39 am, Miki Tebeka <miki.teb...@gmail.com> wrote:
> float('infinity') should be good enough.

Yes, that is the answer however the implementation is inconsistent.

py> float("inf")
inf
py> float("infinity")
inf
py> int("inf")
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    int("inf")
ValueError: invalid literal for int() with base 10: 'inf'
py> int("infinity")
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    int("infinity")
ValueError: invalid literal for int() with base 10: 'infinity'

The best place for INFINITY is a constant of the math module.

# Hypothetical #
py> from math import INFINITY
py> 1 < INFINITY
True
py> 99999999999999999 < INFINITY
True

[toc] | [prev] | [next] | [standalone]

#20819

Rick Johnson wrote:

> I get sick and tired of doing this!!!
> 
> if maxlength == UNLIMITED:
>     allow_passage()
> elif len(string) > maxlength:
>     deny_passage()
> 
> What Python needs is some constant that can be compared to ANY numeric
> type and that constant will ALWAYS be larger!

Easily fixed:



class Greatest (object):
    def __cmp__ (self, other):
        if isinstance (other, Greatest):
            return 0
        return 1
        
    def __hash__ (self):
        return id (Greatest)
        
class Least (object):
    def __cmp__ (self, other):
        if isinstance (other, Least):
            return 0
        return -1
        
    def __hash__ (self):
        return id (Least)



	Mel.

[toc] | [prev] | [next] | [standalone]

#20821

On Fri, 24 Feb 2012 10:21:45 -0500, Mel Wilson wrote:

> Rick Johnson wrote:
> 
>> I get sick and tired of doing this!!!
>> 
>> if maxlength == UNLIMITED:
>>     allow_passage()
>> elif len(string) > maxlength:
>>     deny_passage()
>> 
>> What Python needs is some constant that can be compared to ANY numeric
>> type and that constant will ALWAYS be larger!
> 
> Easily fixed:
> 
> 
> 
> class Greatest (object):
>     def __cmp__ (self, other):
>         if isinstance (other, Greatest):
>             return 0
>         return 1
>         
>     def __hash__ (self):
>         return id (Greatest)

__cmp__ no longer exists in Python 3, so this solution could only work in 
Python 2.

Here's a version using rich comparisons:

class Greatest:
    __eq__ = __le__ = lambda self, other: isinstance(other, type(self))
    __ne__ = __gt__ = lambda self, othr: not isinstance(othr, type(self))
    __lt__ = lambda self, other: False
    __ge__ = lambda self, other: True
    __hash__ = lambda self: 42


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20822

On Feb 24, 9:21 am, Mel Wilson <mwil...@the-wire.com> wrote:

> Easily fixed:
>
> [...snip code...]

Yes i could write my own implementation of INFINITY if i wanted,
although i would have returned True and False as apposed to 1 and 0
AND used the identifiers Infinity and Infinitesimal, but i digress :-
P.

However, INFINITY is something i believe a language should provide;
which python does, albeit inconsistently.

[toc] | [prev] | [next] | [standalone]

#20824

On 02/24/2012 08:34 AM, Rick Johnson wrote:
> Yes i could write my own implementation of INFINITY if i wanted,
> although i would have returned True and False as apposed to 1 and 0
> AND used the identifiers Infinity and Infinitesimal, but i digress :-
> P.
> 
> However, INFINITY is something i believe a language should provide;
> which python does, albeit inconsistently.

How do you represent infinity as an binary integer number?  Or are you
suggesting that the integer type (class) be modified to allow an
"infinity" state that really isn't a number at all (could not be stored
as a integer in C)?

Float is a different story because IEEE does define a binary
representation of infinity in the floating-point specification.

I know of no language that has any form of representation of infinity
for integers mainly because there's no way to represent infinity as a
standard twos-compliment binary number.  In a language that deals
directly with types in memory such as C, having an infinity
representation would be possible but would make simple math really hard,
and much slower.

All this reminds me of the original cray supercomputers.  They didn't
use twos compliment for integers so they had two representations of zero
(+0 and -0).  Made programming a bit tricky.  When asked why the cray
didn't just do two's compliment like everyone else, Seymour Cray
responded that when the computer was designed he simply didn't know
about twos compliment.

[toc] | [prev] | [next] | [standalone]

#20839

On Fri, 24 Feb 2012 09:23:08 -0700, Michael Torrie wrote:

> All this reminds me of the original cray supercomputers.  They didn't
> use twos compliment for integers so they had two representations of zero
> (+0 and -0).  Made programming a bit tricky.

While there is only one integer zero, I would like to point out that in 
floating point, there are usually two zeroes, -0.0 and +0.0, and that 
this is by design and a feature, not an accident or a bug.

Well-written floating point functions should keep the sign when they 
underflow, e.g.:

py> 1e-200 * 1e-200
0.0
py> 1e-200 * -1e-200
-0.0

and well-written functions should honour those separate zeroes because 
sometimes it makes a difference.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20825

On 24/02/2012 16:23, Michael Torrie wrote:
> On 02/24/2012 08:34 AM, Rick Johnson wrote:
>> Yes i could write my own implementation of INFINITY if i wanted,
>> although i would have returned True and False as apposed to 1 and 0
>> AND used the identifiers Infinity and Infinitesimal, but i digress :-
>> P.
>>
>> However, INFINITY is something i believe a language should provide;
>> which python does, albeit inconsistently.
>
> How do you represent infinity as an binary integer number?  Or are you
> suggesting that the integer type (class) be modified to allow an
> "infinity" state that really isn't a number at all (could not be stored
> as a integer in C)?

The C integer bit doesn't matter since e.g.
 >>> 
a=10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 >>> a
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

And no, I'm not going to calculate how much memory I'd need to store a 
string that's this long :)

> Float is a different story because IEEE does define a binary
> representation of infinity in the floating-point specification.
>
> I know of no language that has any form of representation of infinity
> for integers mainly because there's no way to represent infinity as a
> standard twos-compliment binary number.  In a language that deals
> directly with types in memory such as C, having an infinity
> representation would be possible but would make simple math really hard,
> and much slower.
>
> All this reminds me of the original cray supercomputers.  They didn't
> use twos compliment for integers so they had two representations of zero
> (+0 and -0).  Made programming a bit tricky.  When asked why the cray
> didn't just do two's compliment like everyone else, Seymour Cray
> responded that when the computer was designed he simply didn't know
> about twos compliment.

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#20840

On 02/24/2012 09:59 AM, Mark Lawrence wrote:
> The C integer bit doesn't matter since e.g.
>  >>> 
> a=10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>  >>> a
> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
> 
> And no, I'm not going to calculate how much memory I'd need to store a 
> string that's this long :)

Sure but that doesn't answer the question posed.  How does Rick plan to
represent an infinite integer? Obviously you've shown that with an
infinite amount of memory we could do it quite easily.  But baring that,
how does Rick suggest we should represent an infinite integer?

[toc] | [prev] | [next] | [standalone]

#20841

On Sat, Feb 25, 2012 at 10:16 AM, Michael Torrie <torriem@gmail.com> wrote:
> Sure but that doesn't answer the question posed.  How does Rick plan to
> represent an infinite integer? Obviously you've shown that with an
> infinite amount of memory we could do it quite easily.  But baring that,
> how does Rick suggest we should represent an infinite integer?

Barring a suggestion from Rick, I think we should define the number 8
to be greater than all other integers. After all, Rick's very much in
favour of evolution, and what would better depict the evolution of
this glorious language than this notation, showing that the infinity
symbol is now walking erect!

ChrisA

[toc] | [prev] | [next] | [standalone]

#20842

On 24/02/2012 23:16, Michael Torrie wrote:
> On 02/24/2012 09:59 AM, Mark Lawrence wrote:
>> The C integer bit doesn't matter since e.g.
>>   >>>
>> a=10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>>   >>>  a
>> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>
>> And no, I'm not going to calculate how much memory I'd need to store a
>> string that's this long :)
>
> Sure but that doesn't answer the question posed.  How does Rick plan to
> represent an infinite integer? Obviously you've shown that with an
> infinite amount of memory we could do it quite easily.  But baring that,
> how does Rick suggest we should represent an infinite integer?

I understand that a Python integer can run to infinity.  Quite how the 
illustrious rr manages to test for the length of a string that's already 
used all of the memory on his system has baffled me, but I'm sure that 
all the people who frequent this list with their Phds, MScs or whatever 
will soon correct me.

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#20862

On Feb 24, 6:35 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote:

> I understand that a Python integer can run to infinity.  Quite how the
> illustrious rr manages to test for the length of a string that's already
> used all of the memory on his system has baffled me,

When did i ever say that i would need a string who's length is
INFINITY? In fact, i don't. My example was just that, as SIMPLIFIED
example of the problem that was the genesis of my question. In my
"real world" problem, i don't expect the string to EVER be more than
double digits in length. But as any good programmer knows, you never
want to solve problems as globally as possible. I need to do
comparisons on strings now, but maybe integers later, or who knows.
INFINITY comparisons are useful in many places.

> but I'm sure that
> all the people who frequent this list with their Phds, MScs or whatever
> will soon correct me.

I don't believe you'd need a Phd to understand my problem.

[toc] | [prev] | [next] | [standalone]

#20843

On 24/02/2012 23:16, Michael Torrie wrote:
> On 02/24/2012 09:59 AM, Mark Lawrence wrote:
>>  The C integer bit doesn't matter since e.g.
>>   >>>
>>  a=10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>>   >>>  a
>>  10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>
>>  And no, I'm not going to calculate how much memory I'd need to store a
>>  string that's this long :)
>
> Sure but that doesn't answer the question posed.  How does Rick plan to
> represent an infinite integer? Obviously you've shown that with an
> infinite amount of memory we could do it quite easily.  But baring that,
> how does Rick suggest we should represent an infinite integer?

We already have arbitrarily long ints, so there could be a special
infinite int singleton (actually, 2 of them, one positive, the other
negative).

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web