В последних примерах as необязательный, в этом случае лучше указывать дефолтное значение для T (например, если по умолчанию используется "button", то должно быть T extends ElementType = "button"), чтобы TS мог определять пропы при незаполненном as
Насчет конфликта пропов: можно упороться и сделать проверялку для as. Например, если мы просто не передаем все "свои" пропы в переданный компонент (а только используем сами), то нельзя передать в as такой компонент, у которого хотя бы один из этих пропов обязательный. Примерно так: https://tsplay.dev/N94q1w Соответственно, при добавлении "общих" пропов, например className, их тоже надо будет исключить из проверки
Примеры 2 и 3 - это "mapping type", а не дистрибуция (во втором ещё и лишняя проверка T[K], есть же ограничение на T)
Кстати, в mapping type есть механизм, аналогичный дистрибуции, если итерируемся по ключам "локального типа" в генерике: https://tsplay.dev/mprVMw - здесь мэппинг по отдельности обработал все элементы объединения, причем кортеж сохранил форму, а примитивы не поменялись.
Как отмечает Диков, перед решением задания студенты много времени тратят на перевод условий задачи. Это тормозит процесс обучения. В ПГУ перевели десятки заданий и выпустили два сборника, чтобы учащиеся могли сосредоточиться на самом задании, а не на переводе.
Я может чего не понимаю, но вроде бы можно было ограничиться переводом заданий. Зачем они полезли со словарем в синтаксис?
Для симуляции проще всего так сделать. Пусть окружность длиной 1. Строим последовательно многоугольник. Если мы ещё не поймали центр круга, значит пока что все вершины "скучковались" на дуге длиной Х < 0.5, слева и справа к ней примыкают дуги длиной Y, так что X+Y+Y = 1. Получаем очередной рандом R от 0 до 1, и если R < Y, то к длине X прибавляем R, иначе если 1 - R < Y, то к длине X прибавляем 1 - R. И так пока не станет X > 0.5 либо не закончатся вершины.
Но можно и аналитически решить, с выводом формулы для вероятности. Первую вершину просто поместим в 0 - некую "начальную" точку на окружности. Позицию i-й вершины определяем как a * 0.5 + b, где а - рандомно 0 или 1, b - рандомно от 0 до 0.5 (для первой вершины оба этих числа равны 0). Далее если отсортировать вершины по их значениям b и пронумеровать в таком порядке, то можно заметить, что они собраны на дуге длиной менее 0.5 (то есть центр круга вне многоугольника) только в том случае, если их значения "а" в этом же порядке выглядят как 0,0,....,0,1,1,...,1, где количество единиц от 0 до N-1. Таких последовательностей всего N штук, то есть вероятность, что мы НЕ поймали центр круга, равна N / 2^(N-1)
Довольно спорный плагин. Я согласен насчет поинта про "сохранение намерений", часто, имея на руках объект, думаешь, а можно ли некоторый его метод передать в колбэк. Но плагин здесь не даст каких-то гарантий, если мы в переменную своего интерфейса принимаем некий посторонний объект, который непонятно как и где был создан. Имхо, тут пока не появится в самом TS поддержка "функций, которые можно передавать в колбэк" (или нельзя, в общем чтобы их как-то различать), то остальное малоэффективно.
С другой стороны, вид функции внутри интерфейса тоже выбирается по своим надобностям, которые никак не пересекаются с таковыми в js (в реализации). Почти всегда лучше использовать стрелочный вариант, потому что нестрелочный бивариантен по параметрам и может выкинуть сюрприз. У нестрелочных зато есть свои фичи, которые могут понадобиться наверно в 0.1% кейсов.
А в классах зачастую хочется "синтаксис метода", для экономности и нужд наследования, если заведомо известно, что будем вызывать напрямую.
Поэтому плагин, который будет принудительно связывать одно с другим, добавит головной боли, имхо.
Вот, прикинул. Если нигде не ошибся, то касательная дает оптимальный результат.
Малая окружность - куда заяц доплыл на первом этапе, теперь он в точке В, волк в точке А, угол АОВ чуть меньше 180 (ровно 180 не получится, это предел), значение х - угол ВОС в радианах, далее они стартуют одновременно и встретятся в точке С (волк по синей линии, заяц по красной). Мы определяем число К - во сколько раз волк быстрее лодки, в зависимости от угла х, то есть К(х). Значение х от 0 до чуть меньше Пи/2. Радиус малой окружности равен 1, большой - К. Длина пути волка L = K * (Pi + x), а длина пути зайца, по теореме косинусов, d = sqrt(1 + K^2 - 2K * cos(x)). Из соотношения скоростей должно быть L = K*d, далее подставляем формулы, сокращаем, решаем кв. уравнение, в итоге получилось K = cos(x) + sqrt(-1 + (cos(x))^2 + (Pi + x)^2)
Я просто вбил эту формулу в wolframalpha, экстремум оказался как раз при x = 1.35047..., при этом К = 4.60334..., ну и легко посчитать, что угол АВС равен 90 гр. для этих значений
И вот тут нужно считать, есть ли такая прямая траектория
Ну собственно да, задача об этом. Эта прямая идет по касательной к "малой" окружности (радиуса R/k, где k - во сколько раз волк быстрее лодки), на которую заяц выходит в первом этапе. И там, составив несложное уравнение, определяем предельное максимально возможное k, оно будет 4.6033..., некое иррациональное число
Вот что вспомнил: задача про волка и зайца. Заяц плавает в лодке по круглому озеру и прямо сейчас находится в его центре. Волк на берегу. Волк бегает в 4.6 раза быстрее скорости лодки, но заяц бегает быстрее волка, ему достаточно выбраться на сушу, чтобы сбежать. Как зайцу причалить к берегу, чтобы там не было волка?
бекреференсы (backreference) использовать не получится.
Видимо, есть какой-то обходной путь, потому что например регексовый движок в Сафари умеет в бекреференсы, но не боится плохих регулярок (даже если они содержат backreference)
Задачу с монетами публиковали на Хабре наверно раз 8. Но почему-то всегда описывают пошаговый алгоритм со всеми ветвями. А надо лишь рассмотреть первое взвешивание и его два возможных исхода. Пусть у нас Q(n) = (3^n + 1)/2 монет, и одна настоящая. Взвешиваем (3^(n-1) + 1)/2 монет против (3^(n-1) - 1)/2 + настоящая
1) Весы поровну. Фальшивая среди оставшихся (3^(n-1) + 1)/2 монет, переход к задаче для Q(n-1)
2) Весы накренились. Имеем набор из 3^(n-1) монет, часть из них "предположительно тяжелые" (которые уехали вниз), другая часть - "предположительно лёгкие". Далее такой комплект всегда можно разделить на 3 равные части, так что в двух частях будет A "легких" и B "тяжелых". Эти две одинаковые по пропорциям части сравниваем, если равны то остается третья, если весы накренились, берем "тяжелые" снизу и "легкие" сверху, в любом случае уменьшив число подозреваемых в 3 раза. И т.д.
Можно ещё упомянуть, что у спредов с квадратными скобками под капотом лежит механизм итерации, а с фигурными - доступ по перечисляемым индексам. Различие можно увидеть на примере [...'👍'] против {...'👍'}. У строк есть и то и другое, но работает слегка по разному
Ну, скорее всего, запретят. И заочно арестуют всех участников.
В последних примерах
asнеобязательный, в этом случае лучше указывать дефолтное значение для T (например, если по умолчанию используется "button", то должно бытьT extends ElementType = "button"), чтобы TS мог определять пропы при незаполненномasНасчет конфликта пропов: можно упороться и сделать проверялку для
as. Например, если мы просто не передаем все "свои" пропы в переданный компонент (а только используем сами), то нельзя передать вasтакой компонент, у которого хотя бы один из этих пропов обязательный. Примерно так: https://tsplay.dev/N94q1w Соответственно, при добавлении "общих" пропов, например className, их тоже надо будет исключить из проверкиПоследние более-менее честные выборы в РФ были в декабре 95 года, так что скоро уже 30 лет
Оно ещё и "движение", наверняка направлено на подрыв существующего строя
Примеры 2 и 3 - это "mapping type", а не дистрибуция (во втором ещё и лишняя проверка T[K], есть же ограничение на T)
Кстати, в mapping type есть механизм, аналогичный дистрибуции, если итерируемся по ключам "локального типа" в генерике: https://tsplay.dev/mprVMw - здесь мэппинг по отдельности обработал все элементы объединения, причем кортеж сохранил форму, а примитивы не поменялись.
Я может чего не понимаю, но вроде бы можно было ограничиться переводом заданий. Зачем они полезли со словарем в синтаксис?
То, что найдено как "typescript", добавляется автоматом к js?
Для симуляции проще всего так сделать. Пусть окружность длиной 1. Строим последовательно многоугольник. Если мы ещё не поймали центр круга, значит пока что все вершины "скучковались" на дуге длиной Х < 0.5, слева и справа к ней примыкают дуги длиной Y, так что X+Y+Y = 1. Получаем очередной рандом R от 0 до 1, и если R < Y, то к длине X прибавляем R, иначе если 1 - R < Y, то к длине X прибавляем 1 - R. И так пока не станет X > 0.5 либо не закончатся вершины.
Но можно и аналитически решить, с выводом формулы для вероятности. Первую вершину просто поместим в 0 - некую "начальную" точку на окружности. Позицию i-й вершины определяем как a * 0.5 + b, где а - рандомно 0 или 1, b - рандомно от 0 до 0.5 (для первой вершины оба этих числа равны 0). Далее если отсортировать вершины по их значениям b и пронумеровать в таком порядке, то можно заметить, что они собраны на дуге длиной менее 0.5 (то есть центр круга вне многоугольника) только в том случае, если их значения "а" в этом же порядке выглядят как 0,0,....,0,1,1,...,1, где количество единиц от 0 до N-1. Таких последовательностей всего N штук, то есть вероятность, что мы НЕ поймали центр круга, равна N / 2^(N-1)
Меня в Реакте ужасает только forwardRef. Остальное в принципе съедобно.
Стрелочные функции в классах как раз и нужны для привязки this, чтобы не возиться с bind. Но да, любой такой подход создает по функции на экземпляр.
подозреваю, что такое предложение уже пылится в ишьюсах репозитория ts
Довольно спорный плагин. Я согласен насчет поинта про "сохранение намерений", часто, имея на руках объект, думаешь, а можно ли некоторый его метод передать в колбэк. Но плагин здесь не даст каких-то гарантий, если мы в переменную своего интерфейса принимаем некий посторонний объект, который непонятно как и где был создан. Имхо, тут пока не появится в самом TS поддержка "функций, которые можно передавать в колбэк" (или нельзя, в общем чтобы их как-то различать), то остальное малоэффективно.
С другой стороны, вид функции внутри интерфейса тоже выбирается по своим надобностям, которые никак не пересекаются с таковыми в js (в реализации). Почти всегда лучше использовать стрелочный вариант, потому что нестрелочный бивариантен по параметрам и может выкинуть сюрприз. У нестрелочных зато есть свои фичи, которые могут понадобиться наверно в 0.1% кейсов.
А в классах зачастую хочется "синтаксис метода", для экономности и нужд наследования, если заведомо известно, что будем вызывать напрямую.
Поэтому плагин, который будет принудительно связывать одно с другим, добавит головной боли, имхо.
Вот, прикинул. Если нигде не ошибся, то касательная дает оптимальный результат.
Малая окружность - куда заяц доплыл на первом этапе, теперь он в точке В, волк в точке А, угол АОВ чуть меньше 180 (ровно 180 не получится, это предел), значение
х- угол ВОС в радианах, далее они стартуют одновременно и встретятся в точке С (волк по синей линии, заяц по красной). Мы определяем числоК- во сколько раз волк быстрее лодки, в зависимости от углах, то естьК(х). Значение х от 0 до чуть меньше Пи/2. Радиус малой окружности равен 1, большой - К. Длина пути волкаL = K * (Pi + x), а длина пути зайца, по теореме косинусов,d = sqrt(1 + K^2 - 2K * cos(x)). Из соотношения скоростей должно бытьL = K*d, далее подставляем формулы, сокращаем, решаем кв. уравнение, в итоге получилосьK = cos(x) + sqrt(-1 + (cos(x))^2 + (Pi + x)^2)Я просто вбил эту формулу в wolframalpha, экстремум оказался как раз при x = 1.35047..., при этом К = 4.60334..., ну и легко посчитать, что угол АВС равен 90 гр. для этих значений
Ну собственно да, задача об этом. Эта прямая идет по касательной к "малой" окружности (радиуса R/k, где k - во сколько раз волк быстрее лодки), на которую заяц выходит в первом этапе. И там, составив несложное уравнение, определяем предельное максимально возможное k, оно будет 4.6033..., некое иррациональное число
Вот что вспомнил: задача про волка и зайца. Заяц плавает в лодке по круглому озеру и прямо сейчас находится в его центре. Волк на берегу. Волк бегает в 4.6 раза быстрее скорости лодки, но заяц бегает быстрее волка, ему достаточно выбраться на сушу, чтобы сбежать. Как зайцу причалить к берегу, чтобы там не было волка?
перед моим входом в комнату, бутылку развернули на 180?
Видимо, есть какой-то обходной путь, потому что например регексовый движок в Сафари умеет в бекреференсы, но не боится плохих регулярок (даже если они содержат backreference)
Задачу с монетами публиковали на Хабре наверно раз 8. Но почему-то всегда описывают пошаговый алгоритм со всеми ветвями. А надо лишь рассмотреть первое взвешивание и его два возможных исхода. Пусть у нас Q(n) = (3^n + 1)/2 монет, и одна настоящая. Взвешиваем (3^(n-1) + 1)/2 монет против (3^(n-1) - 1)/2 + настоящая
1) Весы поровну. Фальшивая среди оставшихся (3^(n-1) + 1)/2 монет, переход к задаче для Q(n-1)
2) Весы накренились. Имеем набор из 3^(n-1) монет, часть из них "предположительно тяжелые" (которые уехали вниз), другая часть - "предположительно лёгкие". Далее такой комплект всегда можно разделить на 3 равные части, так что в двух частях будет A "легких" и B "тяжелых". Эти две одинаковые по пропорциям части сравниваем, если равны то остается третья, если весы накренились, берем "тяжелые" снизу и "легкие" сверху, в любом случае уменьшив число подозреваемых в 3 раза. И т.д.
Шутки шутками, но иногда возникает мысль, что Реакт не запретили просто потому, что в Думе о нем не знают
Там замена (c , b) -> lcm, а оно имеет общие делители с "а", если gcd(a, c) > 1
Можно ещё упомянуть, что у спредов с квадратными скобками под капотом лежит механизм итерации, а с фигурными - доступ по перечисляемым индексам. Различие можно увидеть на примере
[...'👍']против{...'👍'}. У строк есть и то и другое, но работает слегка по разному