Конечно, здесь идет речь именно об этом понятии. Забавно, но мы в своих комментариях оба дописываем текст за автора, добавляя пояснение, почему употребление термина «tragedy of the commons» уместно — как обнаруживается это явление в ситуации, описываемой в статье.
Что касается перевода, то я воспринимаю «трагедию общин» как исторический, пусть не совсем точный, термин, описывающий понятие из теории игр. В википедии, кстати, используются оба варианта, просто «трагедия общих ресурсов» выбрана в качестве основного.
Есть еще забавный пассаж насчет того, что веб находится в собственном классе (и в оригинале так же). Узнаю брата математика! На этот раз термин употреблен более-менее корректно, хотя читатель ничего не потеряет, если не распознает отсылку.
Нет, эта ошибка есть и в оригинале. Просто автор употребил всуе занятый термин. Я тоже прицепился к этому месту, ожидая в этом разделе разъяснение того, как именно возникает феномен трагедии общин. Например так: в основном «пипл хавает», так что каждому производителю в отдельности экономически невыгодно улучшать качество, а та часть пользователей, которая «не хавает», не может существенно повлиять на рынок; в результате возникает петля положительной обратной связи, из-за которой всем становится хуже.
В тексте несколько раз встречается такое понятие — вертикальное видео. Возможно, я отстал от жизни, но для меня это означает всего лишь формат кадра, который, надо полагать, несколько удобней к съемке и просмотру на телефоне по сравнению с горизонтальным фото/видео. Здесь же, судя по эмоциональной нагрузке, имеется в виду что-то другое. Что именно имел в виду автор?
GitHub (в отличие от Notion) уже не в состоянии лишить меня моих заметок.
Теоретически может, но для этого надо в этом злодействе ему помочь.
Во-первых, завести привычку делать иногда git push -f. Это не такой уж грех, когда пользуешься репозиторием единолично. Польза от переписывания истории состоит в том, что дерево можно спрямить, сделать линейнее, посклеивать мелкие малоосмысленные комиты и переписать комментарии. В общем, сделать красивее.
Соответственно, придется делать git rebase на других копиях. Это тоже войдет в привычку.
Изредка делать git gc. Для обычных репозиториев сборку мусора нужно делать примерно никогда, но если понадобилось хранить огромные массивы данных, заводить множество временных веток, да еще часто перезатирать репозиторий, то придется бороться с переполнением диска.
Теперь осталось, чтобы GitHub в удачное время совершил свое черное дело и перезаписал репозиторий мусором. Тогда git pull скажет ой, но пользователь вспомнит, что недавно на другом устройстве он делал git push -f и привычным жестом сделает rebase. Ну и на всякий случай решит сделать сборку мусора. И так повторит на всех своих устройствах. В общем, в том анекдоте — споткнулся, упал на ножик, и так 15 раз.
Действительно, равномерность нужно доказывать (а люди часто забывают об этом), и это не всегда тривиально. Я сначала хотел сказать, что здесь доказательство очевидно, но потом задумался. И уже засомневался, что это правильный алгоритм. ;)
> выпадение 0 и 0,5 по первой координате равновероятно Это некорректное рассуждение — нельзя говорить о вероятности выпадения отдельных точек, поскольку распределение непрерывное, а не дискретное. Можно рассуждать о вероятности попадании в интервал.
Вроде бы легко исправить генерацию, чтобы она стала более эффективной. Для этого нужно выбирать очередную координату не из [-1,1], а из [-r, r], где r вычисляется по предыдущим координатам. Там, правда, получается O(n) вычислений квадратного корня, но при больших размерностях это должно быть выгоднее, чем отсекать львиную долю точек в наивном алгоритме.
Замечание по переводу. Лучше выглядит (да и как-то стандартей, если поискать похожие примеры) "грепабельность" без удвоения согласной. По-английски, ясен пень, удвоение нужно, чтобы сохранить закрытость слога.
Да, а чтоб рокировку сделать, нужно было ввести довольно длинную последовательность: ВИ, ход ладьи, ВВ, ход короля. Удивительно, что современный способ выразить рокировку — просто ход королем на две клетки — был реализован в компьютерах сравнительно поздно. Еще у этой машины был забавный баг — она позволяла делать рокировку ферзя с ладьей.
Причём далеко не бинарному, то есть степень логарифма не 2, а исчисляется десятками, а то и сотнями.
Так наоборот же — чем больше основание логарифма, тем лучше, быстрее получается. Собственно, основная фишка этих B-tree состоит в том, чтобы сделать деревья пошире и уменьшить глубину.
А вот такая задача: реализовать функцию inc_argmin(i, v), которая увеличивает i-й элемент на v и возвращает индекс минимального элемента. Можно считать, что изначально массив устроен тривиально, например, заполнен одинаковым значением.
Мой хит — это выпадающее меню на полторы сотни элементов с выбором страны. Особенно на вебе, когда известно, что у пользователя с большой вероятностью десктоп, и, соответственно, имеется механическая клавиатура. Думаю, в основном сей травматический опыт заставил меня написать комментарий к этой статье, хотя ничего ужасного в решении, которое описывает автор, я не вижу. Всё-таки это мобильное приложение — как ни крути, нужно тыкать пальцами в экран, а не жать механические кнопки, при этом функциональность календаря довольно сложна, я не могу сходу предложить простое клавиатурное решение, которое было бы очевидно лучше. К примеру, формат crontab-a функционально беднее этого календаря, и без мануала в нем сходу не разобраться.
TOTP прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
мы не можем разрабатывать интерфейс под определенных пользователей
Надеюсь, что ты найдешь свой календарь
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.
На печатную плату похоже.
Конечно, здесь идет речь именно об этом понятии. Забавно, но мы в своих комментариях оба дописываем текст за автора, добавляя пояснение, почему употребление термина «tragedy of the commons» уместно — как обнаруживается это явление в ситуации, описываемой в статье.
Что касается перевода, то я воспринимаю «трагедию общин» как исторический, пусть не совсем точный, термин, описывающий понятие из теории игр. В википедии, кстати, используются оба варианта, просто «трагедия общих ресурсов» выбрана в качестве основного.
Есть еще забавный пассаж насчет того, что веб находится в собственном классе (и в оригинале так же). Узнаю брата математика! На этот раз термин употреблен более-менее корректно, хотя читатель ничего не потеряет, если не распознает отсылку.
Нет, эта ошибка есть и в оригинале. Просто автор употребил всуе занятый термин. Я тоже прицепился к этому месту, ожидая в этом разделе разъяснение того, как именно возникает феномен трагедии общин. Например так: в основном «пипл хавает», так что каждому производителю в отдельности экономически невыгодно улучшать качество, а та часть пользователей, которая «не хавает», не может существенно повлиять на рынок; в результате возникает петля положительной обратной связи, из-за которой всем становится хуже.
В тексте несколько раз встречается такое понятие — вертикальное видео. Возможно, я отстал от жизни, но для меня это означает всего лишь формат кадра, который, надо полагать, несколько удобней к съемке и просмотру на телефоне по сравнению с горизонтальным фото/видео. Здесь же, судя по эмоциональной нагрузке, имеется в виду что-то другое. Что именно имел в виду автор?
6 эвристика подвела — в том предложении должно быть «что бы».
Теоретически может, но для этого надо в этом злодействе ему помочь.
Во-первых, завести привычку делать иногда git push -f. Это не такой уж грех, когда пользуешься репозиторием единолично. Польза от переписывания истории состоит в том, что дерево можно спрямить, сделать линейнее, посклеивать мелкие малоосмысленные комиты и переписать комментарии. В общем, сделать красивее.
Соответственно, придется делать git rebase на других копиях. Это тоже войдет в привычку.
Изредка делать git gc. Для обычных репозиториев сборку мусора нужно делать примерно никогда, но если понадобилось хранить огромные массивы данных, заводить множество временных веток, да еще часто перезатирать репозиторий, то придется бороться с переполнением диска.
Теперь осталось, чтобы GitHub в удачное время совершил свое черное дело и перезаписал репозиторий мусором. Тогда git pull скажет ой, но пользователь вспомнит, что недавно на другом устройстве он делал git push -f и привычным жестом сделает rebase. Ну и на всякий случай решит сделать сборку мусора. И так повторит на всех своих устройствах. В общем, в том анекдоте — споткнулся, упал на ножик, и так 15 раз.
Действительно, равномерность нужно доказывать (а люди часто забывают об этом), и это не всегда тривиально. Я сначала хотел сказать, что здесь доказательство очевидно, но потом задумался. И уже засомневался, что это правильный алгоритм. ;)
> выпадение 0 и 0,5 по первой координате равновероятно
Это некорректное рассуждение — нельзя говорить о вероятности выпадения отдельных точек, поскольку распределение непрерывное, а не дискретное. Можно рассуждать о вероятности попадании в интервал.
Вроде бы легко исправить генерацию, чтобы она стала более эффективной. Для этого нужно выбирать очередную координату не из [-1,1], а из [-r, r], где r вычисляется по предыдущим координатам. Там, правда, получается O(n) вычислений квадратного корня, но при больших размерностях это должно быть выгоднее, чем отсекать львиную долю точек в наивном алгоритме.
Замечание по переводу. Лучше выглядит (да и как-то стандартей, если поискать похожие примеры) "грепабельность" без удвоения согласной. По-английски, ясен пень, удвоение нужно, чтобы сохранить закрытость слога.
Да, а чтоб рокировку сделать, нужно было ввести довольно длинную последовательность: ВИ, ход ладьи, ВВ, ход короля. Удивительно, что современный способ выразить рокировку — просто ход королем на две клетки — был реализован в компьютерах сравнительно поздно.
Еще у этой машины был забавный баг — она позволяла делать рокировку ферзя с ладьей.
В большинстве примеров содержится логическая ошибка — выдается ответ YES, когда начальное и конечное поле совпадают.
Здесь неправильно — не «на четверть меньше», а «составляет четверть», то есть в четыре раза меньше.
Так наоборот же — чем больше основание логарифма, тем лучше, быстрее получается. Собственно, основная фишка этих B-tree состоит в том, чтобы сделать деревья пошире и уменьшить глубину.
Ага, спасибо. Похоже на «научное закрытие», что тоже полезно.
А вот такая задача: реализовать функцию inc_argmin(i, v), которая увеличивает i-й элемент на v и возвращает индекс минимального элемента. Можно считать, что изначально массив устроен тривиально, например, заполнен одинаковым значением.
Есть ли решение со сложностью O(1)?
Рекомендую проставить ударение. ;)
Мой хит — это выпадающее меню на полторы сотни элементов с выбором страны. Особенно на вебе, когда известно, что у пользователя с большой вероятностью десктоп, и, соответственно, имеется механическая клавиатура. Думаю, в основном сей травматический опыт заставил меня написать комментарий к этой статье, хотя ничего ужасного в решении, которое описывает автор, я не вижу. Всё-таки это мобильное приложение — как ни крути, нужно тыкать пальцами в экран, а не жать механические кнопки, при этом функциональность календаря довольно сложна, я не могу сходу предложить простое клавиатурное решение, которое было бы очевидно лучше. К примеру, формат crontab-a функционально беднее этого календаря, и без мануала в нем сходу не разобраться.
TOTP прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.