Isn't bool __invert__ behaviour "strange"?

[Saizan]

Why subclassing bool from int either __invert__ or __neg__ haven't been
overrided to produce a boolean negation? I suspect backwards
compatibility or something alike, but I still wonder..

And since bool can't be subclassed, to have a type like bool but with
boolean negation what do you suggest? A wrapper maybe?


(I would use it so I can evaluate user-defined boolean expression
creating istances of his/her variables in my namespace and than eval()
his/her expression)

 

[Bjoern Schliessmann]

Why subclassing bool from int either __invert__ or __neg__ haven't
been overrided to produce a boolean negation?

I wonder what -True or -False should evaluate to.

Regards,


Björn

 

[Saizan]

I wonder what -True or -False should evaluate to.

Regards,


Björn

Well in boolean notation -True == False and -False == True, actually
you may prefer ¬ or a line over the term, but since there's no such
operator in python I think we should use "-" which is also the operator
used by Bool himself in his formulation for negation which was 1-x.
Now that I think of it 1-x should work as a negation in Python, too,
since True == 1 and False == 0, but it would be a little annoying to
write expressions in this way.

 

[John Roth]

Why subclassing bool from int either __invert__ or __neg__ haven't been
overrided to produce a boolean negation? I suspect backwards
compatibility or something alike, but I still wonder..

And since bool can't be subclassed, to have a type like bool but with
boolean negation what do you suggest? A wrapper maybe?


(I would use it so I can evaluate user-defined boolean expression
creating istances of his/her variables in my namespace and than eval()
his/her expression)

The not operator and the bool() builtin produce
boolean results. Since bool is a subclass of int,
all the integer operations will remain integer
operations. This was done for backwards
compatability, and is unlikely to change in the 2.x
series.

I don't remember if this is supposed to change
in 3.0. See PEP 3100 and 3099.

John Roth

John Roth

 

[Carsten Haese]

I wonder what -True or -False should evaluate to.

Well in boolean notation -True == False and -False == True, actually
you may prefer ¬ or a line over the term, but since there's no such
operator in python [...]

It's called "not":
True

-Carsten

 

[Bjoern Schliessmann]

Well in boolean notation -True == False and -False == True,
actually you may prefer ¬ or a line over the term,

(I can't remember reading "-" (minus) for a standard boolean
negation operator anywhere. Even C/C++ uses "!".)

but since there's no such operator in python I think we should
use "-"

Stop! What about the "not" operator? It's Python's operator for
negation.

which is also the operator used by Bool himself in his formulation
for negation which was 1-x.

Boole's original formulation uses some weird mathematical things to
emulate "not", "and" and "or". Focus lies on "mathematical" here.

Now that I think of it 1-x should work as a negation in Python,
too, since True == 1 and False == 0, but it would be a little
annoying to write expressions in this way.

And "a little" unreadable

Regards,


Björn

 

[Saizan]

The not operator and the bool() builtin produce
boolean results. Since bool is a subclass of int,
all the integer operations will remain integer
operations. This was done for backwards
compatability, and is unlikely to change in the 2.x
series.

Ok, shame on me, I completely overlooked "not" and it surprises myself
because it's not like I haven't used it, I just didn't see "not" as an
operator, maybe because i can't find a __not__ method in bool class.
(Is it hidden somewhere or is computed in some other way?)

(However (not x) whould be as annoying as 1-x even if a little more
readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))
Maybe direct eval is just the wrong way of doing this, I should look
for or make muParser bindings for Python instead..)

 

[Bjoern Schliessmann]

(However (not x) whould be as annoying as 1-x even if a little
more readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))

Did you notice that you use bitwise AND and OR here? How about

not (not x) and (not y) or (not (z or v))

(or what is "!" supposed to mean?)

BTW, not's binding is stronger than and's (IIRC). So

not (not x) and (not y)

mutates to

x and (not y)

Regards,


Björn

 

[Paul McGuire]

Ok, shame on me, I completely overlooked "not" and it surprises myself
because it's not like I haven't used it, I just didn't see "not" as an
operator, maybe because i can't find a __not__ method in bool class.
(Is it hidden somewhere or is computed in some other way?)

(However (not x) whould be as annoying as 1-x even if a little more
readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))
Maybe direct eval is just the wrong way of doing this, I should look
for or make muParser bindings for Python instead..)

What about __nonzero__?

class IsOdd(object):
def __init__(self,n):
self.val = n

def __nonzero__(self):
return self.val % 2

