Comparisons and sorting of a numeric class....

[Ian Kelly]

On Fri, Jan 23, 2015 at 4:46 AM, Andrew Robinson
<andrew3 at r3dsolutions.com> wrote:
> Although, I have to laugh -- Verilog can syntheze a CPU -- implement memory
> -- and then load a program and run python on the virtual machine.   When the
> pentium was first developed, I watched as Intel actually booted up MS-DOS
> under using Xilinx chips to run the verilog program's output they could
> physically run anything a pentium processor could run.  That's *IS* what I
> consider "general purpose".

Turing-complete and "general purpose" are not the same. Would you
write a web application or a banking system in Verilog? Using Verilog
to host a virtual machine that runs such a program written in some
other language doesn't count; the actual application is still written
in that other language. You could implement the same Pentium virtual
machine in Brainf*** if you chose, but it will still be an esoteric
language, not a general-purpose one.

> But you're sort of confounding my need for type information in my new class
> as a way to advertise compatability with bool, with subclassing -- which is
> only one way that I was exploring to get the 'type' name attached to the new
> object;  That's a mistake that D'Aprano seems to be repetitively making as
> well.

No, I'm just responding specifically to the complaint you've been
making about not being able to subclass bool.

> C++ *DOES* allow the necessary kind of type checking and subclassing for
> what I need to do in spite of not having a subclass mechanism built into the
> language for base types; eg: C++ allows a semantic subclass to be
> constructed which can be typecast to a bool for compatibility, but otherwise
> presents extra data and the type the enhanced object reports is irrelevant.
> As I've mentioned before, people can do object oriented programming in C,
> So, to satisfy your curiosity -- I'll show you a mixed C/C++ example, where
> I make a semantic subclass that has five values AllFalse, PartFalse,
> Uncertain, PartTrue, True ; and these five values will have a typeid() of
> bool and be 100% compatible with legacy C++ bool; but upon request, they
> these 'bool' types will re-cast into a semantic subtype that provides
> additional certainty data.
>
> See the program at end of e-mail.  It compiles with gcc 4.8.2 with no
> warnings;  g++ filename.cc ; ./a.out

I'm not convinced this is generally safe. Unaware client code that
uses these values will lose the certainty values, even if the values
are later passed back into aware code.

const bool& is_p_equal_np() {
    return Uncertain;
}

void some_other_sbool_aware_code(const SBool& value) {
    if (SBool(PartFalse) < value) {
        cout << "Success: value is greater than PartFalse" << endl;
    } else {
        cout << "Failure: value is not greater than PartFalse" << endl;
    }
}

void some_sbool_unaware_code() {
    bool uncertainty = is_p_equal_np();
    some_other_sbool_aware_code(uncertainty);
}

Calling some_sbool_unaware_code() prints the Failure message because
the bool reference gets lost, and the typecast to SBool in
some_other_sbool_aware_code consequently results in AllFalse.

To the extent that this does work, it seems to be based on pointer
arithmetic, which is intentionally and explicitly something that
Python doesn't support. If Python had the means to distinguish name
bindings, then I see no other reason the same approach couldn't work.

> But let me explain a bit more why I'm picking on Python:  For even if we set
> the electronic engineering concerns aside that I've raised (and they are
> valid, as OOP is supposed to model reality, not reality be bent to match
> OOP) -- People's facile explanations about why Python's version of bool is
> the way it is -- still bothers me here in the python mail list -- because
> people seem to have a very wrong idea about bool's nature as a dualton being
> somehow justified solely by the fact that there are only two values in
> Boolean logic; For, singletons style programming is not justified by the
> number of values an object has in reality -- And I know Charles bool didn't
> use singletons in his algebra,  -- just read his work and you'll see he
> never mentions them or describes them, but he does actually use dozens of
> *instances* of the True and False objects he was talking about -- for the
> obvious reason that he would have needed special mirrors, dichroic or
> partially silvered, to be even able to attempt to make one instance of True
> written on paper show up in multiple places; And that's silly to do when
> there's no compelling reason to do it.

Writing down the word true multiple times doesn't create multiple
"instances" of the mathematical true. Mathematically, they're all the
same platonic object.

> As far a subtyping goes; The very fact that Guido used subtyping to create
> bool in the first place (subtype of int), precludes any real claim that bool
> should not itself be subclassable just because bools only have two values;
> I mean, seriously --  Guido's 'strict' Bool is already an impure form of OOP
> that is borderline hypocrisy, as it can '+' to 2 or 3... and many other
> things;  and worse I've just come across a couple of papers which suggest
> that Guido doesn't like subclassing when Composite object structures could
> be used instead to replace the subclass 'is' relationship with a 'has a'
> relationship.  So -- if that's the case, why isn't bool a composite to begin
> with ?  eg: Guido's programming guides must be read with a caveat 'do what
> Guido says and not what Guido does' ?!

bool is a subclass of int for backward compatibility. The bool type
wasn't added to Python until version 2.3. Before that, Python used 0
and 1 (hence why the __bool__ method is named __nonzero__ in 2.x).
Because bool subclasses int, it still does; it just has a more
specific type and names for them as well.