он не может похвастаться опросом 400 человек по коленям (а я могу)
Это неплохо. Хотелось бы видеть ваши выводы из опроса, а не 4 коммента подряд про бег босиком. Мои же выводы - в беге есть некоторый риск для суставов, которого ~половина бегунов из хабровчан избежать не может. То ли бегать не умеют, то ли опасное это дело.
Его нет у большинства на Хабре (у меня точно нет, да и у вас ведь нет?), но вы ведь поднимаете эту тему здесь.
Кстати, по опросу в статье, у бегавших колени болели в 53% случаев, а у не бегавших - в 42%. Допустим, что эти данные достоверны и статистически значимы. Тогда можно сделать вывод о некоторой вредности применяемых хабровчанами методов при беге. Пири же утверждает, что его методы позволяли избежать больных коленей. Так что, если ему верить, то методы Пири более эффективны в плане избегания травм, чем методы бегающих хабровчан.
Поэтому я считаю, что советы Пири более полезны, чем советы большинства людей здесь.
P.S.: бегать босиком он не призывал, как раз из-за всякой опасной грязи, но обращал внимание, что некоторые бегуны из Африки, даже много лет тренируясь без обуви или в чём попало (и где попало), добиваются высоких результатов и не получают больных суставов. Он делал вывод, что искусственная амортизация за счёт обуви не необходима, а больше важна естественная за счёт техники бега. Статья же этот момент упускает.
Я привёл мнение из книги легкоатлета Гордона Пири "Бегай быстро и без травм", и привёл потому, что те моменты, которые он считал важными, упущены в статье. Думаю, он неплохо понимал в беге и в обуви для бега.
а как громко в будете кричать когда наступите на маленькое стеклышко
Не преувеличивайте. Было бы странно бегать босиком в местах, где раскиданы стёкла, гвозди, противопехотные мины, камни и т.п., а тем более, бегать, не глядя на дорогу. Даже от гвоздей обувь уже не защищает.
Может, и модно, но безопасно как раз с носка на пятку - так нагрузка на суставы минимальна (распределяется лучше). Есть мнение, что важна именно техника, а обувь - чем легче, тем лучше, даже босиком можно бежать без ударов.
LSM по скорости поиска чуть менее эффективно, чем B дерево (всё-таки, сегменты перебираются линейно, да и в кэш процессора не влезают). У него другие плюсы, типа асинхронной балансировки без прерывания операций поиска и записи, и очень быстрой записи. Если интересно, можете посмотреть на реализацию f2fs - там lsm деревья используются, если верить вики.
В общем, в описании LSM я не нашел самого главного - как делается поиск.
Поиск посегментно, начиная с "журнала", а затем с последнего записанного сегмента к первому, пока данные по ключу не найдутся. Внутри сегмента данные упорядочены, так что подойдёт бинарный поиск. Журнал может быть небольшой и неупорядочен, так что линейный поиск. Но можно, конечно, загружать сортированный сегмент или журнал в память для кэширования, и уже в памяти любые структуры строить - хоть b-деревья, хоть хэш-таблицы. Наверно.
Я не очень знаком с этой структурой, прочитал описание несколько дней назад. Мне она показалась относительно простой, но если оптимизировать, конечно можно залезть в дебри.
Читал о реализации наподобие следующего: 1 неотсортированный "журнал" в памяти или на диске, плюс n отсортированных сегментов на диске. При поиске просматривается "журнал", а затем все остальные сегменты. При вставке/обновлении в журнал добавляется запись, при удалении - отметка о удалении. Если журнал велик, он сортируется и сбрасывается на диск как новый сегмент. Сегменты при каких-то условиях объединяются (сортировка слиянием), при этом перезаписанные или удалённые записи теряются. Ещё элементарно делаются снэпшоты для изолированных транзакций - это всего лишь дополнительный журнал на транзакцию, который либо сливается с сегментами потом, либо отбрасывается.
Я несколько лет назад проводил подобные тесты на Java и на С++, и, ЕМНИП, разницы не было (во всех 4х вариантах).
У меня нет существенного опыта в дотнете, но когда я проводил бенчмарки, оптимизатор в дотнете казался более слабым, чем в java, хотя у него были свои плюсы.
Но самое главное - не во сколько раз быстрее выполняется виртуальный вызов, а сколько времени (или сколько процентов времени) это экономит в общем алгоритме. В видео разница 10 крат, но эти 10 крат - это 1.5нс. Скорее всего, 10 млн. таких вызовов (15мс) пользователь никак не заметит, 100 млн. - заметит с трудом. Очень редко приходится оптимизировать код настолько сурово.
Какие-то нюансы техники, конечно, всегда есть (взять хотя бы тот факт, что int на С - это не целое число, как кажется на первый взгляд, а элемент подмножества целых чисел), но постановка задачи (с нюансами или без) существенно влияет на сложность решения.
результат должен выражаться в виде композиции элементарных функций без всяких «если», а все граничные условия должны выдавать корректный результат естественным образом.
На практике чаще нужно именно решение, а не "композиция элементарных функций" (тут мы, грубо говоря, начинаем считать программирование "практикой", в отличие от математики-"теории", и на практике применяем условные ветвления вместо математических трюков, потому что так сложилось). Собственно, "композиции элементарных функций" в изначальной постановке не было, и предложенное решение является решением. Если эти все дополнительные условия нужны, это уже другая задача.
Выглядит как издевательство над людьми. Мало того, что функционирование инструментов специально ухудшается, так ещё и принимается решение за человека в неких "антидеградационных" целях (весьма сомнительных). Кому это нужно? Человеку нужно получать ответы быстро. По своей воле такое никто не будет использовать. Всё равно что ботинки, в которых нельзя ходить по 10 минут после надевания в "антиперемещательных" целях, а то мало ли, уйдёшь куда-то.
В Вашей оптимистической теории они будут повышать уровень отдельных студентов.
Система образования повышает уровень большинства студентов, но некоторые из студентов необучаемы, а некоторые обучаются в итоге "выше среднего" - они и могут поддерживать уровень, если становятся преподавателями.
И через некоторое количество итераций у Вас будет один Платон, который обучит одного Аристотеля.
Число "Платонов" и "Аристотелей" всегда было невелико. Но не вижу серьёзных доводов или свидетельств о том, что это число обязательно должно равняться 1 или уменьшаться.
Если совсем не вникать в аналитические формулы, можно попробовать методом Монте-Карло построить таблицу площадей "квадрантов" в зависимости от смещений x-y. То есть просто просчитать таблицу 8х8 или 16х16 (сколько будет достаточно?) путём растеризации круга и подсчёта пикселов из разных квадрантов.
Если вникать - то, пожалуй, пару интегралов записать придётся..
Это неплохо. Хотелось бы видеть ваши выводы из опроса
, а не 4 коммента подряд про бег босиком. Мои же выводы - в беге есть некоторый риск для суставов, которого ~половина бегунов из хабровчан избежать не может. То ли бегать не умеют, то ли опасное это дело.Успокойтесь, никто у вас кроссовки не отбирает.
Его нет у большинства на Хабре (у меня точно нет, да и у вас ведь нет?), но вы ведь поднимаете эту тему здесь.
Кстати, по опросу в статье, у бегавших колени болели в 53% случаев, а у не бегавших - в 42%. Допустим, что эти данные достоверны и статистически значимы. Тогда можно сделать вывод о некоторой вредности применяемых хабровчанами методов при беге. Пири же утверждает, что его методы позволяли избежать больных коленей. Так что, если ему верить, то методы Пири более эффективны в плане избегания травм, чем методы бегающих хабровчан.
Поэтому я считаю, что советы Пири более полезны, чем советы большинства людей здесь.
P.S.: бегать босиком он не призывал, как раз из-за всякой опасной грязи, но обращал внимание, что некоторые бегуны из Африки, даже много лет тренируясь без обуви или в чём попало (и где попало), добиваются высоких результатов и не получают больных суставов. Он делал вывод, что искусственная амортизация за счёт обуви не необходима, а больше важна естественная за счёт техники бега. Статья же этот момент упускает.
Я привёл мнение из книги легкоатлета Гордона Пири "Бегай быстро и без травм", и привёл потому, что те моменты, которые он считал важными, упущены в статье. Думаю, он неплохо понимал в беге и в обуви для бега.
Не преувеличивайте. Было бы странно бегать босиком в местах, где раскиданы стёкла, гвозди, противопехотные мины, камни и т.п., а тем более, бегать, не глядя на дорогу. Даже от гвоздей обувь уже не защищает.
ICE - "электронные средства противодействия вторжению", из "Нейромант" Гибсона.
https://ru.wikipedia.org/wiki/Intrusion_Countermeasure_Electronics
Может, и модно, но безопасно как раз с носка на пятку - так нагрузка на суставы минимальна (распределяется лучше). Есть мнение, что важна именно техника, а обувь - чем легче, тем лучше, даже босиком можно бежать без ударов.
Где-то читал, что правильная техника бега крайне важна. Ударные или сверхвысокие нагрузки чуть ли не в 100% случаев убивают суставы.
Сам особо не бегаю, но в околоспортивной тусовке есть несколько знакомых с больными коленями и один с протезом сустава.
LSM по скорости поиска чуть менее эффективно, чем B дерево (всё-таки, сегменты перебираются линейно, да и в кэш процессора не влезают). У него другие плюсы, типа асинхронной балансировки без прерывания операций поиска и записи, и очень быстрой записи. Если интересно, можете посмотреть на реализацию f2fs - там lsm деревья используются, если верить вики.
Поиск посегментно, начиная с "журнала", а затем с последнего записанного сегмента к первому, пока данные по ключу не найдутся. Внутри сегмента данные упорядочены, так что подойдёт бинарный поиск. Журнал может быть небольшой и неупорядочен, так что линейный поиск. Но можно, конечно, загружать сортированный сегмент или журнал в память для кэширования, и уже в памяти любые структуры строить - хоть b-деревья, хоть хэш-таблицы. Наверно.
Я не очень знаком с этой структурой, прочитал описание несколько дней назад. Мне она показалась относительно простой, но если оптимизировать, конечно можно залезть в дебри.
Это частная реализация.
Похоже на надёжный пароль.По-видимому, lsm проще, чем b-деревья.
Читал о реализации наподобие следующего: 1 неотсортированный "журнал" в памяти или на диске, плюс n отсортированных сегментов на диске. При поиске просматривается "журнал", а затем все остальные сегменты. При вставке/обновлении в журнал добавляется запись, при удалении - отметка о удалении. Если журнал велик, он сортируется и сбрасывается на диск как новый сегмент. Сегменты при каких-то условиях объединяются (сортировка слиянием), при этом перезаписанные или удалённые записи теряются. Ещё элементарно делаются снэпшоты для изолированных транзакций - это всего лишь дополнительный журнал на транзакцию, который либо сливается с сегментами потом, либо отбрасывается.
Интересная вещь.
Журналируемую БД наверное проще реализовать на LSM-деревьях, однако в книге Кнута 1973/1978 года их быть ещё не должно.
etcетцЯ несколько лет назад проводил подобные тесты на Java и на С++, и, ЕМНИП, разницы не было (во всех 4х вариантах).
У меня нет существенного опыта в дотнете, но когда я проводил бенчмарки, оптимизатор в дотнете казался более слабым, чем в java, хотя у него были свои плюсы.
Но самое главное - не во сколько раз быстрее выполняется виртуальный вызов, а сколько времени (или сколько процентов времени) это экономит в общем алгоритме. В видео разница 10 крат, но эти 10 крат - это 1.5нс. Скорее всего, 10 млн. таких вызовов (15мс) пользователь никак не заметит, 100 млн. - заметит с трудом. Очень редко приходится оптимизировать код настолько сурово.
Не так уж сложно, на самом деле. С десяток операций всего, даже если считать как в столбик. Главное не бояться.
Какие-то нюансы техники, конечно, всегда есть (взять хотя бы тот факт, что int на С - это не целое число, как кажется на первый взгляд, а элемент подмножества целых чисел), но постановка задачи (с нюансами или без) существенно влияет на сложность решения.
На практике чаще нужно именно решение, а не "композиция элементарных функций" (тут мы, грубо говоря, начинаем считать программирование "практикой", в отличие от математики-"теории", и на практике применяем условные ветвления вместо математических трюков, потому что так сложилось). Собственно, "композиции элементарных функций" в изначальной постановке не было, и предложенное решение является решением. Если эти все дополнительные условия нужны, это уже другая задача.
Выглядит как издевательство над людьми. Мало того, что функционирование инструментов специально ухудшается, так ещё и принимается решение за человека в неких "антидеградационных" целях (весьма сомнительных). Кому это нужно? Человеку нужно получать ответы быстро. По своей воле такое никто не будет использовать. Всё равно что ботинки, в которых нельзя ходить по 10 минут после надевания в "антиперемещательных" целях, а то мало ли, уйдёшь куда-то.
А вы посмотрите на число плюсов в том комменте.
Система образования повышает уровень большинства студентов, но некоторые из студентов необучаемы, а некоторые обучаются в итоге "выше среднего" - они и могут поддерживать уровень, если становятся преподавателями.
Число "Платонов" и "Аристотелей" всегда было невелико. Но не вижу серьёзных доводов или свидетельств о том, что это число обязательно должно равняться 1 или уменьшаться.
Если совсем не вникать в аналитические формулы, можно попробовать методом Монте-Карло построить таблицу площадей "квадрантов" в зависимости от смещений x-y. То есть просто просчитать таблицу 8х8 или 16х16 (сколько будет достаточно?) путём растеризации круга и подсчёта пикселов из разных квадрантов.
Если вникать - то, пожалуй, пару интегралов записать придётся..