многие сделанные мной устройства работают автономно выполняют задачи без участия человека или оператора месяцами.
Ну и что? У меня устройства тоже работают 24/7 ГОДАМИ. И не обслуживаются. Только задачи таких устройств строго детерминированы. А управление оружием не относится к детерминированным задачам. Цели маневрируют, цели мимикрируют, цели изменяются . И все это происходит очень быстро. Мало того, цели очень похожи на своих. Поэтому чуть ли не основная и самая сложная задача автономного оружия - отличить своего от чужого в условиях РЭБ и иных способов противодействия. Повторяю, Слесарь, автономный дрон может сделать в части выбора целей не более, чем автономный человек. Без связи рой дронов не работоспособен.
Добавлено after 2 minutes 46 seconds: Слесарь, ты мне с определением стратегий Соловьева напомнил. Если кто не в теме, он просился в академию Генштаба. Не взяли. Формально он полковник, могли бы и взять. Но он вроде в запасе, хотя откуда нам знать.
_________________ Недоброжелатели: HariusHek, Sigma, КРАМ, Николай_С, Муркиз Список закрыт, остальных конкурсантов прошу напрасно не беспокоить.
Только задачи таких устройств строго детерминированы. А управление оружием не относится к детерминированным задачам.
Я как-то в далеком прошлом делал одному студенту за деньги для его дипломной работы прогу на ПК по формулам какого-то уже не помню математика, сначала выделяющий границы на изображении отдельного образа, по типу как наверное сейчас делает любой смартфон в несколько камер, а потом сличала этот образ с теми или иными другими картинками и математически находила сходства, если бы стояла задача обнаруживать цели, по типу как пару десятилетий ваш фотоаппарат определяет улыбки на лице, современными средствами и методами делал бы это так же у себя на кухне, как делал это пару десятилетий тому назад.
Кто изучал объектоориентированное программирование, то знает, что сначала мы разрабатывает объект и наделяем его различными методами, а потом можем этот объект и соответственно методы миллион раз многократно использовать всего одной строчкой кода, что открывает за собой невообразимые возможности, по части обработки данных, о тех же объектах получаемых в реальном времени изображения, на много порядков превосходящих по избирательности и скорости возможности человека. На самом деле человек, кто бы мог управлять, не нужен... Человек, это скорее обуза, чем преимущество.
Добавлено after 18 minutes 27 seconds: КРАМ, я даже простые поделки с моторчиками и лампочками, для пром оборудования, делаю чтоб во много автоматика управляла оператором, а не оператор управлял автоматикой. Логика работы моих устройств заставит оператора поступать правильно чтоб устройство правильно выполняло задачу. Точно так же как современный автомобиль способен автоматически перехватывать управление водителя, применить иной способ управления. если водитель в неадеквате или не видит, чтоб не допустить аварии.
Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.
Взломали энигму, взломают и любой современный код. Дело времени.
надо внести ясность))
1- есть протокол шифрования. 2- есть ключи шифрования. это разные вещи.
-в энигме протокол шифрования определялся конструкцией самой энигмы. (в энигме протокол шифрования держался в секрете). -ключи шифрования вводились вручную. (в энигме ключи шифрования держались в секрете).
взломать это всё... задачка была не из лёгких)) но в итоге справились. особенно когда в руки союзников попала первая трофейная энигма и стало всем понятно принцип её работы. но это уже мелкие детали))
а всего этих энигм было огромное множество. и у каждой свой принцип действия. поэтому все они были между собой несовместимы. нельзя было передать сообщение из одной версии энигмы на другую версию энигмы даже если были одинаковые ключи шифрования.
чтоб избавиться от этой путаницы придумали единые стандарты протоколов шифрования. поэтому теперь достаточно знать только ключ шифрования, а стандарты протоколов шифрования и так известны (протоколы шифрования описаны в любом справочнике).
в этом первое отличие ВОВ от СВО.
что значит "взломают любой современный код" ?
1- взламывать протокол шифрования не надо (протоколы шифрования описаны в любом справочнике). 2- взломать (подобрать) ключи шифрования... можно но трудно)) а вот тут эже действительно правильно сказать "Дело времени".
Кто изучал объектоориентированное программирование, то знает, что сначала мы разрабатывает объект и наделяем его различными методами, а потом ...
напомнило про зенитные кодексы Аль-Эфесби
но да, часть из того что сейчас немыслмо без "ИИ" в конце 70х делали простейшие боевые алгоритмы, выполняемые например на 8048 ... и несказать что практические результаты были совершенно несравнимы ...просто технологические возможности неизгладимо влияют на подходы
Кто изучал объектоориентированное программирование, то знает, что сначала мы разрабатывает объект и наделяем его различными методами, а потом можем этот объект и соответственно методы миллион раз многократно использовать всего одной строчкой кода, что открывает за собой невообразимые возможности, по части обработки данных, о тех же объектах получаемых в реальном времени изображения, на много порядков превосходящих по избирательности и скорости возможности человека. На самом деле человек, кто бы мог управлять, не нужен... Человек, это скорее обуза, чем преимущество.
Я просто диву даюсь твоей самоуверенности при такой безграмотности. ООП никаких преимуществ по скорости обработки не дает против структурного программирования. Скорее наоборот. ООП заменяет сущности структурного программирования, но влияет это лишь на понимание кода программистом. Любой код написанный на ООП можно переписать на структурный язык. Независимо от выбора языка, классический код для ЭВМ является детерминированной сущностью. Его поведение строго трассируется в четкой зависимости от входных воздействий. Кроме того, дело вообще не в скорости. Даже AI не в стоянии заменить человека в бою на этапе принятия тактических решений. А суть боя именно в таких решениях.
делаю чтоб во много автоматика управляла оператором, а не оператор управлял автоматикой.
Тупой безграмотный подход. Автоматика не должна управлять человеком. Иначе от нее не будет никакого толка. Человек в детерминированных алгоритмах слабое звено. Человек должен выполнять только работу лежащую ВЫШЕ слоя автоматов. А управление автоматами должно быть абстрагировано на уровень человеческого нативного мышления. То есть пилот не крутит штурвал, пилот управляет идеологией полета, определяя его цель и контролируя непредсказуемое для автомата.
Так дело не во в объеме перехваченных сообщений. И примерной их идентификациями с актуальными событиями чтоб было ясно что искать. Не секрет же что уровни шифров в ВОВ были разные - где дивизия где Ставка
объем перехваченных сообщений ничего не даст.
Если раньше было достаточно захватить трофейную машинку и узнать её секрет... То теперь это не работает)) Искать можно только ключ. Остальное и так известно.
Вся современная криптография работает по принципу:
"Если хочешь что-то спрятать то поставь это на видном месте"
Добавлено after 2 minutes 21 second: В итоге все всё знают но ничего сделать не могут)) В этом главная фишка всей современной криптографии.
часть из того что сейчас немыслмо без "ИИ" в конце 70х делали простейшие боевые алгоритмы, выполняемые например на 8048 ... и несказать что практические результаты были совершенно несравнимы ...просто технологические возможности неизгладимо влияют на подходы
Нет. Сейчас при разработке устройства или метода, 90% работы выполняет не человек, а машина, соответственно если не быть ленивым и поработать с такими новыми возможностями как следует, на все 100%, то можно получить результат на 1000% более прогрессивный, чем это делалось в конце 70-х чисто ручным способом на тех же ЭВМ 70-х. К результату так же прибавится в милион раз большая вычислительная способность и в миллиард раз большие объемы памяти, соответственно в реалиях современности получим в триллион раз более высокий результат чем в 70-е. В 70-е наверное даже никто не планировал всеволновый карманный копеечной стоимости радиоприемник сделанный на основе полностью цифровой обработки принимаемых сигналов, без единого колебательного контура при преобразовании сигналов и питанием от маленькой батарейки, ввиду невозможности это реализовать промышленностью всего мира, хоте все необходимые формулы и методы на тот момент уже были придуманы, а сейчас это просто детская игрушка. купил, попользовался и бросил...
ООП никаких преимуществ по скорости обработки не дает против структурного программирования.
Ты просто далекий... ООП освобождает меня при разработке от многого множества рутинных задач, соответственно позволяет больше думать об общей концепции архитектуры проекта, и меньше заботиться о деталях его внутренней реализации. Соответственно предоставляет мне возможность без особого труда одновременно поработать и как каменщик который высекает отдельные кирпичики будущего здания, и как главным архитектором проекта. Мне лучше видно как отдельные кирпичики, так и общую концепцию. Я не утопаю в миллионах страниц однообразного повторяющего текста, а могу оперировать глобальными концепциями всего на одном листе бумаги. причем ООП лучше сообразуется с тем, что могла бы доделывать и исправлять по части рутинных задач за меня машина. Структура ООП программирования во многом исправляет человеческое мышление и делает проекты много лучше и эффективней. Сделанные за многократно меньшее время, чем при простом процедурном программировании.
ООП освобождает меня при разработке от многого множества рутинных задач, соответственно позволяет больше думать об общей концепции архитектуры проекта, и меньше заботиться о деталях его внутренней реализации.
Ты просто никакой программист. Поэтому тебе ООП нужен лишь потому, что он предоставляет готовые кубики, из которых ты делаешь детские проекты. На самом деле никаких принципиальных преимуществ у ООП нет. По поводу того, что ты думаешь об "архитектуре проекта" местная публика убедилась на примере твоих страданий с солнечным инвертором. Весь "энтузиазм" ушел в гудок.
О том что в готовом проекте труд непосредственно людей, это мизерный процент произведенной работы, писал неоднократно... Бла...бла...бла... ...Так зачем мне заниматься взрослыми проектами, устраиваться на работу по взрослому, когда за детские проекты платят много больше за единицу потраченного времени.
Слесарь, ты любую чисто техническую тему сводишь к флуду о своей любви к безделью и о том, как ты ловко отремонтировал очередную железяку, получив за нее месячную зарплату... Мы обсуждали вопрос о ТЕХНИЧЕСКИХ преимуществах и недостатках ООП и структурного программирования. Ты изначально написал:
Слесарь писал(а):
Кто изучал объектоориентированное программирование, то знает, что сначала мы разрабатывает объект и наделяем его различными методами, а потом можем этот объект и соответственно методы миллион раз многократно использовать всего одной строчкой кода, что открывает за собой невообразимые возможности, по части обработки данных, о тех же объектах получаемых в реальном времени изображения, на много порядков превосходящих по избирательности и скорости возможности человека.
Где тут про то, что ты экономишь время на свое безделье? Ты написал чушь. ООП не дает всех перечисленных преимуществ. Обрабатывать данные можно и структурными языками. Это дело привычки и вкуса. А то, что тебе стали доступны "кубики" с исходниками на ООП - никакого отношения к преимуществам ООП не имеет.
А то, что тебе стали доступны "кубики" с исходниками на ООП - никакого отношения к преимуществам ООП не имеет.
Ты далекий. Имелось в виду удобство работы одновременно на разных уровнях абстрагирования, что существенно повышает производительность труда программиста и разработчика архитектуры ПО. А так же помогает выстраивать лучшую архитектуру проекта, защищает от множества структурных ошибок, помогает грамотно выстраивать иерархию программных объектов и исполняемых модулей. А еще помогает глобально проектировать непосредственно в тексте объектоориентированного языка, по тому что вначале описывают сами объекты, их свойства, производность и подчиненности, интерфейсы взаимосвязей объектов, исполняемого процедурного кода на этом этапе может еще не существовать, а потом только можно раздавать задания кодировщикам кто исполнит задуманное , все процедуры внутри объектов, уже непосредственно в исполняемом коде, без путаницы, каждый кодировщик займется наполнением своего конкретного объекта, следуя описанием интерфейсов как задумано архитектором, непосредственно на том же языке как и исполняемые коды. а так же кодировщиком без труда в той же среде разработки может выступать и сам архитектор и лучше понимать и контролировать работу других кодировщиков. Что кратно повышает общую производительность труда при производстве программных продуктов и делает проекты более мощными и качественными чем при только процедурном программировании.
Добавлено after 10 minutes 2 seconds: Так как проектирование проекта начинается с описания структур производности и подчиненности различных объектов, в дальнейшем сам язык программирования защищает разработчика от множества грубых ошибок при использовании объектов. что существенно повышает качество общей архитектуры, улучшает понимание что должно получиться на выходе и как это использовать, существенно упрощает работу как разработчика, так и отдельных кодеров.
Добавлено after 11 minutes 3 seconds: А по поводу готовых кирпичиков, разработчику в среде ООП открывается огромная база библиотек и описаний программных интерфейсов к другим программам и к операционным системам, так что бывает достаточно только спроектировать надстройку над уже готовой другой программой или операционной системой используя описания в среде ООП интерфейсов к исполняемым модулям системы, как например архитектура COM модулей, своего процедурного кода при этом может быть самое минимальное количество, все будет выполняться например через COM интерфейсы. Подключаюсь к работающему COM модулю системы, передаю данные и получаю результат.
COM интерфейсы уже давно удалены из всех компов...
Такого не может быть. Я просто привожу как пример чем повседневно занимался более 20 лет тому назад, пока не нашел другие более выгодные для себя занятия.
Имелось в виду удобство работы одновременно на разных уровнях абстрагирования....
Слесарь, когда ты говоришь, такое ощущение, что ты бредишь...(с) Что ты имел ввиду, ты высказал достаточно однозначно в своем сообщении, часть которого я процитировал выше. Теперь ты пытаешься переобуться в прыжке, подменяя техническую эффективность компилятора на удобство работы с ним. Разговор шел о возможности автономной работы дронов без связи. Ты свел все это к тому, что лично тебе удобно писать на ООП. Ты, стесняюсь спросить, балабол дрон? И кроме того, а ты создал хоть один проект на ООП для встраиваемой системы? Мы же о дронах говорили. Есть железобетонная уверенность, что всё твое словоблудие относится к твоим упражнениям с ПК...
И кроме того, а ты создал хоть один проект на ООП для встраиваемой системы?
Ты дремучий дед. Каждое приложение по сути это один из программных вариантов встраиваемой системы, потому как все приложения встроены в те или иные базовые системы. и не важно, программные это объекты или аппаратные, суть от этого не меняется. Интернет приложения для МК и цифровая обработка сигналов на МК у меня работают созданные в стиле, структуре и языке ООП, с классами и системой обмена сообщениями между отдельными модулями проекта, для организации лучшей многозадачности. Естественно работая много лет до этого разработчиком виндовс ООП приложений, плагинов и СОМ серверов, я во многом перенес эту идеологию в область МК разработки. И естественно если мне сейчас понадобится сделать распознавание образов с изображений, я просто портирую свои старые наработки ООП на платформу МК. Но последнее время увлекся ПЛИС и по этому сейчас считаю что перенос старых методов распознания и обработки образов заново на процессорные платформы, утопическая ветвь развития, на базе ПЛИС это все можно делать многократно компактней (во много раз меньше кода) и в сотни, а может и в тысячи раз быстрее обработка образов, нежели у процессорных вариантов.
Каждое приложение по сути это один из программных вариантов встраиваемой системы, потому как все приложения встроены в те или иные базовые системы. и не важно, программные это объекты или аппаратные, суть от этого не меняется.
Интернет приложения для МК и цифровая обработка сигналов на МК у меня работают созданные в стиле, структуре и языке ООП, с классами и системой обмена сообщениями между отдельными модулями проекта, для организации лучшей многозадачности.
Не нужно на мне тренироваться в треше для клиентов. Если бы я тебя не знал, то твоя болтовня частично прокатила бы. Расскажи нам, Слесарь, для каких МК ты писал интернет приложения? Для каких МК ты писал цифровую обработку сигналов и в чем заключалась эта цифровая обработка? Какой компилятор ты использовал и и что означает "в стиле ООП"? Какое отношение к ООП имеет обмен сообщениями между модулями проекта?
если мне сейчас понадобится сделать распознавание образов с изображений, я просто портирую свои старые наработки ООП на платформу МК.
Просто кокойты полет лютой фантазии... Ты ничего не сможешь портировать с винды на МК. Просто поверь мне на слово. А когда возникнет желание - проверь.
Но последнее время увлекся ПЛИС и по этому сейчас считаю что перенос старых методов распознания и обработки образов заново на процессорные платформы, утопическая ветвь развития, на базе ПЛИС это все можно делать многократно компактней (во много раз меньше кода) и в сотни, а может и в тысячи раз быстрее обработка образов, нежели у процессорных вариантов.
Тут есть небольшая проблема. Математику нужно знать. А с этим у тебя очень туго. Поэтому ты несешь тут этот бред. ЗЫ. Но ты не расстраивайся, Слесарь. Закон Брандолини на твоей стороне.
Сейчас этот форум просматривают: Repeater и гости: 10
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
... и несказать что практические результаты были совершенно несравнимы 
...просто технологические возможности неизгладимо влияют на подходы 
