bool should be Comparable

[Alex Tatumizer]

Bool should be made comparable.

E.g., boolean value can be a part of complex key (say, for in-memory "database"), and to construct search tree (or sorting for binary search) we need comparable values.

It's Comparable in java.

Open an issue? 

[Gen]

I vote yes.

[Florian Loitsch]

You can create one (and if it's just for having some form of record of the request), but I will close it as "notPlanned".

I don't see how one can compare booleans in a meaningful way.

For all of your cases one can provide a custom `compare` method that can sort the booleans in a desired way. The custom `compare` method doesn't need to take Comparables (if it does, it's a bug).

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[dangli...@gmail.com]

>> I don't see how one can compare booleans in a meaningful way.

Never too late to learn!

http://msdn.microsoft.com/en-us/library/wz786x34.aspx

Boolean.CompareTo Method (Boolean)

.NET Framework 4.5

Other Versions

1 out of 1 rated this helpful - Rate this topic

Compares this instance to a specified Boolean object and returns an integer that indicates their relationship to one another.

Namespace:  System
Assembly:  mscorlib (in mscorlib.dll)

Syntax

---

C#

C++

F#

VB

public int CompareTo(
	bool value
)

Parameters

value

Type: System.Boolean

A Boolean object to compare to this instance.

Return Value

Type: System.Int32
A signed integer that indicates the relative values of this instance and value.

Return Value	Condition
Less than zero	This instance is false and value is true.
Zero	This instance and value are equal (either both are true or both are false).
Greater than zero	This instance is true and value is false.

[Alexander Voronin]

Boolean is class and bool is a base type. 

2013/8/29 <dangli...@gmail.com>

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
когда я опустился на самое дно, снизу мне постучали..

[Alex Tatumizer]

