How come true, false don't support <=> (comparison) operator?

[Cilibrar1]

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

I have been surprised at having to make my own versions of these
functions for use in an Array of boolean values. Some people suggest
that I would be better off using integers and bitmasks, but the Array
has many methods that I need to use; for example, the <=> operator
as applied to booleans:
a = Array.new(10, true)
b = Array.new(10, false)
It would be convenient if I could compare the two bitstrings
lexicographically.
a <=> b
Another common thing I find myself needing is to sort these, like:
a.sort!

I have used the following code to make these operations work:
class TrueClass
def to_i() 1 end
def <=>(b)
to_i <=> b.to_i
end
end
class FalseClass
def to_i() 0 end
def <=>(b)
to_i <=> b.to_i
end
end

Would anything break if this were made a part of the standard package?
In thinking about possibilities for future versions of Ruby, perhaps
it would make sense to have TrueClass and FalseClass both derive
from a common base class, say, BooleanClass.

I would enjoy hearing your thoughts as a followup in this forum,

Rudi Cilibrasi

[David_Alan_Black1 (David Alan Black)]

Hello –

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

I guess one reason is that it’s not clear (to me, anyway) why true
would be > false, or false > true. Is there ordinality to Boolean
values?

I have been surprised at having to make my own versions of these
functions for use in an Array of boolean values. Some people suggest

Don’t be surprised – that’s half the fun of Ruby!

David

···

On Fri, 25 Oct 2002, Rudi Cilibrasi wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Greg_McIntyre1 (Greg McIntyre)]

true <=> false (should be +1 or -1)
false <=> false (should be 0)

I agree with David. They don’t make sense in general (except maybe the
latter one), as booleans have no ordinality.

Another common thing I find myself needing is to sort these, like:
a.sort!

I don’t usually belabour efficiency, but isn’t this horrendously
inefficient? Correct me if I’m wrong, but assuming #sort is a quicksort,
this is O(nlogn) whereas you could simply iterate through the bits and
collect two groups, one of ‘trues’ and one of ‘falses’ and then
concatenate them, which would be O(n).

Maybe that’s just me.

I have used the following code to make these operations work:
class TrueClass
def to_i() 1 end
def <=>(b)
to_i <=> b.to_i
end
end
class FalseClass
def to_i() 0 end
def <=>(b)
to_i <=> b.to_i
end
end

Personally I don’t like these as we have true and false classes for a
reason. I mean… if you want to use integers, use integers. If you want
a convenient but inefficient representation for a bitstring you can
sort, use arrays of integers. The only reason you’d want to use true and
false is that they better reflect what you’re doing… but not if you
defeat that purpose by converting back to integers for every operation.

That’s my 2c, anyway.

···

–
Greg McIntyre
greg@puyo.cjb.net
http://puyo.cjb.net

[William_Djaja_Tjokro (William Djaja Tjokroaminata)]

Hi,

Actually I am wondering the same thing. There was a recent similar
question

http://www.ruby-talk.org/53560

but there was no response to it. Just the fact that it is asked again and
again probably warrants a full, logical, satisfying answer.

Regards,

Bill

···

Rudi Cilibrasi cilibrar@ugcs.caltech.edu wrote:

In thinking about possibilities for future versions of Ruby, perhaps
it would make sense to have TrueClass and FalseClass both derive
from a common base class, say, BooleanClass.

[Eric_Hodel1 (Eric Hodel)]

class TrueClass
def to_i() 1 end
def <=>(b)
to_i <=> b.to_i
end
end
class FalseClass
def to_i() 0 end

0 == true in Ruby

···

Rudi Cilibrasi (cilibrar@ugcs.caltech.edu) wrote:

def <=>(b)
to_i <=> b.to_i
end
end

–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

[Martin_DeMello1 (Martin DeMello)]

cilibrar@ugcs.caltech.edu (Rudi Cilibrasi) wrote in message

Would anything break if this were made a part of the standard package?
In thinking about possibilities for future versions of Ruby, perhaps
it would make sense to have TrueClass and FalseClass both derive
from a common base class, say, BooleanClass.

