Можно определять как угодно. Но отказывается, что если рассматривать функцию f(x) = sin(x rad), как функцию безразмерной величины x, то для неё несколько достаточно важный утверждений принимают наиболее простой вид.
Это и первый замечательный предел sin(x) ~ x при малых x, и разложение синуса в ряд Макларена, и связь с (комплексной) экспонентой e^ix = cos(x) + i*sin(x).
Поэтому Вы либо считаете в радианах, либо у Вас во всяких таких формулах появляются всякие множители типа 2pi
Ну, так им не нужна была площадь под графиком. Им было нужно непрерывное суммирование. А оно возникает безотносительно понятия площади (и графиков).
Насколько мне известно, утверждения типа «смещение тела равно заметаемой площадью под графиком его скорости» опять же являются следствием теоремы о том, что площадь под графиком равна соответствующему интегралу. Или такие утверждения можно ещё как-то вывести?
Определённый интеграл - это семейство (линейных) функционалов. В частности, в крайнем случае можно рассматривать интеграл Даниеля - там даже не уточняется конкретный вид этих функционалов. В случае же Римановского интеграла - это не более чем предел интегральных сумм.
Интегралу правда можно придать геометрический смысл площади под графиком, но только в том случае, когда площадь прямоугольника/квадрата определена стандартным способом. Путаете причину и следствие
все проблемы вылезают тогда, когда они не используются.
Вопрос в дефолтах. Разница в том, что в расте проблемы нет, до тех пор пока пользователь явно не начнёт использовать unsafe.
Но основная фишка боровинга в том, что он позволяет выразить безопасный контракт. То, что внутри будет unsafe - не шибко важно. Важно, что в публичный интерфейс будет безопасным - как бы им не пользовались, проблем с памятью не будет.
Проблема не в setenv при вызове из раста. Проблема в том, что setenv может вызвать какой-то сишный код.
Т.е. внезапно, setenv вызывать безопастно, а вот getenv требует гарантии, что сишный код из другого потока не вызовет setenv. В отсутствии ffi вызовы getenv и setenv безопасны.
Плюс, хочется, всё же иметь интероп с сишным кодом - видеть изменения из сишного кода и прореагировать изменения в сишный код.
А как в дотнете решают эту проблему? Копируют весь environ при запуске?
К сожалению, поменяется. Возврат через ифы и раскрутка стока имеют незначительные, но всё же различия наблюдаемого поведения. Они не имеют значения сами по себе, но это сломает обратную совместимость.
Также не стоит забывать, что сбор стэктрейса – процесс весьма недешёвый. Поэтому обработку (штатных) ошибок имеет смысл делать без них (особенно в нагруженных местах). А для багов(=нештатных ошибок) использовать механизм исключений со стэктрейсом, как в Яве - вполне разумно. Но в тех же го и расте такой механизм есть - паники.
новых версиях языка лонгджамп нужно удалить и сделать реализацию на возвращаемых значениях
Как реализацию регекспов в плюсах сделали быстрее (не сделали – сломает abi)?
то в новых языках
А в новых так и делают. В том же zig есть call-trace - он автоматом генерирует «путь от места обработки до места возникновения».
В том же расте, тоже так. И, к слову, там на практике есть три варианта обработки ошибок: anyhow(со стэктрейсами, похожи на исключения), thiserror (фактически calltrace) и сырые легковесные ошибки. И чаще используются первые два варианта, а не третий, как Вы намекали выше.
Этой проблемой НЕ страдают системы с исключениями (ибо как правило язык с исключениями даёт возможность в исключении получить и распечатать стек вызова функций)
Мой опыт показывает, что баг чаще возникает в месте, вообще не связанном по стэку вызовов. Оно даже может быть выше функции foo, которая залогировала проблему.
Поэтому, стэктрейс помогает далеко не всегда, как Вы здесь утверждаете, а только в простых случаях. Не берусь утверждать, насколько простые случаи распространены – зависит от предметной области и YMMV.
И как уже писал выше, в других языках, как правило, есть инструменты для диагностики подобных простых случаев. Эти инструменты используются в хоть сколько-нибудь серьёзных проектах (если его не джуны пишут, которые языком пользоваться не умеют – но тут ничего не поделать)
События они же и есть данные - какая разница, будет ли приложение каждый раз создавать новый объект, или гонять туда-сюда один и тот же. Если не использовать === то это должно быть ненаблюдаемо. Вы же не пытаетесь сравнивать собития на равенство, да? (за исключением тестов).
Проблема с обратной совместимостью кажется надуманной: если у нас появились данные в событии - то разумно пробежаться по местам использования и предоставить там эти данные.
Если на вакансии вы увидите требование "знание линейной алгебры" у вас будут спрашивать …
Это просто так сложилось у 3D-шников, что они свои трюки с матрицами называют «линейной алгеброй».
Если такую же формулировку увидеть, например, у физиков, то они, скорее будут спрашивать про собственные значения и всякую эрмитовость. Про матрицы могут даже не спросить.
Именно это даёт профит, а не умение доказывать что это так и почему это так работает, и откуда берётся.
Практика показывает, что люди, которые умеют это доказывать, в среднем чуть лучше пишут 3D-шный код. Впрочем, это, чаще всего, не шибко важно и я не считаю, что это нужно знать, чтобы успешно писать код.
Какая оценка? Зачем? В подавляющем большинстве задач вы просто …
Это и есть оценка. И как было написано в начале, если распределение плохое, то такой подход будет врать. В таких ситуациях нужно использовать более хитрые оценки.
В остальной части комментария Вас куда-то понесло - проигнорирую эту часть.
Если мы каким-то образом узнали, что распределение имеет тяжёлые хвосты - то наша оценка скорее всего врёт. Большинство хороших оценок требует конечную дисперсию - а потому они неприменимы.
Разумеется, если задача ограничить реальный перцентиль, а не его оценку.
Ну вот выяснил я, что 99-перцентиль ответа — 420 мс. В требованиях написано, чтобы было 300 мс (или 500 мс). Как мне знание существования негауссовых распределений поможет?
Если в требованиях 300 мс - то ничем. Идём оптимизировать.
А если в требованиях 500 мс - то выбрасываем оценку в 420 мс и идём искать оценки, которые работают для текущего распределения.
Обратимые линейные операторы не образуют поле, за исключением тривиального случая - операторов над одномерным пространством. При вычитании можно получить нулевое собственное значение
Все туда пишут (вот прямо вообще все, без разбору), и вы назначаете ей три читателя: один читатель, который пишет все в файл, второй - перекидывает на удаленный сервер, а третий читатель выводин на консоль.
Только это broadcast очередь, а не mpmc. Если будет mpmc, то часть ошибок будет только в консоле, часть ошибок только в файле и часть ошибок только на сервере.
По сути своей, mpmc имеет смысл только для равноправных читателей (которые делают одно и то же). Поэтому весьма редкий зверь.
Проблема с использованием вектора в том, что он уничтожается при пробуждении вектора (mem::take заберёт вектор, а взамен поставит пустой). Поэтому в рабочем режиме будут постоянно происходить аллокации вектора (каждый раз заново). Рассуждения про удвоение размера в таком случае неприменимы.
Это можно починить, если использовать метод drain. В таком случае, из вектора будут забраны все элементы, но оставлена сама аллокация памяти. Это предотвратит походы в аллокатор памяти в рабочем режиме. Тем не менее, данная схема страдает от утечек: если один раз у нас образовалась большая очередь, то память мы никогда уже не вернём. Такие утечки в канале общего назначения могут быть неприемлемы.
Собственно решение предложенное в статье, позволяет избежать аллокаций, а также избежать утечек в описанном выше смысле.
P.S. На мой вкус, выбор решения в статье не до конца обоснован. Выглядит так, будто просто взяли решение, которое использует tokio, без оглядки на то, почему.
magic запускает лямбду в том, что вы назвали "горутиной"
Нет, magic выполняет лямбду в самом обычном потоке ОС, который создан через Раст/Си.
Горутиной я здесь называю те самые стекфулл таски, которые Вы предлагаете внедрить в интерпретатор питона.
Также я предполагаю, что в питоне передали всё на стеквфулл корутины, как Вы и предлагаете. Передали также сетевую библиотеку, чтобы она делала yield. И сделали так, что код по умолчанию исполняется в некой «горутине». Итого никаких async/await здесь нет и не должно быть.
Если сделать итог по используемым потокам, то у нас здесь есть 3 потока ОС:
Поток интерпретатора, на котором должны крутится все горутины
Два потока, которые спаунятся в расте.
В общем не вижу проблем в преобразовании данного кода в асинхронный
Меня в этом коде не интересует «преобразование его» в асинхронный. Меня интересует, что будет в этом коде происходить с Вашей моделью стекфул тасок/горутин, которую Вы предлагаете. Предположим она уже сделана и сетевая библиотека переписана.
если на этот момент существует s2.read() и ожидает данных из сокета и эти данные пришли, то управление будет пердано ему.
Сокета s2 не может быть в этот момент из-за мбтекса. В этом примере, в принципе, важно обратить внимание на то, что происходит в нативной части.
там мы видим thread::spawn, очевидно, что при переходе
Нет, по двум причинам сразу. Первая - как писал выше, нет задачи переделать на асинхронную парадигму. Вторая - нативного кода, который спаунит потоки ОС уже написано довольно много. Вы предлагаете переписать весь нативный код?
Подитожу: интересует, как этот код без изменений будет выполняться в Вашей модели - задачи и возможности его поменять нет.
Почитал вики по РС - там действительно несколько порождающих многочленов. Приведу краткую выжимку. @NickDoom
Берём конечное поле F, размера q - это наши передаваемые символы, они же байты.
Сообщения для передачи разбиваются на блоки размера k. Каждый блок рассматривается как многочлены степени не выше k, над полем F. Иными словами, блоку сопоставляются многочлен m(x), где коэффициент перед x^i будет i-ым символом(байтом) в блоке.
Далее рассматривается кольцо P многочленов над F, по модулю x^n - 1. Элементами этого кольца являются многочлены степени не выше n. Множество сообщений вкладывается в это пространство.
Кодовые слова, они же - закодированные блоки, представляются в виде многочленов из P. При этом, в отличии от сообщений, не всякий многочлен степени n является кодовым словом (т.е. не все многочлены могут получиться при кодировании). Множество тех многочленов, которые могут получиться при кодировании называют C.
При довольно общих соображениях, можно показать, что C является главным идеалом. То есть, есть такой многочлен g(x) из P, который делит все кодовые слова.
Тогда процесс кодирования выполняется просто умножением на g(x). Пусть у нас есть блок m(x), мы хотим его закодировать и получить кодовое слово c(x). Тогда c(x) = m(x)g(x).
Теперь можно разобраться с порождающими многочленами. Дело в том, что у нас есть два вида многочленов здесь. С одной стороны, у нас есть кольцо P многочленов p(x), с другой стороны, у нас есть конечное поле F, которое строиться через многочлены f(u). То есть, поле F задаётся как многочлены f(u) по модулю a(u).
Итого, у нас есть:
Порождающий многочлен a(u) поля F
Порождающий многочлен g(x) для идеала C - он же порождает сам код РС.
(Не сильно важно, но ещё есть порождающий многочлен x^n - 1 кольца P).
P.S. Замечу, что озвученная выше теория не является специфичной для кодов РС. Она верна для гораздо более широкого класса кодов - циклических кодов. Конкретно коды РС определяются особенным способом построения многочленов g(x).
Ну, sympy, скорее всего, делает всё же символьное дифференцирование.
За численным дифференцированием стоит идти в условный numpy.
Ну и на практике, более эффективным вариантом является autodiff в условныом pytorch/tf и прочем.
Можно определять как угодно. Но отказывается, что если рассматривать функцию f(x) = sin(x rad), как функцию безразмерной величины x, то для неё несколько достаточно важный утверждений принимают наиболее простой вид.
Это и первый замечательный предел sin(x) ~ x при малых x, и разложение синуса в ряд Макларена, и связь с (комплексной) экспонентой e^ix = cos(x) + i*sin(x).
Поэтому Вы либо считаете в радианах, либо у Вас во всяких таких формулах появляются всякие множители типа 2pi
Ну, так им не нужна была площадь под графиком. Им было нужно непрерывное суммирование. А оно возникает безотносительно понятия площади (и графиков).
Насколько мне известно, утверждения типа «смещение тела равно заметаемой площадью под графиком его скорости» опять же являются следствием теоремы о том, что площадь под графиком равна соответствующему интегралу. Или такие утверждения можно ещё как-то вывести?
Определённый интеграл - это семейство (линейных) функционалов. В частности, в крайнем случае можно рассматривать интеграл Даниеля - там даже не уточняется конкретный вид этих функционалов. В случае же Римановского интеграла - это не более чем предел интегральных сумм.
Интегралу правда можно придать геометрический смысл площади под графиком, но только в том случае, когда площадь прямоугольника/квадрата определена стандартным способом. Путаете причину и следствие
Вопрос в дефолтах. Разница в том, что в расте проблемы нет, до тех пор пока пользователь явно не начнёт использовать unsafe.
Но основная фишка боровинга в том, что он позволяет выразить безопасный контракт. То, что внутри будет unsafe - не шибко важно. Важно, что в публичный интерфейс будет безопасным - как бы им не пользовались, проблем с памятью не будет.
Проблема не в setenv при вызове из раста. Проблема в том, что setenv может вызвать какой-то сишный код.
Т.е. внезапно, setenv вызывать безопастно, а вот getenv требует гарантии, что сишный код из другого потока не вызовет setenv. В отсутствии ffi вызовы getenv и setenv безопасны.
Плюс, хочется, всё же иметь интероп с сишным кодом - видеть изменения из сишного кода и прореагировать изменения в сишный код.
А как в дотнете решают эту проблему? Копируют весь environ при запуске?
То же, что мешает сделать альтернативную libc на маке…
К сожалению, поменяется. Возврат через ифы и раскрутка стока имеют незначительные, но всё же различия наблюдаемого поведения. Они не имеют значения сами по себе, но это сломает обратную совместимость.
Также не стоит забывать, что сбор стэктрейса – процесс весьма недешёвый. Поэтому обработку (штатных) ошибок имеет смысл делать без них (особенно в нагруженных местах). А для багов(=нештатных ошибок) использовать механизм исключений со стэктрейсом, как в Яве - вполне разумно. Но в тех же го и расте такой механизм есть - паники.
Как реализацию регекспов в плюсах сделали быстрее (не сделали – сломает abi)?
А в новых так и делают. В том же zig есть call-trace - он автоматом генерирует «путь от места обработки до места возникновения».
В том же расте, тоже так. И, к слову, там на практике есть три варианта обработки ошибок: anyhow(со стэктрейсами, похожи на исключения), thiserror (фактически calltrace) и сырые легковесные ошибки. И чаще используются первые два варианта, а не третий, как Вы намекали выше.
Мой опыт показывает, что баг чаще возникает в месте, вообще не связанном по стэку вызовов. Оно даже может быть выше функции foo, которая залогировала проблему.
Поэтому, стэктрейс помогает далеко не всегда, как Вы здесь утверждаете, а только в простых случаях. Не берусь утверждать, насколько простые случаи распространены – зависит от предметной области и YMMV.
И как уже писал выше, в других языках, как правило, есть инструменты для диагностики подобных простых случаев. Эти инструменты используются в хоть сколько-нибудь серьёзных проектах (если его не джуны пишут, которые языком пользоваться не умеют – но тут ничего не поделать)
Так а в чём именно проблема-то?
События они же и есть данные - какая разница, будет ли приложение каждый раз создавать новый объект, или гонять туда-сюда один и тот же.
Если не использовать
===то это должно быть ненаблюдаемо.Вы же не пытаетесь сравнивать собития на равенство, да? (за исключением тестов).
Проблема с обратной совместимостью кажется надуманной: если у нас появились данные в событии - то разумно пробежаться по местам использования и предоставить там эти данные.
Это просто так сложилось у 3D-шников, что они свои трюки с матрицами называют «линейной алгеброй».
Если такую же формулировку увидеть, например, у физиков, то они, скорее будут спрашивать про собственные значения и всякую эрмитовость. Про матрицы могут даже не спросить.
Практика показывает, что люди, которые умеют это доказывать, в среднем чуть лучше пишут 3D-шный код. Впрочем, это, чаще всего, не шибко важно и я не считаю, что это нужно знать, чтобы успешно писать код.
Это и есть оценка. И как было написано в начале, если распределение плохое, то такой подход будет врать. В таких ситуациях нужно использовать более хитрые оценки.
В остальной части комментария Вас куда-то понесло - проигнорирую эту часть.
Если мы каким-то образом узнали, что распределение имеет тяжёлые хвосты - то наша оценка скорее всего врёт. Большинство хороших оценок требует конечную дисперсию - а потому они неприменимы.
Разумеется, если задача ограничить реальный перцентиль, а не его оценку.
Если в требованиях 300 мс - то ничем. Идём оптимизировать.
А если в требованиях 500 мс - то выбрасываем оценку в 420 мс и идём искать оценки, которые работают для текущего распределения.
Обратимые линейные операторы не образуют поле, за исключением тривиального случая - операторов над одномерным пространством. При вычитании можно получить нулевое собственное значение
Там пример слишком упростили. Хотели, вероятно, сделать классический пример очистки ресурсов:
Такой паттерн, по сути, RAII руками - доволно часто встречается.
Только это broadcast очередь, а не mpmc. Если будет mpmc, то часть ошибок будет только в консоле, часть ошибок только в файле и часть ошибок только на сервере.
По сути своей, mpmc имеет смысл только для равноправных читателей (которые делают одно и то же). Поэтому весьма редкий зверь.
Проблема с использованием вектора в том, что он уничтожается при пробуждении вектора (mem::take заберёт вектор, а взамен поставит пустой). Поэтому в рабочем режиме будут постоянно происходить аллокации вектора (каждый раз заново). Рассуждения про удвоение размера в таком случае неприменимы.
Это можно починить, если использовать метод drain. В таком случае, из вектора будут забраны все элементы, но оставлена сама аллокация памяти. Это предотвратит походы в аллокатор памяти в рабочем режиме. Тем не менее, данная схема страдает от утечек: если один раз у нас образовалась большая очередь, то память мы никогда уже не вернём. Такие утечки в канале общего назначения могут быть неприемлемы.
Собственно решение предложенное в статье, позволяет избежать аллокаций, а также избежать утечек в описанном выше смысле.
P.S. На мой вкус, выбор решения в статье не до конца обоснован. Выглядит так, будто просто взяли решение, которое использует tokio, без оглядки на то, почему.
Нет, magic выполняет лямбду в самом обычном потоке ОС, который создан через Раст/Си.
Горутиной я здесь называю те самые стекфулл таски, которые Вы предлагаете внедрить в интерпретатор питона.
Также я предполагаю, что в питоне передали всё на стеквфулл корутины, как Вы и предлагаете. Передали также сетевую библиотеку, чтобы она делала yield. И сделали так, что код по умолчанию исполняется в некой «горутине». Итого никаких async/await здесь нет и не должно быть.
Если сделать итог по используемым потокам, то у нас здесь есть 3 потока ОС:
Поток интерпретатора, на котором должны крутится все горутины
Два потока, которые спаунятся в расте.
Меня в этом коде не интересует «преобразование его» в асинхронный. Меня интересует, что будет в этом коде происходить с Вашей моделью стекфул тасок/горутин, которую Вы предлагаете. Предположим она уже сделана и сетевая библиотека переписана.
Сокета s2 не может быть в этот момент из-за мбтекса. В этом примере, в принципе, важно обратить внимание на то, что происходит в нативной части.
Нет, по двум причинам сразу. Первая - как писал выше, нет задачи переделать на асинхронную парадигму. Вторая - нативного кода, который спаунит потоки ОС уже написано довольно много. Вы предлагаете переписать весь нативный код?
Подитожу: интересует, как этот код без изменений будет выполняться в Вашей модели - задачи и возможности его поменять нет.
Почитал вики по РС - там действительно несколько порождающих многочленов. Приведу краткую выжимку. @NickDoom
Берём конечное поле F, размера q - это наши передаваемые символы, они же байты.
Сообщения для передачи разбиваются на блоки размера k. Каждый блок рассматривается как многочлены степени не выше k, над полем F. Иными словами, блоку сопоставляются многочлен m(x), где коэффициент перед x^i будет i-ым символом(байтом) в блоке.
Далее рассматривается кольцо P многочленов над F, по модулю x^n - 1. Элементами этого кольца являются многочлены степени не выше n. Множество сообщений вкладывается в это пространство.
Кодовые слова, они же - закодированные блоки, представляются в виде многочленов из P. При этом, в отличии от сообщений, не всякий многочлен степени n является кодовым словом (т.е. не все многочлены могут получиться при кодировании). Множество тех многочленов, которые могут получиться при кодировании называют C.
При довольно общих соображениях, можно показать, что C является главным идеалом. То есть, есть такой многочлен g(x) из P, который делит все кодовые слова.
Тогда процесс кодирования выполняется просто умножением на g(x). Пусть у нас есть блок m(x), мы хотим его закодировать и получить кодовое слово c(x). Тогда c(x) = m(x)g(x).
Теперь можно разобраться с порождающими многочленами. Дело в том, что у нас есть два вида многочленов здесь. С одной стороны, у нас есть кольцо P многочленов p(x), с другой стороны, у нас есть конечное поле F, которое строиться через многочлены f(u). То есть, поле F задаётся как многочлены f(u) по модулю a(u).
Итого, у нас есть:
Порождающий многочлен a(u) поля F
Порождающий многочлен g(x) для идеала C - он же порождает сам код РС.
(Не сильно важно, но ещё есть порождающий многочлен x^n - 1 кольца P).
P.S. Замечу, что озвученная выше теория не является специфичной для кодов РС. Она верна для гораздо более широкого класса кодов - циклических кодов. Конкретно коды РС определяются особенным способом построения многочленов g(x).