'1' + 1 ==> True ???

[Nicola Mingotti]

Hi ,

I obtained this result :
------

'1' > 1 True
------
with python2.2.3 and 2.3.3 .
(Yes , in python 2.2 i get 1 instead of True)

but
------ '1' + 1 TypeError
-------

and
-----------------------------'1'.__gt__._ _doc__

'x.__gt__(y) <==> x>y'
-----------------------------

so i'm a little puzzled :)

Is this a bug or is there a very good reason
to this strange behaviour ?

Thank you all .

bye .

(Please forgive english mistakes)

[Peter Hansen]

Nicola Mingotti wrote:

This is all what i wanted to know .
Even if i can't see it's utility , at least
for the behaviour of the comparison between strings
and numbers with every string considered greater of every int .

One example of its utility: in a sort algorithm, you would want to be
able to produce consistent orderings of items in a list, even if some of
the items were strings, and others were integers. (That may in fact be
its _only_ utility, for all I know.)

-Peter

[Isaac To]

>>>>> "Peter" == Peter Maas <fp********@net scape.net> writes:

Peter> Nicola Mingotti schrieb:

2) Like C -----> Char is converted to int #include<stdio. h> int
main(){ printf("%i %i", '1' > 1 , '1' + 1 ); return 0;
}

Peter> That's not really a conversion. '1' is 0x31 in memory and 0x31 >
Peter> 1.

That's really not a conversion, but not because '1' is 0x31 in memory. It
is because C defines '1' to be equivalent to (in every respect, including
type) the integer to represent it---which is 49 (0x31) in most computers we
use today. So in C (and our current platforms), '1' means 49 and 49 means
'1'. Adding '1' with '1' give you 98, and adding "hello" and '1' gives you
a pointer to the 49-th byte after the beginning of "hello". The size of '1'
is 4. C++ is a bit better in the last respect: '1' is of size one byte
rather than 4 bytes in C++ (so in C++ language, char is a short integer).

Peter> C simply compares memory locations, so comparisons are perhaps
Peter> even be machine dependent.

Untrue. It does not try to compare "memory location". Instead it is simply
comparing based on the values of the two operands. Since C defines '1' to
be its representationa l value which is 49, and 49 is greater than 1, the
comparison result is non-zero.

Peter> Unlike C, Python's comparison results for different types are
Peter> defined in a strange but archicture independent way, see Python
Peter> Library Reference 2.3.3.

Also untrue. Python's comparison result is dependent on implementation, so
even in the same computer, two different Python implementation can give you
different results; and you cannot make any assumption in different
platforms.

Regards,
Isaac.

[Peter Maas]

Isaac To schrieb:

Peter> That's not really a conversion. '1' is 0x31 in memory and 0x31 >
Peter> 1.

That's really not a conversion, but not because '1' is 0x31 in memory. It
is because C defines '1' to be equivalent to (in every respect, including
type) the integer to represent it---which is 49 (0x31) in most computers we
use today.
The mapping of '1' to 0x31 is defined by ASCII which is used by C. If a C
instruction retrieves a char it reads data from an adress and if there is
a 0x31 stored at the adress C treats it as '1'. My short form of this is
"'1' is 0x31 in memory".
Peter> Unlike C, Python's comparison results for different types are
Peter> defined in a strange but archicture independent way, see Python
Peter> Library Reference 2.3.3.

Also untrue. Python's comparison result is dependent on implementation, so
even in the same computer, two different Python implementation can give you
different results; and you cannot make any assumption in different
platforms.
I didn't talk about different programs but different machines (architecture).
Python Standard Library (Comparison) has this

Implementation note: Objects of different types except numbers are
ordered by their type names;

Mit freundlichen Gruessen,

Peter Maas

Regards,
Isaac.

--
Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplu sr.de
-------------------------------------------------------------------

[Dan Bishop]

Peter Hansen <pe***@engcorp. com> wrote in message news:<pd******* *************@p owergate.ca>...

Nicola Mingotti wrote:

This is all what i wanted to know .
Even if i can't see it's utility, at least
for the behaviour of the comparison between strings
and numbers with every string considered greater of every int .

One example of its utility: in a sort algorithm, you would want to be
able to produce consistent orderings of items in a list, even if some of
the items were strings, and others were integers. (That may in fact be
its _only_ utility, for all I know.)

Then, instead of having broken operators in the language, why not
redefine the sort routine?

def _transform(x): .... if isinstance(x, (int, long, float)):
.... return ('', x)
.... elif isinstance(x, complex):
.... return ('', x.real, x.imag)
.... else:
.... return (type(x).__name __, x)
.... def _untransform(tp l): .... if len(tpl) == 3:
.... return complex(tpl[1], tpl[2])
.... else:
.... return tpl[1]
.... def sortedCopy(lst) : .... transformedList = [_transform(x) for x in lst]
.... transformedList .sort()
.... return [_untransform(x) for x in transformedList]
.... sortedCopy([2L, 'spam', 42, 2+1j, 3.14159])

[2L, (2+1j), 3.1415899999999 999, 42, 'spam']

[Jeff Epler]

On Thu, Mar 18, 2004 at 08:46:04PM +0100, Peter Maas wrote:

The mapping of '1' to 0x31 is defined by ASCII which is used by C. If a C
instruction retrieves a char it reads data from an adress and if there is
a 0x31 stored at the adress C treats it as '1'. My short form of this is
"'1' is 0x31 in memory".

Wrong. (surely C99 didn't change this)

C doesn't require ASCII as a source-encoding nor as the character
encoding on the target machine.

C's requirements for character set are pretty minimal. The letters and
digits are all required (can someone tell me whether lower-case is
required?), as well as a small set of punctuation, newline, and space.
(Are any of tab, carriage return, vertical tab, or formfeed required?)

This may be the required set of punctuation (the rest are available as
digraphs or trigraphs:
! " % & ' ( ) * + , - . / : ; < = > ? _

My source for the set of punctuation is:
http://csit1cwe.fsu.edu/extra_link/v...f/rulngchr.htm

Jeff

[Erik Max Francis]

Jeff Epler wrote:

This may be the required set of punctuation (the rest are available as
digraphs or trigraphs:
! " % & ' ( ) * + , - . / : ; < = > ? _

My source for the set of punctuation is:
http://csit1cwe.fsu.edu/extra_link/v...f/rulngchr.htm

Note there's a subtle distinction here; this is the list of required
punctuation _in C source code_. It doesn't have to be the same set of
required punctuation of the character set with which a C program is
running (although obviously usually it will be). Furthermore, the
original poster didn't have anything to say about punctuation at all, so
I'm not even sure why you're bringing this up.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ I do not promise to consider race or religion in my appointments.
I promise only that I will not consider them. -- John F. Kennedy

[Isaac To]

>>>>> "Peter" == Peter Maas <fp********@net scape.net> writes:

Peter> The mapping of '1' to 0x31 is defined by ASCII which is used by
Peter> C. If a C instruction retrieves a char it reads data from an
Peter> adress and if there is a 0x31 stored at the adress C treats it as
Peter> '1'. My short form of this is "'1' is 0x31 in memory".

In the original post, the literal '1' need not be (and probably is not)
stored in memory at all. In this case you have no "address". But that is
subtle details. The main point is still that, in the world of C, '1' and 49
are completely indistinguishab le *values*. Or put it in another way, in C,
a character literal does *not* represent a "character" . Instead, the
literal '1' is just "the *number* which, by the most common convention used
by the computer hardware, is interpreted as the character representing the
arabic numeral 'one'". It is a *number*. That's the reason why you can add
up 1 and '1'. Not because C "ignores type information and care only the
memory". (Try adding up 2.5 and "1").

It is an important distinction: even in C we talk about the abstraction of
expression, and the abstraction of character literal is a number, not a
"character" in the eye of a regular Python programmer.

Peter> I didn't talk about different programs but different machines
Peter> (architecture). Python Standard Library (Comparison) has this

Peter> Implementation note: Objects of different types except numbers
Peter> are ordered by their type names;

As you said, it is "implementa tion note". Also, about C your argument is
that different platforms can have different encoding in their characters,
and thus different ordering. Since type names are expressed in characters,
it follows directly that names of types in Python also has such dependency.

Regards,
Isaac.

[Peter Maas]

Jeff Epler schrieb:

On Thu, Mar 18, 2004 at 08:46:04PM +0100, Peter Maas wrote:

The mapping of '1' to 0x31 is defined by ASCII which is used by C. If a C
instruction retrieves a char it reads data from an adress and if there is
a 0x31 stored at the adress C treats it as '1'. My short form of this is
"'1' is 0x31 in memory".

Wrong. (surely C99 didn't change this)

C doesn't require ASCII as a source-encoding nor as the character
encoding on the target machine.

ASCII is a recipe to map characters to integers in the range [0,127].
Does C assign the same integer value as ASCII to a character literal
(single printable character or \xhh enclosed in simple quotes)?

If the answer is yes then convert the question to a statement and
you get what I meant. :)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplu sr.de
-------------------------------------------------------------------

[Peter Maas]

Isaac To schrieb:

Peter> I didn't talk about different programs but different machines
Peter> (architecture). Python Standard Library (Comparison) has this

Peter> Implementation note: Objects of different types except numbers
Peter> are ordered by their type names;

As you said, it is "implementa tion note". Also, about C your argument is
that different platforms can have different encoding in their characters,
and thus different ordering. Since type names are expressed in characters,
it follows directly that names of types in Python also has such dependency.

You are right. I give up :)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplu sr.de
-------------------------------------------------------------------