Слишком большая статья для описания такой простой вещи. Лучше б рассказали старинную байку, как фанаты ассемблера и си зарубились из-за скорости, договорились помериться, вычисляя n-е число Фибоначчи, и всех уделал какой-то чувак, написавший чуть ли не на бейсике.
Как только узнаёшь в задаче возведение матрицы в степень – остальное должен написать, не задумываясь.
Кстати, если копнуть глубже – это решение не за логарифмическое время. Ведь числа с ростом N становятся всё длиннее, и умножение, соответственно, медленнее. Исходя из объёма вашей статьи и упоминания в ней быстрого алгоритма умножения – я ожидал увидеть как минимум алгоритм Карацубы.
Я даже догадался, в чём была реальная проблема (глупо переплачивать за мощные сервера, которые работают с такой же нагрузкой, как хилые), но прозвучало крайне странно :-)
Газовой плиты более чем достаточно. А то и зажигалки. Сунуть кончик в пламя и посмотреть на поведение. Медь расплавить труднее, и она после этого собирается в шарик. Алюминий провисает, как говно в носке (оксидная оболочка не даёт растечься, но форму уже не держит).
Ну или просто поскрести и посмотреть цвет под медью. Как вариант – поскрести и сунуть в Крот, алюминий с шипением растворится.
Ну, можно использовать stash вместо временной ветки, но в SourceTree нет такой свободы действий с ним.
TortoiseGit – не уверен, вроде нет (собственно, политика git с его индексом не способствует реализации такой фичи, это меркуриал с его mq как бы намекает – сделай, мол). В SourceTree – точно нет.
Но это не основная моя претензия к git (в конце концов не так часто приходится нарезать несколько коммитов из рабочей копии), так, мелкое неудобство. Просто вы сказали, что якобы в git это удобнее, что противоречит моему опыту.
Процесс именно что усложнился. Сейчас мне проще с той же целью (чтобы что проверил – то и закоммитил) закоммитить во временную ветку, вернуться на рабочую и по частям переносить из временной, собирая отдельные коммиты. Заметное усложнение, так что я, честно говоря, редко так делаю, чаще коммичу вслепую :-)
Ну и инструмент у меня был как раз "в коробке", я в те времена ставил TortoiseHg, там работа с shelve (продвинутый аналог git stash) очень удобная.
1 – поспорил бы. В hg у меня для таких случаев был подход: убираю в stash (ну или как он там назывался, давно дело было) все изменения, кроме тех, что нужно закоммитить (есть удобный инструмент для переноса их туда-обратно, вплоть до отдельных строк), компилирую-проверяю, коммичу, переношу из stash следующую порцию и так далее.
Т.е., грубо говоря, что не в индексе – того и в рабочей копии нет, можно проверять перед коммитом.
Было удобно. А с переходом на git – стал делать то же самое вслепую: выбрал файлы в индекс, закоммитил. Потому что процесс, аналогичный привычному, резко усложнился.
Вот да, после полноценных бранчей гитовское поделие родом из CVS – боль... Но, увы, в битве систем контроля версий победил гит, приходится приспосабливаться, добавлять костыли...
Я правильно понимаю, что сосед думал то же самое про ваш код, потому что место для упрощения в вашем коде видел, а в своём – нет?
TL;DR
Слишком большая статья для описания такой простой вещи. Лучше б рассказали старинную байку, как фанаты ассемблера и си зарубились из-за скорости, договорились помериться, вычисляя n-е число Фибоначчи, и всех уделал какой-то чувак, написавший чуть ли не на бейсике.
Как только узнаёшь в задаче возведение матрицы в степень – остальное должен написать, не задумываясь.
Кстати, если копнуть глубже – это решение не за логарифмическое время. Ведь числа с ростом N становятся всё длиннее, и умножение, соответственно, медленнее. Исходя из объёма вашей статьи и упоминания в ней быстрого алгоритма умножения – я ожидал увидеть как минимум алгоритм Карацубы.
Только к возведению в степень, не к умножению.
Я даже догадался, в чём была реальная проблема (глупо переплачивать за мощные сервера, которые работают с такой же нагрузкой, как хилые), но прозвучало крайне странно :-)
Задача вообще непонятна. Обычно ж стараются, чтобы всё разом не умирало, а не наоборот.
(зануда mode on) Ватт*час и А*час, не Ватт/час и А/час.
Множественное наследование от интерфейсов безболезненно, множественное наследование от типов тянет за собой ряд проблем.
А разве критично его соблюдать? Там же вроде всё сводится к тому, что он вообще есть и разный для разных пар.
Газовой плиты более чем достаточно. А то и зажигалки. Сунуть кончик в пламя и посмотреть на поведение. Медь расплавить труднее, и она после этого собирается в шарик. Алюминий провисает, как говно в носке (оксидная оболочка не даёт растечься, но форму уже не держит).
Ну или просто поскрести и посмотреть цвет под медью. Как вариант – поскрести и сунуть в Крот, алюминий с шипением растворится.
У меня тянула сильно больше. Но всё равно с удовольствием перешёл на ethernet.
Ну ok. Не так важно, как именно внедрена типизация, лишь бы она была)
Необходим – не скажу, но я помню, какое счастье было, когда js-часть нашего проекта перевели на ts. Стало на порядок легче жить.
Он не реализуется на чистом js, говорю как человек, которому это понадобилось делать :-)
Просто реализуете в нативе функцию SetTimeout, которая обеспечивает нужный функционал, и скармливаете её js-движку.
Корявый перевод слова hack.
Смотрю на слово "extends" вместо значка ⊂ (является подмножеством) в применении к второму аргументу Pick и грущу.
Ну, можно использовать stash вместо временной ветки, но в SourceTree нет такой свободы действий с ним.
TortoiseGit – не уверен, вроде нет (собственно, политика git с его индексом не способствует реализации такой фичи, это меркуриал с его mq как бы намекает – сделай, мол). В SourceTree – точно нет.
Но это не основная моя претензия к git (в конце концов не так часто приходится нарезать несколько коммитов из рабочей копии), так, мелкое неудобство. Просто вы сказали, что якобы в git это удобнее, что противоречит моему опыту.
Процесс именно что усложнился. Сейчас мне проще с той же целью (чтобы что проверил – то и закоммитил) закоммитить во временную ветку, вернуться на рабочую и по частям переносить из временной, собирая отдельные коммиты. Заметное усложнение, так что я, честно говоря, редко так делаю, чаще коммичу вслепую :-)
Ну и инструмент у меня был как раз "в коробке", я в те времена ставил TortoiseHg, там работа с shelve (продвинутый аналог git stash) очень удобная.
1 – поспорил бы. В hg у меня для таких случаев был подход: убираю в stash (ну или как он там назывался, давно дело было) все изменения, кроме тех, что нужно закоммитить (есть удобный инструмент для переноса их туда-обратно, вплоть до отдельных строк), компилирую-проверяю, коммичу, переношу из stash следующую порцию и так далее.
Т.е., грубо говоря, что не в индексе – того и в рабочей копии нет, можно проверять перед коммитом.
Было удобно. А с переходом на git – стал делать то же самое вслепую: выбрал файлы в индекс, закоммитил. Потому что процесс, аналогичный привычному, резко усложнился.
Вот да, после полноценных бранчей гитовское поделие родом из CVS – боль... Но, увы, в битве систем контроля версий победил гит, приходится приспосабливаться, добавлять костыли...
Я нагуглил про оптику, с роботом, но принцип именно тот, что вы описали: https://www.optic-electric.com/78.html