Який найважчий предмет / теорія CS, який ви вивчали, але важливий для цієї галузі? А причина будь ласка?
Який найважчий предмет / теорія CS, який ви вивчали, але важливий для цієї галузі? А причина будь ласка?
Відповіді:
"У комп'ютерній науці є дві важкі проблеми: кешування, іменування та помилки" 1 "
Чесно кажучи, побудова компілятора!
Дизайн та аналіз алгоритмів
Я думаю, що питання залежить від того, у кого ви були вчителі, і як цей предмет був організований у вашій кар’єрі.
Аналіз алгоритмів може бути таким же важким, як хтось хоче. Порахуйте, що є невирішені проблеми, і не тільки це: проблеми, які неможливо вирішити.
Вся справа в тому, що у вас може виникнути проблема, і якщо ви знаєте, що її неможливо вирішити, це ідеально. Але що робити, якщо цього не зробити? Ви можете витратити багато часу, намагаючись продемонструвати, що це NP-Complete, або намагаючись знайти поліноміальне рішення часу для його вирішення.
Продемонструвати NP-комплектність непросто. Так, відомо багато проблем, але справа в тому, щоб знайти скорочення, щоб продемонструвати, що це NP-Complete. А що, якщо ви витрачаєте багато годин / днів / місяців, намагаючись продемонструвати це, і це можна вирішити за багаточлен? :)
Існують також інші предмети, такі як « Компілятори» , «Теорія груп» та « Примітивні рекурсивні функції», які можуть бути такими ж важкими, як тематичний план або бажає вчитель;
Розпізнавання шаблонів, тобто Штучний інтелект. Це стосується розумних обчислень разом з іншими інструментами розпізнавання шаблонів, такими як Оптичне розпізнавання символів, Голос до тексту, Ідентифікація обличчя тощо.
Багато «крутих» речей, які ви можете зробити або бажаєте зробити з комп’ютерами, покладаються на ці алгоритми, і ми десятиліттями намагалися вдосконалити їх без великого успіху.
Мій вибір - теорія обчислюваності
(Хм ... може, це не так важливо, але це точно було складно)
У комп'ютерних науках є лише дві важкі проблеми: недійсність кешу та іменування речей. - Філ Карлтон
теорія категорій (дискретна математика), але варта того
Криптографія
Якщо ви зробите це злегка неправильно, це може коштувати компанії мільйонів.
Операційні системи, особливо та частина, яка має щось спільне з нанизуванням різьби.
І причина не в тому, що було важко змусити 5 філософів їсти піцу виделкою. Причина полягає в тому, що написання багатопотокового коду само по собі складно і не обов’язково легко для обчислення людського (принаймні чоловічого - на думку моєї дружини) розуму.
Я теж голосую за дизайн компілятора. Особливо там, де йдеться про частину ДФА та НФА. Я також не так чітко розумію проблеми та інше.
Добре технічно це галузь математики, але дуже актуальна в КС.
Майже все в CS засноване на чергах (видимих (очевидних) та невидимих (не настільки очевидних чи мається на увазі)).
У перші дні ЦС черги були очевидні.
Черга програм (кожна програма колода карт).
Нині черги не такі очевидні. Наприклад, Інтернет: мережа з комутацією пакетів, але пакети утворюють черги, а маршрутизація пакетів - це форма мінімізації черги.
Проблеми з іграшками, які вам даються в курсі, не надто важкі, але, коли ви починаєте розглядати реальні проблеми, це перетворюється на серйозну жорстокість.
Інтерпретація вимог клієнта, коли клієнт насправді не знає, чого хоче. Це не викладається в коледжі, і це одна з найважливіших навичок.
Особисто моя була формальною логікою. Почати з цього було важко, але як тільки ти зведеш правила і встигнеш з ним достатньо пограти, твій мозок іде Logic++;
, що в розвитку дуже хороша річ.
Як зауваження, я відповідаю на запитання безпосередньо - це, безумовно, не було найскладнішим предметом, коли я робив ступінь, але це, мабуть, найскладніший предмет у реальному житті.
Конструкції компілятора. Важко, але треба зрозуміти поняття, що стоять за цим
Кернел Дизайн кого? Ну, я не знаю, як це робиться і які цільові функції для ОС, але для мене думка про створення ядра повинна бути непростим завданням.
Я також думаю про безпеку комп’ютера ; Я не знаю, що робить систему небезпечною, за винятком, звичайно, явних переповнень буфера, інжекцій XSS та SQL.
Я не впевнений, але здається, що деякі алгоритми також небезпечні; подивіться на проект MetaSploit, у ньому перераховані всі типи та види порушень безпеки: ви можете бачити, що існує маса способів помилок програми.
У цій галузі є багато незручних тем, але мої вибори для постійних труднощів - це ті, що стосуються властивостей глобальної системи . Приклади цієї загальної теми включають:
Це важко, тому що ти шукаєш те, що існує лише тоді, коли все правильно; вам потрібна властивість глобальної системи, але практично всі наявні інструменти (і всі ті, що відносяться до справжніх проблем, на мій досвід) лише справді мають місцеві міркування. Це процес переходу від міркувань про фрагменти програми до цілого шебангу, який важкий, особливо тому, що цілком можливо мати фрагменти, які самі по собі правильні, але там, де все ще є непомітні помилки, оскільки компоненти неправильно розташовані; помилки можуть бути небажаними особливостями ...
Інформаційні послуги з менеджменту
У період навчання в коледжі у мене був один предмет управління кожний семестр, що цілком зводило мене з розуму.
Жорстко! а такі предмети , як Compiler Design , OS Design і т.д. жорсткі , але вони дійсно цікаві і складні. Я дуже заплутався в таких предметах, як інформаційна система управління / послуги тощо, оскільки вони сповнені нудьги, і вам доведеться пройти багато теорії.
Якщо ви працюєте в C / C ++, покажчики - це найважливіша концепція, яку потрібно знати. Але я якось не зрозумів це повністю в коледжі.
Який найважчий предмет / теорія CS, який ви вивчали, але важливий для цієї галузі?
Дискретна математика.
Це було важко, оскільки теорії дуже слабко пов'язані між собою, але вони використовуються в CS. Я думаю, що занадто багато запам'ятовування ...
Доведення індукцією, великим O, рекурсією, діленням і підкоренням, теорією графіків, бла-бла ... argh!
Компілятор для мене був легким, адже нам довелося взяти Теорію автоматів. ^^
Мені подобаються ваші відповіді (і я не забув їх відкликати), як компілятор, ядро тощо, але більшість програмістів ніколи не стикалися з цими проблемами. Існує трохи простіше, але більш поширене питання: паралельність - нитки, блокування. Написати програму, яка створює магічні помилки, дуже просто, якщо ми зробимо навіть невелику помилку в архітектурі одночасності.
Тож, я кажу, це не найскладніша проблема в обчислювальній техніці, але оскільки вона зазвичай використовується, вона небезпечна.
Об'єктно-орієнтоване програмування
Можливо, тому, що я різав зуби на FORTRAN та APL, але перехід від суто процедурних мов до предметів - це те, з чим я боровся протягом багатьох років. Це не допомагає так званим "експертам" писати суперечливі статті та навчальні посібники про те, що означає бути об'єктно орієнтованими та найкращими / правильними способами побудови об'єктно-орієнтованих програм.