Ну да. "Лучше меньше, да лучше". Что-то полезное раз в полгода всяко лучше, чем "покрасили стены" и прочие новости, интересные только хозяину заведения, каждые три дня. В вашем примере новости спортзала, которые могут понадобиться – изменение графика работы, появление сауны или нового типа тренажёров (или, наоборот, что что-то вывели из обращения). Не более того. И то, если таких новостей станет слишком много – они станут бесполезны.
Если речь идёт о камере с ПЗС-матрицей и затвором – вроде всё как раз довольно близко к поведению плёночной камеры, порядок снятия данных с матрицы не столь важен.
У нас в офисе чуть иначе: душевая, в ней гидрозатвор есть – но здание 40-этажное, и проектировщики прошляпили проблему с перепадом давления. В результате при ветре есть неиллюзорный шанс опустошения сифона (его просто высасывает в канализацию) с последующей вонью.
Вы таки будете смеяться, но я с этим столкнулся год назад, переехав в Белград. На съёмной квартире хозяин сразу предупредил – мол, закрывай пробку в мойке на кухне, а то пахнет, это тут обычная проблема. Заглядываю под мойку... Ну вы поняли. У него на глазах делаю эрзац-сифон из гофры, проблема решена.
Не уверен, что с O(1) по памяти можно уложиться в O(n²): ведь у нас тогда нет дополнительной памяти для выходных данных, их придётся выплёвывать в условный stdout по очереди. Значит, придётся делать устранение дубликатов. Даже интересно, какая на самом деле сложность получится. Решение с O(n³) видится с ходу (идём по первому списку, проверяем очередной элемент из него, если он нам подходит – заново проверяем все, что были до него, и если ни один из них не подходит – выдаём в stdout), но, может, можно улучшить?
xkcd#927. Да, это тоже (хотя в стандартах бывают дыры – вспомните историю 20-летней давности про файл, который невозможно прочитать с компакт-диска), но я даже не про стандарты, а про общий подход.
Вот как так-то? Казалось бы, дай отпечатку индивидуальный приватный ключ (который нельзя вытаскивать из чипа) и строй защиту на этом, но умудряются всадить какие-то нелепые ошибки.
Ну, desqview емнип с расширенной памятью дел не имел, а между процессами, живущими в первом мегабайте (первый 640 + high memory addresses), память как-то делил, приходилось выбирать софт, которому много основной памяти не надо. Я его ещё на 286 вроде использовал.
Ну да. "Лучше меньше, да лучше". Что-то полезное раз в полгода всяко лучше, чем "покрасили стены" и прочие новости, интересные только хозяину заведения, каждые три дня.
В вашем примере новости спортзала, которые могут понадобиться – изменение графика работы, появление сауны или нового типа тренажёров (или, наоборот, что что-то вывели из обращения). Не более того. И то, если таких новостей станет слишком много – они станут бесполезны.
Если речь идёт о камере с ПЗС-матрицей и затвором – вроде всё как раз довольно близко к поведению плёночной камеры, порядок снятия данных с матрицы не столь важен.
А может, просто писать в новостях что-то полезное? (ощутил себя чуваком из Boardroom suggestion meme)
Свет с Венеры отразился от верхних слоёв атмосферы и вызвал взрыв болотного газа.Вообще-то оно меняет местами перед и зад. Выводы делайте сами.
Всё указано: "взамен кантон получит зелёный тариф".
Да, это совсем жесть.
У нас в офисе чуть иначе: душевая, в ней гидрозатвор есть – но здание 40-этажное, и проектировщики прошляпили проблему с перепадом давления. В результате при ветре есть неиллюзорный шанс опустошения сифона (его просто высасывает в канализацию) с последующей вонью.
Итог – трубы забили нафиг, пользоваться душем нельзя, сушу там зонтик :-)
Теоретически берём обычный merge sort на 2 потока – и он вроде укладывается в это описание :-)
Так что нужно читать подробнее, не одним O(n)...
Вы таки будете смеяться, но я с этим столкнулся год назад, переехав в Белград. На съёмной квартире хозяин сразу предупредил – мол, закрывай пробку в мойке на кухне, а то пахнет, это тут обычная проблема. Заглядываю под мойку... Ну вы поняли. У него на глазах делаю эрзац-сифон из гофры, проблема решена.
Так оно O(n) по памяти (нужно место под отсортированный массив).
Да, действительно. И это, очевидно, предел.
Спасибо!
Не уверен, что с O(1) по памяти можно уложиться в O(n²): ведь у нас тогда нет дополнительной памяти для выходных данных, их придётся выплёвывать в условный stdout по очереди. Значит, придётся делать устранение дубликатов.
Даже интересно, какая на самом деле сложность получится. Решение с O(n³) видится с ходу (идём по первому списку, проверяем очередной элемент из него, если он нам подходит – заново проверяем все, что были до него, и если ни один из них не подходит – выдаём в stdout), но, может, можно улучшить?
В сложность по времени.
По памяти – всегда считают дополнительную память, приплюсовать к ней исходные данные недолго.
Какой своп? Мы раз за разом перечитываем исходные данные, они не включаются в оценку расхода памяти.
ЗЫ: но в O(n²) по времени, вроде, так просто не уложиться, надо же ещё дубликаты убирать...
xkcd#927. Да, это тоже (хотя в стандартах бывают дыры – вспомните историю 20-летней давности про файл, который невозможно прочитать с компакт-диска), но я даже не про стандарты, а про общий подход.
Вообще обычно это называется fixed point (формат с фиксированной точкой). Или вы что-то другое сделали?
Я думал, что их применяют там, где устойчивость заведомо есть.
Вот как так-то? Казалось бы, дай отпечатку индивидуальный приватный ключ (который нельзя вытаскивать из чипа) и строй защиту на этом, но умудряются всадить какие-то нелепые ошибки.
Ну, desqview емнип с расширенной памятью дел не имел, а между процессами, живущими в первом мегабайте (первый 640 + high memory addresses), память как-то делил, приходилось выбирать софт, которому много основной памяти не надо. Я его ещё на 286 вроде использовал.
Справедливости ради, вытесняющая многозадачность тогда была – DESQview. Сам пользовался, убирая мейлер в фон.