Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 128
ну, во-первых реализация удаления элемента скажем так спорная.
во-вторых, я за такой код отрывал бы что-нть жизненно важное. (на php и js не пишу, но подозреваю, что это плохой пример для подражания)
Да, я понимаю, что смешаные типы в массиве это забавно, но надо понимать, что это влечет проблемы и их лучше избегать изначально.
насчет голосования и языков — «разруха она в головах», писать надо так, чтобы такого поведения не возникало.
во-вторых, я за такой код отрывал бы что-нть жизненно важное. (на php и js не пишу, но подозреваю, что это плохой пример для подражания)
Да, я понимаю, что смешаные типы в массиве это забавно, но надо понимать, что это влечет проблемы и их лучше избегать изначально.
насчет голосования и языков — «разруха она в головах», писать надо так, чтобы такого поведения не возникало.
ну, во-первых реализация удаления элемента скажем так спорная.Задача была написать нечто где ну уж точно никто не может заподозрить ошибку.
Да, я понимаю, что смешаные типы в массиве это забавно, но надо понимать, что это влечет проблемы и их лучше избегать изначально.Совершенно верно — из нужно избегать изначально. На этапе проектирования языка. В Python — уже первый массив не отсортирован, в Lisp — про него даже нельзя сказать отсортирован он или нет (операции сравниения для чисел и строк разные, если пытаться подсунуть «чужеродный» объект — просто вылетит исключение).
Задача была написать нечто где ну уж точно никто не может заподозрить ошибку.
Вы с ней не справились.
a[i]!=e вот это условие явно и недвусмысленно на это намекает. В javascript и пхп сравнение всегда стоит производить оператором ===. Исключение из этого правила для js – это сравнение на «неопределенность», тогда следует писать != null, да и то из исключительно практических соображений: некоторые авторы сторонних библиотек пихают null вместо undefined в свойства объектов и передают undefined вместо null в качестве аргументов функции (обычно в функциях с сигнатурой (err, result)).
Python, неправильный элемент 2.
>>> a = [1,2,«3»,4,«5»,6]
>>> z = [x for x in a if x != 2]
>>> z
[1, '3', 4, '5', 6]
все правильно, в чем проблема-то? И да, используйте итераторы. for — уже история.
>>> a = [1,2,«3»,4,«5»,6]
>>> z = [x for x in a if x != 2]
>>> z
[1, '3', 4, '5', 6]
все правильно, в чем проблема-то? И да, используйте итераторы. for — уже история.
да, до кучи, я не понял по чему отсортирован массив [7, «13», «5», 6] поясните незнающему
Что значит «по чему отсортирован»? Первый элемент меньше второго, второй — меньше третьего, третий — меньше четвёртого. Кто скажет что это не отсортированный массив? А какой тогда массив из этих элементов вы хотели бы называть отсортированным?
который был пропущен через функцию сортировки ( если она, конечно, не зациклится на таких данных ;-) )
Нет, не зациклится. Для сортировки в обоих случаях не применяется обычные операторы сравнения. Просто там некоторые элементы после «сортировки» будут идти не по порядку (в смысле могут быть случаи когда a[i]<a[i+1]>a[i+2] в «отсортированном» массиве). То есть если понимать отсортированность в этом смысле, то с удалением — проблем не будет, но будут проблемы со вставкой.
Для сортировки в обоих случаях не применяется обычные операторы сравнения. Просто там некоторые элементы после «сортировки» будут идти не по порядку (в смысле могут быть случаи когда a[i]<a[i+1]>a[i+2] в «отсортированном» массиве).
Если сортировать приведенный вами в примере массив $before с помощью операторов сравнения, то получится массив
array("5", 6, 7, "13"), где тут случай «a[i]<a[i+1]>a[i+2]»?"5" < 6 == true
6 < 7 == true
7 < "13" == true
Пожалуйста, поясните, почему у вас
array(7, "13", "5", 6) является отсортированным? И какой функцией вы его сортировали?
Присоединяюсь :) Не знаю как в JS, но в PHP выдаётся что они оба не отсортированы. Быть может виноват конкретный интерпретатор…
codepad.org/ehlz2C3c
codepad.org/ehlz2C3c
<?php
function remove_element(/* array */ $a, /* element */ $e) {
$b = array();
foreach($a as $m) {
if ($m != $e) array_push($b, $m);
}
return $b;
}
function is_sorted1(/* array */ $a) {
for($i = 0; $i < count($a)-1; $i++) {
if ( $a[$i] > $a[$i+1]) return 0;
}
return 1;
}
function is_sorted2(/* array */ $a) {
$j = 0;
for($i = 0; $i < count($a)-1; $i++) {
if ( $a[$i] < $a[$i+1]) $j++;
}
return $j == count($a)-1 ? 1 : 0;
}
$before = array(7, "13", "5", 6);
$after = remove_element($before, "13");
var_dump($before);
print(is_sorted1($before));
print(is_sorted2($before));
print("\n");
var_dump($after);
print(is_sorted1($after));
print(is_sorted2($after));
?>Вы тут используете для сравнения операторы "<" и ">". Автор указал, что не использовал их для сортировки:
Так что ваш код немного не то проверяет.
Для сортировки в обоих случаях не применяется обычные операторы сравнения.
Так что ваш код немного не то проверяет.
Тогда мы приходим к ранее озвученному вопросу, что же автор имеет в виду под отсортированностью, если не сравнение элементов.
:) Одним словом в этом случае и ваш пример не проверяет отсортированность.
Его код то проверяет — пример неверный. Я помнил что в PHP это маразм наблюдается и не подумал что и в PHP может быть маразм и в JavaScript'е — маразм, но и там и там это разные маразмы.
Ой-ой-ой. Посыпаю голову пеплом. Не учёл что каждая несчастная семья несчастлива по своему.
Исправил пример для PHP.
Исправил пример для PHP.
Ага, ботва, теперь работает. Надеюсь те, кто ещё не знал об этой особенности сравнений в PHP — узнает.
P.S. codepad.org/AGlUdT7A
P.S. codepad.org/AGlUdT7A
Тут, насколько я понимаю, фокус в том, что 7 как число меньше как строка 13, приведённая к числу. А 13 как строка меньше, чем 5 как строка (типа, лексикографически). Ну а 5 по-любому меньше 6-и.
Так если для сортировки использовалось описанное вами отношение, то оно нетранзитивное:
Так как оотношение нетранзитивное, почему множество, на котором оно определено, называется упорядоченным?
$before = array(7, "13", "5", 6);
7 < "13" // 7 как число меньше, чем строка "13", приведённая к числу
"13" < "5" //"13" как строка меньше, чем "5" как строка (типа, лексикографически)
Но, 7 > "5" // 7 как число больше, чем строка "5", приведённая к числу
Так как оотношение нетранзитивное, почему множество, на котором оно определено, называется упорядоченным?
Так как оотношение нетранзитивное, почему множество, на котором оно определено, называется упорядоченным?А как вы ещё назовете множество с операциями больше и меньше?
Вы уже поменяли пример в топике, теперь ясно, как вы его упорядочили (раньше было неясно).
Если отношения ">" и "<" не являются транзитивными, то и множества, на котором эти отношения определены, не являются упорядоченными. В PHP эти отношения не являются отношениями порядка (для смешанных множеств) вследствие их нетранзитивности, а значит и приведенные вами в качестве примера массивы не упорядочены.
А как вы ещё назовете множество с операциями больше и меньше?
Если отношения ">" и "<" не являются транзитивными, то и множества, на котором эти отношения определены, не являются упорядоченными. В PHP эти отношения не являются отношениями порядка (для смешанных множеств) вследствие их нетранзитивности, а значит и приведенные вами в качестве примера массивы не упорядочены.
> P.P.S. Вообще весь топик вырос из дискуссии где мне пытались объяснить что я ничего не понимаю в программировании и моё нежелание мириться с подобными, с позволения сказать, языками программирования свидетельствует о моей серости и убогости, а не о проблемах в языке.
Ну вот и снова пустая демагогия.
Ну вот и снова пустая демагогия.
выдаёт 7,5,6
и-и-и?
и-и-и?
Насколько я понял, идея сводится к тому, что для некоторых языков можно придумать такой код, что результат исполнения будет неестествен. Правильно ли я это понял?
Если да, то я совершенно с Вами согласен, а код, который Вы привели, может быть неплохим вопросом для интервью.
Хочется также отметить, что языки программирования с динамической типизацией накладывают бОльшую ответственность на разработчика, так как необходимо следить за тем, чтобы не оказаться в ситуации, которую иллюстрирует Ваш пример.
А вообще работает принцип SI=SO
Если да, то я совершенно с Вами согласен, а код, который Вы привели, может быть неплохим вопросом для интервью.
Хочется также отметить, что языки программирования с динамической типизацией накладывают бОльшую ответственность на разработчика, так как необходимо следить за тем, чтобы не оказаться в ситуации, которую иллюстрирует Ваш пример.
А вообще работает принцип SI=SO
Хочется также отметить, что языки программирования с динамической типизацией накладывают бОльшую ответственность на разработчика, так как необходимо следить за тем, чтобы не оказаться в ситуации, которую иллюстрирует Ваш пример.Почему тогда подобных проблем нет в Python'е или в Lisp'е? Это — не языки с динамической типизацией уже?
По моему разработчикам языков не стоит валить на динамическую типизацию свою безграмотность.
У $before тип массив! Не сортированный массив, не правильный массив, просто массив! Вы сказали удалить, он и удалил. А вот если бы он начал сортировать или чтото еще делать, то это думаю было бы уже неправильно.
В Computer Sciense есть два таких факта (как бы очевидных для всех, кроме программистов на JavaScript или PHP):
1. Если из отсортированного массива удалить элемент — то массив останется отсортированным.
2. Если в отсортированный массив вставить элемент так, чтобы он был больше предыдущего элемента и меньше последующего — то массив останется отсортированным.
Это — фундаментальные факты, следуюшие из того, что операции «<» и «>» являются отношением порядка.
Так вот в языках PHP и JavaScript операции «<» и «>» не являются отношением порядка и соответственно вы можете выбирать — что именно вас интересует: вариант 1 или вариант 2. Можно называть «отсортированными» разные массивы и получать нарушение либо первого фундаментально факта, либо второго (на выбор), но соблюсти их одновременно (и, соответственно, получить право использовать достижения Computer Sciense) нельзя. Вот такое «удобство» польза от которого очень сомнительна, а вред очевиден.
В этих недоязыках есть и другие проблемы, но я специально выбрал самый вопиющий пример.
1. Если из отсортированного массива удалить элемент — то массив останется отсортированным.
2. Если в отсортированный массив вставить элемент так, чтобы он был больше предыдущего элемента и меньше последующего — то массив останется отсортированным.
Это — фундаментальные факты, следуюшие из того, что операции «<» и «>» являются отношением порядка.
Так вот в языках PHP и JavaScript операции «<» и «>» не являются отношением порядка и соответственно вы можете выбирать — что именно вас интересует: вариант 1 или вариант 2. Можно называть «отсортированными» разные массивы и получать нарушение либо первого фундаментально факта, либо второго (на выбор), но соблюсти их одновременно (и, соответственно, получить право использовать достижения Computer Sciense) нельзя. Вот такое «удобство» польза от которого очень сомнительна, а вред очевиден.
В этих недоязыках есть и другие проблемы, но я специально выбрал самый вопиющий пример.
Я все же думаю, что эти правила справедливы только для однородных элементов.
В случае разнородных элементов к ним применяются разные правила сравнения, в зависимости от типа.
Кроме того, разве правила сравнения строки и числа однозначны? Где-нибудь сказано, что число обязательно нужно приводить к строке и сравнивать как строки? Думаю, это все же зависит от языка.
Ну, и еще: как быть с тем, что в Вашем примере (7, «13», «5», 6) соотношения выполняются только для непосредственных соседей, но не дальше? И, как мне кажется, разные методы сортировки входных данных дали бы разные результаты, хотя по логике сортировка массива должна бы быть инвариантна к алгоритму.
В случае разнородных элементов к ним применяются разные правила сравнения, в зависимости от типа.
Кроме того, разве правила сравнения строки и числа однозначны? Где-нибудь сказано, что число обязательно нужно приводить к строке и сравнивать как строки? Думаю, это все же зависит от языка.
Ну, и еще: как быть с тем, что в Вашем примере (7, «13», «5», 6) соотношения выполняются только для непосредственных соседей, но не дальше? И, как мне кажется, разные методы сортировки входных данных дали бы разные результаты, хотя по логике сортировка массива должна бы быть инвариантна к алгоритму.
Я все же думаю, что эти правила справедливы только для однородных элементов.Это подход Lisp'а. Грамотный подход IMO.
В случае разнородных элементов к ним применяются разные правила сравнения, в зависимости от типа.
Кроме того, разве правила сравнения строки и числа однозначны? Где-нибудь сказано, что число обязательно нужно приводить к строке и сравнивать как строки? Думаю, это все же зависит от языка.И да и нет. На эту тему есть два подхода, которые можно назвать разумными:
1. Подход Lisp'а. Сравнение строк и чисел запрещено — получаем от разумных алгоритмов разумный результат или синтаксическую ошибку.
2. Подход Python. Сравнение объектов разных типов разрешено, все алгоритмы работают, а уж как именно сравниваются объекты разных типов — неважно.
Подход же JavaScript'а/PHP в корне порочен: у нас есть фича (объекты разных типов сравнивать можно), но использовать её нельзя. Зачем нам такая фича?
Ну, и еще: как быть с тем, что в Вашем примере (7, «13», «5», 6) соотношения выполняются только для непосредственных соседей, но не дальше? И, как мне кажется, разные методы сортировки входных данных дали бы разные результаты, хотя по логике сортировка массива должна бы быть инвариантна к алгоритму.Это прямое следствие того, что авторы языка непонятно чем думали, когда его разрабатывали.
Тут причина не в динамической, а в нестрогой типизации. Если типизация нестрогая, тогда и происходит то, что вы описиваете — операции "<" и ">" теряют свойство транзитивности.
Проблема ни в строгой/нестрогой типизации, а в больной голове. Разные типы либо должны сравниваться логично (Python: objects of different types always compare unequal, and are ordered consistently but arbitrarily, либо не сравниваться вообще (Lisp: сравнение объектов неправильного типа кидает исключением). Наличие же того маразма, что есть в JavaScript и PHP обозначает что в языке есть фича, которая иногда «делает хорошо», а иногда — приводит к взрыву. Зачем в языке такая фича? Для чего она может использоваться?
Приводит «к взрыву» она если использовать ее бездумно, да и то. это не взрыв, взрыв как раз исключение. А автоматическое приведение типов операндов особенно в случае строк и чисел очень удобно в основной области применения php. Главно знать как оно работает и там где нужно использовать принудительное приведение типов
питон: ходите вот по этим эккуратным дорожкам. если захотите перебраться на другую — воспользуйтесь специальным мобильным мостиком.
яваскрипт: бегайте где хотите, но если вы прочтёте пятый том инструкции по выживанию, то узнаете, что в поле у нас закопаны мины, описанию схемы их расположения посвящены тома 6, 7 и 8.
тебе что больше хочется? реализовать новую вебзванольноаяксовую визивигнутую фичу или потрахаться с языком?
яваскрипт: бегайте где хотите, но если вы прочтёте пятый том инструкции по выживанию, то узнаете, что в поле у нас закопаны мины, описанию схемы их расположения посвящены тома 6, 7 и 8.
тебе что больше хочется? реализовать новую вебзванольноаяксовую визивигнутую фичу или потрахаться с языком?
Я только высказал свое мнение причины поведения, которое вы описываете — нетранзитивность операций сравнения, но я ни в коем случае не защищаю такой подход, поскольку он действительно очень опасен.
Кстати, хотел исправиться: имелась в виду не нестрогая/строгая, а сильная/слабая (strong/weak) типизация. У Питона и Лиспа — она сильная по отношению к числам/строкам, поскольку они не интерпретируют строки, как числа, у JavaScript и PHP слабая — они могут интерпретировать строки как числа, поэтому и получается такой эффект.
Кстати, хотел исправиться: имелась в виду не нестрогая/строгая, а сильная/слабая (strong/weak) типизация. У Питона и Лиспа — она сильная по отношению к числам/строкам, поскольку они не интерпретируют строки, как числа, у JavaScript и PHP слабая — они могут интерпретировать строки как числа, поэтому и получается такой эффект.
>Разные типы либо должны сравниваться логично <...> либо не сравниваться вообще
Никто вас не ограничивает в js конвертировать значения к нужному типу. В чём проблема? Много-много лет js-программисты легко и непринуждённо пользуют не-транзитивный ==, без взрывов, если знаете, как работает оператор, откажитесь от внутренней конвертации, сделайте это заранее, проверьте тип и проч. Более того, например, строгое сравнение давно в языке, а им многие не пользуются и не стали бы пользоваться, если бы не дурацкая реклама последних 2-3 лет.
>Зачем в языке такая фича? Для чего она может использоваться?
Для всего. Столкновение разных типов в js — это жизнь, примитивные значения корреспондируют с соответствующими объектами, из DOM-a/BOM-a разные типы лезут и т.д. и т.п., всё это на лету, и язык даёт возможность не заморачиваться с конвертацией и делает это прозрачно. Если не нравится — конвертируем значения из типа в тип руками. И все дела.
Никто вас не ограничивает в js конвертировать значения к нужному типу. В чём проблема? Много-много лет js-программисты легко и непринуждённо пользуют не-транзитивный ==, без взрывов, если знаете, как работает оператор, откажитесь от внутренней конвертации, сделайте это заранее, проверьте тип и проч. Более того, например, строгое сравнение давно в языке, а им многие не пользуются и не стали бы пользоваться, если бы не дурацкая реклама последних 2-3 лет.
>Зачем в языке такая фича? Для чего она может использоваться?
Для всего. Столкновение разных типов в js — это жизнь, примитивные значения корреспондируют с соответствующими объектами, из DOM-a/BOM-a разные типы лезут и т.д. и т.п., всё это на лету, и язык даёт возможность не заморачиваться с конвертацией и делает это прозрачно. Если не нравится — конвертируем значения из типа в тип руками. И все дела.
Много-много лет js-программисты легко и непринуждённо пользуют не-транзитивный ==, без взрывовОй ли? Сколько дыр в безопасности эта помощь проделала? Это ли не «взрывы»? Потом ситуация с == не так остра: есть нормальный оператор ===, который, в общем-то, и нужно использовать.
Столкновение разных типов в js — это жизнь, примитивные значения корреспондируют с соответствующими объектами, из DOM-a/BOM-a разные типы лезут и т.д. и т.п., всё это на лету, и язык даёт возможность не заморачиваться с конвертацией и делает это прозрачно.Ну если вас не волнует работоспособность ваших творений — то да, можно не заморачиваться. Если волнует — заморачиваться таки приходится.
> есть нормальный оператор ===, который, в общем-то, и нужно использовать.
Если мыслить в строгой типизации, то да, иначе — выбирайте, как удобней. А Ваша любовь к непонятно откуда взявшимся утверждениям, по-прежнему, — вряд ли уместна.
Если мыслить в строгой типизации, то да, иначе — выбирайте, как удобней. А Ваша любовь к непонятно откуда взявшимся утверждениям, по-прежнему, — вряд ли уместна.
>Ой ли
Нестрогое равенство с самого начала стандарт де-факто в js. До сих пор. Строгое равенство введено позднее и редко используется там, где важна проверка типа (тип заранее неизвестен). Если вы знаете точно тип или уже конвертировали значения к нужному типу, то нестрогое сравнение — это и есть строгое сравнение (алгоритм один в один), если вы не знаете/предполагаете тип, то а) вы пользуетесь бонусом в виде конвертации при нестрогом сравнении и добиваетесь каких-то своих целей, б) вы используете строгое сравнение, чтобы не допустить конвертации и поймать false. Всё в рамках ваших задач. Учитывая то, что тип значения в js нужно вести глазами всю дорогу до конца, нестрогое сравнение полностью удовлетворит все желания…
>Ну если вас не волнует работоспособность ваших творений — то да, можно не заморачиваться. Если волнует — заморачиваться таки приходится.
Укол зонтиком? Отвечу не сам. Strong typing is one reason that languages like C++ and Java require more finger typing. You have to declare all your variables and you have to do a lot of work just to make the compiler happy. An old saying from Unix developers goes something like, «If only your programs would be correct if you simply typed them three times.» You'd gladly do that if typing your programs three times was enough to make them work correctly, but unfortunately it doesn't work that way. All that attention to getting the types right doesn't necessarily mean you don't have other bugs in your program. /Guido van Rossum/
Нестрогое равенство с самого начала стандарт де-факто в js. До сих пор. Строгое равенство введено позднее и редко используется там, где важна проверка типа (тип заранее неизвестен). Если вы знаете точно тип или уже конвертировали значения к нужному типу, то нестрогое сравнение — это и есть строгое сравнение (алгоритм один в один), если вы не знаете/предполагаете тип, то а) вы пользуетесь бонусом в виде конвертации при нестрогом сравнении и добиваетесь каких-то своих целей, б) вы используете строгое сравнение, чтобы не допустить конвертации и поймать false. Всё в рамках ваших задач. Учитывая то, что тип значения в js нужно вести глазами всю дорогу до конца, нестрогое сравнение полностью удовлетворит все желания…
>Ну если вас не волнует работоспособность ваших творений — то да, можно не заморачиваться. Если волнует — заморачиваться таки приходится.
Укол зонтиком? Отвечу не сам. Strong typing is one reason that languages like C++ and Java require more finger typing. You have to declare all your variables and you have to do a lot of work just to make the compiler happy. An old saying from Unix developers goes something like, «If only your programs would be correct if you simply typed them three times.» You'd gladly do that if typing your programs three times was enough to make them work correctly, but unfortunately it doesn't work that way. All that attention to getting the types right doesn't necessarily mean you don't have other bugs in your program. /Guido van Rossum/
Сортировка — расположение элементов списка в определенном порядке. Когда вы отсортировали массив и получили [7, «13», «5», 6], вы делали это по вами же заданным правилам. Например я могу написать такой код:
Соответственно, я получу массив [«5», 6, 7, «13»] — массив, отсортированный по моим правилам (а именно ai < aj, j ⊆ {x | i+1 < x ≤ n}). По вашим правилам он не будет считаться отсортированным. Так вот, когда я удаляю элемент из массива предложенным вами методом, то по моим правилам он остается отсортированным, т.к. ваш метод корректно удаляет элемент.
Вы же придумали (или просто не задумывались о том, что оно есть) свое правило, которое является достаточно вычурным, а в своем методе удаления элемента это правило не учитываете. Вас же не удивляет, что при удалении элемента из сбалансированного двоичного дерева, иногда необходима операция поворота и перебалансировки?
arr = [7, "13", "5", 6];
arr.sort(function(a, b) {
return a - b;
});
Соответственно, я получу массив [«5», 6, 7, «13»] — массив, отсортированный по моим правилам (а именно ai < aj, j ⊆ {x | i+1 < x ≤ n}). По вашим правилам он не будет считаться отсортированным. Так вот, когда я удаляю элемент из массива предложенным вами методом, то по моим правилам он остается отсортированным, т.к. ваш метод корректно удаляет элемент.
Вы же придумали (или просто не задумывались о том, что оно есть) свое правило, которое является достаточно вычурным, а в своем методе удаления элемента это правило не учитываете. Вас же не удивляет, что при удалении элемента из сбалансированного двоичного дерева, иногда необходима операция поворота и перебалансировки?
Соответственно, я получу массив [«5», 6, 7, «13»] — массив, отсортированный по моим правилам (а именно ai < aj, j ⊆ {x | i+1 < x ≤ n}).А давайте не будем выдавать желаемое за действительное? В вашем «какбы-типа отсортированном массиве» первый элемент меньше последнего и, соответственно, согласно вашим правилам массив не отсортирован. Более того: он вообще не может быть отсортирнован согласно вашим правилам. В принципе.
Вы же придумали (или просто не задумывались о том, что оно есть) свое правило, которое является достаточно вычурным, а в своем методе удаления элемента это правило не учитываете.А вас не удивляет функция sort, которая нифига не сортирует и в приниципе не может сортировать?
Тьфу — последний элемент меньше первого, конечно. Но не суть. Суть в том, что ваша функция массив не сотрирует.
Ну вот в том то и дело, что сортирует, но по другим правилам. Эти правила я причем определил сам, передав функцию их описывающую параметром метода sort, как вы, наверное, заметили.
Любой упорядоченный набор элементов я могу назвать отсортированным, если смогу придумать для него условие сортировки, которому он удовлетворяет. Даже численную сортировку можно сделать двумя способами — в прямом и обратном порядке. Если вы привыкли сортировать в прямом, значит ли это, что массив, отсортированный в обратном, вовсе и не является сортированным?
То, что вы утверждаете, что операторы < и > в Яваскрипте и ПХП не являются отношениями порядка — абсолютно верно. И если уж подходить к вопросу с позиции отношения порядка, то как раз в вашем примере массив не является отсортированным, т.к. 7 < '13', но больше 6.
Было бы кстати очень узнать источник тех двух свойств отсортированных массивов, о которых вы говорите в своем комментарии чуть выше.
Любой упорядоченный набор элементов я могу назвать отсортированным, если смогу придумать для него условие сортировки, которому он удовлетворяет. Даже численную сортировку можно сделать двумя способами — в прямом и обратном порядке. Если вы привыкли сортировать в прямом, значит ли это, что массив, отсортированный в обратном, вовсе и не является сортированным?
То, что вы утверждаете, что операторы < и > в Яваскрипте и ПХП не являются отношениями порядка — абсолютно верно. И если уж подходить к вопросу с позиции отношения порядка, то как раз в вашем примере массив не является отсортированным, т.к. 7 < '13', но больше 6.
Было бы кстати очень узнать источник тех двух свойств отсортированных массивов, о которых вы говорите в своем комментарии чуть выше.
Ну вот в том то и дело, что сортирует, но по другим правилам. Эти правила я причем определил сам, передав функцию их описывающую параметром метода sort, как вы, наверное, заметили.Я это заметил — но это ничего не изменило. Вы пишете что вы называете массив отсортированным если «ai < aj, j ⊆ {x | i+1 < x ≤ n}». Так вот у вас это неверно если i равно нулю, а j равно трём.
То, что вы утверждаете, что операторы < и > в Яваскрипте и ПХП не являются отношениями порядка — абсолютно верно. И если уж подходить к вопросу с позиции отношения порядка, то как раз в вашем примере массив не является отсортированным, т.к. 7 < '13', но больше 6.И в вашем и в моём случае соседние элементы идут в «правильном» порядке, и в вашем и в моём случае массив в целом — не отсортирован. Более того если бы взяли другой массив (скажем [«13», «8», «90»]), то ваша функция его бы сделала из сортированного — несортированным.
Было бы кстати очень узнать источник тех двух свойств отсортированных массивов, о которых вы говорите в своем комментарии чуть выше.Ну вы и сами его знаете — это верно для любого отсортированного массива, если операция сравнения такие является отношением порядка.
Собственно вопрос в том и заключается: «это ж кем надо быть чтобы за 30 серебренников продать родину?»! Что JavaScript и PHP получили за свои операторы сравнения, которые не являются отношением эквивалентности (оператор == — слава богу ему в подмогу дали нормальный оператор ===) и отношением порядка соотвественно? За какие такие сладкие преимущества они согласились расстаться со всем наработанным теоретической информатикой (немного утрирую, конечно, но очень многое летит если у вас оператор сравнения — это не отношение порядка, а бог знает что)? Что они получили взамен? Много новых интересных способов создать в программа разные виды уязвимостей? Сомнительная польза…
Я это заметил — но это ничего не изменило. Вы пишете что вы называете массив отсортированным если «ai < aj, j ⊆ {x | i+1 < x ≤ n}». Так вот у вас это неверно если i равно нулю, а j равно трём.
С чего же? Функция, которая задает сортировку, приведена. Если ей передать '5' и '13' она вернет отрицательное число, что значит, что '5' меньше '13' по тем правилам, которые я выбрал для данной конкретной сортировки. Где вы видите противоречие?
Мне кажется не стоит хаять языки программирования. Они даны — играйте по их правилам.
Мне кажется не стоит хаять языки программирования. Они даны — играйте по их правилам.Я и играю. Получаю маразм. Это вы «меняете правила игры» задавая свою функцию сортировки. Если потом проверить отсортированность массива по «правилам игры языка» — он окажется не отсортированным.
Я и играю. Получаю маразм.
Не могли бы вы описать реальную задачу, решая которую вы столкнулись с этой «проблемой»? Задачу, в которой вам необходимо сортировать множество из разнородных элементов.
Я и играю. Получаю маразм. Это вы «меняете правила игры» задавая свою функцию сортировки. Если потом проверить отсортированность массива по «правилам игры языка» — он окажется не отсортированным.
Вообще-то определение «упорядоченный» не указывает, каким конкретно образом множество упорядочивается, главное, чтобы это было отношение порядка.
Не могли бы вы описать реальную задачу, решая которую вы столкнулись с этой «проблемой»? Задачу, в которой вам необходимо сортировать множество из разнородных элементов.Да легко: у меня есть набор объектов из базы, я добавляю туда парочку своих. В базе ID'шники хранятся как числа, вновь созданные объекты имеют числовые ID'шники (по недосмотру или специально — чтобы не путались с объектами вытащенными из базы). Lisp мне скажет «ты что — придурок?» и я программу поправлю. Python молча проглотит всё и всё будет работать. В JavaScript/PHP всё будет работат у разработчика, но рано или поздно «ляжет» у заказчика. В реальной жизни ID'шники были составными (то есть простой возможности использовать ассоциативные массивы не хватало).
Вообще-то определение «упорядоченный» не указывает, каким конкретно образом множество упорядочивается, главное, чтобы это было отношение порядка.Час от часу не легче. То есть в PHP у нас вызов функции sort() не создают отсортированный массив? Это — новаторский подход, конечно…
В базе ID'шники хранятся как числа, вновь созданные объекты имеют числовые ID'шники
Должно быть, вы имели ввиду «вновь созданные объекты имеют строковые ID'шники»?
Вы немного не поняли. Вы привели не ту задачу, в которой необходимо упорядочивать именно разнородное множество, вы привели лишь задачу, в которой язык программирования ведет себя не так, как вы ожидали вследствие вашей же невнимательности. Не знаю, как вас, но вот лично меня несколько смущает, что одни и те же объекты хранятся в одном множестве, имея при этом разный тип (это я про ID'шники).
Час от часу не легче. То есть в PHP у нас вызов функции sort() не создают отсортированный массив? Это — новаторский подход, конечно…
Не знаю, в чем заключается новаторский подход.
В математике частично упорядоченным множеством называется множество, на котором определено отношение частичного порядка. Еще раз повторю, что в PHP отношения "<" и ">" не являются отношениями частичного порядка на смешанных множествах, состоящих из строк и чисел одновременно. Значит массив
array("11", "a", 2, 3) не является упорядоченным с математической точки зрения. Укажите, где я не прав.Должно быть, вы имели ввиду «вновь созданные объекты имеют строковые ID'шники»?Да, конечно.
Не знаю, как вас, но вот лично меня несколько смущает, что одни и те же объекты хранятся в одном множестве, имея при этом разный тип (это я про ID'шники).А почему нет? Если в базе у нас объекты одного типа, а «фиктивные» объекты имеют другой тип, то это простой способ добиться того, чтобы они никогда не совпали (они, впрочем, в PHP могут совпасть в смысле ==, но не в смысле ====). В Python этот же подход будет отлично работать без каких-либо проблем, в Lisp'е мне придётся определить свою функцию. В PHP я тоже могу определить свою функцию, но вот беда: если я этого не сделаю, то никаких ошибок отдиагностировано не будет — программа просто не заработает.
Не знаю, в чем заключается новаторский подход.Ась? Не знаете или притворяетесь?
Значит массив array(«11», «a», 2, 3) не является упорядоченным с математической точки зрения.С точки зрения математики это — не упорядоченный массив. А вот с точки зрения PHP — вполне себе упорядочнный:
$arr=array("11", "a", 2, 3);
sort($arr);
var_dump($arr);
Вот это и есть новаторский подход. Новая информатика и математика. Где отношения порядка нетранзитивны, а сортировка имеет другой смысл нежели в математике.
Если в базе у нас объекты одного типа, а «фиктивные» объекты имеют другой тип
И потом, через месяца два взглянув на код, будет сложно понять, почему одни идентификаторы фиктивные, а другие нет. Лучше бы уж они являлись экземплярами пользовательских классов, типа Id и MockId, а не имели типы «число» и «строка».
С точки зрения математики это — не упорядоченный массив. А вот с точки зрения PHP — вполне себе упорядочнный.
В мане по PHP написано, что не следует использовать функцию sort для сортировки массивов с разнородными элементами, по-скольку результат может быть непредсказуем. Потому утверждение «А вот с точки зрения PHP — вполне себе упорядочнный» — неверно. К тому же у sort имеется второй аргумент, который позволяет управлять способом сортировки. Скажите, а что если упорядочивать не просто множество из строк и чисел, а вообще из произвольных объектов, то там отношения "<" и ">" будут отношениями порядка? Я имею ввиду именно встроенные, а не перегруженные.
Где отношения порядка нетранзитивны, а сортировка имеет другой смысл нежели в математике.
Список возможных отношений порядка не заканчиваются на "<" и ">".
Реальную задачу, кстати, так и не привели.
Скажите, а что если упорядочивать не просто множество из строк и чисел, а вообще из произвольных объектов, то там отношения "<" и ">" будут отношениями порядка? Я имею ввиду именно встроенные, а не перегруженные.Если язык вменяем — то да. Скажем Python это гарантирует. Либо, как вариант, такой возможности в языке вообще нет — ну на нет и суда нет.
Питон ваши строковые айдишники отсортирует и поместит в конец списка. Получится у вас [6, 7, '13', '5'].
И я очень сомневаюсь, что такой результат вас устраивает, потому что '5' оказывается после 6, что это за сортировка такая? Будете удивляться, почему у вас «гладиолусы обыкновенные» ('5') выводятся позже «гладиолусов с секретом», хотя идентификаторы то идут в другом порядке, а строкой пятерку вы сделали, как сами признались, для того, чтобы «не путалось».
В итоге вам все равно нужно будет написать свое правило сортировки, которое вас удовлетворит. Пример не засчитан.
И я очень сомневаюсь, что такой результат вас устраивает, потому что '5' оказывается после 6, что это за сортировка такая? Будете удивляться, почему у вас «гладиолусы обыкновенные» ('5') выводятся позже «гладиолусов с секретом», хотя идентификаторы то идут в другом порядке, а строкой пятерку вы сделали, как сами признались, для того, чтобы «не путалось».
В итоге вам все равно нужно будет написать свое правило сортировки, которое вас удовлетворит. Пример не засчитан.
К слову, нередкое стремление людей непременно объяснить «почему хорошо именно то так как есть» — само по себе интересное явление. В таких случаях, опыт пользователя подгоняется под систему, но нет и идеи что может быть наоборот. Но пока я с этим не разобрался — как отличить где «чрезмерная защита системы», а где «капризность новичков».
Алан Купер написал про нечто схожее страницу текста: апологеты и уцелевшие.
Алан Купер написал про нечто схожее страницу текста: апологеты и уцелевшие.
минут 15 пытался понять о чем вообще тут разговор идет.
ИМХО если функция написана и применяется правильно (по всем правилам языка), то никаких спорных моментов быть не должно. А если вы хотите получить ответ на Главный Вопрос Жизни, Вселенной и Всего Такого, то и оставайтесь со своим 42.
Дзен Программисту все равно отсортирован его массив, или нет. Программа в любом случае будет работать.
смотрю на строчку
$before=array(7, «13», «5», 6);
и не пойму, в каком месте он отсортирован, если приводим к целым числам, то получаем, что должно быть (5, 6, 7, 13), если к строкам, то («13», «5», «6», «7»), а сортировать в одной последовательности числа и строки произвольно изменяя операцию сравнения чисел на операцию сравнения строк, это как сортировать купюры (разных образцов) и монеты, то по весу, то по номиналу.
$before=array(7, «13», «5», 6);
и не пойму, в каком месте он отсортирован, если приводим к целым числам, то получаем, что должно быть (5, 6, 7, 13), если к строкам, то («13», «5», «6», «7»), а сортировать в одной последовательности числа и строки произвольно изменяя операцию сравнения чисел на операцию сравнения строк, это как сортировать купюры (разных образцов) и монеты, то по весу, то по номиналу.
а сортировать в одной последовательности числа и строки произвольно изменяя операцию сравнения чисел на операцию сравнения строк, это как сортировать купюры (разных образцов) и монеты, то по весу, то по номиналу.
Думаю, что можно определить такое отношение порядка, которое позволит упорядочить смешанное множество, состоящее из строк и чисел. Только вот, например, в PHP, отношение "<" действительно не является отношением порядка (для смешанных множеств), так как:
var_dump('asd' < 1); // true
var_dump(1 < '2a'); // true
var_dump('asd' < '2a'); // false
Видимо это до нас пытается донести автор?
Выходит автор просто не читал мануала к PHP и почему-то решил, что операторы "<" и т. п. выражают отношения порядка, хотя там (в мануале) черным по белому (часть по серому :) ) написано, что это Comparison Operators, причем с неочевидными правилами сравнения и приведения типов для разных типов операндов
Выходит автор просто не читал мануала к PHPЯ как раз прочитал описания мануала к PHP — и мне стало дурно.
написано, что это Comparison Operators, причем с неочевидными правилами сравнения и приведения типов для разных типов операндовДа-да-да. Вот только беда: там не написано какому идиоту пришло в голову придумать такие правила. Как их использовать-то?
Представьте что у вас есть автомобиль. Отличный автомобиль, одна беда: при повороте налево он иногда взрывается. Ты говоришь: автомобиль дерьмо — какого фига он взрывается при повороте налево? А тебе отвечают: ты инструкцию не прочитал — согласно инструкции так и должно быть! Я говорю: отлично, прямо в инструкции написано что автомобиль — дерьмо, поменяйте. В чём дело-то? Ну не должно быть я грамотно спроектированном языке фич использование которых приводит к взрыву!
Да очень просто использовать — если не уверены, что правильно понимаете как правила сработают — приводите типы операндов вручную, если знаете, что именно реализованная в языке функциональность вам нужна, то используйте ее, а не смотрите на исключения и думайте как их обойти.
Некорректная аналогия :) Взрываются иногда как раз всякие лиспы, тут скорее автомобили с контролем концентрации паров алкоголя в салоне (строгая типизация) и без оного (слабая), в инструкции к с ограничителем ясно написано, что как если концентрация превысит н промиле, то машина не тронется, а вот без сограничителя написано, что может быть если сесть за руль пьяному. Выбор за вами, доверяйте или себе, или искусственному ограничителю
Некорректная аналогия :) Взрываются иногда как раз всякие лиспы, тут скорее автомобили с контролем концентрации паров алкоголя в салоне (строгая типизация) и без оного (слабая), в инструкции к с ограничителем ясно написано, что как если концентрация превысит н промиле, то машина не тронется, а вот без сограничителя написано, что может быть если сесть за руль пьяному. Выбор за вами, доверяйте или себе, или искусственному ограничителю
А почему вы утверждаете, что массив-результат не отсортирован? Если считать ключом сортировки индекс элемента в исходном массиве, то очень даже отсортирован.
А если сортировать по встроенному в язык отношению порядка «меньше», то в приведенных вами языках оно не транзитивно, поэтому и исходный массив трудно назвать отсортированным.
А если сортировать по встроенному в язык отношению порядка «меньше», то в приведенных вами языках оно не транзитивно, поэтому и исходный массив трудно назвать отсортированным.
>В этих недоязыках есть и другие проблемы, но я специально выбрал самый вопиющий пример.
Вам нужно было придраться к конкатенации, ну, что может быть вопиющееееее, чем:
Во множестве операций в javascript непосредственно от типа операндов зависит сам результат, хош конвертируй во что нужно, хош соглашайся с происходящим. Или складывай числа, или лепи слова. Или лексикографически сортируй или используй свой алгоритм. Или сравнивай значения, не проверяя типы, или проверяй, сравнивая. Всё для вас… ;)
Вам нужно было придраться к конкатенации, ну, что может быть вопиющееееее, чем:
alert( [(2 + '3'), (2 + 3), (3 + '2')] ); //-> 23,5,32Во множестве операций в javascript непосредственно от типа операндов зависит сам результат, хош конвертируй во что нужно, хош соглашайся с происходящим. Или складывай числа, или лепи слова. Или лексикографически сортируй или используй свой алгоритм. Или сравнивай значения, не проверяя типы, или проверяй, сравнивая. Всё для вас… ;)
Виноват, предыдущее сообщение не вам, а в ответ на это.
В данном случае у вас имеются две операции, которые для разных типов данных делают разные, никак не связанные, действия. Это плохо, слов нет, но в данном случае как бы даже никто и не претендует на то, что это — одна операция. Эти операции даже и называются по разному (для чисел — это операция сложения, для строк — операция конкатенации)!
Так и есть, один оператор, но от типа операндов разный результат, два выхода. Удобно? Мне удобно. Возьмите в руки другой оператор ==. Смотрим на алгоритм и считаем варианты в зависимости от ТИПА операндов. Удобно? Конечно же удобно воспользоваться предложенной конвертацией, если я знаю типы, знаю, как и что будет конвертировано и будет ли вообще, алгоритм всё описывает. Если не знаю, не нужна конвертация, то здравствуй, строгое сравнение. Всё для вас.
нифига не удобно. вот точка в пхп — это удобно — она приводит операнды к строке и конкатенирует, а плюс — приводит к числу и складывает. а вот плюс в яваскрипте — это идиотизм, нужно вручную приводить операнды к строке, чтобы быть уверенным, что на выходе у тебя получится тоже строка и наоборот — приводить к числу, чтобы получить число. и какой толк от такой слабой типизации, если вменяемым программистам приводить типы приходится всё-равно? да, раздолбаи могут на это забивать — дескать они «думают» при програмировании, а недовольные — дураки, не способные запомнить пару десятков простых правил…
Угу. Вот как раз это место в PHP сделано хорошо. А JavaScript и в Java — плохо. Но в Java статическая типизация. Она спасает: если вы что-то перепутали, то программа не запустится и «бомба» уж точно не взорвётся.
В языке со статической типизацией подобный «вольности» допустимы — их отловит компилятор, так что с разъярённым заказчиком вам столкнуться не придётся, а вот как раз в языках с динамической типизацией все подобные «улучшения» боком выходят. Их в Python'е есть и в Lisp'е немного — но до бардака JavaScript/PHP им расти и расти.
В языке со статической типизацией подобный «вольности» допустимы — их отловит компилятор, так что с разъярённым заказчиком вам столкнуться не придётся, а вот как раз в языках с динамической типизацией все подобные «улучшения» боком выходят. Их в Python'е есть и в Lisp'е немного — но до бардака JavaScript/PHP им расти и расти.
> нифига не удобно
локальная привычка
> вот точка в пхп — это удобно
локальная привычка
> плюс в яваскрипте — это идиотизм
локальная привычка/непривычка
И что? Кто не привык к PHP скажет — зачем мне дополнительные операторы для чего-то, если я знаю, как, и в каких ситуациях работает нужный оператор?
Я ж говорю — весь «спор» лишь из-за привычки к статической или, по крайней мере, строгой, типизации. При рассуждениях, автор темы, якобы, оперирует фундаментальными понятиями, не учитывая ни типологию множества, ни особенности альтернативных систем, которые оперируют динамически с этими множествами (при этом все нюансы оговорены).
локальная привычка
> вот точка в пхп — это удобно
локальная привычка
> плюс в яваскрипте — это идиотизм
локальная привычка/непривычка
И что? Кто не привык к PHP скажет — зачем мне дополнительные операторы для чего-то, если я знаю, как, и в каких ситуациях работает нужный оператор?
Я ж говорю — весь «спор» лишь из-за привычки к статической или, по крайней мере, строгой, типизации. При рассуждениях, автор темы, якобы, оперирует фундаментальными понятиями, не учитывая ни типологию множества, ни особенности альтернативных систем, которые оперируют динамически с этими множествами (при этом все нюансы оговорены).
затем, чтобы не писать такую фигню, когда нужна конкатенация, а не абы какое сложение:
function combine( var1, var2 ){
return String( var1 ) + String( var2 );
}
function combine( var1, var2 ){
return String( var1 ) + String( var2 );
}
> абы какое
ну я и говорю — локальная привычка, не более.
ну я и говорю — локальная привычка, не более.
я больше трёх лет программирую исключительно на яваскрипте, пхп и хслт, а си и паскаль забыл как страшный сон. о какой-такой привычке идёт речь? уж не о привычке ли писать надёжные, предсказуемые, отчуждаемые программы? или может быть о привычке трезво смотреть на особенности языка а не тупо молиться на священное писание?
а что не надежного с приведением типа?
> трезво смотреть на особенности языка а не тупо молиться на священное писание?
так ведь я и рассуждаю об особенностях языков; а то, что ты называешь «мольбой на писание» — опять, возможно лишь вытекает из привычек того, что видел в других технологиях и идеологиях. Кто пишет технологию — пишет правила. При этом, как я отмечал раньше, можно в абстрактных рассуждениях отклоняться от этих правил. Но называть это «мольбой на священное писание» — извини, не умно.
> трезво смотреть на особенности языка а не тупо молиться на священное писание?
так ведь я и рассуждаю об особенностях языков; а то, что ты называешь «мольбой на писание» — опять, возможно лишь вытекает из привычек того, что видел в других технологиях и идеологиях. Кто пишет технологию — пишет правила. При этом, как я отмечал раньше, можно в абстрактных рассуждениях отклоняться от этих правил. Но называть это «мольбой на священное писание» — извини, не умно.
> затем, чтобы не писать такую фигню, когда нужна конкатенация, а не абы какое сложение
> String( var1 ) + String( var2 );
Йоу. А было б 10 аргументов, все 10 суём в String? Ну, и конечно же других вариантов слепить строку в js нет… Может действительно стоит трезво посмотреть на особенности (и алгоритмы!!!) языка… ;)
> String( var1 ) + String( var2 );
Йоу. А было б 10 аргументов, все 10 суём в String? Ну, и конечно же других вариантов слепить строку в js нет… Может действительно стоит трезво посмотреть на особенности (и алгоритмы!!!) языка… ;)
главное — что нам приходится вручную приводить к строке. каким способом — не важно.
и что? т.е., я правильно понял, — ты отрицаешь даже строгую динамическую типизацию, не то, что динамическую нестрогую? т.е. ты чувствуешь себя спокойно только при статической типизации, которая в почти всегда автоматом строгая?
нет, я отрицаю нестрогие операторы. когда один и тот же оператор выполняет различные действия в зависимости от типа операндов — это заставляет программиста отказываться от динамической типизации в пользу явного приведения типов.
> главное — что нам приходится вручную приводить к строке.
Ты говоришь о ручном приведении. Оно имеет место быть всегда при строгой типизации (Ruby, Python в некоторых местах, Java, C++ и т.д.)
> это заставляет программиста отказываться от динамической типизации в пользу явного приведения типов
Да никто никого не заставляет. Еще раз — там, где знаешь, что надо привести — приводи вручную (таких случаев будет меньше, если мыслишь и оперируешь объектами, типизация которых не столь важна в конкретных случаях), если не надо — будет приведено автоматом согласно описанию.
А иначе — пожалуйста — бери любой «статический» язык — он будет и быстрее, и «надежней», и для каждой операции, если повезет, свой оператор может даже будет.
Ты говоришь о ручном приведении. Оно имеет место быть всегда при строгой типизации (Ruby, Python в некоторых местах, Java, C++ и т.д.)
> это заставляет программиста отказываться от динамической типизации в пользу явного приведения типов
Да никто никого не заставляет. Еще раз — там, где знаешь, что надо привести — приводи вручную (таких случаев будет меньше, если мыслишь и оперируешь объектами, типизация которых не столь важна в конкретных случаях), если не надо — будет приведено автоматом согласно описанию.
А иначе — пожалуйста — бери любой «статический» язык — он будет и быстрее, и «надежней», и для каждой операции, если повезет, свой оператор может даже будет.
а ты думаешь я с яваскриптом вожусь от хорошей жизни?
надо мыслить стратегически. рано или поздно кому-нибудь придёт в голову передать в твою функцию не тот тип и он будет очень удивлён, получив вместо 11 двойку. спустя несколько часов отладки он выйдёт на твою функцию, где ты поленился привести тип. тогда он либо добавит приведение типа в неё, либо будет вынужден самостоятельно приводить его при каждом вызове твоей функции.
надо мыслить стратегически. рано или поздно кому-нибудь придёт в голову передать в твою функцию не тот тип и он будет очень удивлён, получив вместо 11 двойку. спустя несколько часов отладки он выйдёт на твою функцию, где ты поленился привести тип. тогда он либо добавит приведение типа в неё, либо будет вынужден самостоятельно приводить его при каждом вызове твоей функции.
В js можно на выбор:
— контролировать тип и использовать '+' без страха;
— конвертировать значение левого операнда в строку;
— склеить в строку встроенным методом;
— склеить в строку сквозь массив.
Это всё видимо кажется ужасным и что тогда взамен? Отдельный оператор? Без него хватает возможностей или мож мне дополнительно числа надо в строку вклеить, а конвертировать лень и т.п. Прописывать всем жёстко тип? Оставить динамику, но бросать исключение и перенаправлять в другое место? И там ручной труд, и там ручной труд…
— контролировать тип и использовать '+' без страха;
— конвертировать значение левого операнда в строку;
— склеить в строку встроенным методом;
— склеить в строку сквозь массив.
Это всё видимо кажется ужасным и что тогда взамен? Отдельный оператор? Без него хватает возможностей или мож мне дополнительно числа надо в строку вклеить, а конвертировать лень и т.п. Прописывать всем жёстко тип? Оставить динамику, но бросать исключение и перенаправлять в другое место? И там ручной труд, и там ручной труд…
Никто в комментах даже не упомянул, что массив в PHP вне зависимости от его начинки имеет ключи в виде хешей — отсюда и его «не сортированность», поетому можно удалить элемент и массив в себе ничего не переставит. В отличии от того же С/С++, где при удалении элемента вам нужно сместить весь массив.
Вобщем топик от банального не знания внутренней работы PHP
Вобщем топик от банального не знания внутренней работы PHP
Минусов наставили, а никто даже не возразил. Эх, плохо быть умным, тебя все ненавидят тогда. Читайте internals mailing list, будете знать больше.
Лично я вас за этот комментарий не минусовал и не плюсовал, но попробую объяснить, за что вам поставили минусы. Если вкратце, то это потому что хотя вы и сказали в принципе правильно про то, что массив в PHP это набор пар ключ->значение, но этот факт абсолютно никакого отношения к топику не имеет.
В топике идет дискуссия о том, что неявные преобразования из строки в число могут иметь интересные последствия — те, что описаны автором в статье. При этом в примере массивы используются так, что то, что вы написали не имеет никакого влияния на результат.
Насчет С++ — то в нем есть stl::map для хранения массива в виде пар ключ->значения.
В топике идет дискуссия о том, что неявные преобразования из строки в число могут иметь интересные последствия — те, что описаны автором в статье. При этом в примере массивы используются так, что то, что вы написали не имеет никакого влияния на результат.
Насчет С++ — то в нем есть stl::map для хранения массива в виде пар ключ->значения.
А разве массив при удалении элемента из него должен что-то делать с порядком других элементов? :)
Автор не из-за этого «возмущается», а из-за того, что JS И PHP представляют непрозрачные операции сравнения, алгоритмы которых сделаны так, что не позволяют сортировать последовательности в строгом математическом понимании этого.
Автор не из-за этого «возмущается», а из-за того, что JS И PHP представляют непрозрачные операции сравнения, алгоритмы которых сделаны так, что не позволяют сортировать последовательности в строгом математическом понимании этого.
плохо не разобравшись в вопросе обвинять собеседника в незнании основ.
особенно глупо выглядят те, кто не видит разницы между незнанием основ и их критикой. а также те, кто пытается защитить глупости языка, которому посвятили лучшие годы своей жизни.
особенно глупо выглядят те, кто не видит разницы между незнанием основ и их критикой. а также те, кто пытается защитить глупости языка, которому посвятили лучшие годы своей жизни.
Sannis
Начну с того, что в мануале lv.php.net/manual/ru/function.sort.php написанно, что функция sort() при содержании разнотипных элементов, цитирую:
Это будет справедливо для любой пользвательской сортировке, которая не приводит данные к единому типу. Как сравнить, что больше:
5 < '13'
Привести 5 к строке и сравнивать как строки, или привести 13 к числу и сравнить как числа?
В первом случае 5 будет больше 13, во втором случае больше будет 13. Надеюсь почему объяснять не надо? Отсюда и неоднозначность.
К тому же функция sort имеет второй необязательный аргумент, который указывает как воспринимать элементы массива: не изменять типы, как строки, числа и как строки с учётом локали. Именно для устранения таких непоняток, как описал автор топика. Это что касается сортировки.
Кстати в мануале написанно, что при сравнении строки и числа, строка будет приведена к числу и сравнение будет происходить как с числами.
Что же касается примера кода:
Если вывести массив циклом, то выведет 11, 2, 3. Автор интересовался почему? Потому что автор либо спал на алгоритмах и структурах данных, либо вообще не учился по специальности. Массивы автоматом не сортируются, никогда и ни в каком языке программирования это не реализовано автоматикой. Потому что выводятся они в том порядке, в каком идут их ключи, т.е. в данном примере массив $before имеет такое строение:
При удалении элемента «a» вы функцией push добавляете элемент в конец массива, где ему _автоматом_ присваивается порядковый номер, т.е. у вас вышло
Что тут неправильного — я не понимаю. Если вы скажите преподавателю на экзамене что это неправильно, получите заслуженный незачёт, потому что это азы азов структур данных, тема 2 или 3 лекции. Обход массивов всегда происходит по порядку в котором стоят ключи, а не данные массива. Вы получите точно такой же результат и в С, и в Delphi, и в Java — потому что это основа основ. В вашем случае типы элементов массива обсалютно не важны, т.к. на них вами показанный код даже не смотрит.
А вот если вы хотите получить _сортированный_ массив, то извольте пропустить его через функцию сортировки, указав как вы хотите сравнивать элементы — как числа или как строки (т.е. по ASCII кодам).
Ещё раз автору топика — из основ предмета «Алгоритмы и структуры данных»: отсортированным массивом может называться только однородный упорядоченный массив. Если в вашем массиве есть и строки, и числа, то он не может быть упорядоченным по определению.
Пример:
$a = array('1', '13', '2', '22');
Это упорядоченный массив с точки зрения строк, только вот с точки зрения чисел он нихрена не упорядоченный.
$b = array(1, 2, 13, 22);
Это упорядоченный массив с точки зрения чисел, а вот с точки зрения строк нихрена он не сортированный.
Именно поетому невозможно отсортировать смешанный масив.
Ещё раз повторяю автору — СТРОКИ СРАВНИВАЮТСЯ ПО ASCII КОДАМ СИМВОЛОВ, числа же сравниваются по их значениям, но обе операции чисто математические! Учите булеву алгебру и как считает компъютер.
Кстати автор удивляется писал в комментах что у него что-то не работает в PHP при ID'ках. Я вообще не понимаю что он хотел сделать сортировкой, и какие такие там составные ID. Он всё ругается, а примеров так и не привёл, а значит понимает что он не прав и где-то лоханулся, но не хочет признавать этого.
Пока он не покажет код и не скажет что он от него хочет получить и в чём состоит глюк — моим решением на месте его начальника было бы или отправить его на принудительное обучение за его счёт, или разжаловать на более низкую должность с более низкой зарплатой, либо уволить за проффесиональную некомпетентность. Это же надо додуматься сортировать обычным сравнением больше/меньше строки и числа в одном массиве.
P.S. Питон выдаёт такой результат потому, что он отдельно сравнивает числа и отдельно строки, потом склеивает это таким образом, что первыми идут все числа, потом все строки. Это моё предположение, если бы кто-нить был бы добр отсортировать на питоне массив данный мной ниже и показать нам результат сортировки, то если он в массив первыми добавит все числа, а потом в хвосте все строки, то я буду прав.
Начну с того, что в мануале lv.php.net/manual/ru/function.sort.php написанно, что функция sort() при содержании разнотипных элементов, цитирую:
Будьте осторожны при сортировке массивов, содержащих элементы разных типов, так как в этом случае результат работы функции sort() может быть непредсказуемым.
Это будет справедливо для любой пользвательской сортировке, которая не приводит данные к единому типу. Как сравнить, что больше:
5 < '13'
Привести 5 к строке и сравнивать как строки, или привести 13 к числу и сравнить как числа?
В первом случае 5 будет больше 13, во втором случае больше будет 13. Надеюсь почему объяснять не надо? Отсюда и неоднозначность.
К тому же функция sort имеет второй необязательный аргумент, который указывает как воспринимать элементы массива: не изменять типы, как строки, числа и как строки с учётом локали. Именно для устранения таких непоняток, как описал автор топика. Это что касается сортировки.
Кстати в мануале написанно, что при сравнении строки и числа, строка будет приведена к числу и сравнение будет происходить как с числами.
Что же касается примера кода:
function remove_element(/* array */ $a, /* element */ $e) {
$b=array();
foreach($a as $m) {
if ($m!=$e) array_push($b, $m);
}
return $b;
}
$before=array("11", "a", 2, 3);
$after=remove_element($before, "a");
Если вывести массив циклом, то выведет 11, 2, 3. Автор интересовался почему? Потому что автор либо спал на алгоритмах и структурах данных, либо вообще не учился по специальности. Массивы автоматом не сортируются, никогда и ни в каком языке программирования это не реализовано автоматикой. Потому что выводятся они в том порядке, в каком идут их ключи, т.е. в данном примере массив $before имеет такое строение:
$before = array(0 => "11", 1 => "a", 2 => 2, 3 => 3);
При удалении элемента «a» вы функцией push добавляете элемент в конец массива, где ему _автоматом_ присваивается порядковый номер, т.е. у вас вышло
$after = array(0 => "11", 1 => 2, 2 => 3);
Что тут неправильного — я не понимаю. Если вы скажите преподавателю на экзамене что это неправильно, получите заслуженный незачёт, потому что это азы азов структур данных, тема 2 или 3 лекции. Обход массивов всегда происходит по порядку в котором стоят ключи, а не данные массива. Вы получите точно такой же результат и в С, и в Delphi, и в Java — потому что это основа основ. В вашем случае типы элементов массива обсалютно не важны, т.к. на них вами показанный код даже не смотрит.
А вот если вы хотите получить _сортированный_ массив, то извольте пропустить его через функцию сортировки, указав как вы хотите сравнивать элементы — как числа или как строки (т.е. по ASCII кодам).
Ещё раз автору топика — из основ предмета «Алгоритмы и структуры данных»: отсортированным массивом может называться только однородный упорядоченный массив. Если в вашем массиве есть и строки, и числа, то он не может быть упорядоченным по определению.
Пример:
$a = array('1', '13', '2', '22');
Это упорядоченный массив с точки зрения строк, только вот с точки зрения чисел он нихрена не упорядоченный.
$b = array(1, 2, 13, 22);
Это упорядоченный массив с точки зрения чисел, а вот с точки зрения строк нихрена он не сортированный.
Именно поетому невозможно отсортировать смешанный масив.
Ещё раз повторяю автору — СТРОКИ СРАВНИВАЮТСЯ ПО ASCII КОДАМ СИМВОЛОВ, числа же сравниваются по их значениям, но обе операции чисто математические! Учите булеву алгебру и как считает компъютер.
Кстати автор удивляется писал в комментах что у него что-то не работает в PHP при ID'ках. Я вообще не понимаю что он хотел сделать сортировкой, и какие такие там составные ID. Он всё ругается, а примеров так и не привёл, а значит понимает что он не прав и где-то лоханулся, но не хочет признавать этого.
Пока он не покажет код и не скажет что он от него хочет получить и в чём состоит глюк — моим решением на месте его начальника было бы или отправить его на принудительное обучение за его счёт, или разжаловать на более низкую должность с более низкой зарплатой, либо уволить за проффесиональную некомпетентность. Это же надо додуматься сортировать обычным сравнением больше/меньше строки и числа в одном массиве.
P.S. Питон выдаёт такой результат потому, что он отдельно сравнивает числа и отдельно строки, потом склеивает это таким образом, что первыми идут все числа, потом все строки. Это моё предположение, если бы кто-нить был бы добр отсортировать на питоне массив данный мной ниже и показать нам результат сортировки, то если он в массив первыми добавит все числа, а потом в хвосте все строки, то я буду прав.
a = [1, "5", 30, "25", 100, 4576, "2534", 11234, "10244", 21, 24, 30, "2534", 34434, "234435"]
habrahabr.ru/blogs/programming/48624/#comment_1264141
Вот теперь, в отличии от этого комментария ( habrahabr.ru/blogs/programming/48624/#comment_1261455 ), вы написали по делу и правильно.
Насчет структур данных: автор не утверждает, что массив всегда отсортирован, он говорит, что если массив отсортирован изначально, и из него удалить некоторые елементы, то массив должен остаться отсортированным. Но в его логике ошибка — как вы и сказали, массив с разнородными данными нельзя назвать отсортированным.
Насчет структур данных: автор не утверждает, что массив всегда отсортирован, он говорит, что если массив отсортирован изначально, и из него удалить некоторые елементы, то массив должен остаться отсортированным. Но в его логике ошибка — как вы и сказали, массив с разнородными данными нельзя назвать отсортированным.
тогда почему функция sort не кидает исключение в связи с невозможностью отсортировать разнородный массив?
В связи со слабой типизацией языка. А почему там такая слабая типизация — это у авторов языка надо спросить.
Но такое поведение функции sort() не являеться ошибочным с точки зрения соответствия документации — потому что, как процитировал Psih, в мануале написано, что при сортировке разнотипных данных функия может давать непредсказуемые результаты.
Но такое поведение функции sort() не являеться ошибочным с точки зрения соответствия документации — потому что, как процитировал Psih, в мануале написано, что при сортировке разнотипных данных функия может давать непредсказуемые результаты.
тогда почему неинициированные переменные не содержат мусора как си?
Не совсем понимаю, при чем тут этот вопрос :) Если дать общий ответ — то потому что так спроектированы эти языки, если хотите более конкретный ответ, то уточните вопрос.
в си было так. но при проектировании пхп решили, что это не хорошо и потому отказались от такой неопределённости. так вот, почему мусор в переменных — это плохо, а функция сортировки делающая вид, что сортирует, а на самом деле просто перемешивает — это нормально?
Теперь понял вопрос. Во-первых хочу сказать, що я не являюсь защитником подхода PHP, и сам считаю, что неявные преобразования, и как следствие проблемная sort() — это плохо. В своем посте выше я только хотел сказать, что хотя это и плохо, но это документировано.
А по вашому вопросу. Подходы работы с переменными, который использует Си, и который использует ПХП слишком разные, чтобы их сравнивать: в Си переменная — это условное обозначение какого-то адреса в памяти (при компиляции все названия заменяются на их адреса). В ПХП переменные — это элементы глобального ассоциативного массива переменных. Соответственно неинициализированная переменная в ПХП означает отсутствия элемента в этом глобальном массиве, а объявленная, но неинициализированая переменная в Си — это просто адрес в памяти, где может быть что угодно.
А по вашому вопросу. Подходы работы с переменными, который использует Си, и который использует ПХП слишком разные, чтобы их сравнивать: в Си переменная — это условное обозначение какого-то адреса в памяти (при компиляции все названия заменяются на их адреса). В ПХП переменные — это элементы глобального ассоциативного массива переменных. Соответственно неинициализированная переменная в ПХП означает отсутствия элемента в этом глобальном массиве, а объявленная, но неинициализированая переменная в Си — это просто адрес в памяти, где может быть что угодно.
Потому что интерпритатор инициализирует переменные со значением по умолчанию. Потому что на уровне реализации переменная в PHP — это zval структура в C, которая инициализируется при создании переменной.
тогда почему zval не инициализируется мусором?
Потому что вы безмозглый упрямец, который не хочет думать сам. Чем слово «инициализация» не указывает на то, что в ZVAL записывается интерпритатором PHP данные, которые ему необходимы? Когда создаётся переменная, в ZVAL записываются стартовые данные, как тип переменной, кол-во ссылок и прочая информация, вместе с тем и её изначальное значение null!
Вы уж извините, но научитесь делать выводы сами, а не ждать пока вам разжуют положат в рот.
Потому что по правилам языка PHP сравнение происходит как с числами, если встречается целое и строка. Это основа основ PHP — от чтения документации Вас никто не освобождал, а вы её не читали. Вы Linux тоже будете хаять, что авторы мудаки, не включили все драйвера по умолчанию в ядро?
Поинтересуйтесь как это сделано в Perl и Python — что будет если там сравнить число и строку.
Поинтересуйтесь как это сделано в Perl и Python — что будет если там сравнить число и строку.
так и есть
Ну и правильно, в топку слабую типизацию.
khim, приведите, пожалуйста, пример, когда при удалении элемента порядок элементов нарушается в массиве, изначально отсортированном по правилам сравнения js.
И ещё, не могли бы Вы привести пример реальной поломки и её результатов из-за особенностей сортировки js, а не абстрактное «взрыв» или «ляжет»?
И ещё, не могли бы Вы привести пример реальной поломки и её результатов из-за особенностей сортировки js, а не абстрактное «взрыв» или «ляжет»?
Автору топика: я, как отмечал, был в отъезде (приехал только сегодня). Вы хотели сделать опрос на основе моей фразы о разных типах множеств с разными операциями (но, ввиду динамической нестрогой (слабой) типизации конкретных технологий — приводимости типов и операций согласно описанным алгоритмам). Немалое количество людей придерживается точки зрения, которая Вам не нравится. При этом, я яро (и в отличии от Вас) не восхваляю одну типизацию и (ее последствия) относительно другой (и ее возможных ограничений) — я рассуждаю о технологиях. Вы же, как я снова отмечал пытаетесь (именно пытаетесь — переходя на личности, демагогируя и прочее) рассуждать о фундаментальности (и то — лишь на основе своих привычек/непривычек), совершенно не учитывая локальную теорию технологии (которая вправе вводить свои сущности и, технологически обосновывая, видоизменять привычные Вам «символы» из других технологий) и приводите высосанные из пальца практические примеры, называя «удалением» из «отсортированного» массива элемент (не показывайте больше никому такие примеры при таких названиях).
Что я понял из дискуссии с Вами — то, что Вы за статическую (или, по крайней мере, динамическую строгую) типизацию, а динамическая нестрогая (слабая) Вас пугает, поскольку вводит новый функционал (видоизменяет ввиду неоднозначной типологии множества) привычных Вам «символов».
Говорить, кто здесь прав, кто нет — нельзя, любая реализация может двигать еще дальше этого, полностью разрушая Ваши привычки. При этом, любые реализации будут верными в своих идеологических мыслях.
А все Ваши кидания «дерьмо» везде и всюду, что кажется непривычным — ничего не решат.
Что я понял из дискуссии с Вами — то, что Вы за статическую (или, по крайней мере, динамическую строгую) типизацию, а динамическая нестрогая (слабая) Вас пугает, поскольку вводит новый функционал (видоизменяет ввиду неоднозначной типологии множества) привычных Вам «символов».
Говорить, кто здесь прав, кто нет — нельзя, любая реализация может двигать еще дальше этого, полностью разрушая Ваши привычки. При этом, любые реализации будут верными в своих идеологических мыслях.
А все Ваши кидания «дерьмо» везде и всюду, что кажется непривычным — ничего не решат.
alert(
[7, «13», «5», 6].sort()
)
[7, «13», «5», 6].sort()
)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К вопросу о языках программирования…