I’m not sure about supporting a default ordering on booleans (as David
said, there’s no real reason to have true > false), but having them
both descend from a common base class sounds like a nice idea.

martin

[Albert2 (Albert)]

Your misunderstanding arises from the words “should be…” above. The only
“should be…” that is appropriate in the design of a programming language is
consistency; And not necessarily consistency with other programming
languages. Actually, for real pure OOP consistency in Ruby, true and false
should be singleton instances of a Boolean class, in which case the operator
<=> should not probably even be implemented.

···

On Friday 25 October 2002 11:44 am, Rudi Cilibrasi wrote:

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

–
Best essay I’ve read in years:

adam.nz: In the Beginning… was the Command Line

[Ptkwt1]

In article Pine.LNX.4.44.0210250754010.2650-100000@candle.superlink.net,

Hello –

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

I guess one reason is that it’s not clear (to me, anyway) why true
would be > false, or false > true. Is there ordinality to Boolean
values?

Actually if you want to get theoretical and mathematical there is an
ordering to boolean values in Boolean Algebra.

Here’s a definition from one of my textbooks (“Logic Synthesis and
Verification Algorithms” by Hachtel and Somenzi):

“A complemented, distributive lattice is a Boolean Lattice or Boolean
Algebra”

What’s a lattice:

“A lattice is a poset [partially ordered set] (AXA, <=) [meaning that
the Cartesian product of the set A with itself with the result ordered by
the less-than or equal relation] in which any two elements have a meet
[greatest lower bound] and a join [least upper bound]. Consequently, all
finite lattices have a greatest element, denoted by 1 [or true], and a
least element 0 [or false], where 1 [true] is an element of set A and 0
[false] is an element of set A.”

So technically true is greater than false.

Phil

···

dblack@candle.superlink.net wrote:

On Fri, 25 Oct 2002, Rudi Cilibrasi wrote:

[Gavin_Sinclair]

In thinking about possibilities for future versions of Ruby, perhaps
it would make sense to have TrueClass and FalseClass both derive
from a common base class, say, BooleanClass.

Hi,

Actually I am wondering the same thing. There was a recent similar
question

http://www.ruby-talk.org/53560

but there was no response to it. Just the fact that it is asked again and
again probably warrants a full, logical, satisfying answer.

Regards,

Bill

Everyone asks it at some point. I did once, and it was answered. I can’t
remember the answer, but it satisfied me. I reckon you should dig up the
answer and put it in the “Things newcomers should know” list. It would be good
fodder for the FAQ, too.

Gavin

PS. I think the answer had something to do with them being constant values.

···

From: “William Djaja Tjokroaminata” billtj@y.glue.umd.edu

Rudi Cilibrasi cilibrar@ugcs.caltech.edu wrote:

[Cilibrar1]

You’re right; I’ve made a simple example that seems to have distracted
you from my point. It is not so obvious why I would want to sort an
array of boolean values, as I could just count. The actual need I
came across in my programming was, rather, having to sort an Array
of Arrays of booleans. In this case, I have entries of the form

true
false false
true false true
false
and so on.

This is different from what I could do easily with integers, in that
any
number of falses all in a row is still equal to the integer value 0.
Arrays carry an explicit length indicator, integers do not.
I want different numbers of falses in succession to be considered
different bit strings, as is the case in formal mathematics. I don’t
agree with the “cultural relativist” idea that since we can’t say
which should be first, true or false, we shouldn’t order them. By
default, when you compare a String, you get forward alphabetical
order, not backward, because that is what more people expect, not
because
there is some deeper structure in Ruby that says alphabetical order is
right. Any default order is better than none for finite sets; those
that don’t like it don’t need to compare booleans for ordering, or
can override the default ordering with their own; To me, the important
question is if this enhancement is likely to surprise people with
unexpected behaviour; I am interested to hear any such hypotheticals.

The very fact that ruby has words for ‘and’ and ‘or’, symbols for &,
&&, |,
and ||, true, and false, implies that it seeks to be compatible with
Boolean algebra. In math, oftentimes the “or” operation is
represented with +, and the “and” operation with *. The reason this
is done is because then certain laws work for Boolean algebra. To be
exact,
If you say:

