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


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

Re: Logic problem: need better logic for desired thruth table.

Started byChris Angelico <rosuav@gmail.com>
First post2015-05-29 13:48 +1000
Last post2015-05-29 08:48 -0400
Articles 3 — 3 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Logic problem: need better logic for desired thruth table. Chris Angelico <rosuav@gmail.com> - 2015-05-29 13:48 +1000
    Re: Logic problem: need better logic for desired thruth table. alister <alister.nospam.ware@ntlworld.com> - 2015-05-29 11:41 +0000
      Re: Logic problem: need better logic for desired thruth table. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-29 08:48 -0400

#91424 — Re: Logic problem: need better logic for desired thruth table.

FromChris Angelico <rosuav@gmail.com>
Date2015-05-29 13:48 +1000
SubjectRe: Logic problem: need better logic for desired thruth table.
Message-ID<mailman.154.1432871339.5151.python-list@python.org>
On Fri, May 29, 2015 at 1:20 PM,  <random832@fastmail.us> wrote:
> The possibility of spelling these with the comparison operators, as some
> have suggested, is a consequence of Python's implementation where True
> == 1 and False == 0. In other languages bool may not be relatable (or at
> least not orderable), or False may be == -1.

True. That said, though, using 0 for False and 1 for True is easily
the most common convention in use today, and the next most likely case
is that comparing booleans would give a simple and immediate error. So
it's most likely to be safe to do. Cross-language compatibility is a
tricky thing anyway; there are all sorts of odd edge cases, even with
otherwise-similar languages (Pike and Python, for instance, have
slightly different handling of slice ranges), so anything that's done
in Python is meant to be interpreted with Python semantics.

ChrisA

[toc] | [next] | [standalone]


#91448

Fromalister <alister.nospam.ware@ntlworld.com>
Date2015-05-29 11:41 +0000
Message-ID<mk9j9i$ejd$1@speranza.aioe.org>
In reply to#91424
On Fri, 29 May 2015 13:48:55 +1000, Chris Angelico wrote:

> On Fri, May 29, 2015 at 1:20 PM,  <random832@fastmail.us> wrote:
>> The possibility of spelling these with the comparison operators, as
>> some have suggested, is a consequence of Python's implementation where
>> True == 1 and False == 0. In other languages bool may not be relatable
>> (or at least not orderable), or False may be == -1.
> 
> True. That said, though, using 0 for False and 1 for True is easily the
> most common convention in use today, and the next most likely case is
> that comparing booleans would give a simple and immediate error. So it's
> most likely to be safe to do. Cross-language compatibility is a tricky
> thing anyway; there are all sorts of odd edge cases, even with
> otherwise-similar languages (Pike and Python, for instance, have
> slightly different handling of slice ranges), so anything that's done in
> Python is meant to be interpreted with Python semantics.
> 
> ChrisA

in the past True has even been -1 with 0 as false
(all bits set in a signed integer)




-- 
I use technology in order to hate it more properly.
		-- Nam June Paik

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


#91452

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2015-05-29 08:48 -0400
Message-ID<mailman.177.1432903758.5151.python-list@python.org>
In reply to#91448
On Fri, 29 May 2015 11:41:38 +0000 (UTC), alister
<alister.nospam.ware@ntlworld.com> declaimed the following:

>On Fri, 29 May 2015 13:48:55 +1000, Chris Angelico wrote:
>
>> On Fri, May 29, 2015 at 1:20 PM,  <random832@fastmail.us> wrote:
>>> The possibility of spelling these with the comparison operators, as
>>> some have suggested, is a consequence of Python's implementation where
>>> True == 1 and False == 0. In other languages bool may not be relatable
>>> (or at least not orderable), or False may be == -1.
>> 
>> True. That said, though, using 0 for False and 1 for True is easily the
>> most common convention in use today, and the next most likely case is
>> that comparing booleans would give a simple and immediate error. So it's
>> most likely to be safe to do. Cross-language compatibility is a tricky
>> thing anyway; there are all sorts of odd edge cases, even with
>> otherwise-similar languages (Pike and Python, for instance, have
>> slightly different handling of slice ranges), so anything that's done in
>> Python is meant to be interpreted with Python semantics.
>> 
>> ChrisA
>
>in the past True has even been -1 with 0 as false
>(all bits set in a signed integer)

	And in VAX/VMS system return codes, odd numbers were "success/info" and
even numbers "failure/warning" -- and VAX F77 did Boolean tests on just the
least significant bit... So it wasn't even just a case of zero/non-zero.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]


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


csiph-web