> You can create one (and if it's just for having some form of record of the request), but I will close it as "notPlanned".

What's the point to open an issue if it gets immediately closed as not planned?

> I don't see how one can compare booleans in a meaningful way.

The same case can be made for other types - e.g. Strings. For some languages (including English) result can be interpreted as alphabetical sorting order,

For others - not. So String comparison is generally not meaningful either. We need it nonetheless  for technical reasons (related to SEARCH, where "order" is used as a device to implement efficient algo).

It's a matter of convenience. Convenience beats (almost) everything, that's why we have booleans comparable in java, C# and elsewhere, regardless of "meaning".

Now everyone needs to specialcase bools in complex keys. Problem is created for no reason IMO.

P.S. Poincare has written a lot about the role of convenience in forming our ideas

E.g.

~~~

The two propositions: "The earth turns round" and "it is more convenient to suppose the earth turns round" have the same meaning; there is nothing more in the one than in the other.

~~~

If I don't succeed in convincing you, maybe Poincare will? :-)

[dangli...@gmail.com]

>> Boolean is class and bool is a base type.

Please explain your thinking. Not everyone here have an academic education.

Also to improve your education.

The bool keyword is an alias of System::Boolean. It is used to declare variables to store the Boolean values, true and false.

public int CompareTo(Object obj)

obj must be null or an instance of Boolean; otherwise, an exception is thrown.

[Gen]

The request was to give that comparison a meaning, the same for all Dart programmers, by introducing a standard order.
I guess false < true like in C, Java and .net.

[Alex Tatumizer]

Maybe we should ban hashCode, too, once we are at it? Because "it has no meaning".

Meaning is defined by context (or, rather, all contexts) where the notion is used

If you want to know what hashCode means, you need to look into Map algos.

Meaning of compareTo is similarly established by algos that deal with search.

The fact that compareTo defined in a programming language sometimes coincides with intuitive idea of comparison is just a nice extra, which works generally only for numbers.

Actually, I didn't expect that we would have to argue about obvious matters like this.

It's strange. Florian, tell me you were joking. Right?

Regardless, please read Poincare's essays on foundations of math and science - it all applies to programming, too. (Sorry for unsolicited advice).

[Gen]

I have the impression that the Dart team wants to finish 1.0 and the ECMA standard as soon as possible.

Therefore the reluctance to deal with changes and discussions that are not considered essential.

I wonder, will ES6 be released soon ? 

[Jos Hirth]

true > false

This is true-ish in JavaScript, Python, Scala, and PHP. It doesn't work in Ruby, Perl, and Java.

I would have guessed that this works in Dart, too.

[Alex Tatumizer]

> true > false

We had an interesting debate with Florian a couple of months ago (debate is buried somewhere along with the issue I opened against DateTime).
Florian developed whole theory to explain to me that operator > has nothing to do with compareTo.
You can see the result in DateTime: there IS compareTo, but there's no ">"

Now, for bool, completely different (and opposite) argument is employed: that > has no meaning for bools. OK, but I don't suggest ">", I am asking about compareTo, which, arguably, has nothing to do with >.
???
 

[Gen]

Right.

But "<" is still related. If the "compareTo" relation is defined, then "<" or ">" as well.

[Lasse R.H. Nielsen]

A problem here is that there is no *natural* ordering on booleans.

You can have both

    int falseBeforeTrue(a, b) => (a ? 1 : 0) - (b ? 1 : 0);

    int trueBeforeFalse(a, b) => (a ? 0 : 1) - (b ? 0 : 1);

(Heck, if we fix bool's hashCode values, we could use those instead of the switching, or let the backends optimize the heck out of it).

I would even accept having those two as static methods on bool.

Actually, if we had "false less than true" implemented, then ">=" would work as implictation which is normally written as "=>". A coincidence? I think so!

/L

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Florian Loitsch]

On Thu, Aug 29, 2013 at 5:29 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

> You can create one (and if it's just for having some form of record of the request), but I will close it as "notPlanned".

What's the point to open an issue if it gets immediately closed as not planned?

People can star it, and find it in the tracker. But the benefit is minor (especially to you), so I wasn't expecting you to do it. 

> I don't see how one can compare booleans in a meaningful way.

The same case can be made for other types - e.g. Strings. For some languages (including English) result can be interpreted as alphabetical sorting order,

For others - not. So String comparison is generally not meaningful either. We need it nonetheless  for technical reasons (related to SEARCH, where "order" is used as a device to implement efficient algo).

I hate the fact that we have compareTo and toLowerCase/toUpperCase on String. I tried to avoid it, but lost that battle.

 

It's a matter of convenience. Convenience beats (almost) everything, that's why we have booleans comparable in java, C# and elsewhere, regardless of "meaning".

If it is a really common operation I can be convinced otherwise. From what I see one doesn't frequently sort a list of booleans, and when one does it isn't painful to provide a `compare` function. 

Now everyone needs to specialcase bools in complex keys. Problem is created for no reason IMO.

P.S. Poincare has written a lot about the role of convenience in forming our ideas

E.g.

~~~

The two propositions: "The earth turns round" and "it is more convenient to suppose the earth turns round" have the same meaning; there is nothing more in the one than in the other.

~~~

If I don't succeed in convincing you, maybe Poincare will? :-)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

[Gen]

Thanks for the reply.

But I am sorry for not understanding the meaning of your example.
Is this the theory of Florian ?

What I think:
-
Define an order for false and true. Natural or not, who cares ?
Everything in computing is stored as a sequence of bits (numbers) and therefore has a "natural" or "technical" or whatever order.
-
False is like 0. And true is like 1.
Where is the problem ?
Maybe your example demonstrated it but I do not understand it.

[Lasse R.H. Nielsen]

On Fri, Aug 30, 2013 at 10:29 AM, Gen <gp78...@gmail.com> wrote:

Thanks for the reply.

But I am sorry for not understanding the meaning of your example.
Is this the theory of Florian ?

What I think:
-
Define an order for false and true. Natural or not, who cares ?

Well, I care :)

When we put a "compareTo" method on a class, it's because we think the objects have a natural ordering, one that is obviously the one you want in almost all cases.

You can order *anything* by using a suitable Comparator. Classes don't need to be Comparable, and most aren't. Those that are Comparable have some intrinsic notion of order that is both common and useful and compatible with equality. You often have to order numbers by magnitude, and magnitude is a natural ordering of numbers, so we made numbers Comparable by their magnitude.

A DateTime doesn't have an intrinsic ordering because it have multiple dimensions: There is the actual date/time and there is the timezone. We could have chosen to order them by their corresponding UTC moment, but that would disagree with equals, so it's not what we consider a natural order.

You can still use comparators to compare DateTime objects in any way you want.

And that brings us to bool. There is no natural ordering on true and false. You can put either first and it still makes sense. That doesn't mean that you can't order them, just that we don't want to single out one particular order. Again, you can pick any order, and you just have to use a comparator function for it.

Everything in computing is stored as a sequence of bits (numbers) and therefore has a "natural" or "technical" or whatever order.

Anything can be ordered. We only consider the ordering "natural" (or whatever word one would prefer to use for it) if it is inherent in the meaning of the object. The technical underlying representation is accidental in most cases, and shouldn't be used. There are two total orderings of bools: "true greater than false" and "false greater than true". Neither is more inherently true than the other, so we chose to not make bool Comparable.

 

-
False is like 0. And true is like 1.

Or false is like 0x404012454 and true is like 0x40401245c. Or the other way around. Or something. 

 

Where is the problem ?

Maybe your example demonstrated it but I do not understand it.

There isn't necessarily a problem with picking an arbitrary ordering on bool.

We think it is a problem if the library decides on one of the two arbitrary orderings, so like for so many other types, we don't. We could make Object comparable solely on its hashCode, but that would make no sense, so we don't.

/L

[Gen]

Thanks for the lengthy reply. I understand your concern now.
Although I do not recognize the benefit of not having a default or standard compareTo method for bool or DateTime or any object.

[dangli...@gmail.com]

>> Or false is like 0x404012454 and true is like 0x40401245c. Or the other way around. Or something.

Let me disagree with you. Boolean is a data type that having two values. Usually these values are true and false.
For some reason it is enough just one bit to encode these values.
Unfortunately, your example is not obvious by the considerations of reasonableness.
More reasonable example may looks like: false is like 0 and true is like 1 (in bits).

[Florian Loitsch]

On Fri, Aug 30, 2013 at 10:54 AM, Lasse R.H. Nielsen <l...@google.com> wrote:

On Fri, Aug 30, 2013 at 10:29 AM, Gen <gp78...@gmail.com> wrote:

Thanks for the reply.

But I am sorry for not understanding the meaning of your example.
Is this the theory of Florian ?

What I think:
-
Define an order for false and true. Natural or not, who cares ?

Well, I care :)

