У нас это был годовой курсовик на 3 курсе. Команд было поменьше, кажется,4 штуки - сложение, условный переход, безусловный переход и еще что-то. И делали не в железе, а в специальной программе для симуляции.
Линейно возрастающее магнитное поле будет вызывать постоянное электрическое поле. Просто это нециклический процесс, поэтому его неудобно использовать в обычном оборудовании.
Напомнило ситуацию, когда для поля person_mnames.mname надо было различать NULL, хранящийся в приджойненной записи, и NULL, возникший из-за неприджойненной записи.
В таких обзорах зачастую не хватает ещё одного фактора - способности открыть большой файл (хотя бы 4-8 ГБ) и, как подвариант, открыть файл размером более оперативной памяти.
Вот Notepad++ такое не умеет. Приходится пользоваться FAR-ом, хотя в целом он менее удобен для меня.
В стандарте IEEE 754 описаны только двоичные и десятичные числа. Чисел по основанию Пи там нет.
Да и у большинства компиляторов для числовых литералов подразумевается десятичная система, если не указано никаких модификаторов. Т.е. 1.0 в Пи просто так не превратится.
В любой, которую можно математически формализовать.
Принципиально ничего не мешает вести расчеты, например, в римских цифрах. Этого не делают просто потому что неудобно.
Иррациональные числа бесконечны
Вы опять путаете бесконечность числа и бесконечность его записи.
конкурс под названием «Практика критерий истинности»
Давайте начнем прямо с заголовка статьи. Цитирую: «Double, Float — не вещественные числа». Приведите, пожалуйста, пример числа, которое не является вещественным, но которое можно хранить в типах Double и Float. Специальные значения типа NaN не считаем.
С ростом размера релиза затраты на разработку функции растут экспоненциально
Подозреваю, что так только в некоторых областях разработки.
У меня на работе затраты на разработку растут линейно или даже чуть медленнее (за счет того, что разработчик погружен в задачу и добавление новой фичи может быть почти бесплатным).
Но у нас довольно высокие и слабо зависимые от размера релиза инфраструктурные затраты.
В результате чего нам выгоднее увеличивать релизы с точки зрения временного КПД.
Впрочем, под флагом того же Agile нас вынуждают снижать размер релиза и, соответственно, снижать наш КПД на длительных интервалах.
Есть еще эффект качества связи. Если коллега находится в месте не с самым лучшим приемом сотовой сети, то включение камеры на его стороне заметно ухудшает качество его же звука.
И как раз с выключенной камерой начинаются «повтори, пожалуйста», «тебя плохо слышно», которые очень мешают встрече.
Наблюдал этот эффект в разной степени в разных системах ВКС, включая Zoom. Но во всех, которыми доводилось пользоваться.
Не понимаю желания уменьшить Time-to-Market сам по себе, в отрыве от остальных метрик.
На моей работе нет никаких проблем нарезать задачи в три раза меньше. Тогда Time-to-Market упадет примерно вдвое (непропорционально, т.к. существуют фиксированные по времени подзадачи). А что на длинных интервалах мы сделаем в полтора раза меньше полезной работы — на это никто не смотрит…
Поясните, пожалуйста, откуда взялось обозначение V2.0?
И чем плата с этим обозначением отличается от других вариантов?
https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1 - тут, например, говорится о версии V3.0
И откусил кусочек птичьего молока :)
У нас это был годовой курсовик на 3 курсе. Команд было поменьше, кажется,4 штуки - сложение, условный переход, безусловный переход и еще что-то. И делали не в железе, а в специальной программе для симуляции.
Или я не понял идею, или даст неверный результат для примера из статьи - "6", "61", "69".
После деления получим 6, 6.1, 6.9. После сортировки 6.9, 6.1, 6. А нужно 6.9, 6, 6.1.
Линейно возрастающее магнитное поле будет вызывать постоянное электрическое поле. Просто это нециклический процесс, поэтому его неудобно использовать в обычном оборудовании.
В таких обзорах зачастую не хватает ещё одного фактора - способности открыть большой файл (хотя бы 4-8 ГБ) и, как подвариант, открыть файл размером более оперативной памяти.
Вот Notepad++ такое не умеет. Приходится пользоваться FAR-ом, хотя в целом он менее удобен для меня.
Да и у большинства компиляторов для числовых литералов подразумевается десятичная система, если не указано никаких модификаторов. Т.е. 1.0 в Пи просто так не превратится.
Принципиально ничего не мешает вести расчеты, например, в римских цифрах. Этого не делают просто потому что неудобно.
Вы опять путаете бесконечность числа и бесконечность его записи.
Давайте начнем прямо с заголовка статьи. Цитирую: «Double, Float — не вещественные числа». Приведите, пожалуйста, пример числа, которое не является вещественным, но которое можно хранить в типах Double и Float. Специальные значения типа NaN не считаем.
Да и тот же CI/CD много хлопот доставляет.
У меня на работе затраты на разработку растут линейно или даже чуть медленнее (за счет того, что разработчик погружен в задачу и добавление новой фичи может быть почти бесплатным).
Но у нас довольно высокие и слабо зависимые от размера релиза инфраструктурные затраты.
В результате чего нам выгоднее увеличивать релизы с точки зрения временного КПД.
Впрочем, под флагом того же Agile нас вынуждают снижать размер релиза и, соответственно, снижать наш КПД на длительных интервалах.
Опечатка. Читать «с включенной камерой»
И как раз с выключенной камерой начинаются «повтори, пожалуйста», «тебя плохо слышно», которые очень мешают встрече.
Наблюдал этот эффект в разной степени в разных системах ВКС, включая Zoom. Но во всех, которыми доводилось пользоваться.
На моей работе нет никаких проблем нарезать задачи в три раза меньше. Тогда Time-to-Market упадет примерно вдвое (непропорционально, т.к. существуют фиксированные по времени подзадачи). А что на длинных интервалах мы сделаем в полтора раза меньше полезной работы — на это никто не смотрит…
Какие впечатления?