Комментарии 480
"а потому, что программировать безумно интересно"
Думаю у многих это не так, скорее потому что ты начинаешь понимать, или ты научишься это делать, или рутина победит)
Что бы продуктивно общаться с компьютером, нужно уметь разговаривать на его языке.
Что бы продуктивно общаться с компьютером, нужно уметь разговаривать на его языке.
Нейросети, имхо, постепенно пошатнут это утверждение. Чего только стоит суета вокруг StableDiffusion. Разумеется не везде и не всегда, но постепенно возможности формулировки задачи на человеческом языке будут появляться в разных местах.
Другое дело, что часто люди даже на человеческом языке сформулировать задачу нормально не могут. Но тут ИИ тоже может хорошо сработать, и научиться понимать бессвязный поток мысли лучше, чем это делают сами люди.
А в остальном согласен.
Разумеется не везде и не всегда, но постепенно возможности формулировки задачи на человеческом языке будут появляться в разных местах.
В этой фразе отражается известное заблуждение, что эти возможности формулировки задачи на человеческом языке полезны. Нет, это не так — формулирование задач компьютеру на естественном, то есть плохо формализованном языке, как правило не нужно.
возможности формулировки задачи на человеческом языке полезны
ИМХО, возможности формулировки задачи на человеческом языке не полезны и не бесполезны, они просто снижают порог вхождения с уровня "умеет работать с компьютером" до уровня "умеет говорить".
И плюсы/минусы тут такие же как у любого другого снижения порога вхождения, например, у перехода от коммуникаторов со стилусом и WP к современным смартфонам, или от C++ к JavaScript, или от профессионального фотоаппарата к мыльнице/камере в смартфоне, или от текстового интерфейса к GUI. Профессиональных возможностей меньше, зато технология становится доступна широким массам.
И да, средний профессиональный уровень продукта, который делается с инструментами с низким порогом вхождения всегда ниже, чем тот, который делается профессиональными инструментами. Это плохо, но закономерно.
Неужели вы думаете, что если вам предоставят компьютер за миллиард долларов, то результаты вашей работы станут в миллион раз лучше, чем на компьютере за тысячу долларов?:)
Нет, я говорил вообще не об этом. Я не зря упомянул "средний уровень продукта", а не просто "уровень продукта". Попробую развернуть мысль.
Инструменты с низким порогом вхождения создают массовость, и из-за этой массовости средний уровень результатов работы, выполненной с помощью этих инструментов, как правило, падает.
Происходит это потому что к "высшему" (в плане профессионализма/ ресурсности/ проработанности) сегменту добавляется "средний" и "низший". Уменьшение количества затрат на получение результата влечёт за собой снижение требований к качеству - зачем тщательно всё выверять, если можно сделать много образцов/деталей, и выкинуть то, что не подошло. Или не выкинуть, а просто оставить мертвым грузом. Плюс, помимо профессионалов, которые долго учились работать с профессиональными инструментами, появляются новички, а потом и вовсе обыватели, которые теперь тоже могут решать подобную задачу. Они решают её хуже, но зато их много, и они могут делать много работы - им помогают дополнительные слои абстракции в инструментах. Это не плохо, это просто особенность, со своими плюсами и минусами.
Сюда входят истории в духе "быстрое приложение на C++ vs тормознутое приложение на JavaScript с гигабайтом почти неиспользуемых библиотек", "художественный уровень фотографии тогда и сейчас", автомобили тогда и сейчас, впихивание контроллеров во все возможные места даже там, где можно обойтись парой транзисторов. Потому что, по факту, решить задачу с помощью контроллера в большинстве случаев для большинства тех, кто это будет делать, проще, хоть это и не оптимально с точки зрения того, что там внутри происходит.
Лично у меня есть работающий компьютер 1990х годов с Microsoft Word 2000, и этот ворд на нём работает быстрее (по ощущениям, раз в 6), чем современный ворд на двухпроцессорной машине с RTX 3080Ti и NVME SSD. При том, что вычислительная мощность там отличается на 3 - 4 порядка, если не больше. Потому что новый Word создан с помощью инструментов, порог вхождения в которые ниже, чем тот, что был у Word 2000. Плохо это? Отчасти да, отчасти нет. Новый Word может больше, чем старый, хотя сам, будучи инструментом, утратил много черт профессионального инструмента, потому что стал массовым. Привет, ленточный интерфейс.
Разумеется, процесс превращения профессионального инструмента в массовый протяжён во времени, и часто на это накладывается другой фактор - научно-технический прогресс, который действует в противоположную сторону - чем новее продукт, тем больше возможностей. Но это два разных фактора, которые следует отличать.
Это всё ИМХО, конечно.
Инструменты с низким порогом вхождения создают массовость…
Массовость порождает новый «средний» уровень, но дисперсия уровня остается - так что новых выдающихся продуктов становится больше, чем вообще всех ранее созданных, что позволяет выбирать. И если вы себе выбрали микрософт офис, как вы отмечаете выше, это всего лишь ваш личный выбор и это вовсе не значит, что за прошедшие десятилетия не появилось новых отличных редакторов на любой вкус. Более того, я уже два десятилетия продолжаю пользоваться консольным midnight commander и абсолютно доволен его производительностью и встроенным редактором :)
помимо профессионалов, которые долго учились работать с профессиональными инструментами, появляются новички, а потом и вовсе обыватели, которые теперь тоже могут решать подобную задачу. Они решают её хуже…
Ох уж это завышенное самомнение… Просто приведу пример - в линуксе все было очень плохо с поддержкой веб-камер, пока один врач-анестезиолог 60+ лет не заинтересовался темой и не написал поддержку сотен камер just for fun. С тех пор в линуксе все хорошо с вебкамерами. Не каждый «обыватель» на это способен, но не нужно считать себя избранным и лучше всех «обывателей».
Ох уж это завышенное самомнение… Просто приведу пример - в линуксе все было очень плохо с поддержкой веб-камер, пока один врач-анестезиолог 60+ лет не заинтересовался темой и не написал поддержку сотен камер just for fun. С тех пор в линуксе все хорошо с вебкамерами. Не каждый «обыватель» на это способен, но не нужно считать себя избранным и лучше всех «обывателей».
Термины "профессионал" и "обыватель" здесь используются в значении "человек, долго и много изучавший и работающий с темой" и "человек, недолго и мало изучавший тему, и мало работавший с ней, или вообще не работавший". Без каких-либо намёков на избранность, и то, что одно плохо, а второе хорошо и даёт какие-то привилегии.
Если рассмотреть пример с анестезиологом с точки зрения того, что я написал выше, то можно сформулировать так: вероятность того, что анестезиолог починит программу есть, но, при прочих равных, она меньше вероятности того, что программу починит программист. Как минимум потому, что далеко не все анестезиологи могут программировать, как и далеко не все программисты могут делать анестезию.
Как и все «обыватели», вы не умеете считать вероятности, очевидно, потому что написал драйвера камер с нуля именно анестезиолог, несмотря на наличие десятков миллионов программистов :) Ну а программисты теперь эти готовые драйвера будут адаптировать под разные дистрибутивы и так далее, в общем, делать необходимую техническую работу, которая не подразумевает создания чего-то нового.
Как и все «обыватели», вы не умеете считать вероятности, очевидно, потому что написал драйвера камер с нуля именно анестезиолог, несмотря на наличие десятков миллионов программистов :)
Кстати, а так и не выяснилось, почему так случилось, что была потребность в работе с вебкамерами, но её никто не делал? Просто из-за сложности? И да, я обыватель :)
Потому, что «профессионалы» не работают бесплатно, а эту большую работу никто не оплатил. И только любители типа Торвальдса или того анестезиолога способны работать не за деньги.
Просто линукс — это даже не просто Большие Деньги, а Очень Большие Деньги. Т.е. его делают, в первую очередь крупные корпорации. И им гораздо важнее вылизанная поддержка mellanox, чем hid/video.
Просто приведу пример - в линуксе все было очень плохо с поддержкой веб-камер, пока один врач-анестезиолог 60+ лет не заинтересовался темой и не написал поддержку сотен камер just for fun
То что он анастезиолог не говорит о том что он обываьтель с точки зрения программирования, и что он до 60 лет ни разу не написал ни одного драйвера! Так что пример скорее всего не коректный.
Насколько помню, человек заинтересовался, научился и написал. Ну и что? Помнится, у нас преподаватель был приходящий из института прикладной физики или аналогичного, известный физик лет 75… так он в маткаде программировать научился в 70+, и вполне умел все нужное сам сделать. Просто ему было интересно.
впихивание контроллеров во все возможные места даже там, где можно обойтись парой транзисторовПотому что, к примеру, проще пустить всего два провода по кругу внутри машины: питание и данные, которые будут управлять всеми устройствами и снимать показания со всех датчиков сразу, точно выдавая диагностику по сбойному контроллеру. Вместо косы проводов толщиной в ногу, с непредсказуемыми глюками и убийственным прозвоном каждого проводка, для поиска проблем
Потому что новый Word создан с помощью инструментов, порог вхождения в которые ниже, чем тот, что был у Word 2000. Плохо это? Отчасти да, отчасти нет. Новый Word может больше, чем старый
А если рассмотреть это через призму того, что в старом Word от версии к версии добавлялось намного больше функционала, чем в современном, при этом команда разработчиков была меньше в разы?
Т.е. в сухом остатке, у нас новые инструменты, ниже порог вхождения, но продуктивность разработчика наоборот, упала по сравнению с 90-ми годами. В чём тогда прогресс?
впихивание контроллеров во все возможные места даже там, где можно обойтись парой транзисторов.
С этим-то как раз всё просто - обработанная медь сейчас на вес намного дороже обработанного кремния.
Тут работает принцип Парето - 80% работы занимает 20% времени. Все те 80% фич, которые можно было сделать быстро, уже давно сделали, и нынешним разработчикам достались сложные фичи, которые надо еще и накладывать на код, написанный давно и другими людьми
Ну это если не поддаваться ощущениям, что раньше трава была зеленее
Да не работает он тут, я же эту кухню изнутри много раз видел :) Огромное количество времени тратится на "а давайте перепишем вот это легаси", причём во многих случаях, если не в большинстве, полученный результат оказывается неудовлетворительным (ну потому что нельзя вот так взять и переписать два десятилетия старого кода, который зачастую ещё и плохо документированный), потом это кладётся под диван, а к легаси добавляются новые костыли.
Огромное количество времени тратится на редизайн ради редизайна, нередко с тем же результатом.
Очень много времени занимает бюрократия - митинги, согласования, коллы и прочая байда. Вам не приходилось присутствовать на полуторачасовых митингах, где утверждали добавление пары текстовых полей к сущности, а потом неделю их добавляли, тестировали, утверждали, деплоили? И так далее, и так далее...
Всё-таки в ИТ раньше трава была куда зеленее :)
Бесконечная история. В какой-то момент перешли на Word 2000 c 97-го и на машине с 32GB RAM он дико тормозил, нужно было ему 64GB. Был тогда очередной искусственный скачок цены на память. И я в какой-то момент держал оба Word-a. Один для работы, а второй для документов в новом формате. Теперь, конечно, летали бы и тот, и другой, а подтупливает, как ни странно, Word 2007. Вопреки 16GB RAM.
Ну и по опыту чат-ботов мы видим, что нормальный GUI все их применения кроет, как бык овцу.
Так вроде как раз всякие штуки вроде { }появились вместо BEGIN END отчасти потому что все намучались с выписыванием этих самых «человеческих слов».
сравните: a => a*a
И: TAKE ARGUMENT NAMED A AND MULTIPLY BY ITSELF
Можно, конечно сказать, что да я просто напишу «TAKE A SQUARED”, но чем это отличается от вызова функции из популярных библиотек, которые эти нейросети и используют. А еще, формулировки немного потеряют консистентность, если нейросети одно и тоже все будут писать своим неидеальным английским. Будем тогда ждать IDE от Grammarly :)
Чтобы писать "a => a*a" нужно знать, как это писать. А многословные формулировки вроде "TAKE ARGUMENT NAMED A AND MULTIPLY BY ITSELF", которые мы можем видеть в Basic/COBOL и прочих - это не естественный язык, а скорее подражание ему. На деле мы все равно пишем команды, просто многословно.
Речь же о том, что задачу обьясняют так же, как объясняли бы её человеку. "Хочу трёхмерный редактор укладки кафельных плиток с возможностью совместного редактирования через аккаунты Google". *появляется софт* "Теперь добавь возможность гуглить текстуру плиток, сделай интерфейс лаконичнее и убери это непонятное текстовое поле". "Сделай мобильную версию". Я имею ввиду примерно это.
Хотя тут уже постепенно отмирает необходимость в софте как таковом - под каждую задачу пользователя софт синтезируется с нуля, и процесс синтеза софта и решения задачи с помощью него сливаются в единый рабочий процесс.
Будет что-то типа «хочу чтоб плитка лежала красиво, цвет не вырвиглазный и дизайн лучше фейсбука».
Да зайдите на апворк и почитайте как люди формулируют задания, чтоли.
Вот кстати «сделай мобильную версию» без уточнения — вполне по человечески. Просто потом вам скажут, что хотели не такую.
хочу чтоб плитка лежала красиво, цвет не вырвиглазный и дизайн лучше фейсбука
Именно! Моё предположение как раз подразумевает, что ИИ, в том числе, позволит переваривать даже плохо сформулированные задачи, без конкретики, где заказчик/разработчик не может и двух слов связать, и не понимает чего хочет. А потом, когда увидит результат
Просто потом вам скажут, что хотели не такую.
И оно переделает. И будет переделывать и доделывать пока не получится то, что устроит. Это же ИИ, а не живые люди. Ему никогда не надоест, а кушает оно только вычислительное время.
В моём примере выше я как раз описал подход - сначала оно делает что-то, что сочтет нужным, а дальше уже человек уточняет, что должно быть, а что не должно. По желанию оно может набросать сразу 100 вариантов реализации, а пользователь выберет, что ему по душе.
Под естественным языком я подразумеваю не язык программирования, а фундаментально новый способ взаимодействия с компьютером, когда конкретика уже не требуется. Если угодно, это следующее звено цепочки перфокарты/перфоленты -> консоль -> GUI -> ???
Часто даже сам формулирущий не знает, как его «переварить».
Для того, чтоб ИИ справлялся хотя бы как мидл он должен быть полным ИИ, который приводит к сингулярности.
Вот я подозреваю, что не обязательно он должен быть полным ИИ, для того, чтобы решать эту задачу. Нейросети последнее время показывают большие чудеса, а там обученные веса нейронов занимают жалкие гигабайты.
И в этих нескольких гигабайтах хранится штука, которая может любые слова превращать в визуальные образы. Она помнит слова, помнит образы, помнит, как ведёт себя светотень. Совсем не так, как мы - то, что делает аналогичную работу в нашей голове, явно побольше нескольких гигабайт, и гораздо сложнее. Но результат-то почти идентичный.
Так и тут - оно, скорее всего, не будет думать так же, как мы, когда формализуем задачу и реализуем её в виде продукта, и не будет её так комплексно осознавать. Но это штуке это и не будет нужно.
Согласен. Но я допускаю, что знания из биологии могут иметь разный "формат", если можно так выразиться. Мы, люди, сформировали знание биологии с помощью такой совокупности образов и понятий, и других механизмов, которая хорошо ложится именно в наш мозг с его плюсами и минусами, и его архитектурой обработки информации.
ИИ же может выработать свой "формат" знаний, который лучше подходит его архитектуре, если так можно выразиться, "мышления". Нам только нужно каким-то образом донести в него информацию, чтобы он самостоятельно её систематизировал, так, как удобно ему. Как пример можно взять обучение нейросетей - это оно и есть, по сути.
Оно может не иметь сознания, не думать и не разговаривать, а просто пытаться имитировать то, что делает человек, находя закономерности. И когда имитация становится достаточно качественной, это можно использовать.
Возможно, я тоже не имею сознания, просто его «имитирую», ибо культура требует
Возможно, я тоже не имею сознания, просто его «имитирую», ибо культура требует
Мы закономерно пришли к проблеме философского зомби и вообще проблеме природы сознания и квалиа :)
Если оно может «имитировать» программу опираясь на знания в области, скажите тогда на минуточку, чем оно отличается от полного ИИ?
Примерно так же, как DALL-E отличается от мозга настоящего живого художника. Оно же не обязательно будет "опираться на знания в области" именно так, как это делает настоящее сложное сознание человека.
К примеру, мы довольно хорошо знаем, как функционирует муравейник, какие там химические команды для чего используются. Но муравьи, тем временем, химию не изучали, механику, планирование ресурсов с логистикой и архитектурой тоже, и, тем не менее, работу свою делают. Строят свой муравейник, еду таскают, тлю пасут (!), даже не осознавая (наверное), что они делают. Там это всё заложено на "аппаратном" уровне. Вот здесь примерно то же самое. Вполне вероятно, что для того, чтобы
«имитировать» программу опираясь на знания в области
достаточно гораздо менее сложных систем, чем сознание и полный ИИ. Вполне вероятно, что наш суперуниверсальный мозг сверхизбыточен для этих задач, и они могут решаться куда более простыми системами, без сознания и сильного ИИ.
Этот ИИ, разумеется, будет посложнее нынешних генераторов картинок, но он всё равно будет гораздо проще, чем человеческий мозг.
. Оно же не обязательно будет "опираться на знания в области" именно так, как это делает настоящее сложное сознание человека.
Но мы же на самом деле не знаем, как работает настоящее сложное сознание человека. Возможно, нам всего лишь нужно будет значительно увеличить количество кремниевых "нейронов" и усовершенствовать методы обучения, чтобы количественные изменения искусственных нейросетей переросли в качественные.
Мозг сделан из электрохимических нейронов с довольно медленными связями и упором на экономию энергии, и кучей аппаратных блоков на разные важные для нашего тела и выживания вещи. Мы же можем позволить себе конструировать электрические/оптические/квантовые/радиофотонные/??? сети без медленной химии, где сигнал движется со скоростью света, а не 30 м/с, и где энергии может тратиться гораздо больше. Вполне вероятно, что при таких вводных данных перехода к сознанию можно добиться куда более простой архитектурой, чем с той, которую имеет мозг.
И вполне вероятно, что то, что мы называем сознанием (будь оно реальным явлением или просто иллюзией), далеко не единственная форма такого качественного перехода. Вполне может быть, что этот ИИ придет к какой-то другой форме восприятия действительности, такой же феноменальной (или даже более феноменальной), как наше сознание, но устроенной по другому.
Вы хотите магии. Чтобы оно магически сделалось хорошо. Но нет, так не бывает.
В програзме такая "магичность" приводит к хрупкости. То есть, вы написали программу, её компилятор оптимизировал, она работает быстро. Потом вы изменили в каком-то левом месте что-то, и оптимизация компилятора больше не срабатывает. Всё.
То есть, когда мы пишем программы, мы хотим предсказуемости, стабильности результатов. "Наделение компьютера Алдан бессмертной душой" эту предсказуемость убъёт. В результате, оно будет когда работать, а когда — нет. Вместо гарантированного подбора кухни под гарнитур, оно иногда будет выдавать картины Дали.
P.S.
Постановка задачи ИИ, вселённого в автомат — это тоже текст, тоже программа.
Вы хотите магии. Чтобы оно магически сделалось хорошо. Но нет, так не бывает.
Любая достаточно развитая технология неотличима от магии (С) Артур Кларк
Современные авто с автопилотом, роборуки, роботы пылесосы, хлебопечки, 3Д-принтеры и квадрокоптеры тоже лет 50 назад казались бы магией.
Как это машина будет корову доить? У неё что, волшебные механические руки будут вымя дёргать? Да ну, глупости. — неточная цитата какого-то фильма про период индустриализации, название которого я не запомнил :/
Есть сказка про блюдечко с яблоком, через которое можно за людьми смотреть. Для времени, когда это было придумано, это была магия. Сейчас этих блюдечек больше миллиарда и их все носят в кармане. Эти блюдечки умеют с вами разговаривать, управлять вашим домом и моментально писать картины без холста, красок и кисточек. И помнить их все. Могут освещать вам дорогу в тёмный час, и достаточно лишь коснуться этого блюдечка в определенном месте, чтобы к вам примчалась карета.
Есть сказка про клубок, который разматывается и показывает путь. Это по современным меркам даже не то что не магия, это какая-то очень морально-устаревшая, даже, я бы сказал, концептуально устаревшая технология.
Как это пылесос сам комнату чистит? У моих знакомых бабушка не верила пока сама не увидела. Магия? Магия. В комнате само делается хорошо, делается чисто.
В програзме такая «магичность» приводит к хрупкости. То есть, вы написали программу, её компилятор оптимизировал, она работает быстро. Потом вы изменили в каком-то левом месте что-то, и оптимизация компилятора больше не срабатывает. Всё.
То есть, когда мы пишем программы, мы хотим предсказуемости, стабильности результатов. «Наделение компьютера Алдан бессмертной душой» эту предсказуемость убъёт. В результате, оно будет когда работать, а когда — нет. Вместо гарантированного подбора кухни под гарнитур, оно иногда будет выдавать картины Дали.
А как же баги? Это тоже непредсказуемость. В текущем подходе тоже всегда есть вероятность, что оно сработает не так, как надо. И бывает что разработчик тоже не понимает, почему оно так делает.
И если у ИИ вероятность багов будет равная или меньше, чем вероятность багов у текущего подхода — почему нет?
P.S.
Постановка задачи ИИ, вселённого в автомат — это тоже текст, тоже программа.
Да, но речь о том, что она будет не такая строгая. Это ближе к выносу реализации задачи на аутсорс вместе с проектированием, аналитикой, разработкой, кодированием и тестированием, только с поправкой, что всё это делает ИИ, и допускается изменение ТЗ тысячу раз с переделыванием всего тысячу раз, пока оно не будет работать так, как надо.
Это так, но при условии, что у тебя есть к этому тяга и если ты каждый раз получаешь какие-то новые задачи. Для гуманитариев обычно - это максимально неинтересно.
Не совсем понял что ты имеешь в виду. Как раз если у тебя одинаковые рутинные задачи, их было бы не плохо автоматизировать. А вообще, кого считать гуманитарием? Вот, к примеру, человек занимается историческими изысканиями, там такая бигдата получается, что нужны не поверхностные знания програмирования что бы это разгрести, но програмист, не знакомый с этой темой, не сможет это обработать корректно.
Что бы продуктивно общаться с компьютером, нужно уметь разговаривать на его языке.
И какой это язык? Один рисует, другой ведёт моделирование и т.д. И у каждого своё общение.
По этому поводу когда-то давным давно была написана статься "Операционные системы: зачем они инженеру?".
Да, а программист, как нестранно, программирует.
Вот и я, будучи уже более 50-лет программистом, осаюсь им прежде всего потому, что "программировать безумно интересно"
Я думаю, что 99.5% программистов никогда не сталкивается с умножением матриц.
0.4% делают это примерно так
c = matrix_multiply(a, b)а оставшиеся 0.1% уже более менее понимают, что, как и зачем.
Программист-самоучка может найти свою нишу и успешно в ней работать
А бывают программисты без своей ниши? Все вроде на чём-то специализируются.
Я боюсь, что IT уже выросло настолько что это не 0.1% (1 на 1000), а уже 0.001% (1 на 100000), кто будет писать свою математическую библиотеку.
В мире уже ~27 миллионов разработчиков.
c = matrix_multiply(a, b)
А потом долго думают, почему они не умножаются, а там просто размерности не совпадают.
Так он выдаст ошибку. Иначе что за библиотека.
Чисто теоретически это может быть что-то древнее и самописное, что просто возвращает код ошибки, но тут да, это искусственный пример, можно привести более реальный. Есть ситуации, где компилятор ошибку не выдаст, например если такой программист не знает что AB не обязательно равно ВА, тогда с точки зрения компилятора ошибки не будет, а вот результат работы программы будет неверным. И подобные ошибки без знаний уже можно вечность ловить.
Я думаю, в данном случае, под matrix_multiply понимается вызов функции из готовой библиотеки для работы с матрицами, коих не мало, и почти наверняка все такие случаи там проверяются и если что идёт не так возвращается ошибка в том или ином виде.
Недавно мне библиотека Eigen для C++ вполне себе генерировала ошибку компиляции при попытке перемножить матрицы не тех размерностей. Какой конкретно случай мне проверить, чтобы убедиться в "неполноценности"?
Если размеры матриц неизвестны на этапе компиляции, то и успешность операции умножения неизвестна на этапе компиляции. Каким образом язык (любой) может в таких условиях выдать ошибку на этапе компиляции?
все такие случаи там проверяются и если что идёт не так возвращается ошибка в том или ином виде.
В случае с произведением матриц АВ и ВА обе операции могут быть вполне законными, а значит никаких ошибок выдавать не должны, то есть программист должен просто знать, что в данном случае порядок умножения, в отличие от чисел, имеет значение. Если он этого не знает, то просто получит неверный результат, хотя чисто технически это не ошибка — библиотека вычислила то, что её попросили.
0.4% конечно, так делают. Но при этом понимание что такое матричное умножение - важно. Например, чтобы выбрать правильный порядок умножения. Да и в целом не понимая что такое умножение составить формулу врядли получится.
Формула в ТЗ написана :) Надо то ему скорее всего не матрицы множить, а или графику крутить, или производственные задачи решать на бизнес уровне. И некий аналитик уже написал формулу (скорее взял из учебника, но может и у эксперта-математика), и откуда взять каждую из матриц. Откуда может быть выбор порядка умножения у программиста?
Например импорт данных из 3д пакета в двиг игровой или наоборот, где меняется "сторонность" (не знаю как правильно по-русски, handedness), а если вдруг еще и вверх оси разные...
Ну может где-то прогеру и приходят задачи с формулами внутри. Мне вот не приходят. Может у меня работа сильно уникальная. Но врядли.
Ну не знаю, а как сдавать задачу, если формул в ТЗ нету?
Когда я сдаю что-то не тривиальное, то первый вопрос "а как проверить, что оно не врет" и проверка это ручной сценарий, посчитанный по формулам из ТЗ. А если их там нет, что мне говорить? "Мамой клянусь, правильно работает!"?
хмм ... обычно это мы пишем формулу, потом отдаем написанную нами формулу заказчику, он ее утверждает и мы добавляем итоговую формулу в ТЗ.
В финале - показываем, что наш проект работает по этой формуле :)
Ну вот простой пример:
Есть грузовик с седлом. Положение седла задано матрицей относительно грузовика. На седле еще одной матрицей задана точка которая должна быть совмещена с прицепом.
В свою очередь у прицепа есть точка крепления к седлу тоже заданная в локальной матрице.
Таким образом у меня есть 5 разных матриц трансформации.
Надо чтобы грузовик встал в такое положение, чтобы точка крепления на прицепе и на седле совпали.
Заказчик мне не будет формулу присылать. Заказчик скажет: "прицеп должен цепляться к грузовику".
Это, кстати, почти не выдуманная задача с реального проекта.
Ну вот вам написали в ТЗ - нужно брать трехмерные вектора ускорений с акселерометра мобильного телефона, поворачивать их на угол, растягивать и переносить туда, а потом пересчитать их длины. Насколько хватит знаний программисту самоучке сделать эту задачу простым и понятным образом?
если человеку требуется использовать в своём софте перемножение матриц, как минимум, он знает что это такое, как это делается, и зачем оно тут вообще надо.
На деле это вообще не так. Вы должны очень хорошо и легко оперировать с понятиями Дискретной Математики. Такими, как Множества, Отношения, Функции, Комбинаторика и Теория Графов. Иначе вы будете делать кучу глупых ошибок и потом еще дольше их искать. Исправлять и не замечать.
> Я думаю, что 99.5% программистов никогда не сталкивается с умножением матриц.
Примерное число программистов, которым может понадобиться на условной "следующей неделе" оптимизировать умножение матриц, составляет ~100%. И это не зависит от языка. Это зависит от предметной области - Встраиваемые системы или Хайлоад. 100% всего ПО мира это Встраиваемые системы или Хайлоад. Либо вам нужно писать своё перемножение матриц, т.к. на вашем железе свой SSE. Либо у вас какой-то Хайлоад и там матрицы 1000x1000 перемножаются. Только не нужно называть веб-разрабочиков программистами, хорошо? Или вообще всех айтишников программистами. Программист это только С++, Java, С# на проектах от 1 000 000 строк кода. Остальные - айтишники.
Очень странное разделение на "программист" vs "it-шник". С чего вы вдруг сняли звание программистов с людей, которые пишут не угодные вам программы?
Я так то радикал, считающий что программист должен знать хотя бы поверхностно как работает то на чем его программы исполняются. Но даже мне не хватает наглости выкидывать из программистов людей не имеющих таких знаний...
Я ни в коем разе не отрицаю необходимости знаний, но серьезность задач это какой то размытый критерий. Система в которой вам, ну например, приходит на почту счет за электричество это несерьезная задача? Подавляющее большинство разработки на планете это типичный энтерпрайз, взаимодейтсвие с базой данных, генерация отчетов, формошлепство, обращения к сторонним сервисам через разные апи, перемножать матрицы самостоятельно там не нужно, а если и кажется что нужно (not invented here?) то скорее всего что то пошло не так и этот велосипед потом обойдется недешево в поддержке. Если только не брать какие то научные отрасли, разработку компиляторов и различных фреймворков, то сугубо математические задачи встречаются довольно редко и как правило уже имеют готовые и отлаженные решения.
Изобретать велосипед таки приходится. Но в целом так как я тупой, мне немного сложно понять суть где я работал, но система по обработки данных работает для каждого банка и задача типовая. Так как я даже не понял сути, суть по сути не нужна. Но соответственно каждый банк изобретает свой велосипед, я как то задумался что такой движок вообще то должен быть в открытом доступе, но меня как то осадили быстро. Ушёл же тоже не разобравшись, но чётко понял что по сути фрейморк над которым работал, это типовая вещь для любого банка.
И готовые и отлаженные решения не редко написаны программистами-самоучками.
Высшее не для программирования нужно, а для понимания конкретной предметной области. Математика это всего лишь одна из таких областей, не более. Программист на заводе, как правило, имеет одни задачи, программист игр совсем другие. Часто им математика нужна на уровне а * b = c.
Высшее не для программирования нужно, а для понимания конкретной предметной области.
И даже это нужно далеко не всегда (пусть и нужно)
У меня был опыт, когда с одной стороны приходил дизайн странички, которая должна по вводу некоторых параметров осуществлять расчет внутри и выдавать другие параметры, а с другой - Excel файлик с примером расчетов (с формулами)
Соответсвенно, как и почему работает так, а не иначе - было интересно исколючительно из общего развития, но на результат не влияло
С учётом того, что народ часто по делу озабочен асимптотиками, математика нужна на уровне аппроксимации частичных сумм рядов. Это конец второго курса.
Для подавляющего большинства случаев ассимп оптику того или иного решения можно посмотреть в <s>таблице красных резиновых мячиков</s> справочнике.
Можно. Но зачем, если можно это понять? И, соответственно, выводить. То есть, быть самостоятельным?
Полагаю, использование библиотек вы тоже порицаете?
Я могу в душе не знать, как работает sort в условном питоне, но при этом его использовать.
А это дает разброс ассимптотик с ним (для адекватных случаев) n/log(n)
Полагаю, использование библиотек вы тоже порицаете?
Вы таки знаете, что чтобы хорошо использовать библиотеку, нужно примерно представлять, что она делает?
А это дает разброс ассимптотик с ним (для адекватных случаев) n/log(n)
Вот-вот.
Вы таки знаете, что чтобы хорошо использовать библиотеку, нужно примерно представлять, что она делает?
Это разве не противоречит принципам инкапсуляции из ООП?
Я должен твердо знать, что быбилотека (библиотечная функция) ожидает получить на вход и что она отдает на выход. Остальное - черный ящик.
В архиредких случаях который приходится приоткрывать, но речь сейчас не об исключениях.
Ну тут даже непонятно, что сказать. Вы когда-нибудь работали программистом?
В том числе в настоящее время
Веб, фронтенд. Миддл+
Понимаю, что вероятнее всего на бекенде своя специфика, но тем не менее
Тогда вы обязаны знать, что все абстракции текут.
Давайте определимся - мы исходим из фундаментального хорошего программирования, или из сурового энтерпрайза?
Если рассматриваем первый случай - согласен с вами по всем пунткам. Да, программист должен иметь возможность посчитать ассимптотику любой используемой функции. Да, нужно понимать не только что делает функция, но и как она работает. И так далее
Но на практике же, когда над кодом куча уровней абстракции и производительность (повторюсь, смотрю со стороны фронта) важна лишь в той степени, чтобы у пользователя из 95% перцентиля устройств не лагало при серфинге - этому не уделяют столь пристального внимания. И когда я (условно) подключаю к страничке MobX - я не лезу читать 4MB исходников, я просто ожидаю, что он ведет себя так, как описано в документации. И только если вдруг я натыкаюсь на неожиданное поведение, которое не гуглится в issues - тогда можно и попробовать разобраться что там под капотом. По факту, такая ситуация за последние 3 года была только 1 раз.
Хорошо это или плохо - вопрос открытый. Но так есть.
По крайней мере, сужу по личному опыту - если у вас он расходится, то поправьте.
А еще вы можете знать как работает sort в условном питоне, знать другие сортировки и понять что для вашего конкретного случая лучше подойдет другая сортировка из-за известной природы данных например (ну допустим надо сортировать целые положительные числа не больше 1000), и вы можете сразу использовать более оптимальную сортировку сохранив время и нервы следующим программистам кому возможно придется оптимизировать продукт в будущем.
Сочетание слов "математика нужна" уже отпугнёт много людей)))
Для понимания конкретной предметной области нужно понимание конкретной предметной области, а не формальное высшее образование. Получить понимание предметной области можно кучей разных способов.
К счастью, программисты приучены учиться все время и освоение контекста на новой работе вполне реально и обычная практика за время онбоардинга. Пришел, увидел кучу незнакомого, погрузился в область и продолжил, либо ушел. А так если требуется что-то гипер специфичное, то скорее проще базово обучить разработке специалистов этой области.
Вы намешали в кучу два понятия - высшее и математика. Нужно ли для овладения профессией идти в вуз? Безусловно нет. Я работал в веб студии, где из 30 человек лишь трое учились в профильном вузе и лишь один из них его закончил. Тем не менее они получали большие проекты от очень крупных компаний и успешно их реализовывали.
Нужна ли для программирования высшая математика. Мой 20-летний опыт говорит что нет. А даже если бы и была нужна, то снова вопрос что мешает изучить её самостоятельно при обилии материала в интернете? Ничто.
Поэтому опыт показывает что разговоры о необходимости вышки ведут исключительно те, у кого она есть, тем самым они набивают себе цену. Ни один из программистов, кто пришёл в ит самостоятельно, не жалуется на отсутствие вышки. У них есть большой выбор работы и хорошие зарплаты.
Что значит - не хочешь свой 3D-движок на С++ писать? У друзей-то, небось, уже по 2, а у кого и 3 пет-проекта! Так и станешь никчемным тим-лидом без корней.. таймеры-то тикают!
Я думаю, что математика нужна для организации работы мозга, как тренировка, как дисциплина. ВУЗ - это тоже своего рода дисциплина, по крайней мере по изначальной задумке. А так да, материалы в интернет по программированию вполне позволяют самообучаться.
Однако, как бы то ни было, мудрое сочетание теории и практики - золотой навык, который без высшего образования, всё-таки, трудно получить, и даже имея высшее далеко не сразу приходит такой навык (если вообще приходит). Нельзя выбрасывать теории, но и нельзя игнорировать практический опыт.
Я думаю, что математика нужна для организации работы мозга, как тренировка, как дисциплина.
В школе у вас математики не было? Или просто за десять лет натренировать мозг нереально и нужно ещё пять?
Однако, как бы то ни было, мудрое сочетание теории и практики
Вот именно поэтому вуз и кажется мне бессмысленным, поскольку там что угодно, кроме мудрого сочетания теории и практики. Очевидный перекос в сторону теории, причём неизбежно устаревающей, ибо высокоуровневое программирование это в сущности набор абстракций, которые очень быстро меняются и совершенствуются с развитием систем, вследствие чего все ваши теории весьма быстро устаревают, и в сухом остатке мы имеем живой ум(либо же его отсутствие) способный воспринимать новые абстракции усовершенствованных языков и подходов и использовать их в работе.
абстракций, которые очень быстро меняются
Извините, что там быстро поменялось? Модная в узких кругах линейная логика появилась до того, как я пошёл в институт.
В школе просто алгебра и геометрия (по отдельности), а в вузе матанализ, "алгебра и геометрия" (вместе), комплексный анализ, матлогика, теория вероятностей и матстатистика, дискретная математика, теория принятия решений, теоретические основы автоматизированного управления и еще многое другое уже на стыке математики и программирования. Вся эта комбинация вправляет мозги на всю жизнь)
"В школе у вас математики не было? Или просто за десять лет натренировать мозг нереально и нужно ещё пять?"
Была. Но понятие "матрицы", введенное в сентябре на первом курсе, сломало мозг :), перевернуло сознание. Не так было очевидно с индексацией, то же умножение матриц - целый новый мир, не говоря уже про линейные зависимости, определители...
"Очевидный перекос в сторону теории"
Да, на то он и ВУЗ. Нельзя всё сразу, и даже работая после инженером, такой золотой опыт приходит не сразу.
Проблема всей отрасли в целом, что она недостаточно формализована, из-за чего сбор информации для обучения других превращается в пытку. Темпы развития ПО требуют улучшать только то, что приносит деньги. И в итоге оно развивается больше как сфера бизнеса, нежели инженерная дисциплина.
Как пример, можно почитать про алокацию и покрытие тестами. Если первое будет в стиле "ну там аэ линейный алокатор крч, эээ", то на второе тебе дадут 100500 примеров как что и где писать, даже свой фреймворк для тестов с нуля.
(Мимо крестопоклонник)
Матанализ, линейная алгебра, дифуры и т.п. особо не устарели с того момента как мне их преподавали в вузе. Зато теперь по работе если я вижу криволинейный интеграл я не пугаюсь и не иду разбираться с 0 что вообще такое интегральное исчисление.
Т.е. вы не видите разницы между школьной "математикой" и высшей математикой вуза? Вот она и настраивает мозги на нужный лад, позволяет мыслить глубже и шире.
Вы намешали в кучу два понятия - высшее и математика.
В отличии от непосредственно программирования, как раз математику без учёбы в ВУЗе освоить крайне малореально. И если предметная область требует наличия математических знаний, надо получать высшее.
что мешает изучить её самостоятельно при обилии материала в интернете? Ничто.
Как минимум,
а) отсутствие учебного плана, по которому можно в нужном порядке изучать различные разделы
б) отсутствие человека, который в интерактивном режиме объяснит непонятные моменты, который в случае изучения высшей математики будет на порядки больше, чем при изучении программирования
в) ничтожное количество профильных форумов, по сравнению с программированием, где можно получить ответы на свои вопросы
г) длительный срок обучения. Стать программистом-джуном за полугодичный курс худо-бедно можно, если вы прилежный ученик. Стать математиком-джуном, это надо несколько лет упорного труда потратить - все эти матаны, терверы, матстаты, их просто много. И если программист может обойтись каким-то одним направлением, в котором работать, бэкграунд математика включает массу смежных направлений, которые все надо понимать.
разговоры о необходимости вышки ведут исключительно те, у кого она есть, тем самым они набивают себе цену
Ну, да, но это работает в обе стороны, потому что разговоры о ненужности вышки вышки ведут те, у кого её нет, и обычно с той же целью :)
Истина тут, как всегда, банально посередине - есть предметные области, где вышка нужна, есть где не нужна. CRUD-формочки клепать можно и без вышки, финтех автоматизировать лучше с вышкой за плечами, причём желательно финансовой/экономической, а не ИТ. Так-то да, если у вас нет вышки, сейчас в ИТ вы без куска хлеба не останетесь, но если у вас она есть, вам будут доступны дополнительные возможности карьерного/профессионального развития, что лишним не бывают.
Как минимум,
а) отсутствие учебного плана, по которому можно в нужном порядке изучать различные разделы
Я бы еще добавил к этим пунктам отсутствие человека, который может проверить решение и указать на ошибку. Нет, можно конечно найти себе личного ментора, который будет все это делать, но едва ли для большинства это проще, чем отучиться в вузе.
Ну, да, но это работает в обе стороны, потому что разговоры о ненужности вышки вышки ведут те, у кого её нет, и обычно с той же целью :)
Тем не менее, в одну из сторон это все же работает лучше, поскольку тому у кого есть вышка, есть с чем сравнивать – он побывал в обоих состояниях, и в состоянии "без вышки" и в состоянии "с вышкой", тот же, кто ее не получал, находился только в одном из них :)
Да и по времени — оказалось достаточно года-двух чтения всяких книжек и прорешивания упражнений, чтобы вполне себе на равных разговаривать с выпускниками факультетов чистой математики по этим направлениям.
Ну, то есть, ты за стандартные 1.5 года получил "магистра" по этой тематике, имея 4 курса близкой к математике специальности + магистра физики. Ну нормально. А если ты ещё 3 года потратишь на аспирантские курсы + выпустишь примерно 3 статьи, то будешь на равных с Эриком :-).
По моему опыту, я иду от конкретного к абстрактному. Я не могу воспринимать арифметику Пеано, не научившись школьной в совершенстве. Поэтому, кмк, может не всё, но оно полезно.
Да и в програзме суммирование рядов вполне себе нужно. Не даром ассимптотики везде спрашивают — это реально пригождается, пусть и не ежедневно. Да, можно, как один китаец мне на собеседовании сказал, "заучить", но зачем, если можно понять? И, соответственно, выводить.
через очень простые соображения, и суммировать ряды там не нужно
Это как это?
В смысле — можно на пальцах просуммировать частичные суммы рядов? Ну можно, но шаг влево, шаг вправо и опа, как сделать неизвестно. А дальше вон, мне там выше рассказывают, что абстракции ООП должны инкапсулировать усё. Ха, ха, ха.
Высший пилотаж в оценках сложности — это работать через производящие функции. Вот это позволяет получить и коэффициенты, правда при этом надо иметь более детальную модель машины, чем просто RAM.
И туда, хочу отметить, твоя условная деятельность и должна идти: автоподсчёт сложности подпрограммы — светлое будущее всего человечества.
интервьювер расстраивался и ставил минусик, потому что считал, что это эквивалентно O(n log n), и типа ты не понимаешь O-нотацию.
Ну дятлов-то полно. Я летом беседовал с разными кадрами, народ, как правило, не знает, что такое хвостовая рекурсия. Это к вопросу о нужности профильного образования (SICP — это вообще-то "Введение в специальность").
Такими соображениями покрывается походу этак 99% задач на собеседованиях, а на практике — ну, см. выше, бенчмаркать надо.
На практике очень разное попадается. И иногда очень развесистые вещи, но это в интересных группах.
Ещё проблема отсутствия образования в том, что "люди не знают того, чего они не знают". Если человек не слышал про ряды, не научился их суммировать, то когда ему попадётся жизненная возможность это использовать, он её пропустит. То есть, банально не увидит.
Ну да, некоторые вообще дальтоники. Но зачем сознательно выбирать этот путь?
В программировании суммирование рядов - это скорее Тейлор/Маклорен - Фурье/Лаплас, нежели асимптотики сложности, и это очень-очень нужно.
Ну, обработка сигналов - довольно обширная предметная область, и было бы странно её исключать из кругозора программистов. Так можно договориться и до того, что деревья поиска не нужны.
Настолько обширная, что жизни не хватит даже на малую ее часть. Например, вы много про полиспектральный и кумулянтный анализ знаете? Или можете посчитать, как связана фрактальная размерность вашего дерева поиска с его эффективностью? Хорошо бы, конечно, знать все - но невозможно - если вы потратите годы на анализ сигналов, то на программирование уже времени не останется.
Абсолютно любая область человеческой деятельности глубиной в жизнь, если в неё закопаться. Но это не значит, что не нужно иметь хотя бы поверхностного представления об основах выбранной вами профессии, как узкой вашей ниши, так и соседних.
Академическое образование это вовсе не про «поверхностное представление об основах», а про углублённое изучение нескольких узких тем. Для «поверхностного представления» школы существуют. Впрочем, выше в обсуждении подсчета корреляции вообще не нашлось пока ни единого комментатора, кто хотя бы среднее посчитать мог (несмотря на мои подсказки, что среднее может меняться во времени и стремиться к бесконечности при наличии линейного тренда, к примеру)… хотя многие похвастались «солидным» высшим образованием. Какая такая обработка сигналов, если люди среднее значение не способны посчитать?
Кстати, а вы могли бы мне объяснить, что такое фрактальная размерность для чисто дискретной структуры, которая к тому же не имеет геометрической реализации?
«дерево поиска» для математики это граф и его фрактальную размерность можно посчитать. Кстати, фрактал Фибоначчи для абстрактной последовательность Фибоначчи вас не смущает?:)
Насколько я знаю, хаусдорфова размерность предполагает наличие метрики, которая не определена на дереве поиска. Вы не могли бы посчитать размерность полного двоичного дерева глубины 1, чтобы я понял, о чём идёт речь?
Любое дерево поиска обязано иметь ключ для операций сравнения в каждом узле, значит, можно определить и метрику для них. Например, дистанция между смежными узлами равна модулю разницы двух ключей. Если хотите, можно использовать и другую метрику - скажем, расстояние между двумя узлами равно количеству ребер в пути, соединяющем эти узлы. Практический пример бинарного дерева поиска - «заметающая» кривая (z-кривая) для индекса на плоскости (для географических данных часто применяется) - очевидно, чем выше фрактальная размерность, тем лучше эта одномерная кривая «заметает» (покрывает) плоскость, а при размерности единица такой индекс невозможно использовать на плоскости.
Вы подождите сыпать ключевыми словами, они меня не пугают, тем более, что конкретно с этими я работал не один год.
Ни кривая Лебега, ни кривая Гильберта не являются деревьями поиска. Это вполне себе непрерывные кривые, с совершенно конкретным погружением в евклидово пространство, что естественно даёт метрику.
Давайте всё же вернёмся к вопросу про фрактальную размерность дискретных объектов. Так какова фрактальная размерность дерева из трёх элементов? Давайте возьмём конкретный пример, дерево 7 <- 13 -> 114.
Классический фрактал канторова пыль - дискретный и представляет пример симметричного дерева поиска с размерностью 0.63. Для вашего случая размерность Минковского получается 0.76 - как и полагается по теории, размерность точечного множества находится в диапазоне от 0 до 1. Считается стандартно - вычисляя, сколько покрывающих отрезков разного масштаба нужно, в вашем случае два отрезка длиной 114-7=107 или 23 отрезка длиной 5 покрывают оба ребра графа.
Дополнение к комментарию @0xd34df00d про несерьёзность вашей арифметики.
фрактал канторова пыль - дискретный
Можете не продолжать. Дискретное множество - это конечное или счётное множество, но никак не континуальное, как канторово.
Вы путаете всюду разрывное множество и дискретное.
Ерунду пишите - бесконечное множество это абстракция, которую вы не можете ни посчитать ни сохранить, так что численно обрабатывается всегда ограниченный набор точек множества. Заявлять про бесконечное множество, которое вы считаете на компьютере - даже не смешно.
Вы как-нибудь договоритесь с голосами в вашей же голове. Я-то изначально предлагал оперировать множеством из трёх элементов, это вы мне то множество Кантора, то фрактал Фибоначчи, то z-кривую упоминаете. При том, что они не только не конечные, но даже не счётные множества точек. И при этом путаетесь в простейших определениях. Ясно-понятно.
Есть много определений фрактальной размеренности, выбирайте любой. Я вам посчитал классическую метрику - не понимаете, так гуглите, а не скандальте, что теория неправильная. Глубина индексного дерева вполне очевидно связана с его эффективностью, и количество ключей связано с глубиной дерева - то есть определяют фрактальную размеренность дерева.
В этой жизни вообще мало что является жизненно необходимым. Однако мне кажется, что понимать, чем отличается bmp от jpeg, нормальный программист должен.
Мне кажется, что вы неверно истолковали моё высказывание. Давайте я перефразирую. Никакой программист мне ничего не должен. Каждый сам делает выбор, чему и насколько глубоко учиться. Лично я и в диалектах жипегов разбираюсь, и (относительно поверхностное) представление о формальных методах имею, и ещё в моём арсенале изрядный список всякого, что, на мой вкус, повышает мои шансы на рынке трудоустройства.
Вы спорите с утверждениями, которых я не делал. На фразу @vkni о том, что суммирование рядов - полезная вещь, вы ответили, что не очень. Это я оспорил, но при этом не предлагаю изучать функциональный анализ в ущерб (условно) топологии. Я думаю, что информатика - это подраздел математики, и иметь базовое представление об основных ветвях оной очень полезно, но при этом заставлять никого не собираюсь.
Подводя итог, мы спорим ни о чём.
Когда-то мне в руки попался послевоенный школьный учебник родом из СССР с названием «алгебра логики и контактные схемы» - в котором была подробно изложена бинарная логика и ее применения. Так вот, для задач программирования этот учебник куда полезнее всей вузовской математики. А современная вузовская математика с бесконечно малыми как пределами последовательностей - для программирования более вредна, чем полезна, куда лучше почитать историю физики и как Ньютон и прочие «древние» вычисления «на бумаге» проводили.
современная вузовская математика с бесконечно малыми как пределами последовательностей
А можно ссылочку, подтверждающее ваше, очевидно, неверное утверждение? Чтобы два раза не вставать, правильное тут: https://dic.academic.ru/dic.nsf/ruwiki/362918
Рекомендую обратить внимание на фрагмент оттуда:
В течение всего XVIII века предпринимались грандиозные усилия для исправления положения, причём в них участвовали лучшие математики столетия, однако убедительно построить фундамент анализа удалось только Коши в начале XIX века. Он строго определил базовые понятия — предел, сходимость, непрерывность, дифференциал и др., после чего актуальные бесконечно малые исчезли из науки. Некоторые оставшиеся тонкости разъяснил позднее Вейерштрасс.
По вашей ссылке написано ровно то, что и я писал выше:
«Бесконечно малая величина — числовая функция или последовательность, которая стремится к нулю.»
Так вот, в физике это не работает - скажем, заряд в точке представляется дельта-функцией, но вы не можете вычислить (конечную) производную от дельта-функции, что необходимо. И до сих пор это решается нестандартным анализом - тем самым, которым Ньютон пользовался:
https://ru.m.wikipedia.org/wiki/Нестандартный_анализ
представления об актуальных бесконечно больших и бесконечно малых величинах сохранялись в учебниках физики и других естественных наук, где часто встречаются фразы вроде «пусть dV — (бесконечно малый) элемент объёма…»
Так что бесконечно малые как самостоятельные величины из науки отнюдь не исчезли, и без них невозможна современная физика.
По вашей ссылке написано ровно то, что и я писал выше:
Вы написали " бесконечно малыми как пределами последовательностей". А предел, если существует - в данном случае - ноль. Число. Но на самом деле мне было интересно про современную ВУЗ'овскую математику услышать.
И до сих пор это решается нестандартным анализом - тем самым, которым Ньютон пользовался:
А потом прекратили этим пользоваться. Я не математик, а физик, но вот от этой фразы я офигел:
Нестандартный анализ — альтернативный подход к обоснованию математического анализа, в котором бесконечно малые — не переменные величины, а особый вид чисел.
Не, ну зачем? Это дает возможность предсказать (точнее доказать что-то новое)? Так нет.
часто встречаются фразы вроде «пусть dV — (бесконечно малый) элемент объёма…»
А это сленг. Такая вот странная хрень, которая в свободном виде не встречается, как те кварки. Или в составе производной, или в интеграле.
Я очень рад, что вы подхватили использованное мной ключевое слово
Нет, нет, я только процитировал википедию.
Про аксиому Архимеда я писал, а не вы, это уж вы через край хватили - приписывать себе аргументы оппонента. Или вы просто не понимаете, как связаны аксиома Архимеда и нестандартный матанализ? Так вот, эта аксиома куда древнее Ньютона.
можно отталкиваться от того, что интересно и хочется изучить, и разматывать клубок обратно
Хорошо, если вы гений типа Ломоносова.
Вышка есть, считаю ее ненужной для подавляющего большинства программистских задач.
Ну да, правило 80%/20% и тут годится ;)
Банально, написать трекер на МК. (Ремешок на руку цепляешь и он отслеживает движение)
Ты идёшь, читаешь, узнаешь что такое кватернионы, узнаешь матан, видишь что датчики шумят, читаешь за фильтры, работает но херово, не нравится идёшь читать за другие фильтры, находишь целую область что этим занимается, находишь страшные слова с дисперсиями вероятностей, читаешь чо это такое, читаешь что это это такое....(минус две недели) Понимаешь что большинство шумящих измерений нужно калибровать, понимаешь что это дорого и пытаешься в мат анализ чтоб научится подбирать коэффициенты для фильтра. Худо бедно подобрал параметры - работает.
9 классов, без вышки, трекер с "удовлетворительной" точностью, не победил только накопление ошибки, нужно калибровать каждые пол часа.
Может стоило бы и в ВУЗе отучиться, потратил бы меньше времени на поиск инфы, но в целом за пару-тройку месяцев разобрался, понял что есть и куда расти по этой теме.
Upd единственный проект за мою жизнь с матаном, даже в написании компиляторов матан не нужон.
трекер с "удовлетворительной" точностью, не победил только накопление ошибки, нужно калибровать каждые пол часа
То есть задача вроде как решена, но пользоваться результатом фактически невозможно.
Зато узнал про матан, фильтры и пр.
В моём случае не хватило денег.
Инерциальные датчики по своей природе не точные, можно вешать бесконечное их количество, но ошибка в любом случае будет накапливаться. В VR шлемах используют +4, или ставят один супер крутой и дорогой.
Поэтому тебе нужны другие датчики которые как-то могли бы подкорректировать текущее предсказание по движению. Даже 3х осевой эхолот может помочь. Если проще, когда ты не будешь двигаться эхолот будет говорить правильные координаты комнаты и фильтр уберёт ошибку в ускорении от других датчиков. (Ты помотал головой, остановился, а у тебя камера плавно плывёт в нужную точку и лишняя инерция от прошлого движения убирается. Но это если учитывать что комната это куб)
***У тех же VR шлемов просто камеры ставят и пытаются в конструкцию комнаты в динамике, а инерциальные датчики просто за мелкие движения отвечают.
еще раз перечитайте на что отвечаете. математик-джун - имеет теорию, но не имеет опыта, и если вы
>Мне интересны всякие там теории типов с матлогами — и мне совершенно не нужны матаны (как анализ бесконечно малых), теорверы, статы, диффуры, урматы, функаны, ТФКП, методы оптимизации, и прочая хрень из стандартного курса прикладной математики.
этого не знаете, то вы даже джуном не стали) да и говорить на темы на одном уровне и решать задачи все же разные вещи, разве нет? а вообще лучше ботать матешу(всю естественно) и параллельно решать олимпиадные задачи на любые темы. это просто прокачка мозгов, а так худо-бедно джуном лет за 5 можно
И если предметная область требует наличия математических знаний, надо получать высшее.а если не требует? На мой взгляд, сейчас (т.е. когда разнообразие задач увеличилось) в основном (т.е. подавляющему числу) программистам математика (выше арифметики) не требуется.
Но мозги математика дисциплинирует, это точно. Хотя возможен и обратный процесс — «хорошие мозги» легче «впитывают» математику.
а) отсутствие учебного плана, по которому можно в нужном порядке изучать различные разделыналичие учебных планов в [отечественных] ВУЗах не говорить о том, что в тех планах «разделы изучаются в нужных порядках». И что хоть как-то показывается взаимосвязь разделов, требования. Но это не проблема высшего образования, это проблема конкретной его реализации.
б) отсутствие человека, который в интерактивном режиме объяснит непонятные моментыналичие ментора — бесценно.
наличие учебных планов в [отечественных] ВУЗах не говорить о том, что в тех планах «разделы изучаются в нужных порядках». И что хоть как-то показывается взаимосвязь разделов, требования. Но это не проблема высшего образования, это проблема конкретной его реализации.
Обычно в вузе есть достаточно опытные преподаватели, которые чисто на собственном опыте могут сказать, в каком порядке студентам нужно изучать темы. Иногда, правда, им мешают образовательные стандарты, из-за чего и получается ситуация в стиле «сегодня я вам расскажу как делать вот эту фигню, а зачем эту фигню делать и почему именно так, а не иначе — вам расскажут через два года».
чисто на собственном опыте могут сказать
во-первых, это должны не «преподаватели говорить», а учебный план. типа «для курса ОТЦ нужны такие-то разделы математики и такие-то физики». «для курса аналоговой электроники нужны курс ОТЦ и вот такие разделы математики», а «для ЦОС » — соответственно свой набор. Ну и аналогичная связь внутри разделов математики…
во-вторых, «могут» <> «делают».
в третьих, все сводится «учите эту фигню, потому что она в учебном плане». Из-за чего на 4-5 курсе у некоторых появлялись озарения «если б я знал, что *** в этом предмете понадобится, я б ее на первом курсе учил, а не проходил»
Да, нам («небольшой группе активных студентов») взаимосвязь и необходимость различных предметов рассказывали преподы и старшекурсники, но это были «частные разговоры» в лабе за кружкой чая. А бОльшая часть сокурсников «учила» потому, что «есть в расписании».
И за 30 лет ситуация не сильно изменилась (сын сейчас заканчивает этот же ВУЗ)
После учебы в вузе вы будете свято уверены, что бесконечно малое это есть не реальная величина (согласно аксиоме Архимеда) и очень удивитесь, что в реальности это не работает. К примеру, Ньютон и прочие «древние» (не только физики, но и математики, кстати говоря) всегда оперировали бесконечно малыми как реальными величинами (нестандартный анализ), что физически корректно в силу квантованности пространства и времени. И в численных вычислениях вы с концепцией бесконечно малого ка предела последовательности окажетесь в ситуации гораздо хуже самоучки, кто для самообразования почитал историю физики или математики:) А уж чтобы кто-то после вуза умел оперировать системами функций (изучите свойства системы тригонометрических функций разного масштаба - получите анализ Фурье, к примеру), которые являются фракталами, кстати говоря - но почему-то фракталы в итоге описал прикладник Мандельброт, а вовсе не фундаментальные математики. И это я еще о реальном уровне выпускников не говорю.
Да, что-то я не видел человека, который функан заботал бы сам)
А академические знания можно только в ВУЗ-ах получить? Выпускникам ВУЗов видимо и в голову прийти не может что некоторым людям не нужен ВУЗ чтобы научиться матрицы перемножать или читать формулы.
я методичку по линейной алгебре взял из библиотеки в 10м классе и всю ее прочитал.
Не скажу, что сильно фундаментально продвинулся, но линейное программирование я более-менее понял еще до университета. И еще я для себя понял, что все возможно выучить - если есть мотивация и свободное время
Так линпрограммирование это же симплекс и тд, нам на линейной алгебре его давали вроде.
Капец. Хотя чему я удивляюсь, в вузах же считают, что линейная алгебра — это про матрицы, а симплекс-метод использует матрицу...
А на каком спецкурсе ВУЗа вы ожидаете увидеть симплекс метод?
Я конечно подозреваю, что "если у вас был предмет высшая математика, то высшей математики у вас не было", но вот в какой семестровый/двухсеместровый курс воткнуть симплкекс кроме линейки я не представляю.
Ну если только есть что-то совсем прикладное и в его рамках изучить линейное программирование как один из методов решения прикладных задач. У нас совсем прикладной курс был двигетели летательных аппаратов, поэтому симплекс был на линейке.
А где такой курс читали? Потому что я в теорию программирования отнёс бы матлогику, вычисляемость, исчисление типов и т.д...
Линейное программирование - это подраздел исследования операций, а не алгебры как таковой...
ну там была не тоненькая методичка, а такое себе "пособие для ВТУЗов" ..
и да, как уже выше написали, - в начале там база про векторы, тензоры и матрицы, системы уравнений и линейные преобразования (пару абзацев про теорию представлений),
а потом уже про выпуклые линейные множества и симплекс-метод (на примерах транспортной задач, максимального потока и т.д.) и в конце про двойственную задачу (с примерами на две-три переменных и несколькими уравнениями - с иллюстрациями графиков).
На самом деле - там было не намного сложнее, чем в учебнике геометрии Погорелова последние главы : да, много разного и нового, но все равно каждая следующая теорема - выводится либо сразу из простых аксиом и определений, либо из предыдущих теорем.
Люди разные. Мне, например, по горло хватало школьной программы, плюс подготовительные курсы к поступлению в ВУЗ не давали возможности читать что-то дополнительное (новое) и в принципе не нужное при поступлении (никто линейную алгебру не требует на вступительных экзаменах, наоборот могут что-то заподозрить :)).
Скорее нужен ВУЗ, чтобы показал, что существует такое понятие как "матрицы" и что с ними можно выполнять определённые действия. ВУЗ по сути даёт сжатую и очищенную выборку знаний для определённой ситуации. Если Вы без ВУЗа захотите изучить "математику", то умрёте от невероятного обилия понятий, знаний и совершенно разных направлений и книг по той самой "математике".
чтобы показал, что существует такое понятие как «матрицы» и что с ними можно выполнять определённые действияи что обобщением к матрицам и действиям над ними упрощаются многие реальные действия (задачи).
1) Открою вам страшную тайну - чтобы узнать что есть понятия "матрицы" или "кватернионы" вовсе не нужен ВУЗ. Можно, к примеру, начать писать игру на том же Unity и обнаружить и матрицы и кватернионы и всё остальное.
2) "математику" нельзя изучить, можно изучить конкретные разделы математики. В разных сферах они свои. И чтобы в них разобраться, представьте себе, тоже не нужен ВУЗ. "Умирать" тоже не обязательно, достаточно иметь время и желание.
3) Не понимаю почему все выделяют математику. В некоторых областях нужна физика, в других биология. К примеру недавно мне понадобилось посчитать химические реакции чтобы получить определенные вещества, что мне теперь - в ВУЗ по химии предложите идти? А когда я захочу сделать светящееся генно-модифицированное растение - в ВУЗ по биологии?
Притом игроделы реально знают и умеют применять кватернионы, но выпускники (российских) ВУЗов знают только слово («краснодипломники» еще и историю изобретения припомнят).
1) Открою вам страшную тайну - чтобы узнать что есть понятия "матрицы" или "кватернионы" вовсе не нужен ВУЗ. Можно, к примеру, начать писать игру на том же Unity и обнаружить и матрицы и кватернионы и всё остальное.
2) "математику" нельзя изучить, можно изучить конкретные разделы математики. В разных сферах они свои. И чтобы в них разобраться, представьте себе, тоже не нужен ВУЗ. "Умирать" тоже не обязательно, достаточно иметь время и желание.
Вы не поняли. Я ни в коем случае не считаю, что обучение в ВУЗ-е - это нечто сакральное. Это обычное изучение с обычным учителем, который также обычно всё изучал и читал. Всё это вполне можно сделать самому. И любой умный человек, отягощённый свободным временем, вполне на это способен. ВУЗ просто сильно помогает с получением таких знаний. И там работают крайне опытные в деле передачи знаний профессионалы. Вспомните, например, свои конспекты по лекциям по физике. Это же превосходная насыщенная выжимка знаний, которая за 100-200 часов на базовом уровне объяснила практически весь мир, который нас окружает. Мне страшно представить, сколько надо было бы потратить времени и сил, чтобы самому получить такое количество знаний. Одних только книг десятки прочитать. И во всём этом не запутаться. И это я не беру лабораторные работы (прикоснуться ко спектрографу и наглядно изучить способ выяснение состава материалов вне универа мне больше нигде не удалось).
3) Не понимаю почему все выделяют математику. В некоторых областях нужна физика, в других биология. К примеру недавно мне понадобилось посчитать химические реакции чтобы получить определенные вещества, что мне теперь - в ВУЗ по химии предложите идти? А когда я захочу сделать светящееся генно-модифицированное растение - в ВУЗ по биологии?
Понятия не имею. Наверное потому, что из непрофильных предметов для программиста наиболее близка именно математика.
Если бы мне такое понадобилось, то я бы начал с чтения учебников :)
И там работают крайне опытные в деле передачи знаний профессионалы. Вспомните, например, свои конспекты по лекциям по физике. Это же превосходная насыщенная выжимка знаний, которая за 100-200 часов на базовом уровне объяснила практически весь мир, который нас окружает. Мне страшно представить, сколько надо было бы потратить времени и сил, чтобы самому получить такое количество знаний.Так эти же преподаватели пишут учебники по своим курсам. И вместо лекций и конспектов можно взять учебник и получить туже самую систематизированную вижимку знаний.
Другое дело что не все учебники хороши и выбирать надо то что соответствует твоему уровню и задачам. Ну так и в ВУЗе полно бездарных преподавателей, и в отличии от учебника выбора преподавателя обычно нет.
Учебник неинтерактивен. В общем, конечно, можно быть Зельдовичем, но большинство людей — это простые смертные.
Так да, я это и пишу. Обучение в ВУЗ - это, по сути, изучение материала (по учебнику и/или по лекциям), практические занятия, интерактив с учителем, близкое общение со сверстниками, общее образование и аттестация полученных знаний. Всё это можно получить и самому - здесь нет ничего невозможного. Но придётся самому выяснять, какую литературу изучать (а учебников могут быть сотни!), искать где-то установки для практической работы, искать преподавателя и пр.
Разные учебники по одному и тому же предмету предполагают немного разный набор требований для изучения и дают немного разный набор знаний. Например, в вузе А на первом курсе читают отдельный предмет «Теория множеств», а в вузе Б такого предмета нет и теория множеств частично даётся в предмете «Математический анализ» (необходимый минимум для изучения оного), а всё остальное — в предмете «Функциональный анализ». Границы математических предметов часто размыты и разные профессора могут относить одно и то же к разным предметам (например, теория меры где только не всплывает — от матана до теорвера, потому что изучать надо, а для отдельного предмета эта тема слишком мала).
Допустим, вы хотите изучить функциональный анализ и выбрали учебник, написанный преподавателем вуза А (очень хороший и имеющий кучу положительных отзывов), а теорию множеств вы изучали по соответствующему разделу учебника по матанализу, который написал преподаватель вуза Б (это тоже очень хороший учебник). Но есть маленький нюанс — примерно половина теории множеств у вас не была охвачена вообще, что вызовет кучу проблем в изучении функционального анализа.
В вузе преподаватель обычно знает, что вы изучали раньше, и порекомендует учебник, соответствующий вашему уровню. При самостоятельном изучении — задача определять границы предметов ложится на вас, а сделать это, не имея законченного математического образования, не так то просто. Я бы при самостоятельном изучении высшей математики посоветовал как минимум ориентироваться на программу какого-нибудь хорошего вуза (они обычно есть в открытом доступе), а ещё лучше — нанять специалиста, который составил бы индивидуальный план с учётом ваших знаний и ожиданий.
ак умножать матрицы и вообще не понимает более половины символов в формулах.
Зачем это всё? Мы просто JSON-ы по REST-ам гоняем туда-сюда.
Так самые банальные задачки могут быть связаны с этим умножением матриц. Например есть какая-нибудь таблица значений, и есть список коэффициентов для этих значений, необходимо просуммировать значения в каждой строке таблицы с учетом коэффициентов. Первое что на ум приходит, это допустим подсчитать общую стоимость различных услуг для каждого пользователя.
По сути это задача умножения матрицы на вектор, но подобные абстракции в формулировке или решении задачи могут вызывать недоумение у неподготовленных людей. Не то чтобы для примера выше нужны подобные абстракции, эта задача и так легко описывается. Но если источников данных не два, а чуть больше, и расчеты немного сложнее, то использование элементов той или иной теории может оказаться просто удобным инструментом, как для формулирования, так и для реализации задач.
То есть, как минимум, наличие общей теоретической базы может позволить общаться на простом языке, через использование сложных абстракций. Хотя соглашусь, что в большинстве случаев это вовсе необязательно, многие задачи можно и на пальцах объяснить.
большинстве случаев это вовсе необязательно, многие задачи можно и на пальцах объяснить.
«объясняю вам на пальцах. Видите средний палец?»/s
ну а если серьезно, то даже в парапрограммировании иногда применяется та же «линейка» — начиная от infostart.ru/1c/articles/730702 и заканчивая infostart.ru/1c/articles/158512
Но применяет ее хорошо если 1%
Чем вам поможет концепция умножения матрицы на вектор, если ни то ни другое в оперативную память заведомо не помещается? Тут поможет только декомпозиция задачи и составление графа зависимостей и его оптимизация… что далеко выходит за пределы познания матрицы и вектора. А если помещаются, то просто берете любую стандартную библиотеку :)
Пример с умножением матриц неправильный ибо конкретно эта задача решается элементарно/берется готовая из библиотеки. Нужно смотреть глубже - зачем оно вообще понадобилось, а точно ли оно нужно, насколько применимо и т.д. в частности возможно что для этой задачи матрицы не надо перемножать, а обойтись кватернионами например. И тут срабатывает то, что в ВУЗе все знают про кватернионы и поэтому не будут косячить с решением/перемножением матриц. Для того чтобы вкусно готовить / хорошо рисовать / переводить с английского не обязательно иметь профильное образование, но профессионального повара, который плохо готовит, ещё стоит поискать. Никто не будет работать с врачом или например инженером строителем без образования/ сертификации и т.д. Черт возьми даже вождение автомобиля требует получения прав - от этого непосредственно зависит жизнь и здоровье людей. И там где от программиста тоже зависит жизнь и здоровье людей - внезапно тоже требуется профильное образование :) как раз что-то серьезное и ответственное.
Так исторически сложилось, когда ЭВМ были большими и решали ответственные важнейшие задачи своего времени, просто так без знания вышки / дискретки /численных методов / архитектуры ЭВМ там было нечего делать.
Но на современном рынке труда это от программистов не требуется, от ответственности отказ полнейший. Ну и вообще зачем идти в лабораторию/НИИ/завод где нужен диплом и будешь нести ответственность если можно найти место где и отвечать не надо и платят больше :)
И образование, я надеюсь,(давно было) ещё гарантирует хоть какой-то минимальный и достаточный стандарт для выполнения работы по профессии. И программирование в этом плане не сильно отличается от множества других профессий.
КНУ, кибернетика. Нету квартернионов в программе.
Я вот первый раз слышу это слово.
Но проблема отсутствия образования в том, что без образования ты можешь даже не догадываться, что приблизительно в задаче можно применять и чего гуглить. Нагуглить что-то, чего вообще никогда не слышал на самом деле очень сильно нетривиальная задача.
Да, можно успешно работать мидлом. Но очень желателен хотя бы один человек в команде, кто таки учился.
Меня как программиста-самоучку бесят "академики", которые считают, что умножение матриц это какое-то тайное знание, которое не просматривается в виде лекций/упражнений на ютубе за пару часов. Такое ощущение, что вас в вузах не столько учат, сколько промывают мозг какие вы классные, нужные и хорошие.
Ну хорошо, это всего лишь умножение матриц. А оптимизируйте мне, плз, регулярную доставку товара из пары складов в несколько магазинов - с учётом сроков доставки, дозагрузки фуры, минимизации простоя фуры (и вообще их количества), расхода топлива. Это уже как раз обычная приземлённая задача для программистов. И ладно, я не прошу задачу решить, нагуглите хотя бы, какой из методов нахождения экстремума функции тут применить, если вы это не изучали :)
Это уже как раз обычная приземлённая задача для программистов.
Сколько требуется программистов для замены перегоревшей лампочки? Ни одного - это аппаратная проблема!
В вашем же случае:
Для начала надо ответить на вопрос - а точно ли это задача для программиста? (да, лет 30 назад больших сомнений в этом не было, но время-то идёт...)
Для этого задуматься, а что такое "программист"?..
И если у вас точно не возникнет хотя бы подозрения, что "программист" понятие весьма растяжимое в плане "что у человека на входе" (на выходе понятно, что программный код, иначе он уже точно не программист), и что это поставленная вами задача - точно задача именно для программиста, то тогда повторите еще раз свою мысль ;)
Для начала надо ответить на вопрос - а точно ли это задача для программиста?
Да, в общем случае это задача программиста. Конечно же, вы можете попасть в организацию, где роль программиста выхолощена до кодирования спущенных аналитиками алгоритмов, т.к. любую профессиональную роль можно сколь угодно дробить на более узкоспециализированные вплоть до атомарных операций. Но во-первых, таких организаций все равно меньше, чем тех, где круг ответственности программиста всё-таки шире, и программистам дают задание в виде "что надо сделать", а "как" - решается уже на их уровне. А во-вторых, даже если вы и попали в такую организацию - а вам точно это надо? Ведь самостоятельное решение более сложных задач, это и интереснее, и значительно выше оплачивается.
К слову, об аналитиках - я когда-то по подобной задаче (только там были танкеры и порты, а не фуры и магазины) обратился непосредственно к логистам, которые это вручную считали, как они оптимизируют фрахты. Цитирую: "ну... вот этот танкер, он сюда не войдет, тут десять метров фарватер, а танкер - двенадцать, поэтому мы его вот сюда войдем. Понятно?"
И это не исключение, по моему опыту, подавляющее большинство заказчиков в среднем и мелком бизнесе, и очень многие - в крупном, способны задачу поставить программистам примерно на вот таком уровне.
и значительно выше оплачивается.
Не знаю, лично у меня наибольшую зарплату обычно предлагали в компаниях, где есть чёткое разделение труда.
Цитирую: "ну... вот этот танкер, он сюда не войдет, тут десять метров фарватер, а танкер - двенадцать, поэтому мы его вот сюда войдем. Понятно?"
И это не исключение, по моему опыту, подавляющее большинство заказчиков в среднем и мелком бизнесе, и очень многие - в крупном, способны задачу поставить программистам примерно на вот таком уровне.
Звучит как айти из нулевых на делфи. И кто будет отвечать за факап при формализации таких требований? А если они придут и скажут "перевозка на 5000км считается нормально, но вот в соседний город в 50км у нас погрешность в сотню литров", потому что выбранный метод эвристики не работает на небольших расстояниях?
А если речь не о грузоперевозках, а о инженерных расчётах, то стоит ли перекладывать вывод формул и уровней апроксимации на программиста, или этим должен заниматься знакомый с предметной областью человек?
Начну с конца:
Конечно же, вы можете попасть в организацию, где роль программиста выхолощена до кодирования спущенных аналитиками алгоритмов, т.к. любую профессиональную роль можно сколь угодно дробить на более узкоспециализированные вплоть до атомарных операций. Но во-первых, таких организаций все равно меньше, чем тех, где круг ответственности программиста всё-таки шире, и программистам дают задание в виде "что надо сделать", а "как" - решается уже на их уровне.
Видите ли, за 30 лет, ну или условно "с советских времён", ситуация достаточно сильно поменялась. Если в древние мохнатые времена предполагалось, что на каждом предприятии, где есть компьютеры, к ним должны прилагаться программисты, которые будут писать какие-то программы для автоматизации чего-то, то сейчас во многих конторах к компьютерам ни "операторы ЭВМ" (как должности) не прилагаются, ни даже сисадмины как фактическая роль.
Нынче разработка и эксплуатация софта очень сильно разделены.
Правда, в контексте цифровой трансформации нам усиленно толкают идею, что неплохо бы вести автоматизацию собственными командами, ну прямо диалектическое "отрицание отрицания" и новый виток спирали... Но это уже философия и другой уровень проблемы.
Да, в общем случае это задача программиста.
В общем случае - в наше время это задача аналитика (как роли). А уж как он там её будет решать - в Maple, Маткаде, Матлабе, Математике или вообще в Экселе - это уже его, аналитика, дело. Ибо изобретать велосипеды для таких задач в наше время нет необходимости. А если аналитики и про программы-то такие не слышали или пользоваться ими не умеют - это проблемы не программистов, а аналитиков.
К программисту эта задача действительно может прийти, но при определённых условиях, тут не озвученных.
Вот интересно, сможем с вам докопаться до этих условий? (кроме принципа "я начальник - ты дурак, потому делай, программист, что тебе сказано, да еще и по дороге в бухгалтерии картридж в принтере замени, и на складе разъём у кабеля переобожми")
сейчас во многих конторах к компьютерам ни "операторы ЭВМ" (как должности) не прилагаются, ни даже сисадмины как фактическая роль.
Во многих не прилагаются, во многих до сих пор прилагаются. По сути, по эту сторону железного занавеса половина среднего бизнеса, которому недостаточно стандартных конфигураций, по-прежнему держит хотя бы своего админа с функцией кастомизации 1С, по другую сторону за этим чаще обращаются на аутсорс, но там так всегда было.
Но и в профессиональных конторах ситуация ничуть не отличается. Мало кто будет держать в штате профессионального математика и бизнес-аналитика в одном лице, особенно если подобные задачи возникают эпизодически, а не являются прямой специализацией компании.
Вот интересно, сможем с вам докопаться до этих условий?
Легко. Знание математики на подобном уровне напрочь отсутствует в штатном наборе скиллов бизнес-аналитика. Он соберёт требования, ограничения задачи, и опишет интерфейс. Математическую часть аналитик вам не опишет, это должен будет как раз программист подобрать. В частных случаях получится пригласить именно профильного консультанта-математика. В общем - это программист будет сидеть и разбираться. Если с математическим бэкграундом, у него получится быстрее. Если без - то долго и с высокой вероятностью неудачи.
Во многих не прилагаются, во многих до сих пор прилагаются. По сути, по эту сторону железного занавеса половина среднего бизнеса, которому недостаточно стандартных конфигураций, по-прежнему держит хотя бы своего админа с функцией кастомизации 1С, по другую сторону за этим чаще обращаются на аутсорс, но там так всегда было.
Админ с кастомизацией 1с? ;) Ну да, а еще и картриджи в принтерах менять, разъемы 8p8c обжимать, витую пару таскать, воду в кулерах менять... Проще говоря - "продвинутый эникейщик", для солидности названный инженер-чтонибудь.
Хотя скорее всего "прогнутся" под стандартную конфигурацию, или опять же наймут аутсорсера на сопровождение нестандартной конфигурации (возможно, в лице той же конторы, что и остальную 1С им поставляют и обновляют).
Но и в профессиональных конторах ситуация ничуть не отличается. Мало кто будет держать в штате профессионального математика и бизнес-аналитика в одном лице, особенно если подобные задачи возникают эпизодически, а не являются прямой специализацией компании.
Минуточку. Я сказал просто "аналитика", без уточнения специализации. Бизнес-аналитик - это достаточно специфичная профессия, которая в штате эксплуатанта, а не интегратора, будет разве что при наличии у конторы СМК, причем реального СМК, а не "бумажного для участия в тендерах".
Ну а если задачи возникают эпизодически - то тут либо нанимать подрядчика, либо забить на задачу, т.к. содержание в штате специалиста ради решения проблем, возникающей раз в год-два- экономически нецелесообразно. Да, иногда можно и просто задачу игнорировать, если постараться.
Легко. Знание математики на подобном уровне напрочь отсутствует в штатном наборе скиллов бизнес-аналитика.
Как уже сказал выше - это вообще не задача для БА. БА работает с бизнес-процессами, потому он в лучшем случае напишет, что если изменить/внедрить автоматизацию на таком-то подпроцессе такого-то бизнес-процесса организации (а если в организации нет СМК - то считай "ой", там надо будет вообще начинать с формализации этих процессов), то у вас улучшатся такие-то показатели работы.
Он соберёт требования, ограничения задачи, и опишет интерфейс.
Для начала - надо ответить на вопрос "а зачем тут вообще писать автоматизацию, а не воспользоваться готовым"? На этот вопрос БА как раз должен ответить, тут ни математиком, ни программистом не надо быть.
Ну и, собственно, пока не ответим на вопрос выше - до программизма не дойдём, ибо смысла нет в программизме до этого момента.
Админ с кастомизацией 1с? ;) Ну да, а еще и картриджи в принтерах менять, разъемы 8p8c обжимать, витую пару таскать, воду в кулерах менять... Проще говоря - "продвинутый эникейщик",
Это называется "системный администратор". Есть, правда, категория системных администраторов, которые работают с более серьёзными продуктами, имеют узкую специализацию, задницу поднимают исключительно в рамках SLA, и они таких ребят не уважают, придумывают для них названия вроде "эникейщиков". Примерно как программист со знанием предметной области унижает программиста, работающего по ТЗ от аналитиков, называя его "кодером" :)
или опять же наймут аутсорсера на сопровождение нестандартной конфигурации
Да, вполне. Это сути не меняет.
Минуточку. Я сказал просто "аналитика", без уточнения специализации. Бизнес-аналитик - это достаточно специфичная профессия
Я уточнил, потому что постановка задач на уровне "как считать эти цифры" - это как раз прерогатива бизнес-аналитика. И бизнес-аналитик, это не профессия, это тоже роль :) Всего лишь ещё более узкая специализация. Не суть важно, в любом случае в 99.99% реальных кейсов не будет ни бизнес-аналитиков со знанием этого, ни сторонних консультантов.
Для начала - надо ответить на вопрос "а зачем тут вообще писать автоматизацию, а не воспользоваться готовым"?
Я могу легко на него ответить: потому что бизнес не готов делать миграцию на другую учётную систему.
Это называется "системный администратор".
Это называется "эникейшик". Который может вырасти из первой линии поддержки на более высокую или даже не совсем поддержку, можно сказать, что даже с рабочей должности на инженерную... Но называться "сисадмином" приятнее, чем каким-нибудь "техником".
И да, с ростом компетенции у админа еще и специализация как правило возникает - сетевик, серверы и т.п.
А вот поддержка 1С тут может быть либо "от бедности организации" (что означает, что человек толком не умеет ни в 1С, ни в администво), либо ближе к девопсу - но такой человек "слишком дорог", чтобы тратить его время на картриджи и разъёмы. Проще заставить пользователей менять их самим (чай не 90-е на дворе, где "требовался программист для работы с программой Word"), ну или вместе с сантехником и электриком еще и техника по "эникейным" работам нанять, если уж работ так много, а пользователи неадекватны.
Есть, правда, категория системных администраторов, которые работают с более серьёзными продуктами, имеют узкую специализацию, задницу поднимают исключительно в рамках SLA, и они таких ребят не уважают, придумывают для них названия вроде "эникейщиков".
Ну или эти время этих ребят слишком дорого, чтобы тратить его на замену картриджей, обжимание разъемов, замены воды в кулере и прочую мелочёвку.
Примерно как программист со знанием предметной области унижает программиста, работающего по ТЗ от аналитиков, называя его "кодером" :)
А вот тут пытаетесь подменить понятия. Нет, степень "крутости" программиста определяется не его знанием предметной области - более того, часто это лишнее знание, засоряющее голову. Тем более, что вникать в предметные области каждого проекта - жизни не хватит.
Знание предметной области могут себе позволить только программисты в командах, работающие над конкретным продуктом и только над ним. Ну или инди-разработчики.
Собственно, именно из-за нецелесообразности тратить время программистов на изучение предметных областей и возникает потребность в использовании аналитиков различных специализаций.
Но, еще раз обращу внимание - зависит от подхода, работает команда над одним и только одним проектом постоянно, или программисты производят код для множества проектов.
Я могу легко на него ответить: потому что бизнес не готов делать миграцию на другую учётную систему.
А зачем сразу миграцию, да еще и учётной системы, для задачи "оптимизации регулярной доставки товара из пары складов в несколько магазинов"?
Эксель отделу логистики же установлен? Ну вот пусть в нём и считают, там же ж можно не только суммы по столбцам в табличках рассчитывать. Не хватает экселя - есть и специализированное ПО, можно доустановить.
Ну или да, он бизнес конечно может обратиться к вендору ПО с просьбой приделать ему еще и такую штуку, вендор ему скажет "любой каприз на ваши деньги, вот такой-то срок и вот столько-то денег в рублёвом эквиваленте, готовы заплатить?" И вот что-то на этом этапе у бизнеса начинается амфибиотропная асфиксия.
Дайте угадаю - вы имели в виду те компании, которые еще сохранили собственную разработку для собственных нужд?..
Это называется "эникейшик".
Это называется "системный администратор". Не существует эникейщиков и кодеров. Есть системные администраторы, есть программисты. А есть зазнавшиеся системные администраторы и зазнавшиеся программисты, которые унижают тех, кто не достиг их уровня профессиональной офигенности.
Знание предметной области могут себе позволить только программисты
Если не брать в расчёт какие-то наукоёмкие отрасли (где профильное образование лучше иметь изначально), знание предметной области могут себе позволить любые программисты, которым не влом. Например, автоматизируя клинику, программисту не требуется знать методы резекции прямой кишки, ему надо знать, какие поля должны быть в истории болезни, и кто и в каком порядке их заполняет. Не такая уж и хитрая предметная область.
Автоматизируя бухгалтерию, программисту не нужно знать план счетов наизусть, и налоговое законодательство. Но что такое основные средства, проводки, дебет, кредит, сальдо, амортизация, это ему тоже знать нужно. И это - не хитрая предметная область. И так далее.
Мы практически все работаем над каким-то конкретным продуктом. И делаем его не неделю, а месяцами и годами. В чём проблема понимать то, что пишешь?
А зачем сразу миграцию, да еще и учётной системы, для задачи "оптимизации регулярной доставки товара из пары складов в несколько магазинов"?
Ну если у вас текущая система не позволяет это делать - что вы купить предлагаете, кроме как новую систему? Модуль логистики к текущей системе? Давайте по дефолту предположим, что его нет - потому что если бы был, про это финдиректор узнал бы раньше программистов, и купил бы его. А раз новую систему, то и миграция прилагается.
Дайте угадаю - вы имели в виду те компании, которые еще сохранили собственную разработку для собственных нужд?..
Я имею в виду любые компании, потому что те, которые не сохранили, обратятся к компании-саппорту своей системы, у которой тоже штатного математика не окажется, и внештатного скорее всего тоже. Вы поймите простую вещь: нет на рынке таких профильных специалистов. Их единицы, и никто их нигде не видел. Это будет делать обычный программист.
Это называется "системный администратор". Не существует эникейщиков и кодеров. Есть системные администраторы, есть программисты. А есть зазнавшиеся системные администраторы и зазнавшиеся программисты, которые унижают тех, кто не достиг их уровня профессиональной офигенности.
Можете сколько угодно политкорректно переименовывать, можете даже продавца назвать "менеджером по продажам", уборщицу - менеджером по мусору, охранника - менеджером по противодействию хулиганству, но суть от этого не изменится.
Более того, можно обнаружить, что и "программиста" на самом деле не существует как одной профессии, а есть целая пачка оных, содержащая слово "программист", и охватывающая как рабочие, так и инженерные должности.
Мы практически все работаем над каким-то конкретным продуктом. И делаем его не неделю, а месяцами и годами. В чём проблема понимать то, что пишешь?
В том-то и дело, что не все, и не всегда. Я ж тут на это уже толсто намекал. Могу еще толще - есть два подхода:
-под продукт создаётся постоянная проектная команда, которая только им и занимается, и состоящая не только из программистов, но вообще из соответствующих специалистов по существу проекта.
- есть функциональное подразделение, занимающееся программизмом, которое производит код по задачам от других подразделений с другим функциональным назначением.
Последнее может участвовать в десятках и сотнях проектов, и если будет вникать в предметную область каждого - никогда ничего не напишет. Да более того, достаточно двух-трёх сильно разных проектов, чтобы выработалась привычка переключаясь на новый - напрочь забывать старый, чтобы не путать контексты.
Если не брать в расчёт какие-то наукоёмкие отрасли (где профильное образование лучше иметь изначально),
И вот таки зря, т.к. помимо оси "степень самостоятельности при выборе решения как именно преобразовывать входные данные в выходные данные и способы их представления" еще есть "специализация": не всякий программист напишет драйвер/модуль ядра, не всякий, кто может написать драйвер/модуль ядра - напишет его для аппаратного устройства, не всякий, умеющий в системное программирование, напишет реализацию сетевого стека и/или сможет работать с данными сети в обход ядерного стека, а еще кто-то должен проектировать базы данных и запросы к ним, и т.д. и т.п.
Поэтому в некоторых специализациях программисту действительно может понадобиться та еще высшая математика, про которую тут без вводной лекции вообще не объяснишь, о чём она вообще.
Но, повторяю, "специализация". Вы же упомянули "оптимизацию доставки товара" как обычную задачу именно для программиста, а не "менеджера по логистике" ("менеджер" там лишнее слово, но так уж у нас в стране повелось, ибо "менеджер" звучит красиво).
Ну если у вас текущая система не позволяет это делать - что вы купить предлагаете, кроме как новую систему? Модуль логистики к текущей системе? Давайте по дефолту предположим, что его нет - потому что если бы был, про это финдиректор узнал бы раньше программистов, и купил бы его. А раз новую систему, то и миграция прилагается.
Я предлагаю оставить существующую учётную систему, а "оптимизацию доставки" пусть делает "менеджер по логистике" любым удобным ему способом - может на бумажке, может в Экселе, можно ему какой-нибудь математический пакет поставить, даже бесплатный, если жаба душит. Потому что выписывать бумажки может и "техник по выписыванию бумажек", а если уж его "менеджером" обозвали - пусть включает голову с вроде как высшим образованием и использует по назначению.
Я имею в виду любые компании, потому что те, которые не сохранили, обратятся к компании-саппорту своей системы, у которой тоже штатного математика не окажется, и внештатного скорее всего тоже. Вы поймите простую вещь: нет на рынке таких профильных специалистов. Их единицы, и никто их нигде не видел. Это будет делать обычный программист.
А вот не факт, что "обычный программист". Разработка модуля управления логистикой - это не "обычная" задача, а скорее всего разовая для конкретной ИС, да и на рынке таких задач не факт что много.
А редкие задачи как решаются?.. За повышенные деньги, в которые заложено привлечение кого-то на субподряд. Вот умеющих решать такие задачи на субподряд и возьмут под этот проект.
Но вот если вдруг окажется, что такие задачи внезапно стали обычными именно для разработчиков ПО - то появляется специализация - и тут да, тут придётся или искать программиста с математическим образованием, или математика, умеющего программировать, или вообще под себя кадры готовить... Вот только вряд ли для учётных ИС, скорее для геоинформационных или каких-нибудь навигаторов - там еще и "команды под конкретный проект" заодно наблюдаются, кстати.
Линейное программирование, задача опитимизации в чистом виде
Да за день можно нагуглить. Ну или доказать что это нерешаемая хрень, которая делается перебором.
Потому что пока вас в вузе учили бухать, подлизывать преподам и косить на зачетах - я учился учиться ^^
Это уже как раз обычная приземлённая задача для программистов.
Да ладно? И много вы таких решили?) Хотя бы десяток был?)) Хотя что вы за программист, если за всю карьеру решили лишь десяток "обычных приземленных задач"
UPD: потратил 5 минут, понял что это есть n методов, например
Градиентный метод с постоянным шагом (без ограничений)
Градиентный метод с переменным шагом (без ограничений).
Метод наискорейшего спуска (без ограничений).
Метод сопряженных направлений (без ограничений).
Метод сопряженных направлений)
и надо посидеть, попытаться перевести задачу в форму функции f(a,b,c,d,...)= и потом просто перебрать эти методы.
И это при том, что никакой похожей задачи у меня никогда не было и я потратил 5 минут.
Если оч надо - я могу найти, но в ответ я попрошу конфиг для либлаб сисд чтобы передавать в квалитигейт dependency track только актуальные рантайм зависимости от вебпак бандла.
Тоже, сказал бы что "типовая задача", но не буду, у меня адекватность есть ;)
Эти методы работают только для выпуклых дифференциируемых функций...
Я вообще вот что подумал - у @PuerteMuerte логика такая:
Программирование = алгоритмы = математика. Хороший программист = хороший математик.
А для меня программирование = архитектура приложений. То бишь своя, новая и неизведанная область. Конечные алгоритмы и матанализ особо тут не влияют, разве что на принципиальную возможность решить задачу за O(*).
Программирование равнялось математике, когда рассчитать какую-то функцию было достижением. Когда ты руками дырявил перфокарты и считал такты. А сейчас тебе просто надо выделить для этой функции место в системе и уже от этого места ты будешь выбирать какую именно функцию ты будешь использовать. Но выделить это место - само по себе искусство и для меня именно это и есть программирование.
Приведу пример где я хоть что-то понимаю - @PuerteMuerte мог бы спросить меня "а вот тебе типовая задача программиста на триангуляцию полигонов. Какой из методов ты бы выбрал, будь у тебя произвольный замкнутый граф?"
А если бы я программировал систему, я бы не упарывался по триангуляции. Я бы шел от общего к частному и конкретный алгоритм бы ставил в самом конце, в зависимости от требований.
Так вот, получается, что в вузах сейчас преподают "Программирование = алгоритмы = математика". Это как раз объясняет, почему задачу оптимизации фур он считает типовой - ну в вузе же мы их решали сотнями, как же так это не типовая задача. А я, поработавший десяток лет в коммерческих компаниях, понимаю что автору место максимум в нии, сидеть вычислять за 10к. Либо, тадаам, учиться настоящему программированию.
И получается интересная ситуация - оба из нас по своему правы и обоснованно считают друг друга говнокодерами, а то чем они занимаются - настоящим программированием. Ну как, я конечно считаю что тут я правее :)
Я вообще вот что подумал - у @PuerteMuerte логика такая:
Программирование = алгоритмы = математика. Хороший программист = хороший математик.
Да было время, когда вместо вместо нынешних "центров обработки данных" были "вычислительные центры"...
А для меня программирование = архитектура приложений. То бишь своя, новая и неизведанная область.
И это правильно.
Конечные алгоритмы и матанализ особо тут не влияют, разве что на принципиальную возможность решить задачу за O(*).
А я, поработавший десяток лет в коммерческих компаниях, понимаю что автору место максимум в нии, сидеть вычислять за 10к.
Оно конечно правильно, но есть нюанс - случаи могут быть разными, может статься что и на ассемблере писать придётся :)
Потому что есть programmer, есть software engineer, есть computer scientist, а по-русски это всё - "программист", ибо так повелось еще со времён, когда должности и профессии были привязаны к ныне отменённой "Единой Тарифной Сетке" (которая определяла допустимые названия должностей и оклады к ним).
Я вообще вот что подумал - у @PuerteMuerte логика такая: Программирование = алгоритмы = математика. Хороший программист = хороший математик.
Эм... нет, я вообще ничего подобного нигде не писал, и даже не могу понять, как вы подобный вывод сделали :)
Я писал, что математика в программировании нужна там, где это предполагает предметная область. Точно так же, как нужна физика там, где программист автоматизирует физические процессы, а финансовое образование нужно при автоматизации финтеха. И да, всякого рода оптимизационные задачи - это достаточно обширный раздел математики, и чёрта с два его получится просто погуглить и разобраться, потому что... это я тоже писал :)
Если гуглить - получится как у вас, куча незнакомых методов, с каждым из которых придётся долго и мучительно разбираться, чтобы в конце (в лучшем случае!) понять, что ни один не подходит.
Эм... нет, я вообще ничего подобного нигде не писал, и даже не могу понять, как вы подобный вывод сделали :)
Ну потому что вы на пассаж про программистов-самоучек и умножение матриц вместо вопроса про программирование полезли в оптимизационные задачи которые решаются в основном математикой.
Отсюда я сделал вывод, что для вас программирование это, в основном, математика.
Иначе получается, что на мое заявление "какие качества характерны для Х" привели совершенно левый незначительный довод.
Угу, а исходная задача — теория графов, то есть гуглеж был вообще не в ту сторону.
Ну смотрите. У меня нет высшего образования. Но я успел поучиться в нескольких вузах и прекрасно себе представляю как организован учебный процесс и в "областном политехе" и в МВТУ.
Теперь по поводу вашего сакрального умения решать типовую транспортную задачу (ну т.е. тот вид задач, который студенты экономических специальностей решают пачками по вышке) - у меня это заняло примерно час. Одному товарищу надо было какую-то контрольную решить с этой транспортной задачей (посчитать в экселе на VBA эти самые матрицы). Я, правда, большую часть времени из этого часа пытался понять откуда у меня вместо нулей в конечной матрице мантиссы вылезли...))
оптимизируйте мне, плз, регулярную доставку товара из пары складов в несколько магазинов - с учётом сроков доставки, дозагрузки фуры, минимизации простоя фуры (и вообще их количества), расхода топлива.
Что то подсказывает, что это делается без высшей математики.
Чтобы составить оптимальный маршрут - вам нужны графовые методы типа алгоритма Дейкстры (но не сам этот алгоритм, ₽ его модификации - скажем, A* подойдет), чтобы остальные оптимизации посчитать - линейное программирование, к примеру. Хотите готовую библиотеку взять? Да пожалуйста, только учтите, многие графовые библиотеки не поддерживают directed графы (то есть односторонние дороги), так что понадобится преобразовать directed граф в эквивалентный undirected (не помню, как на русском называются). Карта дорог OSM часто не содержит информации о полосах движения, так что потребуется модифицировать граф дорог OSM (иначе остановка на левой и правой стороне дороги будет эквивалентна, что на более-менее крупных дорогах невозможно). Ну, если вы все это сами сделаете и без обращения к высшей математике - то вам высшая математика не нужна :)
так что понадобится преобразовать directed граф в эквивалентный undirected (не помню, как на русском называются)
Лол, это невозможно (в отличии от обратной операции).
Directed граф соответствует асимметричной матрице, а undirected - симметричной, и операция симметризации асимметричной матрицы приводит directed граф к эквивалентному undirected. Когда-то я даже код выкладывал: https://github.com/mobigroup/osmrouting/blob/master/oneways/pgr_dijkstraSymmetrizeCostMatrix.sql
Про связь графа и матрицы смотрите, к примеру https://bookdown.org/omarlizardo/_main/4-4-the-asymmetric-adjacency-matrix.html
Одну дорогу с двусторонним движением можно представить как две с односторонним, а вот наоборот не очень, можно на ДТП нарваться.
Если вас не убеждает математическая теория, то я выше дал ссылку на код в репозитории - там есть пример дорожной сети с односторонними дорогами и роутинг по ней средствами PgRouting без поддержки односторонних дорог (путем симметризации асимметричной матрицы, то есть представления directed графа как undirected). И даже статьи на хабре я писал про все это. Но вы почему-то игнорируете и теорию и практические примеры, зато спорите про преимущества академического образования :)
Я просто разжевал то, что сказал @mayorovp, и это вы игнорируете очень практический пример. Ещё раз: есть неорграф a-b, его эквивалентно можно представить как орграф a->b, b->a, тут вопросов нет. В обратную сторону не работает. Если у нас есть орграф c->d, его невозможно эквивалентно представить через неорграфы, и ваш профиль на гитхабе не сильно интересен в этом разрезе.
Открываем мою статью на хабре, на которую я ссылался выше "Делаем маршрутизацию (роутинг) на OpenStreetMap. Добавляем поддержку односторонних дорог"https://habr.com/ru/post/512580/ Как указано в статье, англоязычная страница википедии, посвященная проблеме коммивояжера, содержит нужный нам раздел Travelling salesman problem: Asymmetric:
Solving an asymmetric TSP graph can be somewhat complex. The following is a 3×3 matrix containing all possible path weights between the nodes A, B and C. One option is to turn an asymmetric matrix of size N into a symmetric matrix of size 2N.
Ровно это приведенный код и делает. Ваши утверждения, что это сделать невозможно, опровергнуты и теорией и практикой, а вы все продолжаете спорить, уже и мой профиль на гитхабе упомянули. Лучше бы код посмотрели, самородок вы наш...
Ну так этот трюк только для задачи коммивояжера и работает, и то надо внимательно выбирать параметр w и не забывать проверять результат на валидность.
Мы здесь и обсуждаем доставку товара и задачу коммивояжера, и вы лично выше клялись, что все это невозможно именно для графа дорог.
Мы тут обсуждаем вот эту задачу:
А оптимизируйте мне, плз, регулярную доставку товара из пары складов в несколько магазинов — с учётом сроков доставки, дозагрузки фуры, минимизации простоя фуры (и вообще их количества), расхода топлива.
Она сводится к задаче коммивояжера только для случая одного склада и одной фуры бесконечной вместимости.
Ваш код творит какую-то хрень, дважды. Первый раз хрень видна ещё в названии: алгоритм Дейкстры спокойно работает на орграфах, для него никогда не требовалась никакая симметризация.
А второй раз — в реализации. Вот вам простейший тест, три вершины и две дуги:
a -> b <- cВ этом графе нет пути между вершинами a и c, а после вашей обработки такой путь появляется. Из чего следует, что графы ни разу не эквивалентны.
Ну извините, вы опять пишете полную глупость - посчитайте веса сегментов любого допустимого пути до и после обработки, они идентичны. Добавляются сегменты нулевой длины и запретительного веса, соответствующие несуществующему пути. PgRouting работает только с не направленными графами (симметричная матрица весов) - и найти путь на дорожном графе с односторонними дорогами он не в состоянии. После обработки направленного графа дорог в приведенном коде PgRouting работает на полученном графе и находит правильный путь даже для односторонних сегментов. Я уж не знаю, как еще объяснить, если сегменты нулевой длины до новых (виртуальных) вершин у вас каким-то чудом меняют длину пути...
Повторюсь: у вас не длина пути меняется, у вас новый путь из ниоткуда возникает, притом совершенно не "запретительной" длины.
С тем же успехом вы могли бы без всяких изысков превратить все дуги в рёбра, а потом раздвоить их обратно в дуги. Было бы в два раза меньше вершин и в три раза меньше дуг, а результат был бы тем же.
PS самое весёлое, что на вот этой страничке — https://docs.pgrouting.org/latest/en/pgr_dijkstra.html — упомянут опциональный параметр directed, предназначенный специально для работы с орграфами, и он true по умолчанию...
Дублирую свой комментарий, потому что вы просто количеством бессмысленных комментариев пытаетесь забить тему:
Открываем мою статью на хабре, на которую я ссылался выше "Делаем маршрутизацию (роутинг) на OpenStreetMap. Добавляем поддержку односторонних дорог"https://habr.com/ru/post/512580/ Как указано в статье, англоязычная страница википедии, посвященная проблеме коммивояжера, содержит нужный нам раздел Travelling salesman problem: Asymmetric:
Solving an asymmetric TSP graph can be somewhat complex. The following is a 3×3 matrix containing all possible path weights between the nodes A, B and C. One option is to turn an asymmetric matrix of size N into a symmetric matrix of size 2N.
Ровно это приведенный код и делает. Ваши утверждения, что это сделать невозможно, опровергнуты и теорией и практикой, а вы все продолжаете спорить, уже и мой профиль на гитхабе упомянули. Лучше бы код посмотрели, самородок вы наш...
P.S. Моя статья написана давно, когда этого параметра не было и как раз решала проблему его отсутствия. Нашли к чему придраться - это никак не отменяет того факта, что ваши утверждения откровенно ложны, поскольку существуют и теория и код, которые решают указанную задачу.
От того, что вы назовёте мои комментарии бессмысленными, а свой код — решающим задачу, построенный вами граф эквивалентным орграфу не станет.
Читаю и поражаюсь, как якобы "практик" способен смотреть на тест, на котором его алгоритм выдаёт фигню, и теоретизировать насчёт того что его код, видите ли, работает...
У меня фундаментальное физмат образование и я много лет занимаюсь научно-вычислительными проектами для вузов, в том числе. Так вот, уже на постановке задачи типа «дана матрица на терабайт» и аспиранты и доктора наук наглухо зависают за отсутствием каких-либо идей, как это вообще обрабатывать на своем десктопе или лаптопе. Про параллелизацию и векторизацию кода почти никто понятия не имеет, так что вся обработка будет выполняться стандартными библиотеками в едином блоке памяти (mmap легко нагуглить) и на одном ядре без попыток хоть как-то это ускорить. И лишь единицы способны хоть что-то прочитать по программированию и научиться, тогда как подавляющее большинство твердо стоят на позиции «нас этому не учили». Да, все ровно так, как и со многими программистами - а что вы хотите, люди-то такие же, не в должности и корочках дело.
Терабайтовые матрицы - сразу подозрение на неправильную постановку / некорректность задачи. Либо это очень специфическая область - тогда необходимо сотрудничество математиков (которые должны знать тонкости вычислений) и программистов (которые должны уметь использовать ресурсы ЭВМ грамотно). Один человек никогда качественно не решит сложную задачу (либо потратит неоправданно много времени). Команда и еще раз команда.
Это уже рядовая задача. К примеру, дамп OpenStreetMap уже давно больше терабайта «весит», а это граф, а не простая матрица. Радарный космоснимок это больше гигабайта растр и серия таких растров за 5 лет это несколько терабайт данных (скоро новые спутники будут доступны, там данных на порядок больше). Данные по океанам, трехмерные геологические модели и так далее и так далее - везде объемы данных огромные.
Да, соглашусь. Данных сейчас много... Но есть ли толк от этого (имею ввиду данные океанов, геологические модели и т.п.)? Я никогда с таким объемом данных не работал. Как бы то ни было, все равно данные читаются последовательно (параллельно-последовательно если быть точнее), за раз их никак не обработать.
Есть ли смысл в том, чтобы посчитать модели, прежде чем наугад бурить скважину за 30-100 миллионов долларов? :)
Суть в том, чтобы эффективно задействовать все ядра процессора. Скажем, на типовом лаптопе сейчас 8 ядер и 16 гигабайт памяти - итого, всего лишь 2 гигабайта на ядро, примерно как и лет 15 назад на коре2дуо (2 ядра и 4 гигабайта памяти). Если вы эти ресурсы сумеете разумно использовать - то можно терабайты данных в сутки «перелопатить» даже очень сложными алгоритмами. На самом деле, эппл эйр работает быстрее сервера интел/амд с равным числом ядер и кратно большей оперативкой, это не так много, но и совсем не мало. А далее встает вопрос масштабирования - будет ли ваше ПО работать в десять или сто раз быстрее при увеличении доступных вычислительных ресурсов.
тогда необходимо сотрудничество математиков (которые должны знать тонкости вычислений)
А для этого математику придётся стать программистом...
программистов (которые должны уметь использовать ресурсы ЭВМ грамотно)
Ну или кодеру вместо фреймворков и архитектур начать вникать в использование ресурсов вычислительными алгоритмами...
И не эффективнее ли в случае, если подобные задачи становятся не редкими исключениями, а нормальной практикой - т.е. если на такую деятельность есть спрос - вместо двух специалистов (математика и кодера) иметь одного программиста с весьма специфичной специализацией?..
Частичное проникновение конечно будет, кто ж спорит. Один программист для крупной компании - неэффективно, зачем тогда команды?
Частичное проникновение конечно будет, кто ж спорит.
Зависит от особенностей деятельности, как всегда.
Если программист в конторе работает как функция - сегодня пишет код для задачи одного проекта, завтра - для другого проекта, то это одно. Для него вообще знание о том, что делают продукты, для которых он пишет код - лишнее, т.к. занимают место в голове и мешают эффективно писать код.
А если это продуктовая команда, делающая один продукт - то уже другое.
Один программист для крупной компании - неэффективно, зачем тогда команды?
Вот и будет команда, в которой пара программистов пишут математическую часть задачи и плевать они хотели на фреймворки, интерфейсы и программные архитектуры, которыми занимаются другие программисты, примерно так же, как последним нет дело до того, как вычисление распараллеливается на 20 вычислительных нод :)
Никого ж не удивит, что специалист по базам данных может себе позволить делать структуру и запросы к ней, но не забивать себе голову пользовательскими интерфейсами?..
Я не настоящий сварщик, но при mmap'e разве нас не будет ограничивать IO?
Нужно же что-нибудь для буферизации в оперативную память и т.п.
Умножение матриц это относительно банальный пример. Попробуйте например загуглить что-нибудь занятное из рендеринга, например GTAO то же банальный, или как PBR устроен (про IBL не забудте). И там уже будет далеко не умножение матриц. Безусловно во всем этом можно разобраться и без бэкграунда который дает мат вуз, но будет это все значительно дольше и больнее. И на разобраться в этом не тайном знании (а оно не тайное, диф и интегральное исчисление всего лишь) уйдет далеко не пара часов на ютубе, если начинать с нуля, если все таки было образование, то как раз пара часов и уйдет на вспомнить что это и почему.
Полагаете, если человек привык самостоятельно изучать программирование, а потом ему где-то понадобится перемножить матрицы, то он не будет в состоянии тоже самостоятельно изучить всё, что нужно про умножение матриц?
Академические знания вовсе не подразумевают умение умножать матрицы вычислительно эффективно. Если вычислительно сложную программу писать, руководствуясь только учебником матанализа, то и работать она будет асимптотически бесконечное время - и с точки зрения чистой математики, все будет замечательно. А только понимать формулы, но не создавать новые - это школьный уровень вообще-то (вы посмотрите школьные задачники по математике дореволюционных времен и периода крепкого СССР, к примеру).
если «общематематические» — то не подразумевают. а если знания «вычислительной математики и численных методов» — то подразумевают. Ну а «среднее положение» — «математика для инженеров» — подразумевают знание того, что для вычислений «математики» в реальном мире на реальной числодробилке (начиная от калькулятора) есть такой предмет, как «численные методы». Ну и, возможно, знание некоторых методов оттуда, применимых к конкретной инженерной дисциплине…
Покажите мне российский вузовский учебник по численным методам, где демонстрируются методы работы с большими данными (в разы или на порядке превышающими объем доступной оперативной памяти)? А еще поясните, как вы собираетесь, скажем, distance correlation на терабайте данных посчитать, согласно учебникам?
Но я вообще не понял смысл вашего вопроса.
Вы ссылаетесь на «численные методы», не понимая, что там изучают - никакого вычислительно эффективного перемножения матриц там нет. А есть простейшие методы матричных вычислений и решения дифуров, методы оценки сходимости и тому подобное - и все на таких примерах, которые можно не задумываясь об эффективности решать на микроконтроллере, встроенном в современную лампочку (кстати, раньше все это считали просто на бумаге). Так что на реальной задаче с терабайтной матрицей никакие академические знания вам не помогут, даже если у вас и был такой предмет, как численные методы.
И вновь вы рассказываете байки про то, как вам мол помогает академическое образование, при этом тщательно обходя заданный выше простой и ясный вопрос - как вы будете считать distance correlation на терабайтной матрице? Видимо, никак, будете искать специалиста с практическим опытом заместо академического :) Кстати, если вдруг захотите погуглить, то не тратьте времени (те библиотеки, что найдете, на больших матрицах не работают).
тщательно обходя заданный выше простой и ясный вопросвы что, хотите получить ответ: Этому учат в таком-то ВУЗе на такой-то кафедре, в таком-то семестре такого-то курса, в 13:15 в аудитории 17?
Так вот в реальности не знаете вы, как искать ответ, и даже никакой идеи не можете предложить. А будете вы гуглить по словам «distance correlation” - ровно так же, как и человек без академического образования. Хотите академическую подсказку? Да пожалуйста - корреляция дистанции основана на центрированных моментах и, насколько я знаю, для них тоже нет открытой big data реализации :) В то же время, человек с практическим опытом начнет с декомпозиции задачи в парадигме map-reduce и построит решение.
И 100500 формошлепов с «практическим опытом» просто не знают страшных слов «декомпозиция» и map-reduce.
зы. вы ожидали, что я брошусь искать ответ на то, «как считать»?
Чем же «формошлеп» с высшим образованием лучше такового без оного? Понтами и «корочкой»? Как видим, на деле для (редкой) реальной задачки, где академические знания могли бы пригодиться, вы гуглить не хотите (или не умеете) и как решать, не имеете понятия. Я же сказал - искать ответ бессмысленно, нужно самому думать… но это для получения «корочки» вовсе не требуется :)
ну а в оставшихся задачах — люди с высшим образованием как правило находят решения лучше и быстрее, чем без оного.
Исключения есть, но, как говорится, «на то они и исключения»
люди с высшим образованием как правило находят решения лучше и быстрее, чем без оного
Бездоказательное утверждение и, в целом, неверное. Я два десятилетия занимаюсь научным программированием и хуже кода, чем от академических специалистов, я не встречал.
Хотите пример? Академическими специалистами написан пакет спутниковой интерферометрия GMTSAR (в составе бинари плюс шелл скрипты). Хороший пакет, мощный, и код достойный и архитектура проекта. Так вот, я переписал часть его функций на питоне и сделал врапперы для остальных функций так, что теперь могу на Apple Air 8 cores 16 GB RAM обработать объемы данных, которые в GMTSAR не получается обработать на рабочей станции 32 cores 512 GB RAM. Полученный пакет интерферометрии называется PyGMTSAR и доступен у меня на гитхабе. Вот вам разница между теорией и практикой. Другой пример - большой пакет обработки данных по океанам (температура, соленость и прочее) - исходный вариант на матлабе требует несколько суток вычислений на сто ядерном кластере, мой вариант на питоне считает две минуты на двухядерном Apple Air 2014 года (я могу дать ссылку на исходный проект - там очевидно, насколько ужасен этот Matlab код с невероятным количеством вложенных eval). Ну и так далее, примеров сотни можно вспомнить.
Так вот, я переписал часть его функций
Ну так у вас ведь академическое образование. То есть получается в данном конкретном случае один "академический специалист" улучшил работу других.
Вот вам разница между теорией и практикой.
А это вообще к чему? По вашему практика есть только у самоучек, а "академические специалисты" в принципе всегда чистые теоретики?
Ну и так далее, примеров сотни можно вспомнить.
Вы хотите сказать что нет примеров для обратной ситуации? Ну то есть когда не "академические специалисты" пишут плохой код, а потом "академические специалисты" его исправляют? Или их по вашему будет сильно меньше?
Есть разница между написать свою реализацию и просто воспроизвести имеющуюся на другом языке с правильным выбором технологий и прочее, последнее это чистейшее программирование. И начал я с того, что именно воспроизвел существующий код и получил принципиально другие свойства продукта. А уж потом еще раз переписал этот код, уже используя академические знания :)
То есть вы даже сами согласны что в какой-то момент академические знания вам всё-таки пригодились.
Так я этим и занимаюсь как хобби, для развлечения, чтобы имеющиеся академические знания пригождались :) Вы тоже можете выбрать хобби так, чтобы вам любые знания и умения пригодились, это совсем не показательно же.
Но при этом приводите это как пример того что академические знания не нужны или даже вредны....
Вообще-то я говорю о том, что академические знания ВМЕСТО практических не годятся. Программист с практическими знаниями (самоучка, в том числе) будет лучше программировать, чем обладатель математических знаний или арфист или сантехник и так далее. Имхо странно, что это вообще обсуждается - знание определенных разделов математики не делает вас лучше как человека или спортсмена или кухарку или доярку или программиста.
Естественно без практики никуда. И никто свежего выпускника ВУЗа сениором не возьмёт. Вопрос скорее в том даёт ли академичкое образование преимущество при равном стаже. И на мой взгляд обычно даёт.
«Вам шашечки или ехать?» Возможно, за «корочки» вас быстрее возьмут «сеньором» (как же любите вы эти все лычки), но я говорю про профессиональный уровень, на который все это мало влияет. И по моей практике, средний выпускник-физик пишет совершенно кошмарный код (и переучить нереально трудно), в отличие от кода просто посредственного от выпускника-программиста (что решается опытом).
Честно говоря я уже вообще не понимаю что вы хотите сказать. Ведь оба выпускника имеют академическое образование и по умолчанию нулевой опыт.
И для меня "сениор" это не просто лычка, а как раз тот самый профессиональный уровень.
То есть направление образования вам вообще не важно и после академического образования физкультурником вы готовы работать физиком-ядерщиком? Ну я и говорю, при таком подходе образование это просто «лычка».
Где вы у меня такое вычитали? Такого я нигде не писал. Я писал что наличие академического образования помогает и является плюсом.
Это не значит что имея диплом по одной специальности вы сразу можете работать во всех. Это значит что вам будет проще освоить новую специальность. И естественно чем ближе ваше образование к непрофильной специальности, тем проще вам будет.
Так ведь нет - знание численных методов, как их подают физикам, только помешает в работе программистом, я уже писал об этом. Потому, что игнорируются ключевые на практике вещи типа оценки и подготовки данных, оценки аппаратных ограничений (объема данных и методов хранения и кэширования)… изучаются только абстрактные алгоритмы вычисления производных и так далее, притом ровно так, как они были когда-то придуманы для вычислений на бумаге.
Я не вижу как оно должно мешать. И да, физику сначала надо будет "войти в ИТ" и понять чем работа программиста отличается. То есть например те самые ваши " оценки и подготовки данных, оценки аппаратных ограничений (объема данных и методов хранения и кэширования)". Но особо много времени это не занимает.
А вот потом умение работать с абстракциями скорее помогает. То есть например у нас в ИТ работает относительно много физиков. Только по моему опыту они относительно быстро уходят в архитекты или там техлиды-тимлиды.
Бездоказательное утверждение
Вы как-то как-то из одной плоскость в другую перескакиваете. Если взять например двух программистов, допустим тех же формошлепов, с сопоставимым по времени и задачам опыту работы (с одного отдела на работе например). При этом один из них без высшего образование, а другой имеет айтишное или математическое. То вы действительно считаете, что при поиске решения вашей задачи, они будут находится в изначально равных условиях, или что у самоучки будет преимущество?
Я не спорю, конечно, что результат подобного эксперимента может оказаться неожиданным, так как не проводил его и не читал про подобные. Но это вполне себе проверяемое утверждение.
Очень часто вижу преимущества именно у самоучек - потому что люди признают свое незнание и готовы искать и учиться, а люди с «корочками» попытаются что-то выученное применить и при неудаче скажут «да это задача какая-то неправильная» и перестанут пытаться. Заученные знания больше вредны, чем полезны, а «учиться учиться» способны лишь единицы и это не зависит от «корочек», скорее, вопрос психологии.
Теория гравитации тоже давно придумана, а вы попробуйте ее на практике применить и построить тоже давно придуманный гравилет.
Да вот хотя бы пример с автором эскулайт, phd в computer science Ричардом Хиппом - он уж два десятилетия «пилит» (с командой) этот эскулайт и с каждым годом добивается существенного прогресса в производительности и возможностях… если сравнивать с первыми версиями (хотя у Ричарда и тогда уже был далеко не только академический опыт) это как постгрес против табличного файла с записями фиксированной ширины. Вот и думайте, что значит практическое знание против академического.
В формуле для вычисления корреляции дистанции нет констант и каждый элемент зависит от всей матрицы, я это уже в другом комментарии писал.
А вы разницу между выборочной средней и генеральной средней знаете? Если да, то это ответ, если нет, то трудно объяснить, почитайте сначала теорию. А вот на практике в map-reduce реализации вполне себе делают вычисление среднего по каждому блоку отдельно - по чисто техническим соображениям. А если среднее и дисперсия бесконечные получаются, то и вовсе придется к двухвыборочной дисперсии переходить - известная проблема дрейфа частоты генератора, к примеру. Вы бы еще про корректность вычисления Фурье преобразования ограниченной выборки спросили :)
А вы разницу между выборочной средней и генеральной средней знаете? Если да, то это ответ
Это ответ только на первый вопрос, но не на второй.
Вы что-то путаете, ответ на второй вопрос есть - среднее по выборке определено для всей конкретной выборки, а среднее по генеральной совокупности и вовсе определено более чем на конкретной выборке. Впрочем, как и указано, это ничуть не мешает в определенных случаях и среднему и дисперсии стремиться к бесконечности, так что хоть обвыноситесь за скобки, результат окажется бессмысленным.
Какая разница для чего оно там определено, в конкретной формуле его можно вынести за знак суммы или нет?
Можно выносить, а можно не выносить - и второй случай гораздо интереснее для больших данных. Так чем вам это все поможет для конкретной задачки с distance correlation?
Тем, что это один из двух способов избежать Ω(N3) сложности алгоритма, равно как и зависимости сразу от всего набора исходных данных.
Ну то есть вы вынесли коэффициент, которого посчитать пока все равно не можете, и на этом успокоились? Как считать-то будете?:)
А чего это я его посчитать не могу-то, в вашей исходной задаче?
Да и на конкретной выборке среднее по выборке всегда существует...
Конвертируем исходный csv файл в бинарный, получаем 200 гигабайт данных. Пусть скорость чтения с SSD диска будет 2 гигабайта в секунду, тогда вы можете прочитать этот файл за 100 секунд. Миллиард раз прочитать файл для анализа всей матрицы дистанций займет 100 миллиардов секунд. Учитывая, что один год это примерно 30 миллионов секунд, получается, что 3000 лет вам понадобится только на чтение файла, не считая времени на вычисления. Отсюда следует, что если вы не Горец - то нет, не можете вы посчитать это среднее, не доживете.
Миллиард раз прочитать файл для анализа всей матрицы дистанций
Зачем? Зачем его читать миллиард раз?
Вы сейчас понимаете, что вы в этой ветке единственный кто предлагает идиотские решения, но почему-то приписываете эти решения остальным?
Зачем его читать больше одного раза то?
У меня не помещается (16 GB RAM). Впрочем, выше кто-то уже предложил кластер использовать, но дальше не продвинулся.
Увы, тут никто даже не попытался оценить, решаемая ли вообще вычислительная задача, если решаемая, какое нужно "железо" и сколько времени надо будет считать. Кроме метода "тыка" - типа давайте возьмем оперативки больше, чем объем данных (а дальше-то что?) идей нет вообще.
Справедливости ради, вашу аргументацию можно в обе стороны завернуть. Я вот считаю себя практическим программистом, и терабайтная матрица для меня выглядит больше как вызов чем как что-то страшное — но вот решить вашу задачу без помощи "академиста" и гугления я не смогу совершенно точно. Хотя бы потому что я вообще не знаю что такое distance correlation.
И да, фиг вы эту задачу в map-reduce декомпозируете, по крайней мере "в лоб" тут не получится точно.
Вообще-то я этот алгоритм за день на map-reduce написал, можете посмотреть в моем профиле на апворк, там есть и не такие задачи :) Определение distance correlation легко нагуглить: https://en.m.wikipedia.org/wiki/Distance_correlation Так вот для программирования этого алгоритма нужны знания практических вещей (аппаратные ограничения и подходы для map-reduce), и никакие академические знания не помогут вам сделать эффективную реализацию.
Формулу ту я видел, но применять в лоб квадратичный алгоритм к триллиону элементов не хватит никакого кластера. Вы или что-то скрываете про задачу, или про своё понимание практического программиста без академических знаний...
Вы или что-то скрываете про задачу, или про своё понимание практического программиста без академических знаний...
Ну если заглянуть в профиль, то :
В 2004 году я закончил Радиофизический факультет ННГУ и моя магистерская работа по моделированию нелинейных оптических сред победила на всероссийском конкурсе (см. www.ifmo.ru/file/conferens/230/2005.doc)
Так все это благодаря правильному использованию как раз практического программирования :) Ну а обсуждаемая задачка с distance correlation прекрасна тем, что выглядит как академическая, но ее нельзя решить с академическими знаниями и можно с практическими, смотрите мой коммент рядом.
Как ни крути, но академические знания у вас есть. Поэтому нельзя исключить что они вполне себе сыграли свою роль и без них ничего остального бы не было. Даже если вы сами считаете иначе.
Так в том и дело - академических знаний программирования у меня нет, а дисциплина "вычислительные методы" совсем не то. Более того, я высшее образование получил до того, как вообще придумали distance correlation и стал известен и популярен map-reduce.
Так в том и дело — академических знаний программирования у меня нет, а дисциплина "вычислительные методы" совсем не то
Извините, но нет. Даже если у вас образование физика или даже химика, то у вас уже есть "академические знания", которые вам могут помочь в программировании. Ну по сравнению с человеком у которого 10 классов школы и всё.
Более того, я высшее образование получил до того, как вообще придумали distance correlation и стал известен и популярен map-reduce.
Ну так академическое образование это в первую очередь не про сами знания, а про умение их получать. Например работать с источниками, искать информацию, банально "уметь думать в нужном направлении" и так далее и тому подобное. Если в вашем ВУЗе вас просто "накачали" набором фактов, то это вам с ВУЗом не повезло. Хотя я сомневаюсь что это так было.
Вообще на своем курсе я был известен как раз тем, что на лекции не ходил - а занимался дома по учебникам, это раз. Два - мои однокурсники или достигли успехов в науке и программируют весьма рудиментарно, или не появлялись на занятиях вовсе (работали) и добились успехов в программировании. Вот чтобы кто-то ходил на занятия и знал физику-математику и еще отлично программировал - вообще не припомню ни единого примера. В общем, в академической среде искать хорошего программиста - это как редкие кораллы искать на людном пляже.
Ну ок это ваш опыт. Но это не значит что его можно экстраполировпть на всех. У меня опыт скорее обратный. То есть большинство тех с кем я учился стали хорошими программистами.
И это не значит что это единственный возможный путь стать нормальным программистом. Но на мой взгляд это наиболее простой путь. По крайней мере у нас.
Вы учились на «не программиста» и почти все ваши однокурсники стали хорошими программистами?! Трудно поверить, просьба огласить вуз, кафедру, год выпуска для проверки :)
Я учился на прикладной математике и на информатике. И там и там большинство одногрупников стало программистами.
ЛЭТИ, прикладная математика 2001. И Friedrich-Alexander-Universität Erlangen, Informatik 2005.
И в чем логика? Если вы учились на программиста и стали программистом, то почему вы сравниваете себя с учившимися на не программиста и ставшими не программистами? Математика у физиков и у вас - это совершенно разные разделы математики и совершенно по-разному применяются, абсурдно сравнивать вашу прикладную математику (действительно, основа программирования) с фундаментальной (как вы хотите описание эффектов квантовой физики применять для написания кода?).
Речь то вроде бы шла об академическом образовании как таковом? Или исключительно о непрофильном?
Так реальные задачи обычно требуют знаний из нескольких областей. Если вы физик-ядерщик и хотите ядерный реактор моделировать - то тут вам и сопромат и программирование нужны, а если программист - то добро пожаловать в изучение ядерной физики и того же сопромата. Вопрос лишь в том, что вы с корочками программиста отказываетесь от изучения двух названных "непрофильных" дисциплин - и толку от вас мало, а самоучка зачастую готов освоить все три и сделать то, что вы не хотите или не можете сделать.
Я всё меньше и меньше понимаю что вы изначально хотели сказать....
Все очень просто - если у вас есть высшее образование в области программирования, это вообще ничего не говорит о ваших знаниях физики, математики или балета. И никаких преимуществ перед «самоучкой» у вас нет, как только вам потребуется выйти за пределы кодинга и решить практическую задачу. А вы пытаетесь выдать наличие «академического образования» в какой-то области за панацею для всего. Хотя безусловно, средний физик или математик программирование освоит куда быстрее, чем средний танцор - ну хотя бы потому, что запоминание сотен и тысяч страниц формул (пожалуй, десяток лучших выпускников с курса запоминают с одного прочтения) дает возможность усвоить огромное количество информации быстро. Но я не видел ни одного физика и математика, кто бы эту (универсальную) способность развил с нуля именно в вузе…
Где вы у меня увидели "панацею для всего"? Ещё раз повторю:
Где вы у меня такое вычитали? Такого я нигде не писал. Я писал что наличие академического образования помогает и является плюсом.
Кроме того вступил в дискуссию я из-за того что вы вроде бы писали что люди с академическим образованием хуже пишут программы чем люди без такового. Вы всё ещё так считаете или я вас неправильно понял?
Вы писали, что наличие академического образования является плюсом для всего. В итоге обсуждения оказалось, что академическое образование в области программирования может являться плюсом для программиста (а может не являться). Ни одного аргумента, как ваше образование поможет вам в непрофильных дисциплинах, вы не привели.
Вы писали, что наличие академического образования является плюсом для всего.
Они и является плюсом. Но не панацеей.
. Ни одного аргумента, как ваше образование поможет вам в непрофильных дисциплинах, вы не привели.
Ну так например то самое умение в абстракции, которое ксттаи вы сами упомянули. Умение работать с источниками и так далее.
На мой вопрос ответите? Ну на тему того что что люди с академическим образованием хуже пишут программы чем люди без таковог?
Посмотрите любой продукт на матлабе - обычно на нем пишут как раз люди с академическим физмат образованием. Пример: https://ecco-group.org/user-guide-v4r4.htm от НАСА и топовых вузов… а весь код пестрит уймой вложенных eval с исполнением инструкций, начиная со сложения, вычитания, умножения и так далее. По историческим причинам, в коде есть функции работы с разными сетками для исходных данных, которые никто не переписывал, а просто делали врапперы (снова с помощью eval). Исходные данные «весят» сотни гигабайт, так что все это совершенно фатально для быстродействия. И более того - не существует ни одного релиза, в котором бы работали все функции и работали правильно - если вам нужно получить один график, то он корректен только в одном релизе, другой - в другом, и так далее.
Вы на мой вопрос можете прямо ответить? Вы вроде бы писали что люди с академическим образованием хуже пишут программы чем люди без такового. Вы всё ещё так считаете или я вас неправильно понял?
да, и я вам это уже показал и доказал, ссылка приведена и описание кода тоже. Не верите - сами код смотрите, «вы ж программист». Подобных примеров у меня огромное количество, но вот этот код открытый и общедоступный, на него каждый может полюбоваться.
Нет, не доказали и не показали. Вы привели отдельные примеры того когда это так есть или может быть. Но это не означает что оно так всегда или даже в большинстве случаев.
Даже если у вас образование физика или даже химика, то у вас уже есть "академические знания", которые вам могут помочь в программировании.
А если историка или юриста — эти знания перестают быть академическими?
Умение расчета орбиталей и физикохимических свойств вещества помогут не больше, чем знание особенностей римской политики времен принципата или триста одного случая наступления ответственности без непосредственной вины.
Нет, они могут помочь… если в процессе работы вы случайно наткнетесь на формулу которую еще не успели забыть.
работать с источниками
а что скрывается за этим магическим словосочетанием? Потому как любознательному человеку работать с источниками приходится учиться задолго до совершеннолетия.
искать информацию
тоже приходится учиться сильно раньше
банально "уметь думать в нужном направлении"
В смысле не отвлекаться?
Так этот навык приходится осваивать еще в младшей школе. Если, конечно, ты не двоешник или за тебя не делают все родители.
Если в вашем ВУЗе вас просто "накачали" набором фактов, то это вам с ВУЗом не повезло
Первое, что слышит абитурьент, приходя в ВУЗ — здесь вам не школа, вам никто ничего не должен. И большая часть преподов в тех ВУЗах, с которым этот имел несчастье так или иначе быть знаком, ведет себя в полном соответствии с этой максимой.
В ВУЗах никого не колышет образовательный процесс, у них совершенно другие задачи. Основная задача ВУЗа — подгонка KPI под дальнейшее финансирование, висящее над ними дамокловым мечом.
Соответственно, весь процесс обучения строится по остаточному принципу.
А обучение умениям работать с источниками и прочим придыхательным прилагательным — в преподаваемые дисциплины не входит и сейчас сводится к меня не волнует, гуглите.
А если историка или юриста — эти знания перестают быть академическими?
Нет, не перестают. Но всё-таки на мой взгляд различие между гуманитарными науками и STEM в этом контексте есть.
а что скрывается за этим магическим словосочетанием? Потому как любознательному человеку работать с источниками приходится учиться задолго до совершеннолетия.
Поиск, умение фильтровать, умение быстро просматривать и так далее и тому подобное. И да, этому можно научиться и самому. Но на мой взгляд подавляющее большинство школьников этого не умеют.
Первое, что слышит абитурьент, приходя в ВУЗ — здесь вам не школа, вам никто ничего не должен. В ВУЗах никого не колышет образовательный процесс, у них совершенно другие задачи.
А вот это уже сильно зависит от ВУЗа. И не знаю как с этим сейчас ситуация в России, но когда я учился в ЛЭТИ того что вы описываете практически не было. А уж если взять немецкий ВУЗ где я учился, то там подход вообще очень сильно отличается от российского-советского.
Когда я пришел в вуз, никакого интернета еще в помине не было. Так что мы изучали библиографию, а ссылки на литературу, которую порой рекомендовали преподаватели - могли вести в «закрытую секцию», откуда студентам книги не выдавали, так что можно получить нужное только на кафедре. Так вот посидеть на кафедре и полистать книгу вообще никак не равно найти нужное в интернете (или хотя бы почитать книгу дома). Теперь интернет общедоступен, но многие преподаватели остались прежними (как и школьные учителя) и я что-то не слышал про замену библиографии на что-то вроде «искусство гуглить».
Опять же, классика - чтобы задать правильный вопрос, нужно знать большую часть ответа. Да вот же мы тут в комментариях уже типичную задачку вычисления одного из видов корреляции мусолим второй день, и почему-то никто еще не сообразил, что же надо искать:) Хотя вроде бы очевидно, что клауд провайдеры предоставляют подобные вычисления на огромных объемах данных и вообще «на лету» - гугл биг квери, скажем, куда более чем на терабайтных данных может сложные метрики считать (и явно на каждый хост все данные не копирует при этом), и методика map-reduce описана многократно и есть открытые реализации, так что, в целом, ясно, куда копать… но все интересующиеся для начала говорят, что это слишком просто, а потом меняют мнение на противоположное :) А вы говорите, что каждый должен и обязан уметь искать информацию всеми способами прямо после вуза…
Когда я пришел в вуз, никакого интернета еще в помине не было.
У меня была точно такая же ситуация. Вот только в библиотеке было свободно доступно всё необходимое.
И да, преподаватели, что в России что в Германии, подсказывали по началу где стоило бы поискать. Но чем дальше тем меньше. Возможно мне повезло с преподавателями в ЛЭТИ. Не знаю. В Германии для университета это скорее норма.
Видимо, вас просто не интересовали никакие редкие издания, которые доступны или только кандидатам наук, или только сотрудникам или только по разрешению директора библиотеки. Ни в одной библиотеке мира любую книгу из фондов вам (тем более домой) не выдадут. А в итоге, вы везде натыкаетесь на цитаты из какого-то редкого издания, которое найти невозможно (и все или почти все те, кто цитируют, сами не читали оригинал, а только перецитируют выдержки из него). А сегодня вы можете просто нагуглить нужное :)
Для обычного образовательного процесса, особенно на первых курсах, такие издания точно не нужны.
Дипломную-курсовую я в России уже не писал и писал их в Германии. Там в библиотеке студентам были доступны все книги. Редкие в виде диакопий(не знаю как это правильно по русски называется), а частично уже и в дигитальном формате. Если были нужны какие-то работы, которых не было в библиотеке, то при наличии обоснования из можно было заказать. За счёт кафедры или в крайнем случае за свой счёт.
И нет сейчас вы точно так же не можете нагуглить всё что вы хотите потому что к куче научных работ допуск платный и не особо дёшевый. Хотя сейчас конечно с этим всем стало проще.
Ну почему же с первого курса, мне начиная с третьего курса для курсовой работы разное интересное понадобилось, а цифровых копий не было, конечно. А нагуглить сейчас можно почти все - в платных библиотеках с закрытым доступом найти DOI и по нему уже откопать на сайхабе или просто в частных архивах. Уж точно «знание сайхаба» сегодня несравнимо полезнее бумажной библиографии.
Ну то есть вы получили умение работать с бумажной библиографией и умение копать на сайхабе и в частных архивах. Умеет это средний выпускник школы или даже ПТУ?
Ну извините, если современный выпускник научится этому годам так к 40 (как мое поколение), то это никуда не годится. А в 20 лет этому не учат и сейчас. Академическое образование это про стабильность, так что лет через 50 расскажут про сайхаб, но, возможно, уже на лекциях по истории :)
Ну извините, если современный выпускник научится этому годам так к 40 (как мое поколение), то это никуда не годится.
Ещё раз: в ВУЗах на мой взгляд этому учат. Где-то лучше, где-то хуже, но учат. В школах и ПТУ скорее нет.
Поэтому умение это делать это одно из преимуществ академического образования.
Академическое образование это про стабильность, так что лет через 50 расскажут про сайхаб, но, возможно, уже на лекциях по истории :)
А вот это скорее проблема именно российских ВУЗов. В Германии точно такой проблемы нет и здесь учат вполне себе актуальным вещам.То есть например у нас в начале 2000-х уже были Java и даже C#.
Ну вот как раз выбор языка программирования это не так важно, на мой взгляд. Все равно в работе будете использовать 5-10 разных языков постоянно (ну как минимум sql, bash, c, python, javascript), так что даже если с других начнете изучать - разница небольшая. Важно качество обучения.
То есть например у нас в начале 2000-х уже были Java и даже C#.
Вы даже не представляете себе, каким замшелым говном на начало 2000х были эти Java и C#.
Вряд ли те, кто начал учить эти платформы на заре их появления, пожалели об этом впоследствии :)
Синдром утёнка. Многие С++ники тоже не осознают, что жизнь проводят как мастер-сантехник из анекдота. :-)
Я вот много на чём писал. В начале 2000-х на Delphi, потом на Java, потом на дотнете, сейчас проект на TS+React+AWS. И знаете, дотнет - лучше :) Он на порядки архитектурно красивее, чем все та мешанина из мусора с редкими бриллиантами, которая сваливается ко мне в node_modules. Поэтому таким утёнком быть не стыдно.
Он на порядки архитектурно красивее, чем все та мешанина из мусора с редкими бриллиантами, которая сваливается ко мне в node_modules.
Ну вы нашли, с чем сравнивать.
Напоминаю, что в 2000 году уже был практически полностью готов Haskell, с классами типов;
уже 15 лет как были реализованы языки с выводом типов Хиндли-Милнером (SML/OCaml);
ad-hock полиморфизм со статическим выводом типов;
чёрт знает сколько времени существовали языки с алгебраическими типами данных;
чёрт знает, сколько времени был pattern-matching, а не убогий switch.
А тут в 2000 году реализован язык с идеями из Simula 68. :-)
были реализованы языки с выводом типов
Да, но это синтаксический сахар, а не нечто важное для продуктивности разработки. Например, в дотнете был готовый фреймворк работы с СУБД, и это на порядки круче, чем такая утилитарная вещь, как дополнительные навороты системы типов.
чёрт знает, сколько времени был pattern-matching, а не убогий switch
А это вообще сахар к сахару. Если выводом типов вы хоть и не сэкономите себе много времени, но хотя бы будете пользоваться повседневно, то pattern-matching вам понадобится раз в месяц в лучшем случае, и то безболезненно меняется на if с регулярками :)
Особенности сишарпа (как и джавы) были не в синтаксисе, а в переносимой и безопасной исполняющей среде.
Да, но это синтаксический сахар, а не нечто важное для продуктивности разработки.
Ну тут сразу две неправильные вещи:
1. Вывод типов не является синтаксическим сахаром. Он накладывает серьёзные ограничения на систему типов. Поэтому, к примеру, в С/С++ Х-М не получится.
2. Pattern-matching нужен буквально везде и всюду. После того, как он попал в руки, вообще непонятно, как без него можно было жить. If-с регулярками, в отличие от нормальных "match with", "case of" и т.д. не проверяет, что вы учли все возможные варианты; If-с регулярками разлетается на много страниц.
И, кстати, мы обсуждаем не синтаксис (синтаксис у C# и Java из Алгола с мелкими коррекциями), а семантику.
Он накладывает серьёзные ограничения на систему типов. Поэтому, к примеру, в С/С++ Х-М не получится.
У меня другой подход к оценке этого. Конечно, не без доли субъективизма, но по крайней мере, мой подход обоснован. Я измеряю любую фичу языка одной общей мерой - насколько она повышает продуктивность решения задач. Вывод типов для обычного императивного языка повышает это несущественно. Да, вы в ряде случаев не держите в голове, какую структуру вы получите в результате выполнения той или иной функции, но только и всего. Это как раз и есть сахар. Да, есть языки, где на этом построена вся парадигма программирования. Но их нельзя напрямую сравнивать и говорить, что лучше, а что хуже.
If-с регулярками, в отличие от нормальных "match with", "case of" и т.д. не проверяет, что вы учли все возможные варианты
...но первый же юнит-тест вам это выявит, а если не покрыто тестами, все равно такой баг мимо вас не пройдёт. А кейсы, где вам надо перебрать все значения перечислений, которых достаточно много, чтобы вероятность забыть один из них была не околонулевая... как часто возникают? Понятно, мой случай - не статистика, но у меня это единичные случаи в году, а не повседневная задача.
Конечно, не без доли субъективизма, но по крайней мере, мой подход обоснован. Я измеряю любую фичу языка одной общей мерой - насколько она повышает продуктивность решения задач.
Очевидно, что любая фича любого языка не повышает продуктивность того, кто ей не владеет. А если человек отказывается её изучать, то она и в принципе не может повысить его продуктивность. :-)
Но, с учётом того, что современный C#, через 20 лет после, таки всосал эти функциональные фичи, вы наверяка их используете. Просто сейчас утверждаете, что "не говорите прозой". Вот вы когда-нибудь возвращали из функции пару значений? Используете ли Option/Result?
Очевидно, что любая фича любого языка не повышает продуктивность того, кто ей не владеет.
Я в данном случае пишу про людей, которые ей владеют. В классическом случае, если вам нужно было вернуть из функции два значения, вы сделали бы объект с двумя полями, и совершенно не заметили бы тех пятнадцати секунд, которые вам понадобились для описания его типа. Да, теперь это удобнее, но тем не менее, вы не экономите часы вашей работы. Секунды и минуты - да. Это не принципиально. В этом и разница между сахаром и фундаментальными изменениями, а не в количестве архитектурных изменений под капотом компилятора.
Вывод типов для обычного императивного языка повышает это несущественно. Да, вы в ряде случаев не держите в голове, какую структуру вы получите в результате выполнения той или иной функции, но только и всего.
Ха-ха, это не тот вывод типов!
В общем случае вывод типов может работать в любом направлении, и порой это действительно сильно упрощает код.
В том же Rust благодаря выводу типов можно писать None не уточняя тип. А это, между прочим, то на чём обычно обламываются "монадописатели", мечтающие добавить монады в другие языки и решающие начать с Option[al].
Или вот ещё пример из Rust:
let mut x = HashMap::new(); // HashMap<(i32, i32), (&str, i32, &str)>
x.insert((5, 6), ("foo", 42, "baz"));Вроде бы кажется не особо важно — ровно до тех пор пока не понадобится создать промежуточную переменную в каком-нибудь алгоритме, который приходится кучу раз исправлять.
Это, наверное, от задач зависит, но, по крайней мере, лично я СУБД пользуюсь очень редко, а наворотами систем типов — очень часто.
Конечно, от задач, но в целом в мире софта, в котором есть хранилище данных, на порядок больше, чем софта на Хаскеле :)
Мы обсуждали, насколько те или иные языки более качественно новые, чтобы от их появления в программе фанатеть
Эм... нет, мы вообще-то обсуждали, стоил ли СиШарп в 2000-е годы внимания, или был отсталым и ненужным :)
С моей точки зрения, в языке важна не новизна парадигмы программирования, а то, сколько вам понадобится времени, чтобы создать нужный вам софт. И в этом деле куда большую роль играет сопутствующая библиотека, а не синтаксические подвыподвёрты.
Но я прекрасно понимаю людей, которым интересны именно синтаксические подвыподвёрты, это тоже увлекательно, просто это немного другой мир и другие цели, это ближе к гимнастике для ума.
Молодая, грамотно спроектированная платформа, построенная как аналог ещё достаточно свежей Java, которую крупнейший поставщик ОС и офисного софта объявил в качестве своей основной платформы в обозримом будущем (и так и сделал)? Язык с простым понятным (и наиболее распространённым) синтаксисом и строгой типизацией?
По-моему, это как раз тот относительно редкий случай, когда в ВУЗе действительно угадали с перспективным направлением для обучения.
Представляю. Но для универа и чтобы просто учиться их вполне хватало.
Да вот же мы тут в комментариях уже типичную задачку вычисления одного из видов корреляции мусолим второй день, и почему-то никто еще не сообразил, что же надо искать
Это вы её мусолите, остальным просто не интересно подробно разбирать очевидные вещи
А вы правильно мыслите. Теперь учтем, что у нас квадратная сложность не от числа значений как таковых, а от числа точек в многомерном пространстве, то есть записей или строк. Пусть будет текстовый файл (типичный формат обмена) на 1 терабайт на входе, в нем набор столбцов, скажем, 50. Значения типа 32-битного float плюс разделитель займут почти 20 байт, итого 1 килобайт на строку и всего получится 1 миллиард записей. Совсем не триллион, верно? Более того, расстояние от точки A до точки Б равно расстоянию от точки Б до точки А, так что еще вдвое меньше. Посчитать это можно и на лаптопе, остается использовать map-reduce так, чтобы не хранить в памяти сразу всю матрицу расстояний размером миллиард на миллиард. Нам для вычислений нужна сама матрица и ее построчные и поколоночные суммы и сумма этих сумм (матрица очевидно симметричная, так что эти суммы построчные и поколоночные равны). Тут уже видна довольна простая реализация - считаем для одного элемента и поблочно считываемого вектора на миллиард элементов дистанции и суммируем с записью на диск, в итоге получаем миллиард поколоночных (построчных) сумм. Можно сразу же вести счетчик сумм от сохраняемых сумм. Дальше остается расписать результат как функцию от дистанций и сумм и снова для каждого элемента читать исходный файл и считать все дистанции.
Как видите, в реализации map-reduce мы считываем исходные данные два раза по миллиарду раз вместо одного раза по миллиарду раз в теории. И тут уж вся задача состоит в том, чтобы правильно выбрать размеры считываемых блоков данных для эффективного кэширования при многопоточной обработке. Так вот я еще не видел академического специалиста, который бы понял, что ограничения тут именно аппаратные и смог бы сделать рабочую реализацию. А "нормальные" программисты с такими аппаратными ограничениями сталкиваются постоянно и задачу решить могут.
Пф, если там на самом деле, как вы говорите, всего лишь миллиард float — то это всего лишь 4 гигабайта, их нетрудно держать в памяти (уж в виртуальной на SSD — так точно). А это значит, что для нахождения distance correlation можно использовать любую нагугленную библиотеку, если только она не на Javascript и не на Питоне. Так что я вижу противоречие вашим прошлым словам.
Ну и называть размер матрицы не по её представлению в памяти, а по записи в текстовом виде — обман.
Кстати, по поводу вашей оптимизации "остается использовать map-reduce так, чтобы не хранить в памяти сразу всю матрицу расстояний размером миллиард на миллиард" — тут всё настолько очевидно, что я не понимаю зачем вы вообще это упоминаете.
А, ещё момент: где в описанном вами алгоритме применяется map-reduce?
А теперь вы как-то упускаете, что матрица размером миллиард на миллиард элементов :) мы же все попарные дистанции между всеми исходными точками (записями) рассматриваем. Так что полный размер матрицы в памяти это 4 миллиарда в квадрате, то есть 16 экзабайт. А теперь попробуйте «любой нагугленной библиотекой» посчитать что-то на матрице такого размера.
Ничего я не упускаю, эту матрицу просто не нужно хранить в памяти.
Подстановку формулы вместо переменной делают ещё в школе, если программист находит такую оптимизацию сложной — тут дело не в "академичности"...
Вы все еще не поняли. Попробуйте записать определение distance correlation так, чтобы можно было всю матрицу не хранить в памяти. Если вы с академическим образованием - вам это не удастся и вы будете пытаться как-то решить неразрешимую проблему обработки такой матрицы. Если вы практик и понимаете, что другого пути нет - то будете искать пути декомпозиции задачи, пока не найдете.
А что там сложного-то?
Берём формулу для dCov, и подставляем в неё формулы элементов матрицы. Всё, больше ничего не требуется.
Нет, конечно, так не работает :) В формуле для dCov используются ДВОЙНЫЕ ЦЕНТРИРОВАННЫЕ дистанции, а не элементы исходной матрицы! И каждая двойная центрированная дистанция вычисляется через ВСЕ элементы матрицы. Итого ваш вариант будет работать в миллиард раз медленнее, чем вы ожидаете - так что вы просто не доживете до момента, когда результат будет посчитан. Кстати, для вычисления корреляции обычно используется не одна, а две матрицы (и в формуле их две, хотя можно посчитать и с одной матрицей, но результат тривиален) - подумайте, нужен ли вам результат, полученный уже после завершения жизни нашей Вселенной :)
Это презумпция тупости оппонента или что? Разумеется, средние по строкам и столбцам придётся предварительно подсчитать.
Но считать-то их надо независимо от хранения матрицы миллиард на миллиард элементов. И, опять-таки, чтобы подсчитать заранее число которое встречается в формуле несколько раз не надо быть каким-то многомудрым практиком, эту оптимизацию школьников учат делать в некоторых школах...
Ах да, есть ещё альтернативный путь, просто раскрыть все скобки, разбить сумму на несколько и несколько раз вынести общий множитель за знак суммы. Вычислений будет больше, но лишь в константное число раз.
Ладно, давайте я вас прямо спрошу - вы сколько раз исходный терабайтный файл целиком читать будете? Для вычисления каждого элемента матрицы нужно прочитать две строки (по одному килобайту в нашем примере) из этого файла, для вычисления среднего по столбцу (строке) нужно прочитать весь файл. А как среднее по всей матрице считать будете? Сохранить в памяти или на диске матрицу дистанций невозможно, потому что это 16 экзабайт. А еще файлов-то два, для подсчета корреляции, и нужно кроме ковариации еще дважды вариации посчитать. Прикиньте время выполнения вашего способа…
Один раз. В 8 нод кластера, где у каждой ноды по 256 Gb RAM.
Да пожалуйста, мне не жалко. Итого, на всех нодах разом вы сможете прочитать два исходных файла данных, необходимых для вычислений. Прекрасно, но для вычисления каждой строки (столбца) вам нужны ВСЕ данные разом на одной ноде - или вы будете эти два терабайтных файла миллиард раз по сети гонять (то есть для каждой строки). Время передачи одного терабайта в гигабитной сети это часа три, умножаем на миллиард и получаем больше 100 000 лет для одного файла данных. Да вы просто сферический программист в вакууме :)
Да почему терабайтный-то? Мы ж не идиоты, мы его по сети не текстом передавать будем...
Передавать можно 1/5 терабайта - миллиард записей, в каждой записи 50 полей типа флоат (4 байта). Все равно безумно долго, так что конвертация в бинарный файл вас не спасет вообще никак.
Так, погодите, у вас только что совсем другие цифры были в исходных данных...
Мы начинали с того, что задан терабайтный csv файл, в котором миллиард строк (многомерных точек) и 50 полей в каждой строке (координаты точки в 50тимерном пространстве). Для вычисления корреляции дистанции (или даже Пирсона) нужно два таких файла обработать совместно, разумеется. Помнится, меня выше даже упрекали, что это мол совсем смешной объем данных:)
Похоже, мы друг друга не понимаем. В том определении, что я вижу, начиная с Википедии, речь идет о вычислении скаляра для пары векторов. О каких матрицах вы говорите?
Открываем википедию: https://en.m.wikipedia.org/wiki/Distance_correlation
И читаем определение: «First, compute the n by n distance matrices (aj, k) and (bj, k) containing all pairwise distances…»
У нас n равно одному миллиарду и каждая матрица дистанций получается размерностью миллиард на миллиард.
Ox же. Вот даже в голову не пришло предварительно вычислить эту матрицу, сохранить и потом использовать при больших векторах. На ходу же можно. Но для этого нужно понимать, что матрица, это лишь способ представления линейного оператора, хоть это тут и не используется (тут не матрица, а просто двумерные массив). Вектор прочитали, второй (который из "усредненных"), и само глобальное среднее посчитали и сохраниили, а потом член класса написали, который по j и к вычисляет нужный коэффициент матрицы.
Вдогонку, университетская специальнось "теория ядра и элементарных частиц", кандидатская по теор.астрофизике, Последние 22 года R&D M&S.
Возвращаемся к уже осуждавшемуся вопросу - вы миллиард раз исходные данные с диска целиком считывать будете (терабайт с CSV или 200 гигабайт в бинарном виде) только чтобы посчитать средние значения по столбцам? И потом снова их считывать, чтобы каждую строку (столбец) матрицы посчитать для дальнейших вычислений?
Вектор занимает не терабайт.
Один столбец (строка) матрицы дистанций занимает 4 миллиарда байт, то есть 4 гигабайта. А чтобы его посчитать, нужно прочитать с диска два исходных файла по 200 гигабайт каждый в бинарном виде, почти полтерабайта в сумме. И так повторить миллиард раз для анализа полной матрицы, чтобы просто получить средние значения :)
Стоимость 5.424 в час, программист всяко больше на программу потратит.
Да и полтерабайта не такой уж невероятный случай, я работал с базой данных mysql запущенной на машинке с 768 RAM, и там лимит был вроде под 2 терабайта памяти.
Вот такие сервера доступны для заказа на IBM, к примеру. В течении суток(Предел в датацентре Далласа — 4096Гб).
Чтение 200гб на более-менее современных NVME вообще ниочем. А еще в датацентре IBM есть Оптан. На 2 террабайта, до 4х штук на сервер. Latency меньше 300нс( у ддр-4, к примеру, 10-20).
Матрица не нужна.
Для вычисления используются миллиард миллиардов значений попарных дистанций для миллиарда исходных записей (точек). Да как угодно назовите, матрицей размером миллиард на миллиард или миллиардом векторов размером миллиард элементов каждый - вы эти данные ни в оперативку поместить не можете, ни на диск, ни даже перебрать эти элементы с подсчетом парных дистанций на лету (потому что только чтение исходных данных с диска миллиард раз подряд займет тысячи лет). Что делать-то будете, носитель академических знаний?:)
Еще раз, для доступа к коэффициентам матрицы A[i,j]=abs(R[i]-R[j], нужен только вектор R. Предварительно вычислять все коэффициенты и сохранять их не нужно. Да, будет несколько медленнее. Это, кажется, ленивыми вычислениями называется?
Нет, это называется отключением мемоизации.
Не соглашусь. См. https://ru.wikipedia.org/wiki/Мемоизация
Опять вы про теорию, про которую не имеете понятия. Ленивые вычисления требуют хранения в памяти всего графа обработки - и для данной задачи это невозможно. Вот у меня Apple Air аж с 24 GB RAM, так какой код запускать для вычислений? Или вы все так и будете фантазировать про межзвездные датацентры, бороздящие просторы галактики?
Ниже простенький код на питоне, который дает те же результаты, что и пакет dcor. Рекомендую также обратить внимание, что если таки использовать матрицу, то она может быть вычислена за время ~N*log(N): https://dcor.readthedocs.io/en/latest/theory.html. Код, очевидно, распараллеливается элементарно, но смысла не вижу, потому что dcor использует пакет numbа. Ну и также не вижу смысла проверять такие супердлинные последовательности. Или надо отдельные фрагменты смотреть, или сглаживать исходные последовательности, уменьшая количество точек до разумного предела.
import numpy as np
import scipy
import dcor
class CenteredMatrix:
def __init__(self, x: np.ndarray):
self._x = x
self._ai = np.zeros(x.shape[0])
self._akl = 0
for i in range(x.shape[0]):
for j in range(x.shape[0]):
aij = scipy.linalg.norm(self._x[i, :]-self._x[j, :])
self._ai[i] += aij
self._akl += aij
@property
def shape(self):
return self._x.shape[0], self._x.shape[0]
def __getitem__(self, ij: tuple[int, int]) -> float:
i, j = ij
return scipy.linalg.norm(self._x[i, :]-self._x[j, :])-2/self.shape[0]*self._ai[i]+1/self.shape[0]**2*self._akl
def my_double_covariance_wo_matrix(a: np.ndarray, b: np.ndarray) -> float:
aa = CenteredMatrix(a)
bb = CenteredMatrix(b)
dcr = 0
for i in range(a.shape[0]):
for j in range(a.shape[0]):
dcr += aa[i, j]*bb[i, j]
return dcr/aa.shape[0]**2
def main():
a = np.array([[1., 2., 3., 4.],
[5., 6., 7., 8.],
[9., 10., 11., 12.],
[13., 14., 15., 16.]])
b = np.array([[1.],
[0.],
[0.],
[1.]])
print(dcor.distance_covariance(a, b))
print(my_double_covariance_wo_matrix(a, b))
if __name__ == '__main__':
main()Отлично, вы посмотрели код библиотеки и понимаете минимальную реализацию. Правда, попутали ковариацию с корреляцией, но это уже мелочи. Так чем этот код поможет на больших данных? Библиотека dcor перестает работать уже на нескольких десятках тысяч элементов... кстати, почему авторы не позаботились об этой проблеме - или это не проблема? Это подсказка для самоучек.
Про сложность вычислений верно - N^2 это явно много на больших данных. Впрочем, для миллиарда записей не поможет. Значит, вопрос в том, можно ли посчитать блоками так, чтобы анализировать блоки раздельно и в то же время получить результат заданной точности. Это подсказка для академических специалистов.
Подсказок, как видим, много, и все ведут к точности оценки по выборке заданного размера. Рассмотрим для среднего значения и дисперсии. С одной стороны, выборка в миллиард значений позволяет в тысячу раз точнее оценить, чем выборка в 1000 значений - поскольку точность оценки обратно пропорциональна квадратному корню из числа значений. Но на практике это или не работает - среднее значение зависит от времени (наблюдаемый процесс не является стационарным) и тогда считать среднее значение и дисперсию по всему массиву данных бессмысленно и необходимо считать по блокам, или можно воспользоваться оценкой среднего зачения от среднего по блокам для стационарного процесса. То есть в любом случае, нам нужно среднее значение по блокам, а не по всему набору данных!
На практике еще и нормировка и выделение главных компонент нужны, иначе какой-нибудь unixtime в одном из полей сделает все вычисления просто бессмысленными.
Получается, на практике ваше образование помогло вам разве что код какого-то самоучки скопировать из готовой библиотеки, но вы его даже применить не умеете к реальным данным... Имхо, это достаточно показательно.
Правда, попутали ковариацию с корреляцией, но это уже мелочи.
Не попутал. И у меня ковариация, и в dcor. Лень было. А для демонстрации хватит.
Так чем этот код поможет на больших данных?
Тем, что инстанс моего класса CenteredMatrix матрицу не хранит. Только 2 вектора. А снаружи - двумерная центрированная матрица. См. код моей функции my_double_covariance_wo_matrix, которая выдает тот же результат, что и dcor.
Библиотека dcor перестает работать уже на нескольких десятках тысяч элементов...
Пакет dcor в данном случае был использован только для проверки, что я свой код без ошибок написал. Ну и как источник тестовых данных.
кстати, почему авторы не позаботились об этой проблеме - или это не проблема?
С моей точки зрения - не проблема. Я уже писал:
Ну и также не вижу смысла проверять такие супердлинные последовательности. Или надо отдельные фрагменты смотреть, или сглаживать исходные последовательности, уменьшая количество точек до разумного предела.
Теперь про нестационарность. Если у вас таковы оба сравнивамые вектора, то применять какие-либо статистические методы для нахождения зависимости между ними не нужно.
Получается, на практике ваше образование помогло вам разве что код какого-то самоучки скопировать из готовой библиотеки, но вы его даже применить не умеете к реальным данным... Имхо, это достаточно показательно.
Еще раз, это мой демонстрационный код. Нет никакой библиотеки, откуды я бы мог его взять. Я несколько раз пытался вам словами алгоритм описать, но вы отказывались понимать. До сих пор не поняли? Или давно поняли и начали тролля изображать?
P.S. Я конечно, согласен с тем, что "ценность программы прямо пропорциональна весу ее выдачи" (С) "Настоящие программисты не используют паскаль", но так то уже дурить голову заказчику совсем нехорошо.
если «общематематические» — то не подразумевают. а если знания «вычислительной математики и численных методов» — то подразумевают.
Нет такого подразделения. Есть "аналитические" методы, есть "численные/вычислительные".
Разница, если кратко и упрощённо, в том, что аналитический метод даёт на выходе формулу решения, куда подставив значения получите ответ в численном виде (ну и если что - потом по этой формуле можете еще много ответов насчитать для разных значений переменных и параметров), а численные методы сразу вычисляют ответ (но при изменении параметров - придётся всё перерешивать заново).
А все эти "инженерные математики", "математики для экономистов/юристов/социологов" и т.п. - это всего лишь попытки дать некоторую выжимку математических знаний студентам нематематических специальностей.
А все эти [математики]- это всего лишь попытки дать некоторую выжимку математических знаний студентам нематематических специальностей.именно так. Ибо далеко не всем нематикам нужна даже выжимка, не говоря о полном объеме.
численные методы сразу вычисляют ответони дают (советуют) хороший (по тому или иному критерию) способ численного вычисления этого ответа с учетом вида входных данных, и существующих ограничений.
они дают (советуют) хороший (по тому или иному критерию) способ численного вычисления этого ответа с учетом вида входных данных, и существующих ограничений.
Они дают ответ в численном виде без выведения формулы вычисления ответа. Формулу дают аналитические методы. Ну да, аналитические методы позволяют получить точный ответ, численные - лишь приближенный... Но точный ответ не всегда имеет преимущество на практике.
А уж выбор подхода (численного или аналитического), и способа в рамках выбранного подхода - это уже "личное дело решающего задачу".
прежде чем получить ответ в численном виде — нужно выбрать способ вычисления этого ответа.
Ваша формулировка включает также и вариант "получить решение в аналитическом виде, подставить в формулу параметры и переменные, и получить ответ в численном виде".
Я же говорю несколько о другом - не важно, какой численный метод вы выберете (их может быть и более одного для данной задачи), формулы для решения и "теоретически точного" ответа, в общем случае, у вас не будет.
А уж выбор конкретного метода решения - это уже "совсем другая история", и там вы уже правы.
Любить иногда "порадовать" соседей игрой на пианино - это одно, а вот зарабатывать себе той игрой на хлеб - это совсем другое.
Вы не рассматриваете важную оговорку из статьи. Если программист-самоучка работает с кодом, в котором много математики, то весьма вероятно, кроме программирования, подучит и математику. И может быть, будет понимать ее не хуже человека, вытяныувшего на тройку в универе просто за счет настойчивых походов к преподавателю на пересдачи. С другой стороны, человек с такой мотивацией может и от университета получить максимум.
А какая разница между изучать закорючки в формулах в интернете ради зачета и забыть и работая в предметной области дагадаетесь?
Во втором случае остаточных знаний — больше.
зы. вы хотели бы, чтоб студент-медик изучал анатомию не «в институте ради зачета», а непосредственно на вас в процессе операции?
Некорректный аргумент: ложная дилемма.
Некомпетентность.
Теоретически полученные знания закрепляются среди студентов практическими работами. Для строителе, геологов и археологов это выезды на местность. Для медиков — ВНЕЗАПНО — присутствие на реальных обследованиях и операциях, практика в медучереждениях. Для обывателя столкнуться с этим можно на регулярных систематических манипуляциях: у стоматолога или гинеколога. Никогда не слышали, как стоматолог кому-то рассказывает, куда смотреть на такой корень толстый и завитной?
Это даже не касаясь того, что в процессе работы всегда приходится осваивать новые знания, в любой професии.
Так что, если студент-медик изучал анатоми непосредственно на вас в процессе операции, то у него будет в ∞ раз больше практического опыта, чем у того, кто сдал на отъябись ради зачета. И когда он станет врачом, для каджита такой врач будет гораздо предпочтительнее.
на отъябись ради зачета.
ну и у вас как раз ложная дилемма: в вашей картине мира в вузах учатся исключительно прохиндеи, стремящиеся ничего не учить и проехать «на кривой кобыле», а практикой занимаются исключительно умные и добросовестные… а это далеко не так.
=) Каджит студентов и образовательный процесс наблюдает не первый год, не в одном ВУЗе. По студентам выборка даже сойдет за репрезентативную.
Ваша попытка сказать "сам такой" провалилась, превратившись в подмену: каджит нигде не утверждал, один подвид студентов изучает только теорию, а другой только практику.
Пишу сам для себя программки уже сколько лет. Были и игры, и компиляторы, и парсеры текста. Но единственный раз когда мне понадобился матан, когда я писал трекер для микроконтроллера и удивился что порядок умножения имеет значение. Спустя года так 3 только
Статья специально перевирает (вернее не досказывает) факты.
Про ту же Гамильтон: степень бакалавра по математике и философии (непрофилирующая дисциплина) в колледже Эрлхэм, аспирантура в области абстрактной математики в университете Брандейс, и как итог - профессор математического факультета.
Серьезно, она не знала как перемножать матрицы? :)
Во многом это утверждение чисто спорное, это как пытаться осваивать дискретную математику именно как академическую науку в надежде, что после этого вы станете выдающимся программистом. В большинстве случаев, увы, это работает как раз наоборот, освоение той же линейной алгебры займёт ну недельку-полторы при работе над реальным проектом, а изучение - обычно семестр, при этом ещё и кое-как, ибо все прекрасно понимают реальную пригодность данных знаний в своей карьере (около нулевую). Да и уж тем более практика показывает, что из математиков программисты обычно очень так себе :/
Я не очень понимаю, каким образом отсутствие академического образование исключает возможность самообразования? И если такому человеку надо освоить изучение матриц, это просто означает необходимость прочитать полторы страницы учебника и потратить максимум два дня неспешного изучения. Разобраться же на уровне понятий и терминологии - это вообще задача на 15 минут.
Золушка, принцесса на горошине, спящая принцесса ... А вот Возняк и Гамильтон неудачные примеры, с моей точки зрения, уж лучше пресловутый Билл Гейтс
ОМГ, сколько лет этому холивару!
В прошлых сериях договорились, что хорошее ВО - нужно, плохое - нет.
В плане математики - да, много книг и хороших, и математику уровня 1-2 курсов технического можно изучить самостоятельно при наличии склонностей, дальше сложно - и книг понятных меньше и математика развесистей становится. И обычно те у кого есть склонности уже оказались в ВУЗе.
Жду книжку на Литресе, а то я не в России)
Какая то популистская статья.
Во первых, какие то яркие примеры программистов-самоучек вполне может быть ошибкой выжившего, ведь статистики того, сколько самоучек бросило обучение нет, а таких, я предполагаю, на порядки больше тех, кто имеет академ образование.
Во вторых, нам показывают график и уверяют, что 69% разработчиков - самоучки. Но на том же графике если сложить всех, кто имеет какую то степень в CS или хотя бы колледж, получим чуть ли не 80%. Вероятно, многие, у кого есть степень, точно также считают себя самоучками.
Мы изучаем алгоритмы и структуры данных, и даже умеем обойти двоичное дерево.
Так себе достижение, если честно. Обход деревьев - это рутина, а не какой то вызов в профессии.
Программисты-самоучки – это сообщество, в котором все до одного имеют дело с компьютерами, коммуникацией и данными, а не обязательно хотят работать программистами на полную ставку.
Как и любые другие программисты.
у вас, как у самоучки, есть своя фишка. Вы читаете эту книгу не потому, что вам ее задали, а из желания учиться, и такое желание – наибольшее из всех возможных преимуществ
Как будто у программистов с дипломом этого желания нет. Какой популизм.
Не в обиду самоучкам, но из статьи выходит ощущение, что вот сейчас "докурю и изучу вашу программирование". А на деле получается, что самоучка сначала тратит массу времени, чтобы дорасти до формошлепа, а потом еще больше, чтобы хотя бы какой то уровень подтянуть и не застрять на уровне веб-макаки.
Для работодателя вообще не принципиально, самоучка ты или нет, потому у самоучек нет преимуществ для работодателя. Единственный плюс для самоучек - это то, что для начала работы и получения зарплаты им не надо проводить годы в универе, изучать темы, многие из которых тебе никогда не понадобятся, можно вместо этого потратить 6-12 месяцев на плотную нацеленную учебу и после идти клепать формы и добирать остальные знания на ходу. Наличие же качественного (ключевое слово - качественного) образования позаоляет залетать в компании с мировым именем сразу после универа, минуя годы формашлепства и гонку среди таких же самоучек.
Означает ли, что самоучкой быть плохо? Конечно нет! Но надо понимать, что научиться программировать и строить системы за месяц не получится. Придется долго и усердно учиться уже на работе, восполнять пробелы в основах CS, которых у выпускников с образованием уже давно нет.
Тема больше к вопросу современного образования. Если раньше школьник/студент выучил 52 формулы по физике - он молодец. Сейчас технологии развиваются так, что в ходу проектная деятельность - на стыке нескольких наук, работа на конечный результат без готового решения и, как правило - никаких правил.
Пример. Вчера на Хабре читал статью об УНЧ на стабилизаторе напряжения LM. Эту штуку сделал либо гений, который увидел скрытые возможности либо не знающий, как и куда применить завалявшуюся микруху.
Так-же у программиста. Задачи, которые сейчас ставятся - не имеют готового решения. И человеку, который пытается разбираться в этой проблеме с нуля часто получается найти нестандартный путь решения проблемы.
Поэтому самостоятельное обучение - да не важно кого - программиста, токаря, электрика, водопроводчика - это просто необходимость и атрибут нашего времени.
И, как я дИтям своим объясняю две вещи.
Ардуино просто создано для статистики. Когда мильЁн человек попробуют сделать часы, сто тыЩЩ добавит к часам погодную станцию, десять тысяч чего-то извлекут нового, тысяча пойдут учиться дальше, сотня придет работать в Микрософт или Гугель, 10 человек разработают смартфон который ты держишь в руках, один станет Гейтсом или Возняком.
Люди делятся на тех кто играет в игры их большинство и на тех, кто пишет игры - их меньшинство.
Если раньше школьник/студент выучил 52 формулы по физике — он молодец.не, раньше все-таки пытались сделать, чтоб школьник понял.
Хотя, безусловно, не везде — и значительная часть просто «зубрила формулы».
Есть два нюанса:
1. рост «количества формул». Если в какие-нибудь там 40-е годы «учебная» физика в лучшем случае ограничивалась электротехникой и «моделью Бора», то сейчас науки разрослись…
2. появился «прямой доступ» к информации. Раньше книжки-то толком не купить было, только работать в библиотеках, или «лекции». а сейчас — начиная от лекций _хороших_ лекторов, и _хороших_ практиков, и заканчивая литературой — не отрывая задницы, с возможностью многократного повторения, в любое время дня и ночи.
И человеку, который пытается разбираться в этой проблеме с нуля часто получается найти нестандартный путь решения проблемы.— ага, и почти всегда — через *опу, уже изученый (и порой даже отвергнутый) другими — но «нестандартный и оригинальный»
Если раньше школьник/студент выучил 52 формулы по физике - он молодец.
Выделить из хаоса физики эти 52 формулы — сложно. Посмотрите, сколько занимают "Начала" Ньютона, и сколько — школьный учебник динамики.
Сейчас технологии развиваются так, что в ходу проектная деятельность -
на стыке нескольких наук, работа на конечный результат без готового
решения и, как правило - никаких правил.
Только, извините, где результаты? Пока видно какие-то попытки довести до ума технологии, идущие из советских лет.
Выделить из хаоса физики эти 52 формулы — сложно. Посмотрите, сколько занимают "Начала" Ньютона, и сколько — школьный учебник динамики.
Почитайте Феймановские лекции по физике - там школьный учебник умещается в десяток формул. Рекомендую. Читается как сказка на ночь.
Суть в том, что за крайние 30 лет образование превратилось из обучения "знать и объяснять" в обучение "найти и проанализировать". Поэтому, те, кто кричатЬ, что даешь Советскую систему - не правы.
Я учился при союзе. Я помню что было обидно, когда Физтех давал задачи и там были формулы-понятия-теоремы из другого раздела, а не того, который проходили. Уже в институте - и ТРИЗ и преподу нормальные. Спасибо, чему-то научили....
Для программера гораздо важней, чем для любого другого технаря эта цепочка - нашел информацию-обработал-применил. Потому как у него в отличии от другого технаря срок конечной реализации продукта короче намного.
Поэтому я считаю, что самоучки - это люди, которые сами на сознательном или бессознательном уровне научились искать информацию, обрабатывать ее и самое главное - применять. И такая ситуация - в любой области.
Я помню что было обидно, когда Физтех давал задачи и там были формулы-понятия-теоремы из другого раздела, а не того, который проходили.
Обидно? Ну, если "проходили", то возможно.
Почитайте Феймановские лекции по физике - там школьный учебник умещается в десяток формул. Рекомендую. Читается как сказка на ночь.
Я читал его в школе. К сожалению, реально хорошо физике мало где учат. То есть, умению строить и работать с моделями, держать в голове размерности и погрешности. Да, советскую систему надо менять, но не так, как получается сейчас.
Поэтому я считаю, что самоучки - это люди, которые сами на сознательном
или бессознательном уровне научились искать информацию, обрабатывать ее и самое главное - применять. И такая ситуация - в любой области.
Это один из навыков, которые должна давать школа. Но он не исчерпывающий. Школа должна давать очень много чего, что человек сам не будет изучать. Вот нет у него тяги к биологии, а пособие по собственному телу он должен получить.
Да, советскую систему надо менять, но не так, как получается сейчас.
Вопрос не в Советской системе образования- это просто расхожее словосочетание. Вопрос в том, что информационные процессы повернулись так, что систему образования надо менять
ФЛФ — это продукт примерно той же системы образования. То есть, нужно делать "советскую систему образования" ещё более "советской". :-)
Если вы посмотрите "сталинские учебники", то увидите, что они написаны в той же простой, очень эффективной манере, что и ФЛФ. Или возьмёте классический учебник Киселёва по алгебре. Тоже просто, относительно строго, но не слишком строго.
из обучения "знать и объяснять" в обучение "найти и проанализировать"
Невозможно "найти и проанализировать", не имея базы. Вы не сможете читать серьёзные книги по алгебре или топологии, не привыкнув к "средне-строгому" изложению матана в ВУЗе, а тот требует нестрогого изложения в школе.
Посмотрите, как разматывают "убеждённого практика" в соседней ветке — если нет базы по графам (буквально 1 семестр), нет базы по оптимизации, то гугли-не-гугли. Просто сознанию не за что зацепиться, чтобы отфильтровать те гигабайты информации.
Согласен с вами. Я думаю, в конечном счёте программирование на каком-то уровне будет необходимо для человека любой профессии как инструмент и школьники уже будут понимать(хотя бы стремиться) как автоматизировать какие-то простые задачи. Я, например, перешёл в программирование из общественного питания. Будучи шефом, нужно было прогнозировать примерное количество блюд проходящих в день. Это занимало много времени и было рутинной задачей. Я как раз увлекся программированием и понемногу сделал инструмент для прогнозирования. В целом, он показывал неплохие результаты, хотя в любом случае приходилось вносить корректировки. Но количество времени удалось значительно сократить. И, безусловно, я звёзд с неба не хватаю, но определенные задачи решать могу и стараюсь этот круг расширять.
Для русскоязычной аудитории это заявление долно производить разрыв мозга, мне кажется:
Не только среди легенд Кремниевой Долины попадаются люди, сделавшие блестящую карьеру программиста, не имея степени по Computer Science.
У русскоязычных нет такого научного напрвления: Computer Science! Видите его даже на русский перевести постеснялись.
Таким образом все русскоязычные, по определению, являются самоучками в области Computer Science, той есть в той области которой для них не существует. Вот такой парадокс, однако!
Вот мне тут один специалист по матлабу отвечал:
(то) как считать систему ДУ (разве не математика?)
Математика, но вычисления это отдельная узкая ее область, тогда как сама математика гораздо шире.
Вроде как, не может быть ничего научного в вычислениях, вот и все!
О, как раз думаю сделать клуб для совместного самообучения.
Мир вообще-то развивается, алллоу. Вуз нужен только для начальных знаний, а потом всё равно придется гуглить, ездить на конференции, постоянно слушать чо там как чего нового, изучать и пополнять знания. Через нескольких лет практики самоучка от человека с вуза ничем не отличается вообще, при условии что идёт постоянное обучение, а не легаси застой.
Разве что самоучка лучше умеет искать информацию и имеет нестандартный подход.
Разве что самоучка лучше умеет искать информацию
Известная же фраза : "Чтобы правильно задать вопрос, нужно знать бOльшую часть ответа" (C) Роберт Шекли.
и имеет нестандартный подход.
И будет говорить о "триангуляции замкнутого графа". Чуть выше.
Известная же фраза : "Чтобы правильно задать вопрос, нужно знать бOльшую часть ответа" (C) Роберт Шекли.
Входит в умение поиска информации. Правильно поставить вопрос, чтобы от общих запросов "найти кратчайший путь" перейти к графу и "список алгоритмов на графе". Правда понятия не имею как от этого перейти к триангуляции, но видимо как-то можно.
И будет говорить о "триангуляции замкнутого графа". Чуть выше.
Так он прав. Через триангуляцию Делоне задача коммивояжёра успешно решается. Вот видишь, ты даже о таком не думал и посчитал это смешным, а он нашел триангуляцию уже.
Входит в умение поиска информации.
Я имел ввиду то, что (хорошее) высшее образование расширяет кругозор, а у самоучки он изначально уже. Естественно, в среднем. Так кому легче сформулировать первый вопрос? И это мы еще не обсуждали пусть начальный уровень знания английского (технического) языка.
Так он прав. Через триангуляцию Делоне задача коммивояжёра успешно решается. Вот видишь, ты даже о таком не думал и посчитал это смешным, а он нашел триангуляцию уже.
Обсуждаемый предполагаемый вопрос был по контексту не про транспорную задачу, а, наоборот, про некую абстрактную альтернативную задачу. И он становится разумным при замене слова "граф" на "контур". Триангуляция (не генерация треугольной вычислительной сетки!) несамопересекающегося полигона - действительно стандартная математическая задача. А триангуляция Делоне - она для выпуклой оболочки множества точек на плоскости. Но если вы говорите, что ее можно использовать для решения задачи из другого раздела математики, поделитесь, пожалуйста, ссылочкой?
Я имел ввиду то, что (хорошее) высшее образование расширяет кругозор, а у самоучки он изначально уже.
Как раз нет, если искать информацию самостоятельно куча посторонних статей будет, а значит и кругозор будет куда выше.
Так кому легче сформулировать первый вопрос?
Естественно у кого кругозор шире, например тот кто подумал о методах триангуляци для нахождения кратчайшего пути.
Обсуждаемый предполагаемый вопрос был по контексту не про транспорную задачу, а, наоборот, про некую абстрактную альтернативную задачу.
Может это в институтах не проходят, но любые задачи с подобными временными рамками и поиском кратчайшего пути на множестве сводимы к TSP. Не только к TSP, кстати, но это уже другой разговор.
он становится разумным при замене слова "граф" на "контур". Триангуляция (не генерация треугольной вычислительной сетки!) несамопересекающегося полигона - действительно стандартная математическая задача. А триангуляция Делоне - она для выпуклой оболочки множества точек на плоскости. Но если вы говорите, что ее можно использовать для решения задачи из другого раздела математики, поделитесь, пожалуйста,
Чего? Какой ещё другой раздел математики? И алгоритмы на графе, и триангуляция и даже TSP это вычислительная топология.
ссылочкой?
Да вы что - это же NP-полная задача и к ней вообще любую другую NP-полную задачу свести можно. Никакого профита это не дает, поскольку сложность решения остается эквивалентной.
"NP-полная задача — в теории алгоритмов задача с ответом «да» или «нет» из класса NP, к которой можно свести любую другую задачу из этого класса за полиномиальное время" https://ru.wikipedia.org/wiki/NP-полная_задача
Именно об этом речь и шла, но это другое и это даёт существенный профит.
NPС задачи математически сводимы, но для некоторых задач не требуется высокая точность и можно применять вероятностные алгоритмы, либо снижать точность отдельных функций. Как раз задача по вычислению времени доставки грузов из складов в магазины можно свести к вероятностным алгоритмам которые разработали для TSP, идеально просто ложится.
Так TSP это и есть задача доставки (вы не можете доставить, не посетив пункты назначения). Зачем сводить задачу доставки к задаче доставки, чтобы воспользоваться методом решения задачи доставки?
Чего это за бред? TSP задача это не задача доставки, это задача поиска кратчайшего пути. Задача доставки, в том виде в котором она сформулирована выше, включает время ожидания на каждом пункте, ожидания на складе, время загрузки и поиск кратчайшего пути. И речь о том что как раз подобная задача доставки сводима к TSP.
Это называется задача поиска кратчайшего пути с ограничениями, и она не «сводима», а именно является задачей поиска кратчайшего пути. Скажем, ограничение - при посещении заданного узла нужно также посетить виртуальный узел (разгрузка) с нулевым расстоянием и ненулевым временем, этот виртуальный узел добавляется к дорожному графу и решается задача построения маршрута. Ровно так же, к примеру, при роутинге добавляются условия на допустимые повороты и так далее. Модифицируется только дорожный граф и на нем решается все та же типовая задача маршрутизации.
Как раз нет, если искать информацию самостоятельно куча посторонних статей будет, а значит и кругозор будет куда выше.
А КПД поиска ниже.
это вычислительная топология.
Я исходил из предположения, что речь о задаче: https://ru.wikibrief.org/wiki/Polygon_triangulation, которая из раздела вычислительная геометрия, а очевидно не топология.
За ссылку спасибо.
А КПД поиска ниже.
Конечно, КПД самообразования и самостоятельного, несистематического обучения всегда будет ниже. Но кругозора больше, просто потому что всякого говнища придётся перебрать куда больше. Является ли это плюсом? Возможно. Иногда. А иногда систематическое образование является плюсом.
Но, как уже и говорил, в процессе профессиональной деятельности все различия нивелируются. После инста точно так же придется гуглить, изучать, читать проф. литературу, проходить какие-то сертификации и получать допуски к работе. Образование не заканчивается после инста, все становятся самоучками в конечном итоге.
Я исходил из предположения, что речь о задаче:
А я думал что о задаче с магазинами. Но триангуляция работает на любом множестве так что разницы особой нет. Есть множество - для него есть триангуляция.
Polygon_triangulation
Тоже можно решить через триангуляцию Делоне, кстати. И более того - существует ограниченная триангуляция Делоне через которую обычно всё это решают, потому что триангуляция это довольно простой и понятный метод.
https://en.wikipedia.org/wiki/Constrained_Delaunay_triangulation
В любом случае "триангуляция графа" не звучит как что-то неправильное. Это. Нормально. Стандартный метод создания рёбер.
которая из раздела вычислительная геометрия, а очевидно не топология.
Ну, кхм, вычислительная геометрия входит в топологию. Топология это вообще всё где есть какое-то множество, ибо любое множество можно представить как топологическое пространство.
После инста точно так же придется гуглить, изучать, читать проф. литературу, проходить какие-то сертификации и получать допуски к работе. Образование не заканчивается после инста, все становятся самоучками в конечном итоге.
Тут как хоть с тем же настольным теннисом. Если тебе изначально правильную технику не поставили, то фиг ты на профессиональный уровень выйдешь. А в университете тебя именно думать и учиться и учили в конечном итоге. Хотя ВУЗы, да, разные бывают. И всякую фигню приходилось сдавать, типа истории кпсс и пр.И потратить 5-6 лет, чтобы потом, как тут кто-то написал, JSON'ы по сети гонять за хорошую зарплату? А с другой стороны, после ВУЗ'а окно выбора будущего шире. Например, заниматься scientific programming'ом можно и после даже 60 лет. Угу :(
Тоже можно решить через триангуляцию Делоне,
Контур может быть не выпуклым.
Тут как хоть с тем же настольным теннисом. Если тебе изначально правильную технику не поставили, то фиг ты на профессиональный уровень выйдешь.
Конкретно программирование это творческая инженерная деятельность, постоянное созидание чего-то нового, постоянная научная и исследовательская деятельность, применение алгоритмов к совершенно новым данным, использование новых подходов к проектированию, а не механически заученные движения. Не получится к любым задачам применять известные или заученные решения и надеяться что всё будет хорошо. В любом случае приходится исследовать, заканчивал кто-то вуз или не заканчивал.
И в этом случае, когда программист постепенно перерастает в инженера-исследователя, не имеет никакого значения кто там какую технику ставил, это может пригодится, а может и не пригодится, никаких гарантий нет вообще. Кто сколько знаний вобрал в себя, кому повезло наткнуться на решение - тот и молодец.
И всякую фигню приходилось сдавать, типа истории кпсс и пр.
Кстати это тоже может пригодится, вдруг кто-то после этого найдёт приемлемое решение задачи византийских генералов, для обеспечение общественного или партийного консенсуса. Кто знает, какие знания нужны для открытия нового.
И потратить 5-6 лет, чтобы потом, как тут кто-то написал, JSON'ы по сети гонять за хорошую зарплату?
Всё в порядке, существует опенсорс и всегда можно свои проекты делать на работе. Главное чтобы никто не узнал.
Контур может быть не выпуклым.
Да, но это решается ограничениями и всё равно применяется триангуляция Делоне, просто потому что она очень эффективна. Очень много алгоритмов существует на основе Делоне с различными дополнениями для невыпуклых множеств, https://doi.org/10.1016/j.inffus.2022.07.023 вот этот например, одно из довольно стандартных решений с случайными проекциями.
Это всё к тому что триангуляция всё еще хороша и логична. Даже для невыпуклых множеств.
постоянная научная и исследовательская деятельность, применение алгоритмов к совершенно новым данным, использование новых подходов к проектированию, а не механически заученные движения
В теории - может быть, но на практике подавляющее большинство из нас шлёпает однообразные CRUD-формочки с нехитрой бизнес-логикой, и скорее всего, проработает в таком режиме примерно всю свою жизнь.
И всякую фигню приходилось сдавать, типа истории кпсс и пр.
Кстати это тоже может пригодится,
как может пригодиться история КПСС — я даже представить не могу.
Хотя пользу я извлек даже из нее — научился конспектировать «первоисточники», но тем не менее. Причем абициозность некоторых преподов этого предмета выходила за всякие границы…
https://doi.org/10.1016/j.inffus.2022.07.023 вот этот например, одно из довольно стандартных решений с случайными проекциями.Это всё к тому что триангуляция всё еще хороша и логична. Даже для невыпуклых множеств.
С корпоративного ноубука таки удалось открыть. В статье контур строится по точкам автоматически, а не задается изначально. Немножко не та задача. Впрочем, ладно, мне если разбиение на треугольники и требуется, то для какого-нибудь FEM-солвера. А триангуляция Делоне хорошего качества не обеспечивает.
Большая цена у переключение между контекстами. Сейчас с одним из учеников именно по этой книге идём(как часть программы обучения программированию). Он молод и пока не ценит того, что имеет в свои годы.
В нашем государстве тебе даже бронь не дадут без высшего образования, будь ты хоть супер-пупер программистом, и работай на супер-пупер важном направлении в супер-пупер it- ном предприятии.
Я бы сказал, что программист в принципе не может не быть самоучкой: хотя многие говорят, что главный скилл программиста - английский язык, лично я считаю, что главный скилл - как раз способность к самообучению, ведь при практически любом бэкграунде просидеть всю жизнь на одном-единственном стеке одной конкретной версии никак не получится, а значит придется постоянно развиваться. Что касается того, нужно ли высшее образование программисту, то мое личное мнение: высшее образование в принципе является обязательным лишь в тех областях, где невозможно получить доступ к необходимой практике в домашних условиях или критически высока цена ошибки (яркий пример - медицина), для программирования же в большинстве случаев достаточно лишь ПК/ноутбука. Сторонники вышки частенько вспоминают математику, но тут я, опять же, не улавливаю связи: математику также можно освоить самостоятельно в необходимом объеме.
>Маргарет Гамильтон и код для NASA, который она написала от руки
небольшое дополнение - точное название должности которую Маргарет занимала - Director of the Software Engineering Division of MIT's Instrumentation Laboratory, это примерно уровень начальника отдела, у нее конечно была сильная команда, когда фотография была опубликована в 1969, подпись была такая: "Here, Margaret is shown standing beside listings of the software developed by her and the team she was in charge of, the LM [lunar module] and CM [command module] on-board flight software team."
ps
заметим что она училась программированию участвуя в разработке sage, задолго до apollo, там было достаточно у кого можно поучиться, т.е. таки не вполне самоучка
Так и вы тоже можете начать писать код для ядра линукс и учиться у Торвальдса и прочих. Какое это отношение имеет к академическому образованию? Это и есть самоучка, потому что если вы не учитесь - то и останетесь просто недоучкой :)
> писать код для ядра линукс и учиться у Торвальдса и прочих
там ситуация была интересней, примерно как если Торвальдс и десяток других такого уровня работали с ней под одной крышей над одним проектом, в то время программисты работающие над sage были впереди академической науки (imho включая Dijkstra), семинары по обучению там тоже были, главное состав очень сильный был, хотя технология создавалась с нуля и под стрессом, вообще над sw несколько сотен программистов работали, включая Margaret, это не слишком широко известно из-за специфики работы, в смысле обычного образования из колледжа она была математик
ps
код ядра linux модифицировать тоже приходилось, как и в аспирантуре учиться именно по специальности, правда супер давно :)
Исходя из опыта проведенных собеседований сделал для себя вывод о том, что профильное высшее образование играет важную роль в формировании специалиста. Выпускник курсов или самоучка чаще всего знает, как выполнить ту или иную задачу, потому что выучил основные функции своего языка и фреймворка, но не знает, почему она решается именно так, что происходит внутри этой функции, какие могут быть подводные камни и прочее. Еще большей проблемой становятся задачи, которые на курсах или в книжках не объясняли. Выпускники профильных направлений в свою очередь могут не знать в текущий момент нужного решения, но легко могут найти решение, потому что знают основы, базу, их этому учили на протяжении 4-6 лет. Все это конечно не исключает исключений с обеих сторон.
Впрочем, это все субъективный опыт, возможно это одно большое совпадение
Сам из самоучек. На последней работе прошел собеседование и сделал тестовое задание. Причем сразу говорил, что у меня нет профессиональной "вышки". Так вот с удовольствием работаю уже 5й год. Со своими навыками мог бы получать и больше, но мне интересно то, чем сейчас занимаюсь, имя оплату в среднем по "сектору".
Приобретение знания самостоятельно - один скил (Самоучка). Умение решать несвойственные и неинтересные задачи - другой (Вуз с его системой дисциплин). А дальше вопрос, насколько вы углубляетесь в свою стезю и сколько вам приходится заниматся тем, что не интересно. И еще. Вузовское образование принудительно расширяет кругозор, закладывая основы. Самоучка выбирает и исследует то что интересно. И у того и у другого есть пробелы в областях компетенций, в которые они не полезут за поиском решения, так как даже не подозревают о такой возможности. Хорошо если есть тот кто может охватить необъятное и указать конкурирующие варианты решения. Резюме. Как бы вы не учились отдуваться руководителю проекта :)
Программировать учился сам. Тогда гугла не было потому как был 1994 год, тогда вообще много чего не было. Учился по инструкциям к компьютеру "Агат 2" и на нем же. Из своих наблюдений могу сказать, что "самоучки" (не все) , особенно поначалу, менее дисциплинированны относительно документирования, рефакторинга и проектирования программ. При этом они более креативны и мотивированы внутренним желанием постоянного роста. "Академики" (не все) хорошо мыслят абстрактно, не плохо работают с "указателями в си" :) , но и их приходится вечно толкать, как "жигули" после 5 лет на штрафстоянке.
P.S. Важно не то - как человек научился ремеслу, а то - какой из него ремесленник получился .
Я самоучка и мой опыт скорее указывает, что спрос больше будет расти на образованных специалистов, потому что ИИ развивается, а он в основе своей состоит из мат. алгоритмов, которые не программисты пишут, а математики. Программисты кто библиотеки пишет, те могут быть самоучками, а для того кто ими пользуется с каждым годом порог вхождения в специальность будет только понижаться. Почему раньше самоучки получали признание? Потому что они создавали что-то по настоящему новое, основу системы которой мы сегодня можем пользоваться. Сейчас же основной базис в IT определён, направление развития определено, а чтобы выполнять эти задачи больше подходит специалитет. Я думаю, что такие технологии просто не возможно было бы создать без таких вот самоучек, это специфические люди, которые обладают обширными познаниями в различных областях, умеет в короткие сроки усваивать большое количество информации и адаптировать её для поставленных задач, и что по истине уникально, эти задачи они сами себе могут придумать. Сейчас скорее будет более выражена тенденция на рынке программистов такая, что делиться рынок будет на программистов которые могут редактировать и улучшать существующие системы и на программистов более пользовательского профиля.
Математики столетиями отдельные системы функций создавали и всю жизнь их свойства изучали (Фурье анализ - система простейших тригонометрических функций разного масштаба), а потом биржевой аналитик Мандельброт вдруг показал, что можно создать разномасштабную систему вообще из всего и она будет обладать определенными свойствами (фрактальность). Или в вузах изучают интегральное и дифференциальное исчисления, но вопросом про интегродифференциальное исчисление можно поставить в тупик, навскидку, 99.99% людей с высшим образованием - получается, люди просто выучили, что им велели, и никаких попыток задуматься не было вовсе. И так далее - кажется, что существующая система образования не дает людям преимущество в придумывали чего-то нового.
Небольшой факт чекинг
Маргарет Гамильтон - изучала математику в Мичиганcком университете и В 1958 году она получает степень бакалавра по математике (стоит ли говорить, что в то время разработка была производной математики)
Кевин Систром - окончил частную школу Миддлсекса в Конкорде, штат Массачусетс, где углублённо изучал компьютерное программирование, а в 2006 — Стэнфордский университет, получив степень магистра в менеджменте
Джек Дорси - посещал Миссурийский университет науки и технологий, прежде чем впоследствии перейти в Нью-Йоркский университет, где его впервые посетила идея создания «Твиттера»
Стив Возняк - Wozniak eventually returned to Berkeley to finish his coursework, earning his degree in 1986. After graduating, he founded CL9, which created the first universal remote control, and later, Wheels of Zeus, which made wireless GPS technology. He also worked as a fifth-grade teacher, taught computer literacy to middle and high schools students, created two music festivals and was actively engaged in numerous business and philanthropic ventures.
Дэвид Карп - больше похож на предпринимателя, чем на разработчика. David Karp (born July 6, 1986)[1] is an American webmaster, entrepreneur, and blogger, best known as the founder and former CEO of the short-form blogging platform Tumblr.
Корректность рушится в самом начале статьи почти в первом же абзаце. Выводы делайте сами)
> Маргарет Гамильтон - изучала математику в Мичиганcком университете и В 1958 году она получает степень бакалавра по математике
только ради точности, BA Earlham College, Richmond, Ind. (math major), хотя действительно первоначально поступила в University of Michigan (1955), но была там только короткое время, кстати термин "software engineering" по слухам является чуть ли не ее изобретением, но это уже позже, когда участвовала в sage
см.
Так... А если я самоучка, который намеренно получил высшее? Что-то как-то тезисы вялые в статье. Я твердо убежден, что человек без математики и сломанной психики (абстрактного мышления), полученных вместе с бессонными носами и разной степени болью (зависит от вашего бэкграунда с пелёнок), это не программист, а его подобие. В детстве мне запомнилась фраза "есть кодеры, а есть программисты". Первое сейчас можно заменить на "разработчики", а последнее на "инженеры". Так вот "engineer" выходят из науки и университетов. И именно такие специалисты сегодня ценятся в первую очередь, и именно в эту сторону нужно двигаться условному "самоучке" коль скоро он любит выбранный им путь. А не говорить ему "чел, да ты итак норм, не пропадешь, на энтузиазме и стремлении к учебе вывезешь". В статье, где развеивают мифы, пишут очередной миф вида "у самоучек есть стремление к знаниям и это их преимущество". Так вот помимо стремления, нужны ещё действия, и не все, кто пошел в универ/вышку/науку сделали это не из точно такого же (но более зрелого) стремления к знаниям.
Я не очень понимаю вашего спора.
Учился в КАИ и КХТИ. В КАИ вышку профессор с мех мата КГУ. В КХТИ простой матан. Сейчас специальность звучит "Прикладная информатика в экономике". В основном приходится заниматься именно бизнес задачами, которые на графы и матрицы не опираются.
Да, нужны фундоментальные знания в бухе. Надо знание матстата, и то не всегда. Бух говорят что они хотят, а ты должен это воспроизвести. И если ошибаешься, это твой косяк...
У попотеть в матрицы считаю просто блажью показать, что я круче...
Пришло время программистов-самоучек