p-адические числа зависят от системы счисления И имеют разные свойства в зависимости от системы счисления Например в поле 10-адических чисел существует n не равное единице и нулю, для которого n^2=n
И при этом p-адические числа имеют реальное(математическое) применение, например в решении Диофантовых уравнений, и доказательстве теоремы Ферма
Можно конечно где-то провести условную границу между "настоящей" и "искусственной" математикой, но всегда найдется кто-то, кто подвинет эту границу, как например было с нулём, отрицательными числами, мнимыми числами...
Если будет слишком много элементов, случится Maximum call stack size exceeded
reduce будет понадежнее, хотя и медленнее
Но у вас уже используется map, и с учетом этого reduce будет уже быстрее чем map+rest arguments
var arr = Array.from(Array(100000), () => ({_id: Math.round(Math.random() * 10000)}));
console.time('reduce');// 1180ms
for(var i = 0; i < 1000; i++)
arr.reduce((a,{_id}) => (a > _id ? a : _id), -Infinity)
console.timeEnd('reduce');
console.time('rest args');// 1748ms
for(var i = 0; i < 1000; i++)
Math.max(...arr.map(x => x._id))
console.timeEnd('rest args');
Также || 0 выглядит как ненужная перестраховка
Если элементов не будет, то вы получите -Infinity, и этот код не поможет
В остальных случая _id вроде всегда число, а значит мы и так получим максимальный _id
По цифрам ничего не скажу — не было даже мысли проверять.
Можете сами проверить, если вам интересно.
Но навскидку я бы не поставил на успех if-а в этом «соревновании».
А вообще преждевременная оптимизация — зло.
Преждевременная микро-оптимизация базовых инструкций, в ущерб поддерживаемости кода — двойное зло.
В моих аргументах выше, производительность пожалуй стоит поставить на второе место по-важности.
Более того наверняка есть контексты, где lodash.get будет уместнее в плане читаемости и поддержки кода.
Но это уже не совсем типовые случаи.
Да, я ошибся насчет второго примера.
Он дергает return() непосредственно перед тем как упасть
И странно, что цикл асинхронной итерации не поступает похожим образом при собственном падении(а не в теле цикла)
Чуть подробнее я описал в комментарии ниже
И теперь я тоже не понимаю что происходит, и нахожу поведение в 4-ом примере непонятным
Да, я ошибся насчет 2-ого примера
Цикл все-таки падает(в теле цикла)
Но, перед тем как упасть, дождавшись промис, сперва дергает .return, и потом уже падает
В таком случае выглядит странно, что for..await не делает также, когда упал именно при обработке IteratorResult
Но при этом, при падении в теле цикла, он также как и цикл синхронной итерации, дергает return()
По-моему в последнем примере все логично
1) цикл начинает первую итерацию.
Запросил iterator.next()
Получил Promise.resolve(42), дождался его резолва
Вызвал тело цикла, и вывел в консоль
2) цикл начинает вторую итерацию
Запросил iterator.next()
Генератор внутри себя дошел до yield Promise.reject(43), и вернул его
Идти дальше, пока не был вызван новый(3-ий по счету) .next() — он не имеет права
Цикл получил Promise.reject(43) в качестве нового значения
Цикл дождался, и успешно бросил исключение
В итоге цикл закончился преждевременно, не вызвав .next в последний раз.
А значит генератор никогда не доберётся до своего finally
Вот если бы падение было в самом генераторе(3-ий пример) — то finally выполнился бы
И если бы цикл не упал, и запросил бы next() в третий раз(2-ой пример) — то finally также выполнился бы(как и любой другой код)
Я только за совместное развитие, понимаю его, и одобряю
Просто уточняю факты для изначального комментатора — не все синтаксические элементы в TypeScript были придуманы командой TypeScript, а скорее являются реализацией и обкаткой существующих черновиков ES.
Причем часто на поздних этапах, в то время как babel начинает обкатку со stage0
Курица или яйцо?
Не могу сказать за все фичи, но часть из них(всех фич, а не конкретно ES2020) появилась сперва в черновиках ES, и только потом, с определенного уровня были поддержаны в TypeScript
К пунктам про gitconfig хочется добавить, что все-таки можно переиспользовать конфиг между разработчиками
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
git config --local include.path "../.gitconfig"
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
Я правильно понимаю что этап валидации домена через файл все равно нужно выполнить?
Я хочу сгенерировать сертификат для локальной сети — 192-168-0-100.sslip.io
Я так понимаю ни LetsEncrypt, ни какой-либо другой центр сертификации не выдаст мне сертификат для домена, который по-факту резолвится в локальную сеть?
т.е. для данного случая нужен свой реальный базовый домен, и wildcard сертификат для него?
ясное указание выхода должно быть на той же строке, что и последняя скобка
Мой вопрос именно про код последнего выхода — $?
Почему нельзя писать так, без явного указания кода?
(
…
); exit;
Судя по документации команды exit — она и так возьмет код последней команды, если его специально не указывать
Является ли важным явно указать его, или это вопрос только читаемости?
Компилятор - одна из разновидностей транслятора.
Транспайлер(транспилятор) - одна из разновидностей компилятора.
Так что всё верно.
p-адические числа зависят от системы счисления
И имеют разные свойства в зависимости от системы счисления
Например в поле 10-адических чисел существует n не равное единице и нулю, для которого n^2=n
И при этом p-адические числа имеют реальное(математическое) применение, например в решении Диофантовых уравнений, и доказательстве теоремы Ферма
Можно конечно где-то провести условную границу между "настоящей" и "искусственной" математикой, но всегда найдется кто-то, кто подвинет эту границу, как например было с нулём, отрицательными числами, мнимыми числами...
$0 - текущий выбранный в инспекторе элемент
$1 - $4 - предыдущие выбранные элементы
x = x && yиx && (x = y)тождественны друг другуВторое конечно мене очевидно выглядит, но по функциональности разницы не вижу
Если будет слишком много элементов, случится Maximum call stack size exceeded
reduce будет понадежнее, хотя и медленнее
Но у вас уже используется map, и с учетом этого reduce будет уже быстрее чем map+rest arguments
Также || 0 выглядит как ненужная перестраховка
Если элементов не будет, то вы получите -Infinity, и этот код не поможет
В остальных случая _id вроде всегда число, а значит мы и так получим максимальный _id
Можете сами проверить, если вам интересно.
Но навскидку я бы не поставил на успех if-а в этом «соревновании».
А вообще преждевременная оптимизация — зло.
Преждевременная микро-оптимизация базовых инструкций, в ущерб поддерживаемости кода — двойное зло.
В моих аргументах выше, производительность пожалуй стоит поставить на второе место по-важности.
Более того наверняка есть контексты, где lodash.get будет уместнее в плане читаемости и поддержки кода.
Но это уже не совсем типовые случаи.
Или чтобы дополнительно замедлить код вызовами функции?
К тому же речь о том, чтобы указывать вопрос для опциональных свойств, а значит замена не один-в-один
Он дергает return() непосредственно перед тем как упасть
И странно, что цикл асинхронной итерации не поступает похожим образом при собственном падении(а не в теле цикла)
Чуть подробнее я описал в комментарии ниже
И теперь я тоже не понимаю что происходит, и нахожу поведение в 4-ом примере непонятным
Цикл все-таки падает(в теле цикла)
Но, перед тем как упасть, дождавшись промис, сперва дергает .return, и потом уже падает
В таком случае выглядит странно, что for..await не делает также, когда упал именно при обработке IteratorResult
Но при этом, при падении в теле цикла, он также как и цикл синхронной итерации, дергает return()
1) цикл начинает первую итерацию.
Запросил iterator.next()
Получил Promise.resolve(42), дождался его резолва
Вызвал тело цикла, и вывел в консоль
2) цикл начинает вторую итерацию
Запросил iterator.next()
Генератор внутри себя дошел до yield Promise.reject(43), и вернул его
Идти дальше, пока не был вызван новый(3-ий по счету) .next() — он не имеет права
Цикл получил Promise.reject(43) в качестве нового значения
Цикл дождался, и успешно бросил исключение
В итоге цикл закончился преждевременно, не вызвав .next в последний раз.
А значит генератор никогда не доберётся до своего finally
Вот если бы падение было в самом генераторе(3-ий пример) — то finally выполнился бы
И если бы цикл не упал, и запросил бы next() в третий раз(2-ой пример) — то finally также выполнился бы(как и любой другой код)
Просто уточняю факты для изначального комментатора — не все синтаксические элементы в TypeScript были придуманы командой TypeScript, а скорее являются реализацией и обкаткой существующих черновиков ES.
Причем часто на поздних этапах, в то время как babel начинает обкатку со stage0
Например Optional chaining был взят из stage3 — github.com/microsoft/TypeScript/issues/16
А Nullish coalescing обсуждался со stage1, а имплементирован похоже на момент stage3 — github.com/microsoft/TypeScript/issues/26578
Не могу сказать за все фичи, но часть из них(всех фич, а не конкретно ES2020) появилась сперва в черновиках ES, и только потом, с определенного уровня были поддержаны в TypeScript
habr.com/ru/company/ruvds/blog/479266
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
Я хочу сгенерировать сертификат для локальной сети — 192-168-0-100.sslip.io
Я так понимаю ни LetsEncrypt, ни какой-либо другой центр сертификации не выдаст мне сертификат для домена, который по-факту резолвится в локальную сеть?
т.е. для данного случая нужен свой реальный базовый домен, и wildcard сертификат для него?
Очень предусмотрительный подход — возьму на вооружение
Эта часть у меня не вызывает вопросов:
Мой вопрос именно про код последнего выхода — $?
Почему нельзя писать так, без явного указания кода?
Судя по документации команды exit — она и так возьмет код последней команды, если его специально не указывать
Является ли важным явно указать его, или это вопрос только читаемости?
Важно, чтобы он был в той же строке, что и закрывающая фигурная скобка, после точки с запятой