Не, ну так-то деление на ноль на x86 красивее всего демонстрировать, когда ни числитель, ни знаменатель не 0: инструкция div процессора делит 32-битное число на 16-битное, и если результат не влез в 16 бит – это считается делением на 0 :-)
Результат вас удивит. В C-подобных языках ^ – это xor, выполняемый над целыми числами, так что это будет (-3)^0, т.е. -3.
А что касается других языков – всюду свои правила, зачастую оператора возведения в степень нет, вместо него функция – и можно рассчитывать, что она завершится с ошибкой.
Оки, видится интересным. Много что можно придумать лучше ntc, но любопытно, какой нашли баланс сложности и качества.
Да и "методы расчёта" пускового тока без учёта методов его ограничения интересны лишь для очень маленьких бп, а вместе с ограничением другие интересные задачи возникнут – есть, про что рассказать вам и почитать нам.
Мне казалось, что там, где его недостаточно (проблемы от высокого пускового тока не ограничатся искрой при втыкании вилки в розетку) – вероятность наличия какого-то решения для ограничения пт стремится к 1.
Кстати, свежий OpenSCAD (не релиз 22 года, а современные билды) тоже на manifold, благодаря чему им можно пользоваться на мало-мальски сложной геометрии (render не тормозит, как на старом движке, можно даже использовать voronoi()).
Типовая проблема с бинарными операциями там – что если у двух объектов в difference одинаковая толщина, то стенка то ли есть, то ли нет – приходится добавлять/вычитать что-то типа epsilon (2*epsilon, 3*epsilon) или явно вызывать render, чтобы избежать этого. Вы в своём CAD сталкивались с такой проблемой? Решали?
Про параметрическое представление: а нет случаем интероперабельности с OpenSCAD? Или хотя бы импорта/экспорта какого-то простого текстового формата для возможной конверсии? В эпоху текстового "ИИ", который легко может набросать или поправить OpenSCAD модель (пусть и с ошибками) было бы очень полезно. Классические кады типа FreeCAD огорчают тем, что по сути можешь или обмениваться STL, или интегрировать в модель scad как есть, бесшовный переход недостижим.
@Nyanny, смотри – тот же саппортер, что на Пикабу. Он воображает, что есть некий таинственный протокол "p2p", а не конкретные протоколы, используемые приложениями.
Опсосы в лице мтс подтвердили взымание платы за p2p, но отказались объяснить, какие именно хосты и протоколы засчитываются, как p2p – сказав "то, что определяется нашими алгоритмами как p2p" (могу дать ссылку на диалог с mts support). Так что с новостью насчёт платы за vpn всё ещё хуже: опсосы (ну, пока один) решили выставлять счета по желанию левой пятки.
Но вообще если бы я делал отказоустойчивую систему – я бы, возможно, тоже заложил резервные публичные ключи, храня соответствующие им приватные независимо и используя только один. Для того, чтобы сливать данные, это не требуется.
А тут не на хороший/плохой делится, а больше по длине)
Ну и не уверен, что там с подключением экрана кабеля к земле/нулю (если я правильно помню, в идеале должно быть только с одной стороны, что внезапно делало кабель неочевидно асимметричным... Но тут могу ошибаться).
Ещё flow... За использование слова "поток" в документации надо сразу увольнять.
А, да, действительно, был невнимателен и решил, что товарищ выше имел в виду sqr(sqrt(-1)), а не наоборот.
Не, ну так-то деление на ноль на x86 красивее всего демонстрировать, когда ни числитель, ни знаменатель не 0: инструкция div процессора делит 32-битное число на 16-битное, и если результат не влез в 16 бит – это считается делением на 0 :-)
Результат вас удивит. В C-подобных языках ^ – это xor, выполняемый над целыми числами, так что это будет (-3)^0, т.е. -3.
А что касается других языков – всюду свои правила, зачастую оператора возведения в степень нет, вместо него функция – и можно рассчитывать, что она завершится с ошибкой.
В смысле выключен провайдером инфраструктуры, и это не предвзятость, а просто адаптация к условиям?
(Ну и могу понять желание сразу перейти на "взрослое" решение – особенно у тех, кто застал netbeui и выборы координатора сети).
Я правильно понимаю, что ведущее бесплатное решение для "взрослого мира" – FreeCAD с его адом зависимостей между частями?
И через несколько секунд разблокировал, чтобы мне видно было)
Теряет hdmi подключение, потом восстанавливает.
Ну тут я бы как раз с его бп начал проверять. Не знаю насчёт гроз, а помехи от выключателей, скорей всего, сквозь него доходят.
Да и проверить его проще – попробовав другой совместимый.
В нашем случае здорово выдаёт то, что чаще всего это случается, когда подходишь к компу и/или садишься в кресло.
Подошёл к коллеге – а у него экран почернел)
Т.е. это расширение для вычитаний в итоге сделали на своём уровне, пользователю о нём думать не надо?
Простой json – это прекрасно. Может даже чатгпт освоит его перевод.
Оки, видится интересным. Много что можно придумать лучше ntc, но любопытно, какой нашли баланс сложности и качества.
Да и "методы расчёта" пускового тока без учёта методов его ограничения интересны лишь для очень маленьких бп, а вместе с ограничением другие интересные задачи возникнут – есть, про что рассказать вам и почитать нам.
Мне казалось, что там, где его недостаточно (проблемы от высокого пускового тока не ограничатся искрой при втыкании вилки в розетку) – вероятность наличия какого-то решения для ограничения пт стремится к 1.
Стоило бы прежде всего начать с вопроса, нужен ли приватный dns или в локальной сети хватит mdns.
Прочитал начало статьи, стал искать в ней слово ntc (типовое дешёвое решение для понижения пускового тока). Почему-то не вижу. О чём тогда статья?
Респект и уважуха.
Кстати, свежий OpenSCAD (не релиз 22 года, а современные билды) тоже на manifold, благодаря чему им можно пользоваться на мало-мальски сложной геометрии (render не тормозит, как на старом движке, можно даже использовать voronoi()).
Типовая проблема с бинарными операциями там – что если у двух объектов в difference одинаковая толщина, то стенка то ли есть, то ли нет – приходится добавлять/вычитать что-то типа epsilon (2*epsilon, 3*epsilon) или явно вызывать render, чтобы избежать этого. Вы в своём CAD сталкивались с такой проблемой? Решали?
Про параметрическое представление: а нет случаем интероперабельности с OpenSCAD? Или хотя бы импорта/экспорта какого-то простого текстового формата для возможной конверсии? В эпоху текстового "ИИ", который легко может набросать или поправить OpenSCAD модель (пусть и с ошибками) было бы очень полезно. Классические кады типа FreeCAD огорчают тем, что по сути можешь или обмениваться STL, или интегрировать в модель scad как есть, бесшовный переход недостижим.
@Nyanny, смотри – тот же саппортер, что на Пикабу. Он воображает, что есть некий таинственный протокол "p2p", а не конкретные протоколы, используемые приложениями.
Опсосы в лице мтс подтвердили взымание платы за p2p, но отказались объяснить, какие именно хосты и протоколы засчитываются, как p2p – сказав "то, что определяется нашими алгоритмами как p2p" (могу дать ссылку на диалог с mts support). Так что с новостью насчёт платы за vpn всё ещё хуже: опсосы (ну, пока один) решили выставлять счета по желанию левой пятки.
"В наше время никому нельзя доверять. Даже себе".
Но вообще если бы я делал отказоустойчивую систему – я бы, возможно, тоже заложил резервные публичные ключи, храня соответствующие им приватные независимо и используя только один. Для того, чтобы сливать данные, это не требуется.
А тут не на хороший/плохой делится, а больше по длине)
Ну и не уверен, что там с подключением экрана кабеля к земле/нулю (если я правильно помню, в идеале должно быть только с одной стороны, что внезапно делало кабель неочевидно асимметричным... Но тут могу ошибаться).
Здорово помогает сбрызнуть кресло антистатиком. И, если мне не изменяет память, есть зависимость от hdmi кабеля (короткий лучше себя ведёт).
Хотя, конечно, подмывает заземлить всё, что можно.