When we put a "compareTo" method on a class, it's because we think the objects have a natural ordering, one that is obviously the one you want in almost all cases.

You can order *anything* by using a suitable Comparator. Classes don't need to be Comparable, and most aren't. Those that are Comparable have some intrinsic notion of order that is both common and useful and compatible with equality. You often have to order numbers by magnitude, and magnitude is a natural ordering of numbers, so we made numbers Comparable by their magnitude.

A DateTime doesn't have an intrinsic ordering because it have multiple dimensions: There is the actual date/time and there is the timezone. We could have chosen to order them by their corresponding UTC moment, but that would disagree with equals, so it's not what we consider a natural order.

You can still use comparators to compare DateTime objects in any way you want.

Clarifications/Corrections:

DateTime has a natural order: if a date happened before another event. So DateTime has a compareTo (and implements Comparable).

However we don't provide <, <=, >=, and > operators on DateTime. This is because == compares true only if two dates also are in the same timezone. If the comparison operators (except ==) took only the time-instant (and not the timezone) into account we would have a discrepancy between the comparison operators and operator==.

In short: a DateTime carries more information than just a time-instant, but we are happy to compareTo only with the time-instant. We are not ok to implement == without the timezone (if d1 == d2, we should have d1.year == d2.year). Note that this is one of the reasons compareTo exists. Otherwise we could just always use the comparison operators. Another reason is doubles where compareTo and the comparison operators are different (like for doubles, where -0 == 0, but (-0).compareTo(0) < 0). Finally, a third reason for compareTo is, that it can be more efficient than doing two comparisons.

