Причём далеко не бинарному, то есть степень логарифма не 2, а исчисляется десятками, а то и сотнями.
Так наоборот же — чем больше основание логарифма, тем лучше, быстрее получается. Собственно, основная фишка этих B-tree состоит в том, чтобы сделать деревья пошире и уменьшить глубину.
А вот такая задача: реализовать функцию inc_argmin(i, v), которая увеличивает i-й элемент на v и возвращает индекс минимального элемента. Можно считать, что изначально массив устроен тривиально, например, заполнен одинаковым значением.
Мой хит — это выпадающее меню на полторы сотни элементов с выбором страны. Особенно на вебе, когда известно, что у пользователя с большой вероятностью десктоп, и, соответственно, имеется механическая клавиатура. Думаю, в основном сей травматический опыт заставил меня написать комментарий к этой статье, хотя ничего ужасного в решении, которое описывает автор, я не вижу. Всё-таки это мобильное приложение — как ни крути, нужно тыкать пальцами в экран, а не жать механические кнопки, при этом функциональность календаря довольно сложна, я не могу сходу предложить простое клавиатурное решение, которое было бы очевидно лучше. К примеру, формат crontab-a функционально беднее этого календаря, и без мануала в нем сходу не разобраться.
TOTP прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
мы не можем разрабатывать интерфейс под определенных пользователей
Надеюсь, что ты найдешь свой календарь
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.
За безальтернативные барабаны, селекторы и прочие аналоговые штуки должен быть отдельный котел для дизайнеров. Я хочу просто вводить цифры и другие стандартные символы со стандартной клавиатуры стандартным образом. Для добавления каждого специфичного элемента ввода должна быть веская, хорошо обоснованная причина. В данном случае приложение довольно сложное, под часть элементов можно подвести обоснования. Но вот простые, типа будильника со стрелками в адроиде, — это сущее издевательство.
Эти два варианта записи соответствуют разным выражениям: 6*(4+5) и (4+5)*6, которые "чисто случайно" вычисляются до одинаковых значений за счет коммутативности операции. Чтобы лучше это прочувствовать, можно взять вместо умножения какую-нибудь некоммутативную операцию, например, деление.
(2) Там, где оценивается точность аппроксимации многочленом, было бы логично поделить интеграл на длину интервала. Тогда получится более осмысленная величина -- среднее на отрезке значение ошибки. А еще обычно в качестве метрики берут максимум, а не среднее.
Эта подпись к рисунку — некорректный перевод «equally distributed». Здесь подразумевается, что величины справа и слева от этого хитрого знака равенства распределены одинаково.
Вот так выучишься правильно произносить, потом попадаешь в другую языковую среду, а там бывает вплоть до полного непонимания. Вот краткий чешский словарик:
wifi -- вифи, C -- це, home office -- гом-офис (буква h читается как украинское г)
Было медицинское исследование, где людям предлагалась операция, но первой группе говорили, что вероятность её успеха 90%, а второй группе сообщили, что вероятность летального исхода 10%.
Это не очень хороший пример. Здесь сообщается объективно разная информация, поскольку кроме «успеха» и «летального исхода» бывают другие варианты, например, послеоперационные осложнения.
«Шанс выжить в 50%» или «Риск умерить в 50%» люди воспринимают по-разному.
Даже в этом примере требуются какие-то дополнительные знания о мире и умственные усилия, чтобы осознать, что кроме «выжить» и «умереть» других вариантов нет. И то, это будет верное утверждение в классической логике, но, например, не в интуиционистской.
Авторам статей напоминаю, что в редакторе Хабра поддерживается нормальный LaTeX. Вставлять заранее отрендеренные картинки некрасиво — они масштабируются произвольным образом, так что короткие формулы кажутся набранными гигантским шрифтом. Давайте не будем уподобляться medium.com, там математические статьи выглядят реально по-уродски. (Мне доводилось там не только читать, но и писать, это больно.)
Здесь неправильно — не «на четверть меньше», а «составляет четверть», то есть в четыре раза меньше.
Так наоборот же — чем больше основание логарифма, тем лучше, быстрее получается. Собственно, основная фишка этих B-tree состоит в том, чтобы сделать деревья пошире и уменьшить глубину.
Ага, спасибо. Похоже на «научное закрытие», что тоже полезно.
А вот такая задача: реализовать функцию inc_argmin(i, v), которая увеличивает i-й элемент на v и возвращает индекс минимального элемента. Можно считать, что изначально массив устроен тривиально, например, заполнен одинаковым значением.
Есть ли решение со сложностью O(1)?
Рекомендую проставить ударение. ;)
Мой хит — это выпадающее меню на полторы сотни элементов с выбором страны. Особенно на вебе, когда известно, что у пользователя с большой вероятностью десктоп, и, соответственно, имеется механическая клавиатура. Думаю, в основном сей травматический опыт заставил меня написать комментарий к этой статье, хотя ничего ужасного в решении, которое описывает автор, я не вижу. Всё-таки это мобильное приложение — как ни крути, нужно тыкать пальцами в экран, а не жать механические кнопки, при этом функциональность календаря довольно сложна, я не могу сходу предложить простое клавиатурное решение, которое было бы очевидно лучше. К примеру, формат crontab-a функционально беднее этого календаря, и без мануала в нем сходу не разобраться.
TOTP прекрасно бэкапится в отдельный файл. Конечно, есть неудобство в том, что это нужно не забывать делать, причем вручную и отдельно от всего остального.
Это так не работает. Нормально делать пункт в настройках, чтобы пользователь сам мог выбрать вариант интерфейса. Так и приложение развивать удобней — кроме экспериментального интерфейса поддерживать консервативный, а в качестве бонуса можно собирать статистику предпочтений пользователей.
За безальтернативные барабаны, селекторы и прочие аналоговые штуки должен быть отдельный котел для дизайнеров. Я хочу просто вводить цифры и другие стандартные символы со стандартной клавиатуры стандартным образом. Для добавления каждого специфичного элемента ввода должна быть веская, хорошо обоснованная причина. В данном случае приложение довольно сложное, под часть элементов можно подвести обоснования. Но вот простые, типа будильника со стрелками в адроиде, — это сущее издевательство.
Немного позанудствую.
(1)
Эти два варианта записи соответствуют разным выражениям: 6*(4+5) и (4+5)*6, которые "чисто случайно" вычисляются до одинаковых значений за счет коммутативности операции. Чтобы лучше это прочувствовать, можно взять вместо умножения какую-нибудь некоммутативную операцию, например, деление.
(2) Там, где оценивается точность аппроксимации многочленом, было бы логично поделить интеграл на длину интервала. Тогда получится более осмысленная величина -- среднее на отрезке значение ошибки. А еще обычно в качестве метрики берут максимум, а не среднее.
Была операция, циклически переставляющая четыре верхних элемента стека. Но всё же некорректно говорить, что там была именно FIFO.
Еще аккуратнее будет 's/моего/своего/'.
Эта подпись к рисунку — некорректный перевод «equally distributed». Здесь подразумевается, что величины справа и слева от этого хитрого знака равенства распределены одинаково.
Вот так выучишься правильно произносить, потом попадаешь в другую языковую среду, а там бывает вплоть до полного непонимания. Вот краткий чешский словарик:
wifi -- вифи, C -- це, home office -- гом-офис (буква h читается как украинское г)
Это не очень хороший пример. Здесь сообщается объективно разная информация, поскольку кроме «успеха» и «летального исхода» бывают другие варианты, например, послеоперационные осложнения.
Даже в этом примере требуются какие-то дополнительные знания о мире и умственные усилия, чтобы осознать, что кроме «выжить» и «умереть» других вариантов нет. И то, это будет верное утверждение в классической логике, но, например, не в интуиционистской.
И в старом было, всегда его использовал. Сломали разве?
Да, у меня тоже опечатка. ;)
Авторам статей напоминаю, что в редакторе Хабра поддерживается нормальный LaTeX. Вставлять заранее отрендеренные картинки некрасиво — они масштабируются произвольным образом, так что короткие формулы кажутся набранными гигантским шрифтом. Давайте не будем уподобляться medium.com, там математические статьи выглядят реально по-уродски. (Мне доводилось там не только читать, но и писать, это больно.)
В исходном уравнении, по-видимому, опечатка: третий с конца моном 95634x на самом деле должен быть кубическим.
Можно по-разному прочитать фразу, но ни одна из версий фактологически не подходит.