Hi, Rob.
Sorry I'm so slow in getting back to you.... there's too much to read
and I can't catch up with the backlog. But I wanted to reply to you, at
least as I think you made some very good points that make more sense to
me than other people's replies.
On 01/15/2015 09:54 AM, Rob Gaddi wrote:
On Wed, 14 Jan 2015 23:23:54 -0800
Andrew Robinson <andr...@r3dsolutions.com> wrote:
Boolean algebra has two values: true and false, or 1 and 0, or humpty
and dumpty, or whatever you like to call them.
You're speaking to an Electrical engineer. I know there are 10 kinds of
people, those who know binary and those who don't. But you're way off
base if you think most industrial quality code for manipulating boolean
logic uses (or even can be restricted to use) only two values and still
accomplish their tasks correctly and within a finite amount of time.
[snip]
Absolutely it does and can. You store anything that's non-boolean in a
non-boolean value, and keep it as fuzzy as you like. But at the end of
the day, an if statement has no "kinda". You do, or you don't. 1 or
0. And so you must ultimately resolve to a Boolean decision.
Yes -- at the *point* of decision; a logic expression always collapses
to a True or False value.
metastability must always resolve to a final value, or else the system
will malfunction.
(Although cache branch prediction can choose to take both paths, one of
them eventually gets flushed).
That's the same in digital circuitry as well, even with uncertainty
meta information appended to it.
You have to ask
if x = '1'
or
if (x = '1') or (x = 'H')
Because you are comparing one value of an enumerated type against
others, the result of that '=' operation being, in fact, a boolean,
defined again on the range (true, false).
That's fine, too. An enumerated type is still a semantic subtype, if
not a formal one recognized by type().
So -- I don't see that you are arguing the two types must be
semantically distinct until the if statement is actually executed, at
which point a true/false decision must be made. I totally agree,
digital systems must make a final decision at some point.
Your example, here, BTW: is almost exactly what I was talking about in
the original few posts of the thread; Eg: a way to comparing the
uncertainty value returned by a float's subtype's compare -- against an
enumerated bool meta-type to resolve that value to a final True or False
for an if statement.
[snip]
We've discovered that we live in a quantum-mechanical universe -- yet
people still don't grasp the pragmatic issue that basic logic can be
indeterminate at least some of the time ?!
But actions can't be. You're not asking the software about it's
feelings, you're telling it to follow a defined sequence of
instructions. Do this, or don't do this.
Right!
And, in quantum mechanics -- a wave packet 'collapses' to one and only
one final decision.
So, I agree with you; and let me get your opinion:
I admit, there can be good reasons to prevent direct subtyping; I know,
for example, that in C++ no base class is allowed to be subtyped -- but
not because of OOP concerns or ideology about bool; I'm fairly sure the
reason had something to do with difficulties in implementing base class
overloading in the compiler due to compile time binding issues.
But that's useless reasoning with an interpreter like Python which
*already* allows subtyping of at least some base classes and does
runtime type() tests instead of compile time tests.
So: The major question I have been asking about is 'when' must the
decision be made, and 'why' (besides oversight / copying other
languages) is the a bool variable/object in Python designed in such a
way as to force the decision to be made early, rather than late -- and
prevent bool from carrying extended information about the bool itself;
eg: meta information -- so that the final decision can be delayed until
an 'if' statement is actually used, and the context is known:
eg:
x = a > b # x is an uncertain compare that generates meta data along
with a boolean True or False.
# this value 'x' can be used in two ways:
if x > bool_meta_threshold: # if statement's branch chosen by meta data.
if x: # If statement's branch chosen by default/base bool value
contained in x, meta data is ignored.
I don't know what you mean about composition vs. sub-classing.
Would you care to show an example of how it would solve the problem and
still allow hierarchical sorting ?
I don't see how you can get pre-existing python functions (like sort,
max, and min) to accept a complex bool value and have that value
automatically revert to a True or False in an intelligent manner without
overloading the operators defined in some class -- somewhere -- to
operate on the data the class contains.
How do you intend to achieve that with this -- composition -- thing you
mentioned ?
You'd do it something like this.
class _clogic(object):
"""Represents 'continuous' logic. For any given instance,
there is a threshold value between 0 and 1 that delineates True from
False, with 0 being entirely False and 1 being entirely True.
"""
def __init__(self, value, threshold=0.5):
self.value = value
self.threshold = threshold
def __bool__(self):
return value > threshold
__nonzero__ = __bool__
def __eq__(self, other):
if other in (True, False):
return bool(self) == other
try:
return self.value == other.value
except AttributeError:
return self.value == other
def __and__(self, other):
return self.__class__(
min(self.value, other.value),
self.threshold)
def __or__(self, other):
return self.__class__(
max(self.value, other.value),
self.threshold)
No need to subclass bool, you just use the __bool__ (or __nonzero__)
methods to say "Alright, well when you do finally have to make a
decision on this thing, here's how you make it. And obviously, you can
add on as many additional data members to carry additional information
as your heart desires.
Hmmm.... That's not much different than the tuple object I made as a
container and which Ian complained about. In fact, you did overload the
comparison operators, just like I did...
Let's see: Ian first complained that I wasn't subclassing in one
example, and then he next complained that he thought I was subclassing
*too quickly* (like he forgot that I didn't subclass before) because of
something to do with 'bool' -- and then he mentioned I wasn't using
composition....
But now --I wonder why it didn't click with him that I avoided
subclassing bool in my tuple example (at all) -- because I was clearly
making a general purpose container (composition pattern) to hold a bool
and uncertainty value.
So -- I really don't think there is anything wrong with what I already
did, except perhaps the name of the class was misleading; for it is
really capable of being general purpose.... not just 'bool'...
In any event, thanks for the example; but it still leaves me with the
distinct feeling that I'm damned if I do -- and damned if I don't...
LOL.
--
https://mail.python.org/mailman/listinfo/python-list