for i in range(4):
if IsOdd(i):
print i,"is odd"
else:
print i,"is even"

Prints:
0 is even
1 is odd
2 is even
3 is odd


-- Paul

 

[Saizan]

Thanks for pointing that out ( the "!" is a misstyped "|"), my classes
of discrete math have warped my mind with a mix of various non-C-style
operators notation, I never use bitwise operation and this is just a
bad day for thinking about things..
However I figured out one thing, Python's logic notation is readable
and complete but not compact. (which is fine for programming, and
that's the aim, isn't it?)

 

[Bjoern Schliessmann]

Thanks for pointing that out ( the "!" is a misstyped "|"),

Ah, I suspected so.

my classes of discrete math have warped my mind with a mix of
various non-C-style operators notation, I never use bitwise
operation and this is just a bad day for thinking about things..

Hehe, I know those days

However I figured out one thing, Python's logic notation is
readable and complete but not compact. (which is fine for
programming, and that's the aim, isn't it?)

Depends. IMHO, readability is fine for programming. In my C++ code,
it happens so often that I forget or overread a "!". And if I want
to understand my functions later on, my brain quite wrinkles
looking at parentheses, !s, &&s and ||s.

Regards,


Björn

 

[MonkeeSage]

Hi Saizan,

I don't really see anything wrong with creating a custom class for
evaluating those kinds of logical statements. It does make the code for
statements more concise and easy to follow (with less binding
ambiguity). Mabye something like this would help:

class logic(int):
def __sub__(self):
return logic(not self)
def eval(self, statement):
return bool(statement)
def make_logical(self, *args):
out = []
for arg in args:
out.append(logic(arg))
return out

l = logic()
# init a buch of variables (or a list) at once
x, y, z = l.make_logical(True, False, True)
# or one at a time
v = logic(False)
# evaluate a statement
print l.eval((x and y) or (-z or -v)) # True

Regards,
Jordan

 

[Steve Holden]

Hi Saizan,

I don't really see anything wrong with creating a custom class for
evaluating those kinds of logical statements. It does make the code for
statements more concise and easy to follow (with less binding
ambiguity). Mabye something like this would help:

class logic(int):
def __sub__(self):
return logic(not self)
def eval(self, statement):
return bool(statement)
def make_logical(self, *args):
out = []
for arg in args:
out.append(logic(arg))
return out

l = logic()
# init a buch of variables (or a list) at once
x, y, z = l.make_logical(True, False, True)
# or one at a time
v = logic(False)
# evaluate a statement
print l.eval((x and y) or (-z or -v)) # True

Is this a serious suggestion, or simply an attempt at sardonic obscurantism?

regards
Steve

 

[MonkeeSage]

Is this a serious suggestion, or simply an attempt at sardonic obscurantism?

Well, I was being serious, but now I'm afraid to see what kind of evils
I've acidentally stepped in, heh!? I honestly don't see anything wrong
with creating a DSL for a given problem domain. Where did I go astray?

Regards,
Jordan

 

[Lawrence D'Oliveiro]

In my C++ code,
it happens so often that I forget or overread a "!". And if I want
to understand my functions later on, my brain quite wrinkles
looking at parentheses, !s, &&s and ||s.

Which is why C++ allows "not", "and" and "or".

 

[Lawrence D'Oliveiro]

I don't really see anything wrong with creating a custom class for
evaluating those kinds of logical statements. It does make the code for
statements more concise and easy to follow (with less binding
ambiguity).

Why not express everything in Conjunctive Normal Form?

 

[MonkeeSage]

Why not express everything in Conjunctive Normal Form?

Because: (¬Can add all the literal operators ∧ Already existed a
concise/unambiguous mechanism for all but negation) ├ Used existing
scheme but added concise/unambiguous negation mechanism.

Regards,
Jordan

 

[MonkeeSage]

Why not express everything in Conjunctive Normal Form?

[snip]

Oh, you meant the actual form. Duh! Yeah, that would work. For some
reason I was thinking you were asking why I didn't implement the
standard symbols, sorry.

Regards,
Jordan

 

[Bjoern Schliessmann]

Which is why C++ allows "not", "and" and "or".

Is this standards compliant? My reference (book) doesn't contain it,
but g++ allows it.

Regards,


Björn

 

[MonkeeSage]

Is this standards compliant? My reference (book) doesn't contain it,
but g++ allows it.

"The C++ standard provides _operator keywords_ (Fig. 21.8) that can be
used in place of several C++ operators." (Deitel & Deitel, 2001; 1082).

Regards,
Jordan