From: sawadatsuyoshi@... Date: 2016-03-15T08:50:44+00:00 Subject: [ruby-core:74336] [Ruby trunk Feature#12134] Comparison between `true` and `false` Issue #12134 has been updated by Tsuyoshi Sawada. Martin D��rst wrote: > Tsuyoshi Sawada wrote: > > > Please do not confuse this with the common proposal to map booleans to integers, particularly `true.to_i # => 1` and `false.to_i # => 0`. That is arbitrary, and does not make sense. > > In absolute terms, it is arbitrary. But it's the most widely used mapping, and therefore would make much more sense than any other mapping. I agree that it is the most common mapping, but I would say that that is an implementation detail (bit level). From the perspective of OOP, a user should be using `true`/`false` when they want to express logic, and not `1`/`0`. > As far as I can remember, it's customary to define true being greater than false. I think this can be explained by the fact that true (something) is easily considered greater than false (nothing). That way of thinking is also arbitrary, I think. If you think of a birth of something, it goes from non-existence to existence, but if you think of the death/disappearance of something, it goes from existence to non-existence. Other than that, perhaps you are assuming the mapping `true` => `1` and `false` => `0`, further interpreting the numbers as cardinality. But as I wrote above, I think the mapping itself is insignificant, and should not be considered at the level of OOP. > I think it's worth to check other programming languages. In Python, for example: > > ~~~PYTHON > >>> True > False > True > ~~~ I think this comes from the mapping in mind, which I am claiming against. > Your specific example can still easily be written as: > > ~~~RUBY > [7, 6, 5, 4, 3, 2, 1].sort_by{|e| [not Prime.prime?(e), e]} # => [2, 3, 5, 7, 1, 4, 6] > ~~~ Yes, that is one important point. Whichever way the comparison is defined, you should be able to reverse it by applying negation on it. ---------------------------------------- Feature #12134: Comparison between `true` and `false` https://bugs.ruby-lang.org/issues/12134#change-57460 * Author: Tsuyoshi Sawada * Status: Open * Priority: Normal * Assignee: ---------------------------------------- There are some needs to sort elements depending on whether they satisfy certain condition expressed as a predicate. For example, to place prime numbers before others: ~~~RUBY require "prime" [7, 6, 5, 4, 3, 2, 1].sort_by{|e| Prime.prime?(e) ? 0 : 1} # => [7, 5, 3, 2, 6, 4, 1] ~~~ or to do such sort with the secondary condition to sort by the size: ~~~RUBY [7, 6, 5, 4, 3, 2, 1].sort_by{|e| [Prime.prime?(e) ? 0 : 1, e]} # => [2, 3, 5, 7, 1, 4, 6] ~~~ Here, the temporal assignment of magic numbers `0` and `1` is ad hoc, but ordering between `true` and `false` makes sense. And given that there are `if` construction (which is unmarked case compared to the `unless` construction) and the ternary operator, in which the truthy branch is placed before the falsy branch, I think it makes sense to assume an inherent ordering of `true` being placed before `false`. So I propose comparison between `true` and `false`: ~~~RUBY true <=> false # => -1 false <=> true # => 1 ~~~ Using this, the cases above can be written more directly as: ~~~RUBY [7, 6, 5, 4, 3, 2, 1].sort_by{|e| Prime.prime?(e)} # => [7, 5, 3, 2, 6, 4, 1] [7, 6, 5, 4, 3, 2, 1].sort_by{|e| [Prime.prime?(e), e]} # => [2, 3, 5, 7, 1, 4, 6] ~~~ --- Please do not confuse this with the common proposal to map booleans to integers, particularly `true.to_i # => 1` and `false.to_i # => 0`. That is arbitrary, and does not make sense. In fact, my proposal goes against such proposal (under the proposal to map booleans, `true.to_i <=> false.to_i` translates to `1 <=> 0 # => 1`, which goes against my proposal `true <=> false # => 01`). -- https://bugs.ruby-lang.org/ Unsubscribe: