На диаграмме сил у вас направление w_c и a_c, кажется, перепутано. Ещё не раскроете секрет, какого бренда контроллеры моторов привода цилиндров использовались в первом прототипе?
У вас в "математической модели" в нижнем плече диоды перевёрнуты, и в уравнениях состояния БДПТ используется угловое ускорение где должна быть угловая скорость.
В разделе "практическое применение" описаны обыкновенные двигатели с переменным магнитным сопротивлением и вентильно-индукторные с независимым возбуждением. Отличный ликбез по моторам от эксперта на хабре уже есть (рекомендую почитать и другие его публикации): https://habr.com/ru/amp/post/371749/
Для публикаций такого рода оценка "низкий технический уровень материала" кажется слишком мягкой. Непонятно, что эта сенсация вообще здесь делает.
Автор почему-то описывает обыкновенный универсальный коллекторный двигатель как "асинхронный", что, очевидно, ошибка. @progchip666, не могли бы вы внести ясность? Спасибо.
Наше отклонение от канонической реализации позволило ускорить выборы с помощью обнаружения ничьей, и в то же время потребовало дополнительных модификаций для обеспечения консисентости
Once upon a time, a man with a dirty lab coat and long, uncombed hair showed up at the town police station, demanding to see the chief of police. "I've done it!" he exclaimed. "I've built the perfect criminal-catching robot!"
The police chief was skeptical, but decided that it might be worth the time to see what the man had invented. Also, he secretly thought, it might be a somewhat unwise move to completely alienate the mad scientist and his army of hunter robots.
So, the man explained to the police chief how his invention could tell the difference between a criminal and law-abiding citizen using a series of heuristics. "It's especially good at spotting recently escaped prisoners!" he said. "Guaranteed non-lethal restraints!"
Frowning and increasingly skeptical, the police chief nevertheless allowed the man to demonstrate one robot for a week. They decided that the robot should patrol around the jail. Sure enough, there was a jailbreak a few days later, and an inmate digging up through the ground outside of the prison facility was grabbed by the robot and carried back inside the prison.
The surprised police chief allowed the robot to patrol a wider area. The next day, the chief received an angry call from the zookeeper. It seems the robot had cut through the bars of one of the animal cages, grabbed the animal, and delivered it to the prison.
The chief confronted the robot's inventor, who asked what animal it was. "A zebra," replied the police chief. The man slapped his head and exclaimed, "Curses! It was fooled by the black and white stripes! I shall have to recalibrate!" And so the man set about rewriting the robot's code. Black and white stripes would indicate an escaped inmate UNLESS the inmate had more than two legs. Then it should be left alone.
The robot was redeployed with the updated code, and seemed to be operating well enough for a few days. Then on Saturday, a mob of children in soccer clothing, followed by their parents, descended on the police station. After the chaos subsided, the chief was told that the robot had absconded with the referee right in the middle of a soccer game.
Scowling, the chief reported this to the scientist, who performed a second calibration. Black and white stripes would indicate an escaped inmate UNLESS the inmate had more than two legs OR had a whistle on a necklace.
Despite the second calibration, the police chief declared that the robot would no longer be allowed to operate in his town. However, the news of the robot had spread, and requests from many larger cities were pouring in. The inventor made dozens more robots, and shipped them off to eager police stations around the nation. Every time a robot grabbed something that wasn't an escaped inmate, the scientist was consulted, and the robot was recalibrated.
Unfortunately, the inventor was just one man, and he didn't have the time or the resources to recalibrate EVERY robot whenever one of them went awry. The robot in Shangri-La was recalibrated not to grab a grave-digger working on a cold winter night while wearing a ski mask, and the robot in Xanadu was recalibrated not to capture a black and white television set that showed a movie about a prison break, and so on. But the robot in Xanadu would still grab grave-diggers with ski masks (which it turns out was not common due to Xanadu's warmer climate), and the robot in Shangri-La was still a menace to old televisions (of which there were very few, the people of Shangri-La being on the average more wealthy than those of Xanadu).
So, after a few years, there were different revisions of the criminal-catching robot in most of the major cities. In some places, a clever criminal could avoid capture by wearing a whistle on a string around the neck. In others, one would be well-advised not to wear orange clothing in certain rural areas, no matter how close to the Harvest Festival it was, unless one also wore the traditional black triangular eye-paint of the Pumpkin King.
Many people thought, "This is lunacy!" But others thought the robots did more good than harm, all things considered, and so in some places the robots are used, while in other places they are shunned.
Было обещано лишь, что «лидер будет найден, если большинство узлов работоспособно и связано друг с другом»
Условие связности большинства в первых примерах не выполняется, потому что A и C не связаны, а один B не составляет большинство. Или я неправильно понял что-то из базовых определений оригинальной статьи про рафт?
Посоветуйте вашему человеку дышать глубже и подбирать инструменты сообразно задаче. Если нужен текстонабиратель, есть nano/vi/notepad.exe. Если нужна IDE, придётся повозиться и пожертвовать парой гигабайт места на диске как минимум (почему это вообще проблема? у него место на диске платное?). Приведённая критика выглядит неадекватно и как-то эмоционально.
Вообще, пользуясь случаем, хочу бросить большой камень всем C++ IDE в принципе, и в этом поддержать вашего горячего знакомого конкретно в части "начинает гораздо чаще глючить и медленно работать". Даже топовые CLion и основанный на clang плагин C++ для VSCode регулярно ломаются в сложных проектах: то индекс слетит, то миспарсинг, то "Resolving symbol..." подвисает на минуту на ровном месте, то авторефакторинг калечит код так что приходится системой контроля версий его откатывать, и т.п. Знающие люди винят избыточность языка, что делает сложность разработки инструментария непомерно высокой (тем более с учётом постоянно развивающегося стандарта). Я сам давно бы завязал с C++ и перешёл на технологии поновее, но легаси всё не отпускает.
У VS Code плохие отзывы, рецензии. Много рекламаций.
Моё возражение касалось выбора IDE, а не инструментов сборки. Насчёт актуальности make сегодня тоже можно дискутировать (нетривиальные проекты чаще используют высокоуровневые системы сборки вроде cmake или meson, и да, я говорю о глубокой встройке, как и вы), но тут действительно есть нюансы.
Эклипс просто неюзабелен по современным меркам. Парсер C++ ломается на всем, что сложнее хеллоуворлда; интеграция отладчика с GDB ломается через раз сама по себе; интеграции с системами контроля версий практически отсутствуют; автодополнение ломается вместе с парсером языка, а если парсер и работает, предложенный функционал абсолютно минимален; нет языковых инъекций и встроенной поддержки других языков, используемых в проекте, вроде питона (только не начинайте про PyDev); нет нативной поддержки современными утилитами (как насчёт CoPilot?). Автоматические рефакторинги C++ там такие, что лучше бы их не было. Список не полный, конечно, я последний раз им пользовался лет пять назад и с тех пор не оглядывался ни разу.
Эклипс был хорош 10-15 лет назад на фоне отсутствия альтернатив. Сегодня его можно советовать для новых проектов только от незнания современных инструментов.
Очередной туториал по Eclipse с make в 2022? Остановите планету, я сойду.
Автору рекомендую открыть для себя человеческие инструменты и отправить наконец эклипс в мусорное ведро на пенсию, где ему и место. Поиск замены можно начать с CLion или VSCode.
Я понимаю, почему бизнесам в области хранения данных есть дело до места. Но вам-то, как конечному пользователю, какая разница? Диски меньше чем на полтерабайта сегодня большая редкость. Ну съест ваш пакет гигабайт-другой, ну десять, на что это повлияет? Стоимость хранения данных продолжает падать, в то время как вычислительные мощности практически не растут последнее десятилетие (если не считать прогресса в области SIMD систем, но это таки другое), так что размен производительности на экономию места в общем случае выглядит неразумным.
АКБ это, буквально, аккумуляторная кислотная батарея. Здесь батарея литий-ионная, а не кислотная, у вас ошибка. Ещё приставка кило в кВт пишется в нижнем регистре.
На диаграмме сил у вас направление w_c и a_c, кажется, перепутано. Ещё не раскроете секрет, какого бренда контроллеры моторов привода цилиндров использовались в первом прототипе?
У вас в "математической модели" в нижнем плече диоды перевёрнуты, и в уравнениях состояния БДПТ используется угловое ускорение где должна быть угловая скорость.
В статье всё-таки речь идёт об ОС GNU с ядром Linux. Говорить «ОС Linux» некорректно хотя бы по отношению к людям, создавшим GNU.
В разделе "практическое применение" описаны обыкновенные двигатели с переменным магнитным сопротивлением и вентильно-индукторные с независимым возбуждением. Отличный ликбез по моторам от эксперта на хабре уже есть (рекомендую почитать и другие его публикации): https://habr.com/ru/amp/post/371749/
Для публикаций такого рода оценка "низкий технический уровень материала" кажется слишком мягкой. Непонятно, что эта сенсация вообще здесь делает.
Для синхронного двигателя (именно о нем идёт речь в статье, см. комментарии выше) всё это неактуально.
Автор почему-то описывает обыкновенный универсальный коллекторный двигатель как "асинхронный", что, очевидно, ошибка. @progchip666, не могли бы вы внести ясность? Спасибо.
Да, теперь понятно, спасибо.
https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00171.html
Годнота, конечно, но:
Условие связности большинства в первых примерах не выполняется, потому что A и C не связаны, а один B не составляет большинство. Или я неправильно понял что-то из базовых определений оригинальной статьи про рафт?
Посоветуйте вашему человеку дышать глубже и подбирать инструменты сообразно задаче. Если нужен текстонабиратель, есть nano/vi/notepad.exe. Если нужна IDE, придётся повозиться и пожертвовать парой гигабайт места на диске как минимум (почему это вообще проблема? у него место на диске платное?). Приведённая критика выглядит неадекватно и как-то эмоционально.
Вообще, пользуясь случаем, хочу бросить большой камень всем C++ IDE в принципе, и в этом поддержать вашего горячего знакомого конкретно в части "начинает гораздо чаще глючить и медленно работать". Даже топовые CLion и основанный на clang плагин C++ для VSCode регулярно ломаются в сложных проектах: то индекс слетит, то миспарсинг, то "Resolving symbol..." подвисает на минуту на ровном месте, то авторефакторинг калечит код так что приходится системой контроля версий его откатывать, и т.п. Знающие люди винят избыточность языка, что делает сложность разработки инструментария непомерно высокой (тем более с учётом постоянно развивающегося стандарта). Я сам давно бы завязал с C++ и перешёл на технологии поновее, но легаси всё не отпускает.
То ли дело эклипс, да?
Я бы сказал, что наибольшее время занимает написание тестов для верификации, но, возможно, это варьируется в зависимости от методологии.
Моё возражение касалось выбора IDE, а не инструментов сборки. Насчёт актуальности make сегодня тоже можно дискутировать (нетривиальные проекты чаще используют высокоуровневые системы сборки вроде cmake или meson, и да, я говорю о глубокой встройке, как и вы), но тут действительно есть нюансы.
Чтож, ну давайте доедать кактус тогда, раз перемены запрещены.
Эклипс просто неюзабелен по современным меркам. Парсер C++ ломается на всем, что сложнее хеллоуворлда; интеграция отладчика с GDB ломается через раз сама по себе; интеграции с системами контроля версий практически отсутствуют; автодополнение ломается вместе с парсером языка, а если парсер и работает, предложенный функционал абсолютно минимален; нет языковых инъекций и встроенной поддержки других языков, используемых в проекте, вроде питона (только не начинайте про PyDev); нет нативной поддержки современными утилитами (как насчёт CoPilot?). Автоматические рефакторинги C++ там такие, что лучше бы их не было. Список не полный, конечно, я последний раз им пользовался лет пять назад и с тех пор не оглядывался ни разу.
Эклипс был хорош 10-15 лет назад на фоне отсутствия альтернатив. Сегодня его можно советовать для новых проектов только от незнания современных инструментов.
Очередной туториал по Eclipse с make в 2022? Остановите планету, я сойду.
Автору рекомендую открыть для себя человеческие инструменты и отправить наконец эклипс
в мусорное ведрона пенсию, где ему и место. Поиск замены можно начать с CLion или VSCode.Я понимаю, почему бизнесам в области хранения данных есть дело до места. Но вам-то, как конечному пользователю, какая разница? Диски меньше чем на полтерабайта сегодня большая редкость. Ну съест ваш пакет гигабайт-другой, ну десять, на что это повлияет? Стоимость хранения данных продолжает падать, в то время как вычислительные мощности практически не растут последнее десятилетие (если не считать прогресса в области SIMD систем, но это таки другое), так что размен производительности на экономию места в общем случае выглядит неразумным.
Мы заигрались.
Использовать какой-то другой язык вместо си? Да ну, бред какой-то.
На самом деле 65504.
АКБ это, буквально, аккумуляторная кислотная батарея. Здесь батарея литий-ионная, а не кислотная, у вас ошибка. Ещё приставка кило в кВт пишется в нижнем регистре.