ID: 21728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.4.0-dev
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
------------------------------------------------------------------------
[2003-02-06 05:21:39] [EMAIL PROTECTED]
I agree. However, in order to give a wholly reliable sort order for
elements of mixed type, I think the only real option is to use a method
that does primary sort on type, with secondary sort on value only when
types are equal. I suppose there might just be a case for providing an
additional sort type for this, but, given that it can be implemented in
userland with a type-checking callback to usort(), I'm not totally
convinced.
At the very least, I think we need a big fat warning in the docs about
the hazards of mixed-type sorting!
Cheers!
Mike
------------------------------------------------------------------------
[2003-02-05 02:34:58] [EMAIL PROTECTED]
Reclassified as a sort() problem as this is too weird and
unpredictable. Maybe php-dev can confirm this behavior as how it
should and will continue to be. Mike, nice response but I still don't
like this ;)
------------------------------------------------------------------------
[2003-01-20 12:00:26] [EMAIL PROTECTED]
There was (and is) a suspicion in me about because the sort is made by
qsort algo. As you said all comparisons are valid ones but the order is
unpredicatble.
Thanks for the comment.
I think we should rethink the sort() function and maybe change the
default way of sorting (from SORT_REGULAR to SORT_STRING).
------------------------------------------------------------------------
[2003-01-20 11:54:48] m dot ford at lmu dot ac dot uk
Well, one of the problems here is that some of the array elements will
take different values in an element-to-element comparison depending on
the type of the other element. For example, "true" will be just that
compared to another string, but 0 when compared against an integer;
strings and integers are both converted to Boolean when compared to
true/false (with resulting loss of significant information).
Another problem is that if you're using a non-sequential sorting
algorithm (such as shellsort or quicksort), simply changing the length
of the array will probably change which element is compared to which,
and hence, because of the strangeness of "dual values" caused by
type-juggling, the final order of the array. (This may be even worse
for an algorithm that is not guaranteed to maintain the order of equal
items.)
If you take a look at the sorted versions of each array cited, you will
find that all of the element-to-neighbour-element comparisons are
actually valid, thus:
array("a","b","c","d","4",5,4,"true","TRUE",true) --
true : 4 ==> (bool) true == true
4 : "4" ==> (int) 4 == 4
"4" : "TRUE" ==> (string) "4" < "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a" : "b" ==> (string) "a" < "b"
"b" : "c" ==> (string) "b" < "c"
"c" : "d" ==> (string) "c" < "d"
"d" : "true" ==> (string) "d" < "true"
"true" : 5 ==> (int) 0 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c") --
false : "TRUE" ==> (bool) false < true
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a" : "true" ==> (string) "a" < "true"
"true" : true ==> (bool) true == true
true : "b" ==> (bool) true == true
"b" : "c" ==> (string) "b" < "c"
"c" : 4 ==> (int) 0 == 4
4 : "4" ==> (int) 4 == 4
"4" : 5 ==> (int) 4 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c", "d") --
false : "4" ==> (bool) false < true
"4" : "TRUE" ==> (string) "4" < "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a" : "b" ==> (string) "a" < "b"
"b" : "c" ==> (string) "b" < "c"
"c" : "d" ==> (string) "c" < "d"
"d" : "true" ==> (string) "d" < "true"
"true" : true ==> (bool) true == true
true : 4 ==> (bool) true == true
4 : 5 ==> (int) 4 < 5
So, in each case, we have a valid sort -- just a *different* valid
sort. The prime determiners here seem to be the non-sequential order
in which the individual comparisons are performed, and, as has been
indicated, the automatic casting that takes place for each one.
(Incidentally, whilst putting the above together I was unable to find a
definitive listing of *exactly* what automatic type-conversions take
place in which contexts. This is a definite oversight, as in contexts
like the above it's important to know, for example, that comparing an
int to a bool will cast the int to bool, and not the bool to int.
Perhaps this needs to become a doc problem for the inclusion of such a
list or table?)
Hope this enlightens at least some souls reading this far!
Cheers!
Mike
------------------------------------------------------------------------
[2003-01-18 12:23:24] [EMAIL PROTECTED]
Maybe it should not happen but the as I said the comparisons done are
correct (extensive type juggling). Maybe SORT_REGULAR is not the way to
sort (by default) but SORT_STRING.
Comments from other people are welcome :)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21728
--
Edit this bug report at http://bugs.php.net/?id=21728&edit=1
