Fri, 25 Oct 2002 20:59:36 +0900, dblack@candle.superlink.net dblack@candle.superlink.net pisze:
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 find ‘false < true’ in all languages I know. Do you know any where
it’s otherwise?
–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.
Actually, in C, that’s not necessarily the case. ‘false’ is integer
0, whereas true is properly defined as !0 – which may be either
one (0x00000001) or -1 (0xFFFFFFFF). Now, if truth is measured
exclusively with unsigned values, then false < true is always true
– but with signed values, that’s not necessarily the case.
(:
When I was doing something recently that required boolean <=>
comparison, I did:
if a != b
a ? -1 : 1
end
This somewhat assumes that false < true, but really in this case it
says which side of the comparison is “more different” different than
the other side. (I actually did it backwards in the code for
Text::Format, where true < false.) It’s a useful comparison at
times, and a nice solution without resorting to #to_i.
Similarly, for arrays (which don’t recognise <=> either if either is
empty – they should, though), I do:
if a.empty? || b.empty?
if a.empty? && !b.empty?
-1
elsif !a.empty? && b.empty?
1
else
0
end
end
This one is easier to deal with, because there is an absolute size
comparison first.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.25 at 14.24.11
On Sat, 26 Oct 2002 03:18:12 +0900, Marcin ‘Qrczak’ Kowalczyk wrote:
Fri, 25 Oct 2002 20:59:36 +0900, dblack@candle.superlink.net
dblack@candle.superlink.net pisze: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 find ‘false <true’ in all languages I know. Do you know any
where it’s otherwise?
I find ‘false < true’ in all languages I know. Do you know any where
it’s otherwise?
It is true in languages that use 0 for false and 1 for true. Python,
Perl, C, and C++ fall into this category. There are probably countless
others.
I don’t think it is not true in Smalltalk:
[pbrannan@zaphod tmp]$ gst -Q
(0 < 1) printNl !
true
(False < True) printNl !
Object: False error: did not understand #<
False class(Object)>>#primError:
MessageNotUnderstood(Exception)>>#defaultAction
in Exception class>>#coreException
MessageNotUnderstood(Signal)>>#activateHandler:
MessageNotUnderstood(Exception)>>#signal
False class(Object)>>#doesNotUnderstand:#executeStatements
Mzscheme doesn’t like to compare true and false with < either:
[pbrannan@zaphod tmp]$ mzscheme
Welcome to MzScheme version 201, Copyright (c) 1995-2002 PLT
(< 0 1)
#t
(< #f #t)
<: expects type as 2nd argument, given: #t; other arguments were: #ifdef
Paul
On Sat, Oct 26, 2002 at 03:18:12AM +0900, Marcin ‘Qrczak’ Kowalczyk wrote:
In article slrnarj2mq.uf6.qrczak@qrnik.zagroda,
Marcin ‘Qrczak’ Kowalczyk qrczak@knm.org.pl wrote:
Fri, 25 Oct 2002 20:59:36 +0900, dblack@candle.superlink.net
dblack@candle.superlink.net pisze: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 find ‘false < true’ in all languages I know. Do you know any where
it’s otherwise?
Well, I’m not too sure what other languages do. I would be more concerned
with doing the right thing mathematically and since false < true is the
basis for Boolean Algebra (see my earlier post - if there is no order
relation between false and true there’s no Boolean Algebra) then I think
we should have the relation false < true.
Phil
I’ve never read C89, but C99 requires that all boolean operators output
0 for false and 1 for true. It becomes confusing because these same
operators are required to treat as true all non-zero values they take as
input.
Paul
On Sat, Oct 26, 2002 at 03:43:21AM +0900, Austin Ziegler wrote:
Actually, in C, that’s not necessarily the case. ‘false’ is integer
0, whereas true is properly defined as !0 – which may be either
one (0x00000001) or -1 (0xFFFFFFFF). Now, if truth is measured
exclusively with unsigned values, then false < true is always true
– but with signed values, that’s not necessarily the case.
Scripsit ille Paul Brannan pbrannan@atdesk.com:
I find ‘false < true’ in all languages I know. Do you know any where
it’s otherwise?It is true in languages that use 0 for false and 1 for true. Python,
Perl, C, and C++ fall into this category. There are probably countless
others.
[…]
I only know one counter-example:
Bywater BASIC Interpreter/Shell, version 2.20 patch level 2
Copyright (c) 1993, Ted A. Campbell
Copyright (c) 1995-1997, Jon B. VolkoffbwBASIC: PRINT 1 = 0
0
bwBASIC: PRINT 1 = 1
-1
bwBASIC: SYSTEM
The same holds for QBasic and Omikron BASIC. In these false is defined
as 0 (all bits are 0 bits) and true as -1 (since all bits are 1 bits).
The reason is - IMHO - that NOT can only be used for logical negation if
true == NOT false, and if one defines false as being 0, true must be -1.
Since BASIC does neither distinguish between logical values and integers
nor have different operators for these, so this hack has to be done.
On Sat, Oct 26, 2002 at 03:18:12AM +0900, Marcin ‘Qrczak’ Kowalczyk wrote:
–
[mpg123d] Just playing: …/13 ruseau no mori - chagall no sora.mp3
Ritsuko: “You cooked this, didn’t you Misato?”
Misato: “Oh, can you tell?”
Ritsuko: “Yes, by its taste.”
bwBASIC: PRINT 1 = 0
0
bwBASIC: PRINT 1 = 1
-1
bwBASIC: SYSTEMThe same holds for QBasic and Omikron BASIC. In these false is defined
as 0 (all bits are 0 bits) and true as -1 (since all bits are 1 bits).
The reason is - IMHO - that NOT can only be used for logical negation if
true == NOT false, and if one defines false as being 0, true must be -1.
Since BASIC does neither distinguish between logical values and integers
nor have different operators for these, so this hack has to be done.
Ah, yes… TRUE is defined as all-bits-on in a lot of Forth
systems, as well. Same rationale…
Regards,
Bill
From: “Rudolf Polzer” AntiATField_adsgohere@durchnull.de