В тексте несколько раз встречается такое понятие — вертикальное видео. Возможно, я отстал от жизни, но для меня это означает всего лишь формат кадра, который, надо полагать, несколько удобней к съемке и просмотру на телефоне по сравнению с горизонтальным фото/видео. Здесь же, судя по эмоциональной нагрузке, имеется в виду что-то другое. Что именно имел в виду автор?
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 прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
мы не можем разрабатывать интерфейс под определенных пользователей
Надеюсь, что ты найдешь свой календарь
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.
За безальтернативные барабаны, селекторы и прочие аналоговые штуки должен быть отдельный котел для дизайнеров. Я хочу просто вводить цифры и другие стандартные символы со стандартной клавиатуры стандартным образом. Для добавления каждого специфичного элемента ввода должна быть веская, хорошо обоснованная причина. В данном случае приложение довольно сложное, под часть элементов можно подвести обоснования. Но вот простые, типа будильника со стрелками в адроиде, — это сущее издевательство.
Эти два варианта записи соответствуют разным выражениям: 6*(4+5) и (4+5)*6, которые "чисто случайно" вычисляются до одинаковых значений за счет коммутативности операции. Чтобы лучше это прочувствовать, можно взять вместо умножения какую-нибудь некоммутативную операцию, например, деление.
(2) Там, где оценивается точность аппроксимации многочленом, было бы логично поделить интеграл на длину интервала. Тогда получится более осмысленная величина -- среднее на отрезке значение ошибки. А еще обычно в качестве метрики берут максимум, а не среднее.
В тексте несколько раз встречается такое понятие — вертикальное видео. Возможно, я отстал от жизни, но для меня это означает всего лишь формат кадра, который, надо полагать, несколько удобней к съемке и просмотру на телефоне по сравнению с горизонтальным фото/видео. Здесь же, судя по эмоциональной нагрузке, имеется в виду что-то другое. Что именно имел в виду автор?
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 прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.
За безальтернативные барабаны, селекторы и прочие аналоговые штуки должен быть отдельный котел для дизайнеров. Я хочу просто вводить цифры и другие стандартные символы со стандартной клавиатуры стандартным образом. Для добавления каждого специфичного элемента ввода должна быть веская, хорошо обоснованная причина. В данном случае приложение довольно сложное, под часть элементов можно подвести обоснования. Но вот простые, типа будильника со стрелками в адроиде, — это сущее издевательство.
Немного позанудствую.
(1)
Эти два варианта записи соответствуют разным выражениям: 6*(4+5) и (4+5)*6, которые "чисто случайно" вычисляются до одинаковых значений за счет коммутативности операции. Чтобы лучше это прочувствовать, можно взять вместо умножения какую-нибудь некоммутативную операцию, например, деление.
(2) Там, где оценивается точность аппроксимации многочленом, было бы логично поделить интеграл на длину интервала. Тогда получится более осмысленная величина -- среднее на отрезке значение ошибки. А еще обычно в качестве метрики берут максимум, а не среднее.
Была операция, циклически переставляющая четыре верхних элемента стека. Но всё же некорректно говорить, что там была именно FIFO.
Еще аккуратнее будет 's/моего/своего/'.