При использовании только одного раунда, мы получаем слишком мало информации
Если я не ошибаюсь, у 17-ти победителей из каждого батча - будут одинаковые mu/sigma
Ну кроме последнего неполного батча
При условии предварительного перемешивания(считаем что в каждом батче представлены посты разного качества), мы можем получить условный ТОП-17, но не порядок внутри него
Условный, потому что некоторые лучшие посты могут попасть в один батч, и только один из них попадёт в ТОП-17
Error.isError - без какого-либо описания даже без отдельного заголовка просто кусок кода, не отделённый от параграфа про using-и
"Новый метод upsert" а затем больше никаких упоминаний этого метода, а в примере кода используется метод "prefs.getOrInsert" Наверно потому что upsert - это не новый метод, а название proposal-а, который вводит метод getOrInsert
слишком. уж очень слишком краткая выжимка в стиле "догадайтесь сами как это работает," вершиной этого представляется упоминание про Symbol.asyncDispose, но без намека что объекты с данным методом используются через await using
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"
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
При использовании только одного раунда, мы получаем слишком мало информации
Если я не ошибаюсь, у 17-ти победителей из каждого батча - будут одинаковые mu/sigma
Ну кроме последнего неполного батча
При условии предварительного перемешивания(считаем что в каждом батче представлены посты разного качества), мы можем получить условный ТОП-17, но не порядок внутри него
Условный, потому что некоторые лучшие посты могут попасть в один батч, и только один из них попадёт в ТОП-17
Почему в TrueSkill Batch выбрано именно 5 раундов в коде?
Это экспериментально подобранная константа, или есть способ расчета?
В таблице стоимости для TrueSkill Batch указано 17 запросов, что соответствует одному раунду. Это ошибка?
Грузится также, как и обычный import
А выполнятся будет - уже по требованию
Если только в подгружаемом модуле нет top-level await - тогда выполнятся начнет сразу, иначе не удалось бы получить синхронный доступ к его экспорту
Error.isError - без какого-либо описания даже без отдельного заголовка просто кусок кода, не отделённый от параграфа про using-и
"Новый метод upsert" а затем больше никаких упоминаний этого метода, а в примере кода используется метод "prefs.getOrInsert" Наверно потому что upsert - это не новый метод, а название proposal-а, который вводит метод getOrInsert
слишком. уж очень слишком краткая выжимка в стиле "догадайтесь сами как это работает," вершиной этого представляется упоминание про Symbol.asyncDispose, но без намека что объекты с данным методом используются через
await usingКомпилятор - одна из разновидностей транслятора.
Транспайлер(транспилятор) - одна из разновидностей компилятора.
Так что всё верно.
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
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки