Как насчет многократного разбухания очереди тестов на CI? Пока были отдельные репозитории — при коммите в проект гонялись только тесты этого проекта. С монорепозиторием — каждый коммит по-умолчанию будет запускать тесты всех-всех проектов.
Математикам и физикам не нужны именно двоичные расчеты. Им нужны либо приближенные расчеты, либо точные.
Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет "под капотом" — им всё равно.
Для точных же вычислений нужно, чтобы при невозможности точного представления числа система явном образом сообщала об этом либо чтобы вообще не допускала ситуацию, когда потеря точности возможна. Но эта задача к обсуждаемой к теме не относится.
Конкретно двоичная арифметика нужна, например, в криптографии. Но в первую очередь потому как современная криптография вся построена вокруг двоичной аппаратной базы. Да и требуется там обычно только целочисленная арифметика. Опять мимо.
Как только оказывается, что fixed point вам не подходит (так как в одном типе могут быть и очень большие и очень маленькие значения), то сразу появляется необходимость постоянно контролировать положение точки, следить за переполнением и т.д. В конечном счете получаете в том или ином виде эмуляцию десятичной арифметики с плавающей запятой.
Пример проблемной ситуации: вам хочется в одном типе данных хранить суммы в Биткоинах (в том числе очень маленькие значения, 0.00000001 и меньше) и в Зимбабвийских долларах (очень большие значения, триллиарды и больше). Fixed point с целым числом вам не подойдет — ему не хватит значащих цифр (19 десятичных значащих цифр в эквиваленте для int64).
Все финансовые расчеты, весь бухгалтерский учет по-хорошему должен делаться в десятичной арифметике с использованием правил десятичного округления, а не двоичного. Сейчас ради этого при выполнении финансовых расчетов идут на всяческие ухищрения (используют высокоуровневые эмуляции того или иного рода).
Вообще говоря, двоичные вычисления как раз почти никому не нужны. Просто в подавляющем большинстве задач детали округления и количество значащих цифр в результате не очень существенны, поэтому особой разницы в том, была ли использована двоичная или десятичная арифметика нет и поэтому все привыкли относиться к двоичным вычислениям, которые нам обычно предлагают по-умолчанию, как к чему-то самом собой разумеющемуся или даже "единственно правильному".
ведь и диапазон значений очень сильно урезается
Нет, не сильно. IEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая. См. вики.
только вот IEE 754 реализован в железе практически везде
Чуть-чуть повздыхаю: в железе практически везде реализована часть IEE 754, а именно бинарные типы. Что же касается таких типов как decimal32, decimal64, decimal128, то они реализованы в относительно экзотических процессорах (POWER и RISC-V). Так что сейчас если хочется честной десятичной арифметики, то приходится так или иначе прибегать к эмуляции. Несмотря на то, что в IEE 754 нужные типы как бы есть.
Во-первых, в докладе может и есть, но в статье выше про это ни слова.
Во-вторых, вполне может быть (и даже скорее всего), что раскрытие HTTPS идет именно по схеме, которую я описал выше, а со стороны СОРМ-а у провайдеров и операторов мобильной связи подтягивается информация типа номера телефона, IMEI, привязанное ФИО и т.д. Т.е. СОРМ присутствует и у провайдеров, и в дата-центрах.
Еще вариант проще: на входе в сеть mail.ru (и ICQ) стоят балансировщики (вероятно аппаратные), которые и оборачивают трафик в HTTPS для клиентов; внутри же сети ходит нешифрованный HTTP-трафик. СОРМ работает внутри сети и видит уже расшифрованный трафик. Никаких ключей при этом СОРМу не нужно.
Вы передали в функцию первым аргументом экземпляр класса, т.е. явно ей сказали: вот тебе объект, работай с ним. Где здесь как-то используется знание функции о том, что она относится к какому-то классу?
При попытке такого вызова вы немедленно получите ClassCastException или какой-нибудь InvocationException. Непосредственно сделать вызов — не выйдет (к счастью).
один вопрос — на… зачем?
Пример с таким вызовом — всего лишь способ показать фундаментальное различие между обсуждаемыми ЯП.
«self» в Питоне — это просто параметр функции. Вы его можете даже переименовать, например в «foobar» и ничего не поменяется. А в Java «this» — это ключевое слово языка, которое всегда ссылается на объект, к которому относится метод.
В Python же «встроенной» ссылки на текущий объект нету, так как в Питоне методы класса — это на самом деле обычные функции, которые фактически ничего не знают про то, что они привязаны к какому-то классу. Просто Питон при вызове метода на экземпляре класса передает в функцию первым аргументом ссылку на этот объект.
Из-за такой особенности Питона, в частности, возможны всякие «грязные трюки » вроде вызова метода одного класса в контексте экземпляра совсем другого класса, что в Java в принципе невозможно (и к лучшему).
У автора каким-то магическим образом использование монорепозитория решает проблему внесения ломающих изменений в API системы.
Вот допустим, что в случае монорепозитория разработчик обновил весь код репозитория на измененное API. Сборка проходит нормально, тесты тоже. Что мы получим при деплое обновленного приложения? Правильно, всё развалится, если мы не выкатываем ВСЕ приложения синхронно.
Во-вторых, почему вообще внесение ломающих изменений в используемый API рассматривается как норма? Обычно наоборот — если у API появились пользователи, то можно только расширять совместимым образом, но не изменять то, что есть.
Если мне не изменяет память, то для более-менее нормально распределенных величин уже при выборке из 100 элементов ожидаемое отклонение расчетного среднего от истинного среднего сильно меньше одного процента.
Другое дело, что, судя по графикам, не помешало бы больше «тестовых аудиторий». Но этот параметр не связан напрямую с числом тестируемых.
Ну вы как бы целиком там читайте. Из Телеграма они вытащили только то, что собеседники обвиняемого сами дали. А из ватсапа — получили всё сразу, так как была синхронизация в iCloud.
Вот вы говорите, что «REST API» — это стандарт. Если так, то где его четкое определение, где спека? Где разбор любых нетривиальных случаев?
Ах да, вы ссылаетесь на спеку по HTTP. Да вот незадача: та спека совсем не про REST. И не про JSON. И не про то, как правильно завернуть произвольный RPC API в связку HTTP+JSON в качестве транспорта.
Как насчет многократного разбухания очереди тестов на CI? Пока были отдельные репозитории — при коммите в проект гонялись только тесты этого проекта. С монорепозиторием — каждый коммит по-умолчанию будет запускать тесты всех-всех проектов.
"дебажный" → "отладочный"
Я бы не сказал, что 11 лет — это "новый формат". У тех же Intel и AMD за это время сменилось не одно поколение процессоров.
Математикам и физикам не нужны именно двоичные расчеты. Им нужны либо приближенные расчеты, либо точные.
Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет "под капотом" — им всё равно.
Для точных же вычислений нужно, чтобы при невозможности точного представления числа система явном образом сообщала об этом либо чтобы вообще не допускала ситуацию, когда потеря точности возможна. Но эта задача к обсуждаемой к теме не относится.
Конкретно двоичная арифметика нужна, например, в криптографии. Но в первую очередь потому как современная криптография вся построена вокруг двоичной аппаратной базы. Да и требуется там обычно только целочисленная арифметика. Опять мимо.
Как только оказывается, что fixed point вам не подходит (так как в одном типе могут быть и очень большие и очень маленькие значения), то сразу появляется необходимость постоянно контролировать положение точки, следить за переполнением и т.д. В конечном счете получаете в том или ином виде эмуляцию десятичной арифметики с плавающей запятой.
Пример проблемной ситуации: вам хочется в одном типе данных хранить суммы в Биткоинах (в том числе очень маленькие значения, 0.00000001 и меньше) и в Зимбабвийских долларах (очень большие значения, триллиарды и больше). Fixed point с целым числом вам не подойдет — ему не хватит значащих цифр (19 десятичных значащих цифр в эквиваленте для int64).
Все финансовые расчеты, весь бухгалтерский учет по-хорошему должен делаться в десятичной арифметике с использованием правил десятичного округления, а не двоичного. Сейчас ради этого при выполнении финансовых расчетов идут на всяческие ухищрения (используют высокоуровневые эмуляции того или иного рода).
Вообще говоря, двоичные вычисления как раз почти никому не нужны. Просто в подавляющем большинстве задач детали округления и количество значащих цифр в результате не очень существенны, поэтому особой разницы в том, была ли использована двоичная или десятичная арифметика нет и поэтому все привыкли относиться к двоичным вычислениям, которые нам обычно предлагают по-умолчанию, как к чему-то самом собой разумеющемуся или даже "единственно правильному".
Нет, не сильно. IEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая. См. вики.
Во-вторых, вполне может быть (и даже скорее всего), что раскрытие HTTPS идет именно по схеме, которую я описал выше, а со стороны СОРМ-а у провайдеров и операторов мобильной связи подтягивается информация типа номера телефона, IMEI, привязанное ФИО и т.д. Т.е. СОРМ присутствует и у провайдеров, и в дата-центрах.
Пример с таким вызовом — всего лишь способ показать фундаментальное различие между обсуждаемыми ЯП.
В Python же «встроенной» ссылки на текущий объект нету, так как в Питоне методы класса — это на самом деле обычные функции, которые фактически ничего не знают про то, что они привязаны к какому-то классу. Просто Питон при вызове метода на экземпляре класса передает в функцию первым аргументом ссылку на этот объект.
Из-за такой особенности Питона, в частности, возможны всякие «грязные трюки » вроде вызова метода одного класса в контексте экземпляра совсем другого класса, что в Java в принципе невозможно (и к лучшему).
Вот допустим, что в случае монорепозитория разработчик обновил весь код репозитория на измененное API. Сборка проходит нормально, тесты тоже. Что мы получим при деплое обновленного приложения? Правильно, всё развалится, если мы не выкатываем ВСЕ приложения синхронно.
Во-вторых, почему вообще внесение ломающих изменений в используемый API рассматривается как норма? Обычно наоборот — если у API появились пользователи, то можно только расширять совместимым образом, но не изменять то, что есть.
Если мне не изменяет память, то для более-менее нормально распределенных величин уже при выборке из 100 элементов ожидаемое отклонение расчетного среднего от истинного среднего сильно меньше одного процента.
Другое дело, что, судя по графикам, не помешало бы больше «тестовых аудиторий». Но этот параметр не связан напрямую с числом тестируемых.
Ах да, вы ссылаетесь на спеку по HTTP. Да вот незадача: та спека совсем не про REST. И не про JSON. И не про то, как правильно завернуть произвольный RPC API в связку HTTP+JSON в качестве транспорта.