Да любое разумное ограничение. Например, 10000 итераций. Если вдруг окажется, что их нужно больше, можно увеличить.
Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда
Будет чёткое понимание, в каких местах алгоритма возникают проблемы со сходимостью (и временем работы). Дальше можно искать ошибки в конкретном месте или менять подход к решению. В крайнем случае можно сделать "в лоб" — убрать ограничение. Если программа не завершится — будет по крайней мере понятно, что пошло не так.
Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
Добавить счётчик итераций, если их слишком много, значит что-то пошло не так и программу лучше остановить.
Сверху крепится карбоновый кузов — сверхлёгкий (поднять его можно вдвоём), прочный (даже в сравнении со сталью) и коррозионностойкий.
А карбон разве не устаёт? Что будет с прочностью через несколько лет?
Если в год я проезжаю в среднем 20000 км, а запаса хода моего автомобиля составляет в среднем 350 км, то за год я заправляюсь примерно 57 раз, каждый раз на 2000 ₽ — итого 114000 ₽ в год уходит только на бензин
цена — в России она составляет 4.360.000 ₽
На фоне цены автомобиля экономия на бензине выглядит незначительной.
Вы видели хоть одного человека, который думает в терминах кватернионов? Что там будет вместо «поверни направо» и «наклонись вперед»?
Можно определить операцию логарифмирования от кватерниона — это будет вектор, направленный вдоль оси вращения и длиной, равной углу поворота. Почти как кватернион, там тоже в координатах x,y,z спрятана ось вращения. Ещё есть обратная операция — экспонента. Например, у нас есть вектор угловой скорости, мы его умножаем на время t, и потом делаем экспоненту и получаем текущую ориентацию.
Так вот, люди вполне могут использовать обозначения "поверни по часовой стрелке вокруг вертикальной оси" или "поверни вокруг поперечной оси на 90 градусов".
Это не совсем то, что принято называть кватернионом, но описание вращения в виде "ось поворота, угол поворота", как мне кажется, намного ближе к кватерниону, чем к углам Эйлера.
Вращение кубика рубика — тоже в углах Эйлера описывается.
Забавно, но я хочу привести это как пример использования кватернионов)
Поворот всего кубика на 90 градусов вокруг оси х — обозначается как "x". Аналогично с осями y,z.
Поворот правой части вокруг оси, смотрящей право, по часовой стрелке — R (right)
Второй пример не очень удачный — можно сказать, что правую грань больше никак и не покрутить. Но тут есть нюанс (возможно, я ошибаюсь, кубиком Рубика не увлекался): повороты L и R делаются в разные стороны. Т.е., R делается по часовой стрелке, если смотреть справа, а L — если смотреть слева.
С точки зрения поворотов относительно вращающего, это немножко нелогично. А вот если смотреть на это как "R — вращение вокруг оси, направленной вправо, L — вокруг оси, направленной влево", то всё становится понятно.
Вы видели хоть одного человека, который думает в терминах кватернионов? Что там будет вместо «поверни направо» и «наклонись вперед»?
Короче, я утверждаю, что люди довольно часто мыслят в терминах "поворот вокруг такой-то оси на такой-то угол", и такая формулировка ближе к кватернионам, чем к углам Эйлера.
Причём если человек внутри корабля или самолёта, ему почему-то привычнее думать в углах Эйлера, а если вращает что-то перед собой (тот же кубик рубика), то становится проще представить ось вращения и крутить вокруг неё.
Эм, на самолёте или спутнике вполне может быть и "носом вверх" и "носом вниз".
Если бы я реализовывал софт для них, я бы внутри использовал кватернионы. Как Вы в терминах углов Эйлера представите угловую скорость? Как производные по этим трём углам? Это же убого получится — спутник, например, вращается с постоянной скоростью, а нам приходится постоянно пересчитывать углы и угловые скорости. А если он вращается вокруг неудачной оси, то в окрестности gimbal lock ошибка вычислений станет большой.
Или, например, как найти оптимальный поворот их положения А в Б?
то не то и не другое, если быть точным. Это некая операция.
Умножение — более фундаментальная сущность, чем какие-то там числа.
Кватернионы единичной длины — группа SU(2). Группа (любая) по определению имеет операцию умножения, и коммутативности никто не требует.
Именно потому что это не сумма и не произведение чисел, оно и не коммутативно.
Это вообще бред. Вот я возьму строчки вида "aaa" (произвольное количество символов "a") и определю на них сложение как конкатенацию: "a" + "aa" = "aa" + "a" = "aaa", оно будет коммутативным и ассоциативным. А вот если взять строчки из символов "a" и "б", то на них сложение вдруг перестанет быть коммутативным, но останется ассоциативным: "аб" + "ба" != "ба" + "aб", ("a"+"б") + "c" == "a" + ("б" + "c")
Вместо нетбука с семёркой и 2гб оперативки в прошлом году купил небольшой ноутбук с десяткой и 8гб памяти. Сравнил их друг с другом.
Хотя если у вас пишутся мегабайты, это своп скорее работает.
Год назад довольно много всего перепробовал, но так ничего и не помогло. По симптомам выглядело примерно как тут, только скорость записи была побольше: https://www.drivereasy.com/knowledge/fix-100-disk-usage-in-task-manager-improve-pc-performance-on-windows-10/ Замечал эту особенность с тупящей виндой и записью на диск ещё на нескольких компах.
Я терпел десятку пару месяцев, потом поставил ssd, линукс как вторую систему и в итоге пользуюсь только им. Никаких сюрпризов, ограничений, перезагрузок, рекламы и установок обновлений по нескольку десятков минут. Он просто работает.
Претензии к плиточкам у вас — ровно те же основы имеет «дайте мне то же самое оформление к которому я привык». Всё.
Мне кажется, суть претензии в другом: PC должен настраиваться и работать так, как это нужно владельцу.
А сейчас в 10 есть куча встроенной фигни, которая мешает работать и которую проблематично отключить или настроить. Вот примеры навскидку:
Система обновлений.
Встроенный антивирус
Неудобый плиточный интерфейс.
Предустановленное барахло типа браузера, кортаны, каких-то игр, пробной версии майнкрафта (на час игры, блин. Издевательство)
Десятка постоянно что-то пишет-читает с диска по нескольку мегабайт в секунду. Нафига? В моём ноутбуке на семёрке жёсткий диск может останавливаться на несколько минут — всё что нужно для работы, помещается в 2гб оперативки.
Дальше мы грузим модельки наших солдатиков. Я их гружу 20 штук. Каждая из 2 тыс полигонов, каждый по 3 вершины, каждый по 5 флоатов, каждый по 4 байта. Итого… 2,35 МБ. Немого?
— Немного, — согласился Федор Михалыч.
— Хотя нет. В каждой модели по 95 кадров. Итого 220 МБ.
А почему бы не навелосипедить свою склетеную анимацию интерполяцию между ключевыми точками?
Вот тут люди сравнили ручное кеширование с его отсутствием — разница незначительная.
Если transform выглядит как поле у gameObject, а position — как поле у transform, откуда новичку знать, что там что-то создаётся?
И вообще, этот код написан для примера — он должен быть максимально простым и коротким. Если в примере переменные вместо публичных станут приватными, а код разрастётся из-за выравнивания и стремления спасти GC от страшной напасти в виде 50 новых объектов в секунду, повысится ли его понятность?
Имхо, лучше создать приватный репозиторий на каком-нибудь bitbucket и клонировать его.
но тогда бот не будет перезапускаться автоматически в случае падения, а это происходит часто – несколько раз в неделю из-за ночного перезапуска серверов telegram (в 3:00 по МСК).
Эм. С какой стати бот-то падает? А если интернета несколько секунд не будет, бот тоже упадёт? Это неправильный подход.
60 км/ч это примерно 17 метров в секунду, средний автомобиль 4,5 метра и пара метров дистанции.
Так не работает. Время реакции водителя принято считать в 0.5-1 секунду, на скорости в 60 км/ч автомобилисты (в среднем) будут держать интервал метров в 10 или даже больше. Ещё прибавим длину авто. Получается где-то 1 автомобиль в секунду в лучшем случае. (Безопасным считается интервал в 2-3 секунды, но в городе слишком много машин для такого). С минимальным интервалом получается где-то 3600 машин в час, с интервалом в 2-2.5 секунды будет около 1500.
А самое печальное, что в реальных условиях средняя скорость движения автобуса получается 10-15 км/ч.
Потому что автобус стоит на светофорах и каждые метров 500 происходит посадка-высадка пассажиров. Я был поражен, когда осознал, что автобус от Лося до Лианозово едет час, хотя расстояние — всего лишь 10км. (сейчас есть МЦК, а раньше приходилось ехать так). Ещё на практике интервал в 10-15 минут между автобусами может превратиться в получасовое ожидание пары рядом едущих автобусов. Передний вынужден подолгу сажать кучу пассажиров, в отстающий на 5 минут задний почти никто не садится, и он начинает догонять переднего, пока не обгонит.
В масштабах Москвы это неприменимо.
На длинные расстояния — слишком долго ехать. На короткие расстояния — тоже неудобно. Вместо пятиминутного ожидания автобуса и пятиминутной поездки можно за те же десять минут дойти пешком.
Наверное, разработчики, думают о том, что бы минимизировать Эффект Браеса. А может навигаторы усиливают этот эффект, случайно?
Регулярно встречаю случаи, когда от навигаторов становится хуже.
Пример — Ярослаское шоссе перед въездом в Москву. место на карте.
Если там пробка, навигатор предлагает объехать её часть (500м) справа, а потом втиснуться обратно на шоссе. Для конкретного водителя так будет быстрее. А теперь посмотрим глобально: источник пробки — где-то далеко впереди, поток машин ограничен. Объезжающие сбоку эти 500 метров экономят время за счёт тех, кто объезжать не стал.
Прилегающая дорога тоже становится забита — наверно, местные жители не рады.
Позитивных эффектов нет. Зато есть негативный — некоторые водители, вместо того, чтобы спокойно ехать каждому в своей полосе, начинают перестраиваться через весь поток направо, проезжают эти 500 метров, потом вклиниваются в движение и перестраиваются куда-нибудь влево. Поток машин, вместо того, чтобы медленно двигаться с постоянной скоростью, начинает дёргаться в режиме разогнался — затормозил.
Идея заключается в том, что первый водитель начинает притормаживать, потом ускоряться до нормальной скорости, однако из-за ограниченной реакции водитель сзади начинает притормаживать чуть больше и чуть медленнее ускоряться и так далее по цепочки, которая разрывается только при соблюдении дистанции.
Этот эффект очень сильно зависит от расстояния между автомобилями. Если дорога относительно свободная, то такие колебания быстро затухают (передний притормозил, второй просто отпустил газ, третий вообще ничего не заметил). В плотном потоке едущему сзади автомобилю действительно приходится сильнее реагировать на действия автомобиля и любое, даже секундное нажатие на тормоз волной переходит на автомобили сзади.
Т.е., как ни крути, суть пробки в том, что пропускная способность дороги недостаточно высокая.
Мне кажется, проблема синтаксиса Питона в том, что код типа такого:
no_none = (x for x in seq if x is not None)
пишется короче, чем в функциональном стиле
no_none = filter(lambda x: x is not None, seq)
Всё равно придётся написать 'x' целых два раза и ещё слово lambda появится. Если захотеть, чтобы no_none была списком, а не генератором, то станет ещё хуже:
no_none = [x for x in seq if x is not None]
vs
no_none = list(filter(lambda x: x is not None, seq))
Появилось ещё одно слово и вложенные скобочки. Нельзя просто так взять и написать на питоне красиво и функционально — чтобы получить какой-то выигрыш в краткости, надо брать что-то реально повторяющееся.
В некоторых языках происходит наоборот — они подталкивают к функциональному стилю как более простому и короткому, например:
val no_none = seq filter (_ != null)
Я время от времени порываюсь написать что-то функциональное на питоне, но почти всё время остаётся чувство, что лучше написать решение "в лоб".
Немножко дико выглядит код после return. Вы по какой-то причине так писали?
Мне кажется, для читабельности лучше было бы использовать локальную функцию после её объявления.
До установки патча температура процессора в пике составляла 72 градуса, после установки уже 86 градусов. Время между замерами 35 минут. В итоге мы получаем не только менее производительный но еще и более горячий CPU (в среднем 10-15%).
Вы как-то лихо оценили горячесть CPU. Вы уверены, что при температуре 72 градуса вентилятор работает на полную мощность (как при 86?).
Кроме того, если предположить, что отвод тепла пропорционален разнице температур, а в комнате около 20 градусов, то получается соотношение типа 66/52 = 1.27. Это уже 27% разницы, а не 10-15%.
Да любое разумное ограничение. Например, 10000 итераций. Если вдруг окажется, что их нужно больше, можно увеличить.
Будет чёткое понимание, в каких местах алгоритма возникают проблемы со сходимостью (и временем работы). Дальше можно искать ошибки в конкретном месте или менять подход к решению. В крайнем случае можно сделать "в лоб" — убрать ограничение. Если программа не завершится — будет по крайней мере понятно, что пошло не так.
Добавить счётчик итераций, если их слишком много, значит что-то пошло не так и программу лучше остановить.
В примере код на C++
О, контрвариантность подъехала. Хотя по вопросу фиг догадаешься, чего вообще они хотят.
А карбон разве не устаёт? Что будет с прочностью через несколько лет?
На фоне цены автомобиля экономия на бензине выглядит незначительной.
Можно определить операцию логарифмирования от кватерниона — это будет вектор, направленный вдоль оси вращения и длиной, равной углу поворота. Почти как кватернион, там тоже в координатах x,y,z спрятана ось вращения. Ещё есть обратная операция — экспонента. Например, у нас есть вектор угловой скорости, мы его умножаем на время t, и потом делаем экспоненту и получаем текущую ориентацию.
Так вот, люди вполне могут использовать обозначения "поверни по часовой стрелке вокруг вертикальной оси" или "поверни вокруг поперечной оси на 90 градусов".
Это не совсем то, что принято называть кватернионом, но описание вращения в виде "ось поворота, угол поворота", как мне кажется, намного ближе к кватерниону, чем к углам Эйлера.
Забавно, но я хочу привести это как пример использования кватернионов)
Второй пример не очень удачный — можно сказать, что правую грань больше никак и не покрутить. Но тут есть нюанс (возможно, я ошибаюсь, кубиком Рубика не увлекался): повороты L и R делаются в разные стороны. Т.е., R делается по часовой стрелке, если смотреть справа, а L — если смотреть слева.
С точки зрения поворотов относительно вращающего, это немножко нелогично. А вот если смотреть на это как "R — вращение вокруг оси, направленной вправо, L — вокруг оси, направленной влево", то всё становится понятно.
Короче, я утверждаю, что люди довольно часто мыслят в терминах "поворот вокруг такой-то оси на такой-то угол", и такая формулировка ближе к кватернионам, чем к углам Эйлера.
Причём если человек внутри корабля или самолёта, ему почему-то привычнее думать в углах Эйлера, а если вращает что-то перед собой (тот же кубик рубика), то становится проще представить ось вращения и крутить вокруг неё.
Эм, на самолёте или спутнике вполне может быть и "носом вверх" и "носом вниз".
Если бы я реализовывал софт для них, я бы внутри использовал кватернионы. Как Вы в терминах углов Эйлера представите угловую скорость? Как производные по этим трём углам? Это же убого получится — спутник, например, вращается с постоянной скоростью, а нам приходится постоянно пересчитывать углы и угловые скорости. А если он вращается вокруг неудачной оси, то в окрестности gimbal lock ошибка вычислений станет большой.
Или, например, как найти оптимальный поворот их положения А в Б?
Умножение — более фундаментальная сущность, чем какие-то там числа.
Кватернионы единичной длины — группа SU(2). Группа (любая) по определению имеет операцию умножения, и коммутативности никто не требует.
Это вообще бред. Вот я возьму строчки вида "aaa" (произвольное количество символов "a") и определю на них сложение как конкатенацию: "a" + "aa" = "aa" + "a" = "aaa", оно будет коммутативным и ассоциативным. А вот если взять строчки из символов "a" и "б", то на них сложение вдруг перестанет быть коммутативным, но останется ассоциативным: "аб" + "ба" != "ба" + "aб", ("a"+"б") + "c" == "a" + ("б" + "c")
Вместо нетбука с семёркой и 2гб оперативки в прошлом году купил небольшой ноутбук с десяткой и 8гб памяти. Сравнил их друг с другом.
Год назад довольно много всего перепробовал, но так ничего и не помогло. По симптомам выглядело примерно как тут, только скорость записи была побольше: https://www.drivereasy.com/knowledge/fix-100-disk-usage-in-task-manager-improve-pc-performance-on-windows-10/ Замечал эту особенность с тупящей виндой и записью на диск ещё на нескольких компах.
Я терпел десятку пару месяцев, потом поставил ssd, линукс как вторую систему и в итоге пользуюсь только им. Никаких сюрпризов, ограничений, перезагрузок, рекламы и установок обновлений по нескольку десятков минут. Он просто работает.
Мне кажется, суть претензии в другом: PC должен настраиваться и работать так, как это нужно владельцу.
А сейчас в 10 есть куча встроенной фигни, которая мешает работать и которую проблематично отключить или настроить. Вот примеры навскидку:
А почему бы не навелосипедить
свою склетеную анимациюинтерполяцию между ключевыми точками?in Unity5 we also cache the transform component on the c# side, so there should no longer be a performance reason to cache the transform component yourself.
Нашёл здесь: https://blogs.unity3d.com/2014/06/23/unity5-api-changes-automatic-script-updating/
Вот тут люди сравнили ручное кеширование с его отсутствием — разница незначительная.
Если transform выглядит как поле у gameObject, а position — как поле у transform, откуда новичку знать, что там что-то создаётся?
И вообще, этот код написан для примера — он должен быть максимально простым и коротким. Если в примере переменные вместо публичных станут приватными, а код разрастётся из-за выравнивания и стремления спасти GC от страшной напасти в виде 50 новых объектов в секунду, повысится ли его понятность?
Имхо, лучше создать приватный репозиторий на каком-нибудь bitbucket и клонировать его.
Эм. С какой стати бот-то падает? А если интернета несколько секунд не будет, бот тоже упадёт? Это неправильный подход.
Так не работает. Время реакции водителя принято считать в 0.5-1 секунду, на скорости в 60 км/ч автомобилисты (в среднем) будут держать интервал метров в 10 или даже больше. Ещё прибавим длину авто. Получается где-то 1 автомобиль в секунду в лучшем случае. (Безопасным считается интервал в 2-3 секунды, но в городе слишком много машин для такого). С минимальным интервалом получается где-то 3600 машин в час, с интервалом в 2-2.5 секунды будет около 1500.
А самое печальное, что в реальных условиях средняя скорость движения автобуса получается 10-15 км/ч.
Потому что автобус стоит на светофорах и каждые метров 500 происходит посадка-высадка пассажиров. Я был поражен, когда осознал, что автобус от Лося до Лианозово едет час, хотя расстояние — всего лишь 10км. (сейчас есть МЦК, а раньше приходилось ехать так). Ещё на практике интервал в 10-15 минут между автобусами может превратиться в получасовое ожидание пары рядом едущих автобусов. Передний вынужден подолгу сажать кучу пассажиров, в отстающий на 5 минут задний почти никто не садится, и он начинает догонять переднего, пока не обгонит.
В масштабах Москвы это неприменимо.
На длинные расстояния — слишком долго ехать. На короткие расстояния — тоже неудобно. Вместо пятиминутного ожидания автобуса и пятиминутной поездки можно за те же десять минут дойти пешком.
Регулярно встречаю случаи, когда от навигаторов становится хуже.
Пример — Ярослаское шоссе перед въездом в Москву. место на карте.
Если там пробка, навигатор предлагает объехать её часть (500м) справа, а потом втиснуться обратно на шоссе. Для конкретного водителя так будет быстрее. А теперь посмотрим глобально: источник пробки — где-то далеко впереди, поток машин ограничен. Объезжающие сбоку эти 500 метров экономят время за счёт тех, кто объезжать не стал.
Прилегающая дорога тоже становится забита — наверно, местные жители не рады.
Позитивных эффектов нет. Зато есть негативный — некоторые водители, вместо того, чтобы спокойно ехать каждому в своей полосе, начинают перестраиваться через весь поток направо, проезжают эти 500 метров, потом вклиниваются в движение и перестраиваются куда-нибудь влево. Поток машин, вместо того, чтобы медленно двигаться с постоянной скоростью, начинает дёргаться в режиме разогнался — затормозил.
Этот эффект очень сильно зависит от расстояния между автомобилями. Если дорога относительно свободная, то такие колебания быстро затухают (передний притормозил, второй просто отпустил газ, третий вообще ничего не заметил). В плотном потоке едущему сзади автомобилю действительно приходится сильнее реагировать на действия автомобиля и любое, даже секундное нажатие на тормоз волной переходит на автомобили сзади.
Т.е., как ни крути, суть пробки в том, что пропускная способность дороги недостаточно высокая.
Мне кажется, проблема синтаксиса Питона в том, что код типа такого:
пишется короче, чем в функциональном стиле
Всё равно придётся написать 'x' целых два раза и ещё слово lambda появится. Если захотеть, чтобы no_none была списком, а не генератором, то станет ещё хуже:
vs
Появилось ещё одно слово и вложенные скобочки. Нельзя просто так взять и написать на питоне красиво и функционально — чтобы получить какой-то выигрыш в краткости, надо брать что-то реально повторяющееся.
В некоторых языках происходит наоборот — они подталкивают к функциональному стилю как более простому и короткому, например:
Я время от времени порываюсь написать что-то функциональное на питоне, но почти всё время остаётся чувство, что лучше написать решение "в лоб".
Немножко дико выглядит код после return. Вы по какой-то причине так писали?
Мне кажется, для читабельности лучше было бы использовать локальную функцию после её объявления.
Вы как-то лихо оценили горячесть CPU. Вы уверены, что при температуре 72 градуса вентилятор работает на полную мощность (как при 86?).
Кроме того, если предположить, что отвод тепла пропорционален разнице температур, а в комнате около 20 градусов, то получается соотношение типа 66/52 = 1.27. Это уже 27% разницы, а не 10-15%.