Столь смелое утверждение должно сопровождаться доказательствами. Так какие RFC регламентируют локальное хранение и обработку данных? Да и вообще, какое отношение к интернету может иметь локальное хранение и обработка данных?
В аналоговом виде - фазовращателями и компараторами. То есть, на сколько градусов нужно сдвинуть фазовращателем фазу принимаемого сигнала одного приёмника, относительно другого, чтобы мгновенные уровни принимаемых сигналов совпали.
Если речь только о двух приёмниках, то по разности фаз можно определить только зону пространства, в которой находится источник, но не направление не него. В плоскости, в которой лежит прямая, на которой находятся приёмники, действительно можно определить направление. Но та же летучая мышь ловит на лету комаров в пространстве.
Уши (микрофоны) у летучих мышей направленные, направление управляемое. ФАР же как раз решает проблему направленности без изменения ориентации приемников.
команда сервиса оплаты решает изменить тип поля или удалить поле user_id и молча выкатывает обновление
Даже не рассматривая, что в реальном мире никто не будет менять тип поля или его удалять, возникает вопрос, а почему бы клиентам не пользоваться рефлексией сервера, для того, чтобы такие вещи проверять?
Зачем нужно было кувыркаться с модулем на 5В, если можно было вполне обойтись реле, диодом, полевиком и резистором? Да и реле тогда можно было бы выбрать двухполюсное.
Почему выключение нагрузки нельзя было определять напрямую датчиком тока?
Ну тут тоже, как повезёт. Помнится, как в 22.04 в момент её выхода, при установке сетевой адаптер отваливался. А уж про nomodeset не слышал только совсем ленивый линуксоид.
У меня первым дистрибутивом Linux был Gentoo. Причём совершенно осознанно, так как хотел действительно изучить Linux. И ни капли об этом не жалею.
Вот только до этого у меня был богатый опыт, начиная с генерации TKS, затем VM/SP, работа с OS/2 (не надо про её дружелюбие, когда нужен HPFS386 и LanServer), Solaris и даже немного FreeBSD. А вот неподготовленному пользователю я бы не то что Gentoo, но и Arch не стал бы рекомендовать.
Ну так тем, кому действительно необходима производительность десятичной арифметики - тем уже хорошо. А тем, кто использует x86-64, и 18 десятичных знаков покрывают большинство задач.
Проблема однако в том, что число приходится распаковывать/детостить на каждое использование.
Ну так именно тут десятичное представление и выигрывает с огромным отрывом у двоичного, когда арифметики нет или мало.
Сравните время на упаковку и распаковку символьного представления числа в BCD и bigint.
calculations on numeric values are very slow compared to the integer types
Следует заметить, что данное утверждение всегда верно для PostgreSQL, но не для DB/2 на IBM мейнфрейме или сервере на PowerPC, так как они поддерживают вычисления в десятичной арифметике аппаратно. Когда-то и x86 поддерживали, хоть и не столь эффективно. Но в x86-64 команды поддержки десятичной арифметики были удалены. Впрочем, осталась поддержка десятичной арифметики до 18 разрядов средствами FPU.
Кроме того, следует учитывать затраты на преобразование двоичных чисел в десятичные и наоборот. Особенно при интеграции. Если вычислений с десятичной точкой мало, то стоит ли конвертировать числа в десятичном представлении в двоичное и обратно?
Если речь о летучей мыши (БПЛА), то там без реального времени никак не обойтись. У меня в деревне они (живые) не только рабицу в полете "видят", но даже комаров в полёте. Причем скорость их передвижения совсем не маленькая - 10-15 м/с.
Когда в конце 80-х занимался АФАРами в институте, в связи с отсутствием доступа к суперкомпьютеру М-13, выкручивались аналоговой вычислительной машиной на ОУ, после чего и ДВК-2 с математикой справлялась за приемлемое для прототипирования время. А вот модели и их параметры просчитывали уже на ЕС-1061
Нет, я просто волею случая немного разбираюсь в аэродинамике и в целом в физике хотябы на школьном уровне.
Не похоже, раз не знаете, что при увеличении скорости со 140 км/ч до 200 км/ч (в 1.4 раза), cила сопротивления среды и расход топлива на единицу пути увеличится в 2.04 раза. Для ЛА подразумевается, что угол атаки при 140 и 200 км/ч отличается незначительно.
А вы несёте совершенно неграмутную дичь.
А за это я Вам искренне благодарен. Более наглядно признать себя демагогом в технической дискуссии было бы сложно )))
Там всё упирается в локализацию реактивного двигателя
Всё упирается в стоимость. Поэтому Tomahawk стоит $2 млн, а Лютый на порядок меньше - $200 тыс. Соответственно потратить даже 9М83 (C-300) на Tomahawk, не говоря уже о 9М38 (Бук), вполне оправдано, а на Лютый - уже явно нет. Вот и гоняются за последними на Аллигаторах, сбивая их 30 мм 2А42, что я собственными глазами наблюдал уже неоднократно.
Обнаружение радаром в обоих случаях в основном ограничивается прямой видимостью и горизонтом
Это я про 2026 год, если что, а не про времена ВОВ.
Сказанное относится как раз к временам ВОВ.
Во-первых, дальность прямой видимостью и горизонтом не ограничивается. Другой вопрос, что для частот до 50 МГц БПЛА слишком мелкая цель.
Во-вторых, при обнаружении низколетящих целей важна скорость объекта, для того, чтобы отличить его от неподвижных и малоподвижных объектов. Особенно, если ФАР размещается не на поверхности земли, а на вышке сотового оператора.
В-третьих, даже при прямой видимости, критически важна когерентность и синхронизация времени, чтобы из всех отражений сигнала выделить сигнал отражённый напрямую от цели, а не после повторного отражения от рельефа, строений или ионосферы.
При чём тут это, если это был лишь пример синхронизации времени с точностью до +-10 наносекунд? Тогда как по оптике точность выше +-100 микросекунд не получите. Разница на четыре порядка!
нахождение объекта в квадрате 100х100м
Исходя из того, что в бистатических радарах, обеспечивающих точность локации в пределах нескольких метров, точность синхронизации +-500 пикосекунд или менее, я бы рассчитывал на точность +-50 нс.
Если же данных этих ФАР должно быть достаточно для поражения БПЛА (ошибка в пределах нескольких сантиметров), то точность синхронизации времени должна быть +-10 пикосекунд.
Это было бы странно, так как новому устройству, подключённому к этому же порту, питание с этого порта получить было бы невозможно.
Столь смелое утверждение должно сопровождаться доказательствами. Так какие RFC регламентируют локальное хранение и обработку данных? Да и вообще, какое отношение к интернету может иметь локальное хранение и обработка данных?
Я имел в виду, что у летучей мыши только два уха. Поэтому только на основе сдвига фаз она бы комаров на лету ловить не смогла.
Я потому и написал, что в аналоговом виде. В случае ЦАР, как в мобильной связи, ответ начинает тянуть на статью или цикл статей, а не комментарий.
В аналоговом виде - фазовращателями и компараторами. То есть, на сколько градусов нужно сдвинуть фазовращателем фазу принимаемого сигнала одного приёмника, относительно другого, чтобы мгновенные уровни принимаемых сигналов совпали.
Если речь только о двух приёмниках, то по разности фаз можно определить только зону пространства, в которой находится источник, но не направление не него. В плоскости, в которой лежит прямая, на которой находятся приёмники, действительно можно определить направление. Но та же летучая мышь ловит на лету комаров в пространстве.
Закройте глаза и не поворачивая головой попробуйте хлопком ладоней убить летящего комара не прямо перед Вами. Если сможете - то Вы уникум ))
А летучие мыши комаров в полете вообще-то ловят ртом, который куда меньше ладоней..
Эксперименты показывают, что если прямо перед собой (когда уши направлены!) человек способен определять направление с точностью 3 градуса по горизонтали, то в передней полуплоскости точность снижается до 12 градусов по горизонтали, а в задней - до 30. По вертикали же всё ещё хуже. Даже прямо перед собой точность падает до 10-15 градусов.
Очень плохо. Для более-менее точного определения направления вынуждены вертеть головой.
Уши (микрофоны) у летучих мышей направленные, направление управляемое. ФАР же как раз решает проблему направленности без изменения ориентации приемников.
Даже не рассматривая, что в реальном мире никто не будет менять тип поля или его удалять, возникает вопрос, а почему бы клиентам не пользоваться рефлексией сервера, для того, чтобы такие вещи проверять?
Зачем нужно было кувыркаться с модулем на 5В, если можно было вполне обойтись реле, диодом, полевиком и резистором? Да и реле тогда можно было бы выбрать двухполюсное.
Почему выключение нагрузки нельзя было определять напрямую датчиком тока?
Ну тут тоже, как повезёт. Помнится, как в 22.04 в момент её выхода, при установке сетевой адаптер отваливался. А уж про nomodeset не слышал только совсем ленивый линуксоид.
У меня первым дистрибутивом Linux был Gentoo. Причём совершенно осознанно, так как хотел действительно изучить Linux. И ни капли об этом не жалею.
Вот только до этого у меня был богатый опыт, начиная с генерации TKS, затем VM/SP, работа с OS/2 (не надо про её дружелюбие, когда нужен HPFS386 и LanServer), Solaris и даже немного FreeBSD. А вот неподготовленному пользователю я бы не то что Gentoo, но и Arch не стал бы рекомендовать.
Ну так тем, кому действительно необходима производительность десятичной арифметики - тем уже хорошо. А тем, кто использует x86-64, и 18 десятичных знаков покрывают большинство задач.
Ну так именно тут десятичное представление и выигрывает с огромным отрывом у двоичного, когда арифметики нет или мало.
Сравните время на упаковку и распаковку символьного представления числа в BCD и bigint.
Следует заметить, что данное утверждение всегда верно для PostgreSQL, но не для DB/2 на IBM мейнфрейме или сервере на PowerPC, так как они поддерживают вычисления в десятичной арифметике аппаратно. Когда-то и x86 поддерживали, хоть и не столь эффективно. Но в x86-64 команды поддержки десятичной арифметики были удалены. Впрочем, осталась поддержка десятичной арифметики до 18 разрядов средствами FPU.
Кроме того, следует учитывать затраты на преобразование двоичных чисел в десятичные и наоборот. Особенно при интеграции. Если вычислений с десятичной точкой мало, то стоит ли конвертировать числа в десятичном представлении в двоичное и обратно?
Если речь о летучей мыши (БПЛА), то там без реального времени никак не обойтись. У меня в деревне они (живые) не только рабицу в полете "видят", но даже комаров в полёте. Причем скорость их передвижения совсем не маленькая - 10-15 м/с.
Когда в конце 80-х занимался АФАРами в институте, в связи с отсутствием доступа к суперкомпьютеру М-13, выкручивались аналоговой вычислительной машиной на ОУ, после чего и ДВК-2 с математикой справлялась за приемлемое для прототипирования время. А вот модели и их параметры просчитывали уже на ЕС-1061
Это будет уже не ФАР, а АФАР. МК может не потянуть. Если ему помочь прецизионными ОУ, то потянет. Но схемотехника усложнится на порядок.
Не похоже, раз не знаете, что при увеличении скорости со 140 км/ч до 200 км/ч (в 1.4 раза), cила сопротивления среды и расход топлива на единицу пути увеличится в 2.04 раза. Для ЛА подразумевается, что угол атаки при 140 и 200 км/ч отличается незначительно.
А за это я Вам искренне благодарен. Более наглядно признать себя демагогом в технической дискуссии было бы сложно )))
Всё упирается в стоимость. Поэтому Tomahawk стоит $2 млн, а Лютый на порядок меньше - $200 тыс. Соответственно потратить даже 9М83 (C-300) на Tomahawk, не говоря уже о 9М38 (Бук), вполне оправдано, а на Лютый - уже явно нет. Вот и гоняются за последними на Аллигаторах, сбивая их 30 мм 2А42, что я собственными глазами наблюдал уже неоднократно.
Сказанное относится как раз к временам ВОВ.
Во-первых, дальность прямой видимостью и горизонтом не ограничивается. Другой вопрос, что для частот до 50 МГц БПЛА слишком мелкая цель.
Во-вторых, при обнаружении низколетящих целей важна скорость объекта, для того, чтобы отличить его от неподвижных и малоподвижных объектов. Особенно, если ФАР размещается не на поверхности земли, а на вышке сотового оператора.
В-третьих, даже при прямой видимости, критически важна когерентность и синхронизация времени, чтобы из всех отражений сигнала выделить сигнал отражённый напрямую от цели, а не после повторного отражения от рельефа, строений или ионосферы.
При чём тут это, если это был лишь пример синхронизации времени с точностью до +-10 наносекунд? Тогда как по оптике точность выше +-100 микросекунд не получите. Разница на четыре порядка!
Исходя из того, что в бистатических радарах, обеспечивающих точность локации в пределах нескольких метров, точность синхронизации +-500 пикосекунд или менее, я бы рассчитывал на точность +-50 нс.
Если же данных этих ФАР должно быть достаточно для поражения БПЛА (ошибка в пределах нескольких сантиметров), то точность синхронизации времени должна быть +-10 пикосекунд.