--

[Florian Loitsch]

Yes. For C programmers (and often other languages) there is an agreement that false has an implicit value of 0, and true of 1. (Try 0 == false in JavaScript).

This is a historical artifact. One could equally implement false as -1 (for example). In practice true and false are frequently implemented as pointers to some object (at least in JS or Dart). As such the 0, 1 distinction doesn't have any meaning anymore.

Given that we don't see practical reasons to call compareTo on booleans we won't make booleans Comparable.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

[Alex Tatumizer]

@Florian: as I noted earlier, difficulties in DateTime all arise from wrong definition of the class, which tries to be too many things at once: it denotes moment in time AND the its REPRESENTATION in different timezones. It's like we would incorporate String representation into integer, and prove (easily) that ints cannot be compared at all: because 9<10 as ints, but "10"<"9" as strings, and we have intractable problem, so let's define compareTo one way, > another way, and on top of that introduce isLesserThan, isGreaterThan, etc, This is what you did in DateTime, and no amount of clever  reasoning will be enough to explain that. But somehow, you are reluctant to introduce "Instant" and split DateTime two notions, so the problem won't go away anytime soon.

Do you at least FEEL how confusing it is?

BTW, example with doubles doesn't justify much. The reason it's complicated with doubles is related to special values NaN, +/-0, +/- infinity. There's no special values in dates, so the analogy looks artificial..

As for practical reasons to compare booleans, there ARE practcical reasons, as I noted in the opening salvo from this thread.

Booleans can be part of complex keys, e.g. we have complex key [ String, int, bool ]. How do you write compareTo function for complex keys of GENERAL composition, e.g. to implement binary search? You want to do it generically, but it won't work BECAUSE your booleans are not comparable. So generic implementation should have special case: if (type==boolean) doOneThing else doAnother

That;s where I encountered a problem in the first place. This make things ugly.

@Lasse: I don't want to disillusion, but your idea of how DateTime is defined is simplistic. You have to really (physically) open the definition to see what it is.

[Florian Loitsch]

On Fri, Aug 30, 2013 at 2:23 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

@Florian: as I noted earlier, difficulties in DateTime all arise from wrong definition of the class, which tries to be too many things at once: it denotes moment in time AND the its REPRESENTATION in different timezones.

correct. It's the ZonedDateTime from threeten.

 

It's like we would incorporate String representation into integer, and prove (easily) that ints cannot be compared at all: because 9<10 as ints, but "10"<"9" as strings, and we have intractable problem, so let's define compareTo one way, > another way, and on top of that introduce isLesserThan, isGreaterThan, etc, This is what you did in DateTime, and no amount of clever  reasoning will be enough to explain that. But somehow, you are reluctant to introduce "Instant" and split DateTime two notions, so the problem won't go away anytime soon.

Do you at least FEEL how confusing it is?

A ZonedDateTime is the most useful for users. Sure: you could also provide Timezone, Instant, Date, Time in addition to ZonedDateTime, but it wouldn't change the fact that ZonedDateTime is what you want to use.

BTW, example with doubles doesn't justify much. The reason it's complicated with doubles is related to special values NaN, +/-0, +/- infinity. There's no special values in dates, so the analogy looks artificial..

As for practical reasons to compare booleans, there ARE practcical reasons, as I noted in the opening salvo from this thread.

