По той же причине, по которой что-либо в нулевой степени равно 1. Когда совсем нет множителей, остается нейтральный элемент (единица). Это справедливо не только для умножения, но и вообще для любых операций с наличием нейтрального элемента. Например, для логического "И" отсюда следует немного странный результат
А толку с этой монетки? Г не имеет механизма, который бы ограничил ему свободный выбор - принимать или не принимать. Потому, как бы он ни понтовался заранее, он всё равно согласится на 1. Даже если подброшенная им монетка выпадет так, чтобы не брать.
Вот если бы такой неотменяемый самоограничивающий механизм для Г существовал, и Г успел его запустить до внесения предложения от Б - тогда да, уже Б был бы поставлен перед фактом.
Итак, Б, В, Г, Д. Если игрок Б предлагает "99, 0, 1, 0", то игрок Г, ранее тоже размахивавший красными линиями, либо примет вариант, либо остается ни с чем (потому что "99, 0, 1", как установлено выше, гарантированно прокатывает). Поэтому он принимает такой вариант. Правильно?
Давайте по порядку. Предположим, что чуваков исходно всего 3. Вы согласны с моими доводами о том, почему "99, 0, 1" в таком кейсе гарантированно принимается?
Пусть осталось всего 3 чувака: В, Г, Д, и прямо сейчас будет делить В.
Д конечно может заранее сказать, что поддержит вариант, только если ему дают не менее двух монет. Заявив, что для него это прямо красная линия)) Но что, если В все равно предложит "99, 0, 1", поставив Д перед фактом и отрезав себе возможность поменять расклад? Теперь если Д пойдет на принцип и откажется, он остается ни с чем. Поэтому Д примет и такой вариант - получить хоть какие-то деньги для него важнее, чем "по-пацански ответить за базар" и отомстить за несправедливую дележку. Игрок В, понимая это, предлагает "99, 0, 1" и предложение прокатывает. Аналогично можно размотать и для 5 игроков.
У css-modules есть досадный минус: из коробки они плохо типизированы. Если написать import styles from './Comp.module.css'; , то styles оказывается просто Record<string, string>. Есть какие-то дополнительные нашлепки, которые генерят *.d.ts, но это так себе.
На текущем проекте используем vanilla-extract, вполне устраивает.
ТСО не добавляют в js, потому что смысла в этом нет. Если функция подходит для ТСО, то её проще и правильнее переписать на цикл. Тот же "хвостовой" факториал выглядит искусственно в сравнении с обычным: "технический" второй параметр, запутанная логика.
Странно конечно, что canvas всё равно выигрывает. Возможно потому, что там не "честные" глифы рисуют.
canvas вообще не рисует, у него есть метод, который просто измеряет размеры строки в пикселях, но там нельзя например задать ограничение по ширине, то есть никакого выравнивания он не делает. Потому и быстрый.
История про то, как внутри браузера реализована некая довольно полезная функциональность, но по каким-то причинам до сих пор нет нормального браузерного api к ней, и пришлось дублировать реализацию. Не в первый раз, кажется.
По поводу BlobUrlRegistry: перед закрытием/обновлением страницы очищать не обязательно, браузер сам всё удалит.
Судьба Мола - быть не понятым современниками. А может, ещё и потомками.
По той же причине, по которой что-либо в нулевой степени равно 1. Когда совсем нет множителей, остается нейтральный элемент (единица). Это справедливо не только для умножения, но и вообще для любых операций с наличием нейтрального элемента. Например, для логического "И" отсюда следует немного странный результат
Так если Г выскажется против, то дальше он остается с нулем, это я уже писал ранее. Значит именно этот вариант Б и предложит.
Зная об этом, Д и В поддержат 98-0-1-0-1.
Я, видимо, не понимаю идею. Опишите вариант, где кто-нибудь из игроков, кроме самого первого, может взять 2 монеты.
А толку с этой монетки? Г не имеет механизма, который бы ограничил ему свободный выбор - принимать или не принимать. Потому, как бы он ни понтовался заранее, он всё равно согласится на 1. Даже если подброшенная им монетка выпадет так, чтобы не брать.
Вот если бы такой неотменяемый самоограничивающий механизм для Г существовал, и Г успел его запустить до внесения предложения от Б - тогда да, уже Б был бы поставлен перед фактом.
Я всё-таки хочу попробовать рассмотреть 4 )
Итак, Б, В, Г, Д. Если игрок Б предлагает "99, 0, 1, 0", то игрок Г, ранее тоже размахивавший красными линиями, либо примет вариант, либо остается ни с чем (потому что "99, 0, 1", как установлено выше, гарантированно прокатывает). Поэтому он принимает такой вариант. Правильно?
Давайте по порядку. Предположим, что чуваков исходно всего 3. Вы согласны с моими доводами о том, почему "99, 0, 1" в таком кейсе гарантированно принимается?
Пусть осталось всего 3 чувака: В, Г, Д, и прямо сейчас будет делить В.
Д конечно может заранее сказать, что поддержит вариант, только если ему дают не менее двух монет. Заявив, что для него это прямо красная линия)) Но что, если В все равно предложит "99, 0, 1", поставив Д перед фактом и отрезав себе возможность поменять расклад? Теперь если Д пойдет на принцип и откажется, он остается ни с чем. Поэтому Д примет и такой вариант - получить хоть какие-то деньги для него важнее, чем "по-пацански ответить за базар" и отомстить за несправедливую дележку. Игрок В, понимая это, предлагает "99, 0, 1" и предложение прокатывает. Аналогично можно размотать и для 5 игроков.
currentColor широко используется в svg, он точно не забыт. Хотя вот я сейчас узнал, что можно не только в svg )
Дней медведевских прекрасное начало
То ли Гайдара, то ли Чубайса
У css-modules есть досадный минус: из коробки они плохо типизированы. Если написать
import styles from './Comp.module.css';, тоstylesоказывается просто Record<string, string>. Есть какие-то дополнительные нашлепки, которые генерят *.d.ts, но это так себе.На текущем проекте используем vanilla-extract, вполне устраивает.
ТСО не добавляют в js, потому что смысла в этом нет. Если функция подходит для ТСО, то её проще и правильнее переписать на цикл. Тот же "хвостовой" факториал выглядит искусственно в сравнении с обычным: "технический" второй параметр, запутанная логика.
Человек не может объективно оценивать период, в который он был молод, ностальгия неизменно измажет всё яркими красками.
canvas вообще не рисует, у него есть метод, который просто измеряет размеры строки в пикселях, но там нельзя например задать ограничение по ширине, то есть никакого выравнивания он не делает. Потому и быстрый.
А если держать на странице отдельный iframe с минимумом верстки, и измерять текст внутри него - это тоже будет долгий layout рефлоу?
История про то, как внутри браузера реализована некая довольно полезная функциональность, но по каким-то причинам до сих пор нет нормального браузерного api к ней, и пришлось дублировать реализацию. Не в первый раз, кажется.
По разному бывает. На моей прошлой работе, например, схему (в дополнение к ТЗ) составляли аналитики, натурально записывая файлы вручную.
Так я об этом и написал )