• is and

• is or
  0 is false
  1 is true
  Then you can say
  a1 = 1a = a (conveniently the same as general algebra)
  a+0 = 0+a = a (again mnemonically convenient)
  a0 = 0 (just like regular times)
  a+1 = 1 (this is unique to Boolean algebra)
  a(b+c) = ab + ac
  a+(b*c) = (a+b) * (a+c)

Notice that you need to decide the difference between “true” and
“false” in order to distinguish between “and” and “or”; both binary
operations are a type of “meet operator” heading toward one end or the
other of a boolean lattice, and they are structurally equivalent,
e.g.,
!((!a)*(!b)) = a+b. And given that we do, in fact, have to break
the symmetry, I don’t see any reason not to do so in the most accepted
fashion based on literature in logic and lattice theory. The to_i
functions I wrote are not, themselves, important; they were just the
easiest way for me to express the <=> relationship clearly. For those
that are interested in the exact definition of a boolean algebra,
you can find a good one at
http://plato.stanford.edu/entries/boolalg-math/
where you can see that they do use 0 and 1 to represent false and true
in the above identities. This page also mentions the natural ordering
that all Boolean algebras have:

Any BA has a natural partial order defined upon it by saying
that x <= y if and only if x + y = y.

This is another way of saying false is less than true.
I think it is an error of omission to not include this natural
ordering
in Ruby.

Rudi

Greg McIntyre greg@puyo.cjb.net wrote in message news:20021026012257.4aa18f21.greg@puyo.cjb.net…

···

true <=> false (should be +1 or -1)
false <=> false (should be 0)

I agree with David. They don’t make sense in general (except maybe the
latter one), as booleans have no ordinality.

Another common thing I find myself needing is to sort these, like:
a.sort!

I don’t usually belabour efficiency, but isn’t this horrendously
inefficient? Correct me if I’m wrong, but assuming #sort is a quicksort,
this is O(nlogn) whereas you could simply iterate through the bits and
collect two groups, one of ‘trues’ and one of ‘falses’ and then
concatenate them, which would be O(n).

Maybe that’s just me.

I have used the following code to make these operations work:
class TrueClass
def to_i() 1 end
def <=>(b)
to_i <=> b.to_i
end
end
class FalseClass
def to_i() 0 end
def <=>(b)
to_i <=> b.to_i
end
end

Personally I don’t like these as we have true and false classes for a
reason. I mean… if you want to use integers, use integers. If you want
a convenient but inefficient representation for a bitstring you can
sort, use arrays of integers. The only reason you’d want to use true and
false is that they better reflect what you’re doing… but not if you
defeat that purpose by converting back to integers for every operation.

That’s my 2c, anyway.

[David_Alan_Black1 (David Alan Black)]

Hi –

In article Pine.LNX.4.44.0210250754010.2650-100000@candle.superlink.net,

Hello –

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

I guess one reason is that it’s not clear (to me, anyway) why true
would be > false, or false > true. Is there ordinality to Boolean
values?

Actually if you want to get theoretical and mathematical there is an
ordering to boolean values in Boolean Algebra.

Here’s a definition from one of my textbooks (“Logic Synthesis and
Verification Algorithms” by Hachtel and Somenzi):

“A complemented, distributive lattice is a Boolean Lattice or Boolean
Algebra”

What’s a lattice:

“A lattice is a poset [partially ordered set] (AXA, <=) [meaning that
the Cartesian product of the set A with itself with the result ordered by
the less-than or equal relation] in which any two elements have a meet
[greatest lower bound] and a join [least upper bound]. Consequently, all
finite lattices have a greatest element, denoted by 1 [or true], and a
least element 0 [or false], where 1 [true] is an element of set A and 0
[false] is an element of set A.”

So technically true is greater than false.

We’re waaaay over my head mathematically, but I’m finding this
interesting enough that I’ll go ahead and ask a couple of stupid
questions

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above? That is: why does true have to go with 1 and
   false with 0?

2. Does being the greatest and least, in a lattice, have to propagate
   to a direct comparison between the two elements? I’m thinking (by way
   of analogy) of an array: [3,1,5,4], where 5 is the greatest element in
   one sense, and 4 is the greatest in another sense (highest indexed).

3. Does all of this necessarily apply to Ruby? That is, does the
   presence of true and false in a programming language imply support for
   Boolean algebra?

These questions are probably all OT babytalk, but I thought I’d give
it a try, just out of curiosity.

David

···

On Sat, 26 Oct 2002, Phil Tomson wrote:

dblack@candle.superlink.net wrote:

On Fri, 25 Oct 2002, Rudi Cilibrasi wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[David_Alan_Black1 (David Alan Black)]

Hi –

From: “William Djaja Tjokroaminata” billtj@y.glue.umd.edu

In thinking about possibilities for future versions of Ruby, perhaps
it would make sense to have TrueClass and FalseClass both derive
from a common base class, say, BooleanClass.

Hi,

Actually I am wondering the same thing. There was a recent similar
question

http://www.ruby-talk.org/53560

but there was no response to it. Just the fact that it is asked again and
again probably warrants a full, logical, satisfying answer.

Regards,

Bill

Everyone asks it at some point. I did once, and it was answered. I can’t
remember the answer, but it satisfied me. I reckon you should dig up the
answer and put it in the “Things newcomers should know” list. It would be good
fodder for the FAQ, too.

I think it would be a suitable FAQ question, but I’m not sure it’s
something newcomers need to know. Even as a relative non-newcomer, I
don’t think I’ve ever actually encountered a situation where TrueClass
and FalseClass not having a common superclass mattered to me. I would
tend not to put it on the same level as things like the absence of ++
or the other things on the newcomers list.

David

···

On Sat, 26 Oct 2002, Gavin Sinclair wrote:

Rudi Cilibrasi cilibrar@ugcs.caltech.edu wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Ptkwt1]

In article Pine.LNX.4.44.0210251926200.4149-100000@candle.superlink.net,

Hi –

In article Pine.LNX.4.44.0210250754010.2650-100000@candle.superlink.net,

Hello –

I am wondering if there is a good reason why Ruby does not by default
support, for instance,
true <=> false (should be +1 or -1)
or even
false <=> false (should be 0)

I guess one reason is that it’s not clear (to me, anyway) why true
would be > false, or false > true. Is there ordinality to Boolean
values?

Actually if you want to get theoretical and mathematical there is an
ordering to boolean values in Boolean Algebra.

Here’s a definition from one of my textbooks (“Logic Synthesis and
Verification Algorithms” by Hachtel and Somenzi):

“A complemented, distributive lattice is a Boolean Lattice or Boolean
Algebra”

What’s a lattice:

“A lattice is a poset [partially ordered set] (AXA, <=) [meaning that
the Cartesian product of the set A with itself with the result ordered by
the less-than or equal relation] in which any two elements have a meet
[greatest lower bound] and a join [least upper bound]. Consequently, all
finite lattices have a greatest element, denoted by 1 [or true], and a
least element 0 [or false], where 1 [true] is an element of set A and 0
[false] is an element of set A.”

So technically true is greater than false.

We’re waaaay over my head mathematically, but I’m finding this
interesting enough that I’ll go ahead and ask a couple of stupid
questions

No they’re good questions…

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above? That is: why does true have to go with 1 and
   false with 0?

Well, you’re getting deep with this one. I suppose you could say that its
a human imposed convention to associate 1 with true and 0 with false.
But yes, the book I referred to does (I think in order to play with your
mind a bit and to illustrate that different types of boolean algebras can
be concocted [more below]) show an example where the 1 and 0 are switched.
However, I don’t think we’d want to do that. It would be kind of like
saying that every place in your program where you see a ‘0’ it actually
means ‘9’ and everyplace you see an ‘8’ it actually means ‘1’ and so on
like:
0 ↔ 9
1 ↔ 8
2 ↔ 7
3 ↔ 6
4 ↔ 5

Yes you could do it as a mathematical exercise, but others wouldn’t get
the same meaning out of it.

2. Does being the greatest and least, in a lattice, have to propagate
   to a direct comparison between the two elements? I’m thinking (by way
   of analogy) of an array: [3,1,5,4], where 5 is the greatest element in
   one sense, and 4 is the greatest in another sense (highest indexed).

Well, a lattice represents a partially ordered set, so some kind of
comparison relation (which you can define, but usually based on
less-than-or-equal) needs to exist between them.

3, 1, 5, and 4 are just symbols whose meaning we supply:

3 generally means a cardinality of three as in here are 3 dots: …
You could just as easily supply some alternate notation as is done by
Hofstadter in “Godel, Escher, Bach” (yeah, I was reading it again recently :):
0 - means 0
S0 - successor to 0 (1)
SS0 - successor to the successor to 0 (2)
… and so on.
(oops, jump back from tangent)

And when you look at a set A = [3,1,5,4] you could interpret it as:
4>5>1>3
5>1>3
1>3

if you decide that the cardinality of (or magnitude represented by)
these symbols is solely based on their index position within the array.

3. Does all of this necessarily apply to Ruby? That is, does the
   presence of true and false in a programming language imply support for
   Boolean algebra?

Primarily I was responding to your question above:
“Is there ordinality to Boolean values?”
To which I reply: yes, there is in the context of the Boolean Algebra.
There has to be for the rules of Boolean Algebra to ‘work’ at a basic level.
BTW: what we’re calling the Boolean Algebra here is commonly
known as the switching algebra. I don’t want to go into it, but there are
potentially an infinite number of boolean algebras that could be concocted
(note the change in case to lower case, where the Boolean Algebra refers
to the specific type of boolean algebra that is familiar to us.)

Now whereas true and false are often referred to as boolean values perhaps
we’re splitting semantic hairs to say that that infers a relation to the
Boolean Algebra since in Ruby true and false are just constant values that
have no common superclass (as is often proposed) called Boolean.

However, we do depend on boolean operations (&&,||,!,and,or,not) in our
programs, true? (!false?) and we do expect these identities to hold:

true && true = true
true && false = false
true || false = true
true || true = true
false || false= false

And if x,y can take on only the values true or false:

if x || y = true
and
x && y = false
then
x is the complement of y and vce versa.

And: x || false = x, x && true = x (Identity)

Given the way we’ve defined the operators to work with the true and false
values in Ruby it would seem isomorphic to the Boolean Algebra
(ie. they match the properties of a boolean algebra in that they are
Idempotent, Commutative, Associative, Absoptive ( x && (x || y) = x ),
Distributive, Identities, and there exists a complement)

If it walks like a duck…

These questions are probably all OT babytalk, but I thought I’d give
it a try, just out of curiosity.

it’s a fun discussion.

Phil

“What is truth?” - Pilate’s question to Jesus circa 33AD

···

dblack@candle.superlink.net wrote:

On Sat, 26 Oct 2002, Phil Tomson wrote:

dblack@candle.superlink.net wrote:

On Fri, 25 Oct 2002, Rudi Cilibrasi wrote:

[Simon_Cozens]

dblack@candle.superlink.net writes:

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above?

You mean like in Unix, where 0 means success and non-zero means failure?

···

–
Building translators is good clean fun.
– T. Cheatham

[Massimiliano_Mirra4 (Massimiliano Mirra)]

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above? That is: why does true have to go with 1 and
   false with 0?

Well, you’re getting deep with this one. I suppose you could say that its
a human imposed convention to associate 1 with true and 0 with false.
But yes, the book I referred to does (I think in order to play with your
mind a bit and to illustrate that different types of boolean algebras can
be concocted [more below]) show an example where the 1 and 0 are switched.
However, I don’t think we’d want to do that.

I think neither does David. He was suggesting switching just the
associations between the boolean and the integer (being they
arbitrary), not the booleans nor the integers. (If I’m
misinterpreting, David, please correct me.)

