`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

О математике и программировании

+66
голосов
Это так, - всего лишь попытка осмысления, не более того.

Для «чистоты мысленного эксперимента» вычеркнем разработчиков наукоёмкого ПО из списка – хотя бы потому, что по спецификациям можно писать любые программы, включая и очень наукоёмкие, и при этом не иметь понятия о прикладной области.

Будем рассматривать простую задачу. Очень простую и обыденную.

Предположим, есть некая механическая кнопка, связанная с контактом, состояние которого  (замкнут-разомкнут) надо прочитать из программы. Например, - кнопка клавиатуры.
Кодировщик, «пасущийся» на вершине программно-аппаратных архитектур, решает эту задачу теми средствами, которые для него оставлены на поверхности. А именно, - с помощью соответствующего API в рамках реализованной архитектурной модели. К слову, - выбор этих моделей невелик: или это нечто мониторно-примитивное, вынуждающее кодировщика самостоятельно опрашивать состояние кнопки каким-то вызовом, назовём его ReadKeyState(), или это традиционная для современных ОС модель просмотра очереди сообщений о событиях, или же более редкая модель назначения определяемых кодировщиком обработчиков разных событий. Вне зависимости от модели, для кодировщика нажатие кнопки – процесс невидимый, точнее, - существующий не как процесс, а только как проявление, свидетельствующее о том, что кнопка точно была нажата.

 

Перед системным программистом, в свою очередь, уже совсем иные виды – его волнует протокол обмена клавиатуры, в которую встроена кнопка, но он всё равно не видит собственно процесса её нажатия, а только проявление этого процесса – некое сообщение в установленном протоколом формате, подтверждающее тот факт, что кнопка точно была нажата.

Я два раза употребил слово «точно» и выделил его не случайно. Потому что замыкание контактов кнопки на самом деле… является очень непростым процессом, и характеризуется таким явлением, как «дребезг» (contact bounce).

Так что для быстрой электроники, к которой подсоединён механический выключатель (кнопка), процесс его замыкания является последовательностью импульсов разной и случайной продолжительности, после которой, собственно, и формируется контакт. Для борьбы с дребезгом придумали много всяких аппаратных и программных ухищрений, но аппаратные неэкономичны, а программные не всегда гарантируют, что контакт был точно замкнут.

Естественно, виден этот процесс работающему на самом нижнем уровне программисту. И если его более высокоуровневым коллегам математика при решении задачи определения нажатия кнопки была не нужна, то здесь случай особый. Потому что без знания математики, причём серьёзной математики, сразу нескольких её прикладных областей, решить задачку красивого и качественного устранения «дребезга» весьма непросто. Зато если знать теорию электронных цепей, аналоговой и цифровой фильтрации, можно написать рекуррентную формулу цифрового фильтра (для знающих электронику – выполняющего роль триггера Шмитта:

Выход(t) = (1/4)*Вход(t) + (3/4)*Выход(t-1)

Такой фильтр реализуется буквально двумя десятками команд современного микроконтроллера и отнимает примерно столько же машинных тактов.

Вот так примерно и получается, - прикладная область навязывает требования к программисту, и надо знать свой уровень абстракции: кодировщикам – языково-библиотечно-инструментальный, системным программистам – спецификации и протоколы, embedded-программистам («железячникам») – специфику физические объектов, принципов обработки сигналов, математическую статистику, теорию систем etc. 
+66
голосов

Напечатать Отправить другу

Читайте также

Абсолютно с вами согласен. На каждом уровне иерархии существуют свои сложности и существует своя "глава" прикладной математики. И в какой-то мере, от специалистов занимающимися проектированием протоколов и созданием железа требуются более глубокие теоретические знания. Во-первых, как вы правильно заметили, все задачи на уровне железа требуют от инженера ясного понимания физики, которая кроется за тем или иным процессом. Во-вторых, изобретения и продукты, основанные на их решениях и выводах, должны быть очень надежными - слишком многое зависит от качественной работы этих вещей.

Тем неменее, иногда инженерам недостаточно просто знать точки подключения протокала "под ними". Например, компьютерные системы для самолётов или военное программное обеспечение. Абстракция помогает, по-моему, только на начальной стадии программирования, когда главная цель - создать рабочее решение проблемы. Далее, когда речь заходит об надежности в экстримальный условиях, быстродействии, совместимости, "дальновидности кода" и т.д. программист невольно спускается вниз по иерархии Computer Architecture.

Например, от ветеранов то и слышишь, что раньше "работали не на решение, а на лучшее решение". Потому что машины были намного слабее и тут программисту было непозволительно забывать о некоторых низкоуровневых вещах и о теории. Сейчас вещи обстоят иначе, но иногда это вредит программистам.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT