Comparisons and sorting of a numeric class....

[Andrew Robinson]

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 <andrew3 at 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.