Booleans can be part of complex keys, e.g. we have complex key [ String, int, bool ]. How do you write compareTo function for complex keys of GENERAL composition, e.g. to implement binary search? You want to do it generically, but it won't work BECAUSE your booleans are not comparable. So generic implementation should have special case: if (type==boolean) doOneThing else doAnother

That;s where I encountered a problem in the first place. This make things ugly.

I still don't understand. If you write a data structure that needs to do comparisons you should provide a way to override your comparison function (see `compare` argument to `List.sort`). Of course, it is a good idea to default to `compareTo` (again see `List.sort`).

@Lasse: I don't want to disillusion, but your idea of how DateTime is defined is simplistic. You have to really (physically) open the definition to see what it is.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Alex Tatumizer]

> I still don't understand. If you write a data structure that needs to do comparisons you should provide a way to override your comparison function (see `compare` argument to `List.sort`). Of course, it is a good idea to default to `compareTo` (again see `List.sort`).

I have an array of data structs of known format (e.g. Pigeon maps, if you follow another thread that deals with Pigeons), let's call this array "a table".

Suppose I want to implement function table.createIndex(["lastName", "age", "isZombie"]); Index can be created over ANY subset of columns. I'd like to be able to use this index in requests like

index.find("lastName=? && age > ? && isZombie = ?", "Smith", 50, true); 

Whatever method to implement index I choose, I need the way to generically implement compareTo over tuples. Hence the special case for bool, otherwise you just blindly call compareTo component-by-component. Now it's not "blindly": if (type==bool) somethingSpecial

Obviously, java accounted for this scenario while providing Boolean.compareTo

Looks like a small issue on the surface, but small issues like this, if not identified and addressed, tend to accumulate and damage the language.

[Lasse R.H. Nielsen]

On Fri, Aug 30, 2013 at 2:01 PM, Florian Loitsch <floi...@google.com> wrote:

On Fri, Aug 30, 2013 at 12:35 PM, <dangli...@gmail.com> wrote:

>> Or false is like 0x404012454 and true is like 0x40401245c. Or the other way around. Or something.

Let me disagree with you. Boolean is a data type that having two values. Usually these values are true and false.
For some reason it is enough just one bit to encode these values.
Unfortunately, your example is not obvious by the considerations of reasonableness.
More reasonable example may looks like: false is like 0 and true is like 1 (in bits).

Yes. For C programmers (and often other languages) there is an agreement that false has an implicit value of 0, and true of 1. (Try 0 == false in JavaScript).

I believe it was the other way around in Basic :)

/L

 

This is a historical artifact. One could equally implement false as -1 (for example). In practice true and false are frequently implemented as pointers to some object (at least in JS or Dart). As such the 0, 1 distinction doesn't have any meaning anymore.

Given that we don't see practical reasons to call compareTo on booleans we won't make booleans Comparable.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

[Alex Tatumizer]

I looked into java ZonedDateTime  - I didn't know you used it as  a prototype for DateTime. This class is convenient indeed, and convenience beats everything else, I agree. ZonedDateTime is *much* richer, of course - but probably you will add stuff later. Because of differences in functionality, it's difficult to appreciate DateTime - it looks severely lacking.

Still, I think renaming isSameMomentAs to isEqualInstant (that's more or less how it is in ZonedDateTime) would be a good idea, because it uses 2 standard words "equal" and "instant" instead of "same" and "moment". At some point, you may still introduce "Instant", then date.instant >= date2.instant, which is IMO better than isBefore and friends, but maybe it's only me..

Anyway, this is only tangentially related to bool.compareTo()

[Gen]

I think that the decision about compareTo for DateTime objects is exactly the same as for bool objects.

The timezone introduces no technical or practical problem that could not be solved in an intuitive way.

Instead it is all about the effort to agree on and implement a standard compareTo method for some or all classes.

[Alex Tatumizer]

@Gen: in DateTime, compareTo is implemented exactly as expected. Why bool provoked such a controversy - I have no idea.