It would be kind of like
saying that every place in your program where you see a ‘0’ it actually
means ‘9’ and everyplace you see an ‘8’ it actually means ‘1’ and so on
like:
0 ↔ 9
1 ↔ 8
2 ↔ 7
3 ↔ 6
4 ↔ 5

Yes you could do it as a mathematical exercise, but others wouldn’t get
the same meaning out of it.

Hmmm, then why does everybody insist on seeing 0' where there actually is false’, and 1' where there actually is true’?

2. Does being the greatest and least, in a lattice, have to propagate
   to a direct comparison between the two elements? I’m thinking (by way
   of analogy) of an array: [3,1,5,4], where 5 is the greatest element in
   one sense, and 4 is the greatest in another sense (highest indexed).

Well, a lattice represents a partially ordered set, so some kind of
comparison relation (which you can define, but usually based on
less-than-or-equal) needs to exist between them.

So in order to assert ordinality between true' and false’ they first
should be demonstrated to belong to a lattice, right?

Which makes me think…

(That usually preludes to one of my pointless digressions. Hit the
`next nessage’ before it’s too late.)

Pick any two numbers, say 9 and 16. 9 is less than 16. You can’t
swap the numbers and keep the relation: `16 is less than 9’ doesn’t
sound quite right, does it?

Now pick any two booleans, say day and night. Day comes before night.
You can swap them, keep the relation, and it still sounds right: night
comes before day. Similarly, true equals negated false, and false
equals negated true.

Looks like it’s no exclusive property of boolean things. Pick any two
days of the week, say Sunday and Thursday: Sunday comes before
Thursday, Thursday comes before Sunday.

Now given those relations, how would you represent numbers, day and
night, and days of the week?

0 → 1 → 2 → 3 → 4 → 5 → 6 → …

    +--> day ----+
    >            >
    +-- night <--+


    +-> Sunday --+ 
    >            >
    >            v
 Saturday      Monday
    ^            |
    >            v
   ...          ...
    ^            |
    >            >
    +- Thursay <-+

All this data can be traversed in one direction but isn’t necessarily
ordered (in the sense that departing from an element will bring you
farther from it), it can also be cyclic (a broken record lattice?).
And booleans seem to be inherently so.

    +--> true ---+
    >            >
    +--- false <-+

Good luck on sorting that.

Some cyclic data need a convention, not to tell where the series
starts, but where we start traversing it. And being a
convention… compare some calendars and you’ll find that some start
weeks on Mondays and some on Sundays.

I’ve never found myself in need of conventions for true and false,
though.

(See that I brought it back on topic? You gave up hope I could, uh?)

Massimiliano

···

On Sat, Oct 26, 2002 at 01:06:12PM +0900, Phil Tomson wrote:

–
We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.

         T. S. Eliot, `Four Quartets'

[David_Alan_Black1 (David Alan Black)]

Hi –

dblack@candle.superlink.net writes:

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above?

You mean like in Unix, where 0 means success and non-zero means failure?

Sort of, but more abstractly. I was trying to suggest that if the
equivalence 1:true, 0:false was what made true > false, and if that
equivalence was purely conventional (and could be flipped without any
loss of logical integrity), then it perhaps didn’t make sense for it
to govern the behavior of Ruby true/false. (And of course in Ruby 0
isn’t false anyway.)

David

···

On Sun, 27 Oct 2002, Simon Cozens wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Giuseppe_Bilotta]

Simon Cozens wrote:

dblack@candle.superlink.net writes:

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above?

You mean like in Unix, where 0 means success and non-zero means failure?

This is true under DOS as well (errorlevel 0 => success), but just
because non-zero means “there was an error”, so it is true, and
zero is false (no error).

Of course if you’re an optimist and look at it from the “success”
viewpoint …

···

–
Giuseppe “Oblomov” Bilotta

“Da grande lotterò per la pace”
“A me me la compra il mio babbo”
(Altan)
(“When I grow up, I will fight for peace”
“I’ll have my daddy buy it for me”)

[Ptkwt1]

In article Pine.LNX.4.44.0210261701170.16157-100000@candle.superlink.net,

Hi –

dblack@candle.superlink.net writes:

1. Why couldn’t one swap ‘true’ and ‘false’ in your square-bracket
   comments in the above?

You mean like in Unix, where 0 means success and non-zero means failure?

Sort of, but more abstractly. I was trying to suggest that if the
equivalence 1:true, 0:false was what made true > false, and if that
equivalence was purely conventional (and could be flipped without any
loss of logical integrity),

Well, no. Don’t think of 1 and 0 here as inegers where we know that 1>0
is a true statement for the integers. Look at it in terms of the
operators and (&&) and or (||):

given an x which can take on either the value true or false, the identity
property must hold:

x && true = x x || false = x

This implies some ordering.

Here’s a lattice:

                {a,b}= true   set union (or) (join, or least upper bound)
                 / \
                /   \
              {a}   {b}
                \   /
                 \ /
                 { } = false  set intersection (and) 
                          (meet, or greatest lower bound)

where { } means empty set

if a = true it doesn’t matter what b’s value is: a + b = true
if a = false it doesn’t matter what b’s value is: a && b = false

There is a defined order between true and false (true > false) because of
the way we define how the operators are to work on those values.

then it perhaps didn’t make sense for it
to govern the behavior of Ruby true/false.

Well, maybe the easier way to look at it is:

The set of the positive integers is: [1,2,3… infinity]

The set of possible boolean values is: [false,true]

(now switching sides in the debate
In Ruby there is some type relationship between 1 and 2 (they’re both
members of the FixNum class). But in Ruby there is no type relationship
between false and true (false is the one and only instance of the
FalseClass and true is the one and only instance of the TrueClass. So,
perhaps one could make the case that we don’t need true > false since they
are members (representatives) of two totally unrelated classes.

(switching back
But that argument might rely too heavily on trying to make the OO
structure the model for reality instead of vice-versa.
Anyway, I guess I’m in the camp that would like to see some kind of
hierarchy like:

class Boolean
…
end

class TrueClass < Boolean
…
end

class FalseClass < Boolean
…
end

Then there would be some kind of type relationship between TrueClass and
FalseClass. That would just seem to make more sense to me, but I do see
the potential pitfalls with that approach too.

Phil

···

dblack@candle.superlink.net wrote:

On Sun, 27 Oct 2002, Simon Cozens wrote:

[Brian_Candler]

But the shell 'operators' treat 0 as true and 1 as false, if you use the
traditional definitions of 'and' and 'or':

cmd1 && cmd2 && cmd3 # if cmd1 returns 0 exec cmd2, etc
cmd4 || cmd5 # if cmd4 returns non-zero exec cmd5

Plus of course there are 'constants':

$ false; echo $?
1
$ true; echo $?
0

That makes it pretty explicit that 0 = true

Regards,

Brian.

···

On Sun, Oct 27, 2002 at 06:28:04PM +0900, Giuseppe Bilotta wrote:

> > 1. Why couldn't one swap 'true' and 'false' in your square-bracket
> > comments in the above?
>
> You mean like in Unix, where 0 means success and non-zero means failure?

This is true under DOS as well (errorlevel 0 => success), but just
because non-zero means "there was an error", so it *is* true, and
zero is false (no error).

Of course if you're an optimist and look at it from the "success"
viewpoint ...

[Massimiliano_Mirra4 (Massimiliano Mirra)]

[snip explanation… still don’t see how it implies ordering, sorry :-(]

Anyway, I guess I’m in the camp that would like to see some kind of
hierarchy like:

class Boolean
…
end

class TrueClass < Boolean
…
end

class FalseClass < Boolean
…
end

Then there would be some kind of type relationship between TrueClass and
FalseClass. That would just seem to make more sense to me, but I do see
the potential pitfalls with that approach too.

I’m wondering what happens when subclassing Boolean a third time.

What would the relationship be among this third class and FalseClass
and TrueClass? And what relationship among its instance (or rather
its singleton) and true' and false’?

Does a class model actually make sense here?

Massimiliano

···

On Sun, Oct 27, 2002 at 10:07:31AM +0900, Phil Tomson wrote: