Pull to refresh

Comments 275

Гораздо важнее уметь разобраться в предметной области в кратчайшие сроки и без посторонней помощи. Как бы полезна информация ни была, всё в голове не унесёшь. Неиспользуемое имеет свойство забываться.

Есть совсем-совсем базовые вещи, которые нужны очень часто и везде. Утрированный пример — сложение чисел. Да, можно разобраться в предметной области по ходу. Но хорошо понимать, как складываются числа — как без этого?


Более жизненный пример — исчисление предикатов (and, or — это вот оно). Вряд ли есть программист, который не сталкивается с ним каждый день (даже если не знает, как называется). Но людей, которые его толком не знают, я встречал. Выглядит очень странно, почти как программист, не умеющий складывать.


Матрицы и реляционная алгебра нужны чуть реже, но все же плохо было бы их не знать.

Я админ(или модный devops если угодно) и матрицы с более сложной математикой даже мне нужны часто(каждый второй-третий проект в котором надо написать какой нибудь код, часто автоматизировать что-то). Но в принципе если в школе была сильная математика то 11 школьных классов математики хватит для подавляющего числа задач.

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

Да это так.
Причем через некоторое время становится абсолютно по барабану: считать прочностные характеристики зданий, или рассчитывать логистику крупной компании. Можн ос легкостью переходить с задачи на задачу, которые вообще никак друг с другом не связаны.
В общем программист должен уметь все. А для этого надо всю жизнь ходить на курсы HTMLAcademy и учиться писать CSS через матрицы))
Только вот зачем тогда все прочие люди на проекте?
UFO just landed and posted this here
Что программисту нужно 100% — это логика. Без этого — увы никак (если программированием не называть рисование формочек, само собой).
Математика же, обычно, нужна постольку-поскольку. Всегда можно нанять узкоспециализированного аутсорсера, если что. А держать такого в штате, обычно, накладно. Может для каких-то CAD'ов — максимум.

Итого: учите всё подряд, что попадётся вам под руку.

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

На 10 году работы программистом внезапно нашёл область, где действительно нужна математика. В частности, тригонометрия и линейная алгебра… И эта область – разработка игр.

У меня в своё время в анализе изображений ТФКП внезапно вылезла. Причем не в связи с преобразованием Фурье, а для простого и быстрого детектирования наличия и направления полосок текстуры (и сегментации в соответствии с ним)

преобразование фурье, свёртки и прочую мелочевку я как-то особо за математику и не считаю. сотни готовых библиотек.

был у меня такой коллега))) слава Богу уже работаем порознь. орал зачем ему знать основы — он и так умный)
написал свой атомик на Java, потому что оракловские медленно работают… они, видите ли работают через синхронизацию…
мало того, что работало с ошибками (ни разу не запустил чтобы проверить), так еще и скорость по бенчмарку показал на ДЕВЯТЬ порядков ниже…
если вы не видите пользы в математике — это совсем не значит, что она не нужна. это просто означает, что в вашей работе будет много велосипедов.
а готовые библиотеки не панацея. как это странно не прозвучит, но надо знать внутреннюю структуру всего, что используется в критических местах, чтобы писать эффективно.


пример из жизни — когда я был маленьким и глупым — получил тестовое задание от яндекса… посчитать количество чисел на офигенно большом отрезке, в которых цифры не повторяются… решение в лоб считало на 8 ядрах около 5 часов… после некоторых манипуляций с точки зрения алгоритмов — 20 секунд...))) убитое время научило в чем разница между быдлокодером и программистом.

<zanuda_mode="on">
Вы уверены, что на 9 порядков? Может быть в 9 раз? Просто на 9 порядков — это в 1000000000 раз медленнее…
<zanuda_mode="off">
О! Мать иматики великие собрались :)
Итак — пусть по бенчу оптимальный алгоритм считает нечто 10 секунд (10^1).
Неоптимальный — (10^10) секунд.
Воспользуемся гуглом для того, что бы посчитать сколько это:
otvet.mail.ru/question/29213929
«примерно 31 год и 8 месяцев»
Вы ждали ответ 31 год? :) Математики собрались,… Яблоку негде упасть :)
Вы там прежде, чем плюсы и минусы расставлять, хотя бы в азах 11тилетки разобрались :)
Школота. Рано вам всем программировать что-то сложнее 2+2.

Напоминаю: речь идет об атомике, атомарной переменной. Это не какой-то алгоритм. Время одной операции тут измеряется микросекундами, если не наносекундами. Т.е. порядок тут 10^-6, если не 10^-9. Соответственно, на 9 порядков дольше — это от 10^0 до 10^3.


Нет, я, конечно тоже не понимаю как можно так накосячить с атомиком чтобы он 15 минут на операцию тратил — но технически тут ничего невозможного нет.


Написали же однажды партнеры самозамедляющуюся очередь с квадратичным временем на операцию...

Ок, пусть и так. Вы верите в 15 минут ожидания одной операции? Это физически возможно?

В коде которых коллег я видел много бреда. И я не вижу причин по которым в том коде, который я не видел, не было бы все еще хуже.

откуда 15 минут? речь о нескольких операциях в секунду вместо пары десятков миллиардов за то же время.
не заметили сразу потому что не сверхкритический модуль и без ограничений по времени (когда выполнится — тогда и выполнится).
да и заметили-то из-за ошибок. а так бы и работало это чудо дальше.

Хм, 10 миллиардов атомарных операций в секунду — это вообще как? Это ж больше тактовой частоты процессора...

открываем спецификацию, исходники и разбираемся… а можно просто взять jmh и сделать самому — вопрос 5 минут.
кроме того, вы считаете, что операции чтения тоже блокируют объект? отличный способ выстрелить себе в ногу получился бы.

UFO just landed and posted this here
UFO just landed and posted this here
Я не говорю о том, что математику знать не нужно. Я говорю о том, что не нужно заниматься велосипедостроительством. Математических библиотек для основных расчетов написано невероятное множество, на всех основных языках и под все основные платформы. Крайне маловероятно, что кто-то напишет что-то лучше имеющегося. Изучайте лучше нейронки. Вот где математика нужна. Там еще кот не и начинался валятся.

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


для продуктов с 10 пользователями в час это не актуально. им допустимо жить под лозунгом "фулскан. и пусть весь мир подождет."

Пафос оценил. Повторюсь: я говорил про основные расчетные алгоритмы математики.

ок…
более основного алгоритма, чем перемножение, вы врятли найдете…
только вот берем убогую машинку со считанными килобайтами памяти и ловим снижение его производительности. переписываем вручную на перемножение Карацубы — вуаля… скорость при малодоступных ресурсах выше, а результат тот же. (на высоких мощностях не работает, а кое где и вредно — ждем реализации проекта Amber)
еще раз повторяю — необходимость возникнет при ограниченных ресурсах. мало памяти. мало времени, много данных, миллионы параллельных сессий… любое допущение стандартного метода выйдет боком уже не на доли миллисекунды. если бы гугл выдавал вам ответ 10 минут — стали бы вы им пользоваться? даже если гарантированно будет ответ в первой же строке.

1. Даже на такой относительно специализированный алгоритм уже есть множество статей и реализаций (первые найденные, наверняка можно и готовую, оттестированную, библиотеку найти):
habrahabr.ru/post/124258
habrahabr.ru/post/262705
habrahabr.ru/post/121950
Ну давайте еще одну реализацию, с блэк-джеком и остальным, сделаем :)
2. Может показаться удивительным, но ограничение ресурсов есть всегда и везде, только лишь в большей или меньшей степени.

то есть вы утверждаете, что нашли бы все эти статьи ДО того, как поставили бы задачку написать код для какого-нибудь микроконтроллера? и особенно до того, как я этот метод упомянул?
не зная теории? я обычно верю людям на слово, но все же…
особенно я бы поржал с оправданий "это не у меня ошибка! это там! в библиотеке!!! где-то в ней! найти не могу — я в исходниках не разбираюсь".
я немного неграмотный специалист, видимо. не могли бы вы мне указать где в этих статьях БИБЛИОТЕКИ, да еще и тесты? я вижу просто красивый код, который вы бы скопипастили. библиотек не вижу.

Быдлокодерство — это изобретение собственных кривых велосипедов вместо использования нормальных имеющихся в том числе.
Просто при разработки игр требования несколько жестче — с одной стороны необходимо писать производительный код, а с другой стороны — игра это маленькая математическая симуляция выдуманной реальности. Поэтому сразу все всплывает.

Но в других областях математика тоже постоянно всплывает, просто принято обычно все это маскировать «а давайте возьмем вот это фреймоворк» — иногда это даже спасает, или просто люди пишут говнокод не пытаясь разобраться в вопросе и быстрей коммитеть. Было дело — общался с чуваком, который писал какую-то штуку типа онлайн-магазина (в группе разработчиков естественно) и к тому моменту когда он дошел до истории как они прикручивали вейвлет-преобразование я уже был офигевший.

Все зависит от задач и от того насколько добросовестно подходят к её решению. Вообще в русском языке есть такое понятие как «халтура». Большая часть погроммистов именно что халтурит — кто-то осознано, кто-то неосознано, но халтурят, причем массово — целыми конторами. Благо в IT полно задач, которые при современных условиях (вычислительные мощности, обилие библиотек, фреймворков, развитые инструменты разработки) позволяют халтурить. Но вот игры — как раз задача не из этой области, прокатить на халтурку — не получится (но народ пытается, и даже наблюдаются какие-то успехи на этом фронте...)

Еще игры делаютя при крайне ограниченном бюджете, так что рулят человеке оркестры. В тоже время придя в какой-нибудь Синопсис можно всю жизнь лепить кнопочки и не вникать, что же там делает вон тот яйцеголовый чувак за соседним столом — просто разделение труда и компания может себе это позволить.
Что программисту нужно 100% — это логика[...]
Математика же, обычно, нужна постольку-поскольку
Какой идиот плюс комментарию поставил? ЕГЭ дает свои плоды: логику из математики выкинуть — это пи**ец, граждане!
Смотря какая логика. Формальная логика это раздел философии, исчисление предикатов или булева алгебра это к математике. Я бы так однозначно не классифицировал логику :)
Вот только хотел сказать то же самое. И видимо, имелось ввиду исчисление предикатов. Так эта жуть тоже не особо нужна. Можно знать что такое OR и AND, свободно ими оперировать, и не знать такие слова как конъюнкция, дизъюнкция, предикат и не знать вообще, что это из мат. логики

разве что при работе в коллективе для понимания между коллегами. если коммуникаций никаких и не предполагается развитие специалиста через книги / лекции / конференции — тогда есть возможность не знать терминологию.

Даже если предполагаются книги/лекции/конференции/общение есть большой шанс не встретить слов конъюнкция и предикат

не сказал бы, что большой. в общении — да. в книгах — вероятность встретить повыше… не встретить на конференции доклад с упоминанием предиката можно только не придя на нее.
я не призываю учить все, что только попадается. жизни не хватит.
не обязательно на зубок это все помнить. но если к вам обратится человек и употребит этот термин — крайне желательно, чтобы вы понимали о чем речь. хотя бы на уровне знания где искать его определение.
Как говорится:
Страшен не тот, у кого есть ядерная бомба, а тот у кого есть ее чертежи и материалы.

Хотел сначала написать, что я вот например не знаю, потом погуглил и вспомнил, что в ВУЗе это было. С тех пор мне ни разу не пригодилось это знание. Но я — это частный случай
Мне всю жизнь регулярно пригождаются.
С тех пор как папа в детстве вдолбил.
Можете привести пример задачи, где вам это пригодилось?
Очевидно, упрощение логических выражений. Люблю, знаете ли, писать довольно сложные логические выражения в if-ах. Иногда к ним приходится применять отрицание. А лишние скобки только мешают. Ну и «Теорию автоматов» тут сыну недавно объяснял, тоже пригодилось. Полезные законы, берите, не сомневайтесь.
UFO just landed and posted this here
Вот так, не видя кода, Вы быстренько провели мне codereview и вынесли вердикт. Завидую, я так не умею. До сих пор «другие программисты» не жаловались. А если вдруг кто-то из них не знает законов де Моргана, я им с удовольствием объясняю.
Вот — код бы увидеть ) Что бы было что обсуждать.
А где именно вам там пригодилось хитрое преобразование по законам де Моргана?
Оно не хитрое. Оно общеупотребительное.
Мой вопрос был к тому, что там у вас везде обычные простые условия, которые пишутся так сразу без всяких преобразований.
Я помню, что такие случаи при разработки (конкретно этого проекта) были, но по всему репозиторию искать, просто для того чтобы пальцем ткнуть, большого желания нет. Возможно потом было отрефакторено.
Ну вот, чтоб далеко не ходить, из сегодняшнего коммита:
if ((piece !== null) && (piece.player == board.player)) {...}

Вполне может получиться, что напахал с условием (много раз так получалось) и надо было сверху добавить отрицание. Если «де Морган» впитался в костный мозг — сразу меняем && на || и меняем условия на противоположные. Часто так получается лучше чем один уродливый not над всей скобкой. Ну это тривиально, в самом то деле.

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

Большое достоинство таких законов в том, что им пофигу тривиально оно в данном конкретном случае или не очень. Они просто работают. И их полезно знать.

Когда уродливый not лучше читается, я его оставляю.

Это так что-ли?)


if ((piece === null) || (piece.player != board.player))

Правильно выше сказали, насчет втыкания и читабельности. Я вот даже сходу затрудняюсь, как назвать это условие.


isCurrentPlayer = ((piece !== null) && (piece.player == board.player));
if (isCurrentPlayer) { ... }
if (!isCurrentPlayer) { ... }
Заведите issue. Обещаю её рассмотреть.
UFO just landed and posted this here
Может быть и относится. Люблю засовывать в каждую строку побольше. С институтского Паскаля на перфокартах пошло. Там где у других студентов была стопка перфокарт толщиной в сантиметр, у меня их было всего с десяток. Важно было даже не это, а то, что в перфокартах всегда были опечатки. А поскольку у меня перфокарт было меньше, меньше приходилось и исправлять. Как бы там ни было, я давно и успешно работаю в софтверной компании и на мой код никто (уже давно) не жалуется. Вот когда я был юниором — было дело.
Если вы серьёзно делаете так в условиях в своём коде в if выражениях, то я не завидую тем, кто будет его читать и отлаживать
Это Ваше право — завидовать кому-то или нет, но владеть навыками упрощения логических (а заодно и арифметических, чего уж там) выражений полезно. Дистрибутивный закон ещё не забыли?
а полезно для чего? какой у вас критерий полезности? вот например, легко читаемый код — это полезно
Умение читать чужой код (не всегда легкочитаемый) — тоже полезно, согласитесь. Меня это умение не раз выручало.
Конечно умение читать код полезно. Но речь сейчас идет скорее об умении писать понятный код, что, согласитесь, полезно
Безусловно! Всегда стараюсь такой и писать. Я там выше ссылочку кинул. Буду очень рад, если Вы возьмёте на себя труд проревьюить код.
UFO just landed and posted this here
Я понимаю, что лабораторная задача, поставленная таким образом потребует именно тех знаний, ради закрепления которых она и была придумана. А вот что-нибудь жизненное было бы интересно
UFO just landed and posted this here
и как задача была поставлена изначально?
UFO just landed and posted this here
прочитал я про них… законом назвали то, что любому логическому мыслящему человеку в голову придет во время работы?
Ну прочитайте ещё. Там их довольно много этих законов. И все используются для формального преобразования логических выражений. Разумеется, «логически мыслящий» человек вполне в состоянии вывести любой из них, но… Зачем ему тратить на это время? Вполне достаточно их знать (ну, или один раз вывести самому, а потом знать).

А вот, к примеру, тому кто делает моды для игр серии TES и "приравненных" к ним (Fallout 3+) — нужно знать как работать с конъюнктивными нормальными формами. Потому что условия в редакторе задаются именно в формате КНФ вместо интуитивно понятных ДНФ.

Довольно специфичная задача, такие не очень то часто встретишь
Большая часть программистской деятельности складывается из довольно специфичных задач.
Это так. Но у нас же контекст обсуждения «нужна ли математика программисту». А специфические задачи программирования могут быть связаны не только с математикой или вообще не с математикой
Согласен. Даже согласен с тем, что есть такие программисты, которым серьёзная математика ни разу за всю жизнь не пригодилась. В этом плане, статья немного наивна, но, на мой взгляд, посыл даёт правильный. Помимо этого, математика — это весело! Серьёзно, я искренне сочувствую программистам, которым не нужна математика.
И я с вами согласен :)
Нам нужно понимать как устроены шрифты: что такое гротеск, чем он отличается от антиквы, что такое интерлиньяж, кернинг, разрядка, капитель. Понимать, что такое сетки и что такое композиция. Кроме этого, разбираться в UX — мы должны знать что такое оптимистичный UI, где поставить прелоадер и зачем это всё нужно пользователю.

Я, например, зеленого понятия обо всём этом не имею :) Что мне не мешает активно и успешно делать отличные интерфейсы, под веб в том числе.
Можно пару работ посмотреть?
Что мне не мешает активно и успешно делать отличные интерфейсы, под веб в том числе.

Может быть, эта успешность только в вашем воображении?
Врятли за плохие результаты будут хорошо платить, согласитесь :)

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

Видишь ли, я и есть начальство :) Я — совладелец продуктовой софтверной компании. А платят нам наши клиенты. Конкуренция у нас — выше крыши. Не как у 1С с их монополией. На аутсорс мы кое-что и отдаём и довольно хорошо платим.

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


зы вспомнил на предмет "у меня высокая зарплата". одно из старых мест моей работы. сидел человечек и получал до фига денег. только не за то, что он писал что-то немыслимое. все в рамках. а просто за то, что продукт был откровенным нагромождением как письмо дяди Федора и он единственный, кто там хоть как-то разбирался. буквально ему платили за то, что он единственный был готов работать говнокопателем. все случаи индивидуальны)

Что не так? Я совладелец и сооснователь компании. И, да, мне платят за мой код в том числе. 60-70% кода всех проектов написаны мной. Про зарплату я нигде не говорил, учитесь внимательно читать. Но говорил, что платят хорошо.

чинит за начальником его код. и никто не скажет,

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

указали на его некомпетентность используя всю глубину русского языка

Странные у вас понятия об IT компании :) На уровне совкового строитреста где-то.
за чужое отличное мнение не увольняли

ну еще бы кто-то так официально объявил. был свидетелем как за высказывание об управленческих способностях назначили "наказание" — ходить точно минута в минуту на работу и после рабочего дня еще отдельно заходить и отчитываться. т.е. расписание с 9. отдел приходит обычно в 10-11 (кому как удобно). а этот человек должен явиться в 9 утра, потому что начальник ему позвонит на рабочий номер и не дай бог тот трубку не снимет. а потом 8 рабочих часов уже прошли, но надо сходить и рассказать что делал. это же не увольнение. это просто охота на ведьм и видел я подобное несколько раз.
смех был когда сотрудник ушел и директору передали "а вообще-то он у нас половину инфраструктуры обслуживал и никто кроме него этого не умеет".


60-70% кода всех проектов написаны мной

мммм… ну еще бы свой код идеальным не казался. я уже выше говорил — все познается в сравнении. наймите человека с опытом 10+ и быстро получите отповедь насколько все криво и допотопно написано. таким людям откровенно пофиг кто перед ними — работу найдут за неделю если что.


На уровне совкового строитреста где-то

ну что ж поделать, если у нас такие требования на окладах под 200к. куда ж нам до вашего передового продукта из трех программистов. (или двух? 60 процентов это очень высокий показатель, говорящий о почти полном отсутствии штата)

Я может быть из другого фронтенда, но со статьей не согласен. Никогда в мои задачи как фронтенд-разработчка не входило вот это все, что описано в статье (интерлиньяж, кернинг и пр). В мои задачи входила разработка архитектуры приложения с использованием фреймворков или без них. После того, как основная часть готова, приходит макет от дизайнера (который как раз таки все это знает) и это просто накладывается сверху без особых разбирательств. Нет, это конечно же не тупое копирование шаблона из psd в css, можно и поинтересоваться всегда почему так, а не иначе. Однако, это совсем не обязательно и необходимо крайне редко.

Вы не знаете, что такое кернинг и делаете UI? Можно мне тоже пример работ? Возможно, у вас талант, но талант плюс знания дали бы больше. Или вы пользуетесь заготовками от людей, которые знают, что это такое.

Где в CSS есть кернинг, который кроссбраузерный?
Уж лучше пусть будет стандартный шрифт, чем измененный дизайнеров, который потом в CSS не воспроизведешь)
Или вы пользуетесь заготовками от людей, которые знают, что это такое.

Я уже писал про UniGUI. Вот им и пользуюсь. Он позволяет отстранится от большинства браузерных особенностей и заниматься непосредственно дизайном форм + кодингом логики.
Погуглил, что такое кернинг. Каким образом это касается кого бы то ни было, кроме разработчиков шрифтов?
Зачем знать о garbage collector кому-либо, кроме разработчиков V8?

Ещё это касается того, кто выбирает шрифт. Что бы выбирать не по принципу "вроде красивый", а осмысленно. Ещё про засечки надо бы знать. Не очень глубоко, но общее представление имеет смысл иметь.

Наверное, вы правы. А как осмысленно выбирать шрифт по кернингу? Мне не очевидно. Он просто должен нормально выглядеть.

Я могу только более внимательно взглянуть не на шрифт в целом, а на детали. Для этого не нужно знать само слово "кернинг", конечно, просто нужно смотреть совпадают ли расстояния между буквами на разных участках страницы (если там разные шрифты). Но для этого про такую мелкую деталь надо бы знать, тем более, что узнать про нее можно за 10 минут.


При этом я не хочу сказать, что такие мелкие детали нужно знать всем. Кто никогда не проектирует интерфейсы, им не обязательно.

А кто разрабатывает шрифт? Разве не дизайнеры?

Ой, и снова здравствуйте!


Это же вы на UniGUI интерфейсы делаете? Из готовых блоков, с дизайном 10-летней давности?

Скоро на 6-ку перейдут ExtJS, будет новее. Обещают до нового года. Мы пишем не чистые веб сайты, а веб-клиенты к своим программам. Результат отличный. Копию того же GMail'а на унигуе можно вполне и быстро накидать. Гугл так безнадёжно устарел?
Нужна ли математика программисту?


Пользователи NumPy недоуменно переглянулись…
При программировании интерфейсов (отображения), как только переходишь черту однообразности, без математики, хотя бы уровня отличника 11 класса, никуда. Пока разработчик берет готовое, я не буду даже говорить об архитектуре, которая, как ни странно, у всех разная, он не подозревает, что ДАЖЕ обычный прелодер, например 3D, вынесет ему мозг. Мне вообще кажется что 90% фронтэндов не понимают матрицы. В сторону canvas, там вообще никуда. Все примеры, которые выкладывают для демонстрации своих фраймворков, естествно демонстрируют самые сильные стороны, которые в реальных проектах в таком виде не используются. на phaser можно онлайн танчики на 10 пользователей сделать за день, на 500 пользователей, придется отказываться от phaser и писать свой движок. В реальности готовое можно использовать только в том виде, в котором тебе дают.

А что будет, если кому-то на работе предложат реализовать алгоритм с первого курса по вписыванию прямоугольников в пространство, как в галерее мансури. Если не знаешь математики, то даже лучше не тратить время, а увольняться, притворившись, что мне с вами не интересно :)
Спорно. Я думаю все движется в сторону унификации интерфейсов и всякие красивости на канвасе не всегда нужны. Ну а галерея масонри реализуется через display: grid тремя строками CSS)
Программисту не нужно то что легко гуглится.
то что легко гуглится.

И это точно не математика.
Это точно та часть математики которая и нужна программисту, ему не нужно решать сложные задчи, ему нужны способы решения типичных задач, которые есть в изобилии.

если он никогда не учил паттерны — как же он узнает, что поставленная перед ним задача типична?

Любая задача типична. Если задача не типична и программист не знает этого/не понимает этого — тот кто дал ему задачу ошибся в уровне программиста.
Если не получилось загуглить значит нетипична, тогда нужно обращаться к спецам этой области, тут уже знание математики не поможет нужно этим заниматься всерьез.

серьезно?
простите, а запрос как должен выглядеть?


обеспечение единственной точки доступа к ресурсу базы данных приложения (выскочит, разумеется, одиночка)
обеспечение распараллеливания вычислений данных и их суммирование как результата с сортировками и другими преобразованиями (выскочит map-reduce)


или вы предлагаете писать по любой проблеме на StackOverFlow, чтобы другие ребята решали за вас? зачем такой спец тогда вообще нужен? за умение писать на форумах?


или вы текст задачи в строку поиска вбивать предлагаете?


я не пытаюсь как-то острить или обидеть. я хочу понять что мне нужно вбить в гугл чтобы выскочило "о! ваша задача уже решалась — вот готовый код для копипаста.".

Умение использовать нормальные готовые решения, либо довести их до таких — это одно из того, за что готовы платить в софт. компаниях. На собственном опыте.
Всего всё равно не найти. Но то, что можно найти, позволяет лицензия и нормально работает — использовать можно и нужно.

прежде чем их использовать — о них нужно знать.
или вы считаете программистом человека, который перед каждой задачей идет на форум и спрашивает не подскажет ли кто типовое решение?
вручили бы вам в 7 классе учебник по аналитической геометрии, физике твердых металлов и музыкальному сольфеджио. поставили задачи, для решения которых в этих учебниках все есть — помогло бы?) даже если бы сказали, что время не ограниченно.


основная проблема будет тут состоять в том, что дешевле найти человека, который это знает и сразу применит, а не ждать пока капуша что-то там в гугле нароет. производительность опытного программиста 6+ выше студента в 10 раз (была где-то статья на хабре) минимум. не все проекты позволят себе такую роскошь, как ожидание.

Не совсем понял, из того что вы написали следует что программист не должен знать программирование, но я такого не утверждал.

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


математики мое утверждение касается лишь в той мере, что она развивает память (как абсолютно любое знание) и учит систематизировать технические знания. более серьезная помощь с ее стороны крайне сильно зависит от поставленной задачи.

«В поисковике найдётся всё» может и сыграть злую шутку в ответственный момент.
1. Начнем с того что надо знать что гуглить. Как правило все практические задачи покрывают сразу несколько разделов математики. Ну вот я сейчас потихонечку пилю задачку где захвачено сразу: глобальная оптимизация и мета-эвристические алгоритмы (метод имитации отжига, генетические алгоритмы, роевой интеллект и т.д.), задачи на обход графа (дискретная математика в принципе базовый минимум для программиста), задачи на раскраску графов, дискретная оптимизация, градиентные методы (Нелдер-Мид, BFGS и т.д.), компьютерная/вычислительная геометрия и внезапно еще потребовалась физика и метод конечных элементов, хотя задача к физике не имеет никакого отношения, ну и т.д. Вообще задача не особо сложная, давно известная и уже 100500 раз решенная, но конечным решением никто естественно не поделится, а охватывает она целую кучу разделов математики :-)

2. Некоторые вещи гуглятся с трудом, если не знать конкретно, что это такое. Если Вы загуглите Kraftwerk 2, то Яндекс и Гугл буду подсовывать второй студийный альбом германской группы Крафтверк, а не алгоритм быстрой оптимизации упаковки. Добавления слов optimization и algorithm поможет слабо (хотя Гугл уже начнет подавать надежды), и так пока не добавите что-нибудь типа VLSI, placement, force-directed и прочие ключевые слова из контекста именно этого алгоритма, хотя и тут гугл с яндексом будут подсовывать много хлама. И это ситуация, когда название алгоритма известно точно, а если еще нет, то что тогда? Наедятся на то что 1 млрд обезьян чисто теоретически могут написать Войну и Мир?

3. Чтобы применять алгоритм, нужно знать тонкости, нужно понимать как работает алгоритм, какие у него особенности. Программисты никогда не слышавшее про вычислительную геометрию на вопрос определения точки внутри многоугольника, начинают выдавать простыни тормозящего говнокода, а потом еще и удивляются почему алгоритм отрабатывает не все случаи, после чего начинают добавлять костыли, когда всего-то надо написать 19 строчек кода включая комментарии, скобочки и пропуски широко-известного Winding number algorithm (который впрочем тоже имеет ограничения применения). Но это еще простая и рутинная задача, а если что-нибудь посложнее? Ну я уже неоднократно наблюдал как погроммисты пренебрегавшие в свое время математикой, по 2-3 недели не могут написать Simulated Annealing — алгоритм 30-и летней давности и уровнем математики 1-го курса любого вуза. Крайний раз чувак перепутал знак «больше»-«меньше» и долго не мог понять почему не работает, когда ему об этом сообщили.

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

5. Возвращаясь к Гугл нельзя не отметить, что зачастую по теме выдается всякий шлак. Если запросить чего-нибудь про Генетические алгоритмы, то там в большинстве случаев будет научпоп 70-ых годов про бинарные хромосомы и одноточечный/многоточечный кроссовер. Ну вот для решения задачи коммивояжера (около 2-х лет проработал на проекте где эта задачка была одной из основных частей ПО) это уже работать не будет, благо эта задачка учебно-типовая гугл осилит, а если что-то посложнее? А вот для чего-то посложнее операторы мутации и кроссовера (а это все математические операторы) придется разрабатывать самому в зависимости от задачи (см. пункт 4).

6. Алгоритмов много, просто тьма. Одну и туже задачу можно решить несколькими десятками алгоритмов, каждый из которых имеет свои достоинства и недостатки — без знания предметной области и без определенного математического бэкграунда оптимального решения не будет никогда (если вообще появится, знаю пару кодерских контор, которые так зафейлили очень жирные заказы). Еще очень распространенная проблема, когда алгоритмы применяют неправильно. Или другой пример, сейчас пошла мода на нейросети и все давай пихать их во все щели, даже туда, где обычный МНК справится.

7. Все любят петь про библиотеки. Так вот хорошие и быстрые библиотеки, которые нас избавят от написания своей реализации умножения матриц, уже стоят денег, ну от 8 до 32 тыщ. долларов за 1 рабочее место. И все равно надо понимать, что и для чего это делается, иначе будет пустая трата денег.

8. Ну и последнее. Программирование — это всего лишь часть прикладной математики, не более чем инструмент для реализации тех или иных математических методов решения практических задач. Научить синтаксису языка N можно любую обезьяну, вот только программируют не ради программирования.
Можно чуть подробнее про сильно платные библиотеки? Я пользуюсь BLAS/CuBLAS, понимаю, что она не идеальна (как любое ПО), но базовые вещи закрывает уверенно.
Тут все упирается в вопрос что Вам нужно.
Можно быть стильным, модным молодежным и использоваться халявный Python/NumPy — только вот скорость там будет мягко говоря уровня черепахи.

BLAS — сейчас де-факто стандарт API для создания библиотек линейной алгебры. Так что BLAS'ов на самом деле много, тот Intel MKL (который тоже бесплатный) этот BLAS содержит, есть Boost C++, который в себе содержит тот же самый uBLAS, вроде как тоже бесплатный, но вот Intel MKL будет уже быстрее.

Основные проблемы начинаются когда:
1) Нужно больше функционала чем просто перемножение и вращение матриц, Фурье и т.п., что можно и самому без особого труда написать. Например, работа с гигантскими разряженными матрицами, просто гигантские матрицы, всякие хитрые солверы (например, какую-нибудь хитрую реализацию Нелдера-Мида), там вообще много чего может быть. Например, в Matlab, в Global optimization toolbox для генетических алгоритмов используется запатентованный Mathworks оператор мутации, а результаты с ним заметно лучше. В общем всегда в платных библиотеках функционала куда больше и там есть то, исходники чего Вы никогда не найдете.
2) Производительность — Intel MKL это уже хорошо и быстро, но иметь компилятор C/Fortran от Intel — лучше, а это уже денег стоит (там разное лицензирование и уже цены от 4 и до 32 тыщ долларов). В общем реально высокопроизводительные вещи стоят уже денег. Всегда.
3) Всякие мелкие тонкости, например, совместимость — ну вот самая распространенная проблема это совместимость по бинарникам. Вставляли недавно одну бесплатную билиотечку, которая реализует L-BFGS, причем с возможность наложения ограничений (вообще BFGS unconstrained алгоритм, но математики не просто так хлеб едят) и еще всякие вкусные солверы (я бы сказал что нетривиальные, я писал проще) и тут начались проблемы с ошибками памяти (причем только под Windows и совсем какие-то рэндомные). Берем исходники, вставляем их в наш проект, немного их правим, компилируем — все работает зашибись, вот только лицензия там GPL… В итоге все сводится к тому, что надо: а) платить, или б) писать самим, а это тоже время-деньги, или в) искать другое решение, которое внезапно оказывается тоже платным.
А еще есть всякие штуки типа многопоточности, векторизации и т.д.
4) Нужны дополнительные компоненты. Есть вот даже такой термин Business Intelligence(или просто BI) — нужно обрабатывать большие объемы данные, анализировать их и выводить в удобно-читаемом виде. Там Вам будет и математика и кучу интерфейнсых мозголомок. Начинаем писать такие штуки сами — тратим время и соответственно деньги. Начинаем использовать халявные библиотеки — все зашибись пока данных не становится слишком много, даже банальная отрисовка графика (только отрисовка!) начинает вешать всю систему (см. п.2), а ведь эти графики должны быть интерактивными… Естественно есть куча готовых высокопроизводительных компонент, например, BI Dundas, который стоит денег… много денег (на сайте даже цены не указаны, т.к. с каждой компании разработчиков бабло стригут индивидуально)
5) Язык программирования. Это отдельная тема. Хорошо быть C/C++ или Fortran программистом. Fortran де-факто язык математического программирования для которого написано десятки тысяч самых разных библиотек, С/С++ тоже неплох и на него оперативно переписывают фортрановские библиотеки. Но вообще и Fortran и C/C++ программисты дорогие, найти их сложно, на C/C++ ее и разработка часто оказывается дороже. Зато каждую обезьяну можно научит писать на Java и C# — таких программистов полно, а вот с библиотеками… гхм, ну вот например .NET до версии 4.5 не поддерживал SIMD, сейчас вроде как начал поддерживать, но как-то не возбуждающе. Выбор библиотек здесь уже куда более куций, библиотеки которые дадут и перфоманс и легкое внедрение — стоят уже деньги, например, ILNumerics или NMath. Можно взять какой-нибудь Accord.NET, но он будет медленный (см. п.2)
6) Особенности лицензирования — то что можно быку (творить всякие безобразия), то не позволено Юпитеру, а Цезаря за это так вообще в Сенате закололи. Например, Advanced Simulation Librar — офигенная штука для высокопроизводительных симуляций бесплатная, пока ты ей дома пользуешься для лабораторок каких-нибудь, а вот для коммерческого пользования рано или поздно придется платить. Или, например, ALGLIB (Delphi, C/C++, C# и т.д.) имеет двойную лицензию — можно использовать на халяву, но там не будет ни многопоточности, ни векторизации, ни интеграции с MKL, ни нативных HPC (higth-perfomance computing) — т.е. медленно, а самое главное халява по GPL, либо платите бабки и все это будет и даже исходники дадут (см. п.1,2,3)

Т.е. все зависит от потребностей и возможностей. Что бы сразу было все, работало быстро и легко интегрировалось (самые главные качества любой библиотеки) — стоит денег или это белый единорог. За какие-то базовые вещи никто денег брать не будет — понятно что за БПФ никто не заплатит, его итак можно быстро написать. С линейной алгеброй дела будут обстоять еще сложнее — т.к. быстро крутить-верететь матрицами сложно.

В любом случае, даже обходясь совсем-совсем готовой библиотекой надо понимать что там внутри происходит. Например, Вы можете найти псевдобратную матрицу с помощью: LU-разложение, разложения Холецкого, QR-разложения, SVD. LU-разложение работает только с невырожденными матрицами, т.е. на практике малоприменимый метод, разложение Холецкого работает только для положительно-определенных матриц и точность оставляет желать лучшего, а QR-разложение в общем-то неустойчивое (для устойчивого нужно использовать модифицированный алгоритм Грама-Шмидта), самым точным и надежным будет SVD-разложение… и самым медленным (а еще оно в своей основе использует QR-разложение). Ну в нахождение псевдообратной матрицы необходимо для получения МНК-решения системы линейных уравнений, а такие задачи встречаются абсолютно везде, фактически любую практическую задачу пытаются свести к МНК.
Платное — оно обычно не просто так платное. Если задача, где нужно использовать эту библиотеку, позволит заработать 30-40 тысяч зелени и выше, почему бы и 4-10 не заплатить? А не позволит — то зачем ею вообще заморачиваться? Даже на бесплатных либах? Академический интерес? Ну ок — посчитаете рано или поздно, однопоточно. Странное у всех отношение какое-то к платным инструментам, честное слово. Платные инструменты позволяют экономить время и/или деньги. Иначе бы их просто вообще никто не покупал.
Ну на то и расчет. Обычно все упирается в производительность и набор функций, чтоб самим время-деньги сэкономить, иначе может выйти дороже (если вообще выйдет).

Для академических целей прайсы кстати очень демократичные, а можно и вообще бесплатно получит. Обычно различают: академические цели, коммерческое использование малыми компаниями, коммерческое использование большими компаниями (вот тут ценник становится просто конским.

Но тут правда еще одна проблема может вылезти — купить-то можно, а потом окажется, что там чего-то нет.

Ну а если говорить о совсем-совсем ПО для математиков, то это: Matlab, Mathematica, Mapple. Стоят тоже конских денег. Например, бесплатная альтернатива Matlab — это Octave, которая таки несколько медленнее и не имеет (пока еще) всего функционала. Они на самом деле крайне удобны для математического программирования — прежде всего за счет синтаксиса и богатых библиотек для всяких рисовалок, вот только коммерческий продукт на них фиг напишешь — все равно потом придется брать какой-нибудь язык общего назначения и переписывать на нем и вот тут выясняется, что Mathwork требует конских бабок за свои продукты не просто так…

Мне иногда кажется, что развитие языков свернуло куда-то не туда…

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

Более вероятно, что программисты загуглят "point in polygon", прочитают википедию, загуглят названия алгоритмов, и выберут подходящую реализацию.


Возвращаясь к Гугл нельзя не отметить, что зачастую по теме выдается всякий шлак.

А вот для этого нужно умение анализировать информацию и разбираться в предметной области. А не учить все подряд из всех разделов математики.

Более вероятно, что программисты загуглят «point in polygon», прочитают википедию, загуглят названия алгоритмов, и выберут подходящую реализацию.

Хз, за 10 лет наблюдений обнаружил, что находят только 2 самых простых способа: использование скалярного произведения или райкастинг. И то, и то — школьный уровень, человек и без гугла должен сообразить. Первый работает только для выпуклых многоугольников, для второго надо учитывать граничные случаи.

А вот для этого нужно умение анализировать информацию и разбираться в предметной области. А не учить все подряд из всех разделов математики.

Вода.

Ну то есть все-таки используют готовые решения, а не пишут простыни тормозящего говнокода.


человек и без гугла должен сообразить

Зачем мне писать свой кривой велосипед, если можно взять проверенную реализацию, в которой учитываются граничные случаи?


Вода.

Не вода, а подтверждение моей точки зрения, что важнее анализ и проектирование, а не доскональное знание одной предметной области. Если математику будет нужно сделать подключение к БД на C#, а Гугл будет выдавать всякий шлак, как ему математика поможет найти среди него правильное решение?

Зачем мне писать свой кривой велосипед, если можно взять проверенную реализацию, в которой учитываются граничные случаи?

Я в другом посте привел простой пример — обращение матрицы, это наверное одна самых распространенных операций вообще:
1) Разложение Холецкого — работает только с положительно-определенными симметричными матрицами
2) LU-разложение — работает только с невырожденными матрицами
3) QR-разложение — может работать с разными матрицами, но не все реализации устойчивые (я встречал в стандартных библиотеках разные варианты) и скорость выполнения уже не айс
4) SVD — переваривает все и с высокой точностью, но медленно, очень медленно.
Возьмете стандартную библиотеку, а там будут реализованы все 4 способа, какой выберите если никогда не слышали алгоритмы факторизации матриц? По-умолчанию разработчики либ обычно подсовывают SVD, шоб пользователь не испытал батхерд, когда попытается засунуть любую случайно сгенерированную матрицу.

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

и это может оказаться самая медленная реализация из возможных (а может и нет, если писал гений оптимизированных вычислений), если она действительно будет переваривать все виды многоугольников да еще на длинных вычислениях. На основании чего разработчик будет делать выбор, если его знания ограничены первыми 6-ю классами школы?

Или другой пример, в FarseerPhysics (теперь VelcroPhysics) и Box2D используются 2 разных подхода для бинарных операций над полигонами общего вида, а еще для Convex ecomposition в первом используется и Ear clipping algorithm, и Bayazit algorithm, а в Box2D только Ear clipping algorithm. Какой сами будите использовать, какой другу посоветуйте?..

Святая вера в идеально стандартное решение — это уже какая-то религия походу.

Если математику будет нужно сделать подключение к БД на C#, а Гугл будет выдавать всякий шлак, как ему математика поможет найти среди него правильное решение?

Подключение БД к C# — это рутина, которая итак описана в MSDN и книжках по .NET, туда его гугл и отправит. А вот на основании чего он будет делать выбор в пользу Array, Dictionary, LinkedList, List, Queue, Stack и т.д. вот это уже куда интереснее, погроммисты которые учились на погроммиста в универе и в отличии от меня не забивали на какую-нибудь дискретку и тому подобное, знают эту разницу без привязки к языку. Внезапно это все математика и там начинаются такие вещи как вычислительная сложность вставок, удаления, поиска, получения по индексу и прочие страшные О.

Гугл будет выдавать всякий шлак, как ему математика поможет найти среди него правильное решение?

Если он ище вопрос по математике и алгоритмам, то:
а) Он сможет задавать более уточняющие запросы, т.к. знает что примерно надо найти, так что шлака внезапно станет меньше
б) Он отфильтрует весь шлак и школьный говнокод
в) Некоторые вещи (по которым он специализируется) он и искать не будет по памяти сразу сделает (если память хорошая)
д) В отличии от чувака с улицы он будет в курсе, что полезные вещи не только на Гугле ищутся, а например, на IEEEXplore или ScienceDirect, наверняка кто-то знает еще больше.

Не вода, а подтверждение моей точки зрения, что важнее анализ и проектирование, а не доскональное знание одной предметной области.

Ок, Гугл! Используя только анализ и проектирование, напишите мне программку, которая будет мне синтезировать антенную решетку с максимальным уровнем SSL и с учетом всяких дополнительных ограничений (угол качания луча, ширина луча, нули ДН, динамический диапазон и т.д., в общем сам с помощью гугла догадайтесь). Если кажется что это слишком сложно и оторвано от жизни, то хотя бы напишите программу оптимальной расстановки мебели в хрущовке…
А вот на основании чего он будет делать выбор в пользу Array, Dictionary, LinkedList, List, Queue, Stack и т.д. вот это уже куда интереснее, погроммисты которые учились на погроммиста в универе и в отличии от меня не забивали на какую-нибудь дискретку и тому подобное, знают эту разницу без привязки к языку.

Я вот в университете на программиста не учился. И "дискретку", что бы это ни было, забивать не мог, ибо у меня ее тоже не было. Это не мешает мне знать, чем отличаются описанные коллекции.

какой выберите если никогда не слышали алгоритмы факторизации матриц

Как ни странно, сначала прочитаю про алгоритмы, потом выберу подходящий. Возможно даже на ваш коммент в поиске наткнусь.


и это может оказаться самая медленная реализация из возможных

Может мне ее будет достаточно?


На основании чего разработчик будет делать выбор, если его знания ограничены первыми 6-ю классами школы?

На основании информации, которую он получил за последние пару часов (или дней) изучения задачи.


Святая вера в идеально стандартное решение

Как из "выберут подходящую реализацию" можно сделать вывод про "идеально стандартное решение"?


Подключение БД к C# — это рутина, которая итак описана в MSDN и книжках по .NET, туда его гугл и отправит.

Там так-то тоже разные способы есть. Библиотеки, фреймворки.


Если он ищет вопрос по математике и алгоритмам, то

Так он ищет про организацию работы с БД.


Используя только анализ и проектирование, напишите мне программку, которая будет мне синтезировать антенную решетку

"Извините, я не специалист в этой области. Обратитесь, пожалуйста, к другому специалисту". Поэтому мне понадобится много времени на анализ именно этой области. Если согласны оплатить это время, пожалуйста.
Задачами на проектирование я с вами меряться не буду, потому что они требуют подробного описания.

Программисты никогда не слышавшее про вычислительную геометрию на вопрос определения точки внутри многоугольника, начинают выдавать простыни тормозящего говнокода, а потом еще и удивляются почему алгоритм отрабатывает не все случаи

О! Как раз наша тема, в том числе. У нас в компании работает программист, который как раз отлично знает нужные нам части математики. Собственно — для этого и брали.
Его реализация алгоритма была страницы две кода, недели 1.5-2 по времени. Работала, правда, безупречно. Моя же, нагугленная за час, реализация была такой:

function DotInPolygon(X, Y: integer; const Polygon: TPointDynArray): boolean;
var
 i, j: integer;
begin
 Result := False;
 j := 0;
 i := Length(Polygon) - 1;
 while i >= 0 do
 begin
  if not ((Polygon[i].X < X) xor (X <= Polygon[j].X)) then
   if Y - Polygon[i].Y < (X - Polygon[i].X) * (Polygon[j].Y - Polygon[i].Y) / (Polygon[j].X - Polygon[i].X) then
    Result := not Result;
  j := i;
  Dec(i);
 end;
end;

Он очень удивлялся такой реализации :) Впрочем — польза от его алгоритма тоже была — погоняли на множестве тестов и убедились что оба алгоритма работают совершенно одинаково. Знание математики при незнании алгоритмов и неумении пользоваться гуглом иногда может помешать разработке.

Так вот хорошие и быстрые библиотеки, которые нас избавят от написания своей реализации умножения матриц, уже стоят денег, ну от 8 до 32 тыщ. долларов за 1 рабочее место.

Ссылки бы было интересно увидеть на либы и цены.
Моя же, нагугленная за час, реализация была такой

Crossing number algorithm, Франклин (вроде даже еще живой), думаю это года 70-80, вытекает напрямую из теоремы Жордана (XIX век). Такой сейчас любой школьник на Паскале напишет и без гугла даже (внезапно). Ничего особенного.

Гуглите дальше, пока не нагуглите без операции деления (я даже подсказку дал).

погоняли на множестве тестов

Плохо гоняли. Вы заставили меня усомниться в эффективности Ваших тестов. Работать будет только для простых многоугольников (гуглите что такое простой многоугольник если не знайте), что также напрямую вытекает из теоремы Жордана. Ну да, еще и деление.

Ссылки бы было интересно увидеть на либы и цены.

Вы же вроде бы гугл-гуру? Разве нет?
Пожалуйста
тыц
Можете потыкать на этой страничке, чтоб посмотреть как меняется цена не забудте еще добавить НДС (18%) и не забываем что ценовая политика зависит от того, кто покупает. Дистрибьютер кстати тоже маржу иметь хочет. Кстати это без Rogue Wave IMSL, на это придется отдельно раскошелится (благо стоит не дрого), а есть еще и другие аддоны.
тыц
тыц
тыц
тыц
Работать будет только для простых многоугольников

Ну так может там в задаче только простые многоугольники и есть?

Может и есть, но об этом ничего не сказали, значит тут 2 случая:
1) Многоугольники общего вида — феил, т.к. задач не решена
2) Чувак просто не понимает возможную сложность и объемы задачи — феил, т.к. люди просто не разобрались в задачи и когда наступит час Х все будут ломать голову над тем, почему все не работает

Плюс пункт 3): там нехорошая операция деления (она вообще-то не такая уж и тривиальная с точки зрения машины), а это уже погрешность вычислений. Так что на простых многоугольниках этот алгоритм тоже может ВНЕЗАПНО зафейлиться — иногда это не критично, иногда нет… хотя есть аналогичные алгоритмы без деления

Соответственно добавим еще и пункт 4) нет никакого обоснования почему решили именно так, а не иначе. Алгоритмов то полно, каждый из них имеет свои достоинства и недостатки — и именно этим надо оперировать, а не:
нагугленная за час

погоняли на множестве тестов


Ну и все это еще приправлено целочисленными аргументами (откуда? зачем? почему?). В общем либо совсем что-то узкоспециализированное, либо очередной говнокод, который потом будет обрастать костылями и в итоге все придет к:
Его реализация алгоритма была страницы две кода, недели 1.5-2 по времени.

Меня всегда такая святая простота умиляла.

Ну и хвалиться что нагуглил такой алгоритм несколько странно: я такую же фигню писал в школе на Паскале, а тогда гуглов не было, а интернет был через соседа по dialup модему. Современные школьники на олимпиадах тоже его вспоминают, студенты у которых были хоть какие-то азы вычислительной геометрии напишут сходу — он простой и элегантный, но уровнем не сильно круче использования скалярного произведения и гуглить тут будет только человек который вообще никогда не слышал про вычислительную и компьютерную геометрию — в этом ничего зазорного нет, но не хвалиться же этим…
Ну и все это еще приправлено целочисленными аргументами (откуда? зачем? почему?). В общем либо совсем что-то узкоспециализированное, либо очередной говнокод, который потом будет обрастать костылями и в итоге все придет к:

Это часть векторного движка. Координаты точки на экране целочисленные.

она вообще-то не такая уж и тривиальная с точки зрения машины


Я в курсе :) В своё время процессора паяли на макетках ещё )

Ну и хвалиться что нагуглил такой алгоритм несколько странно: я такую же фигню писал в школе на Паскале, а тогда гуглов не было, а интернет был через соседа по dialup модему.

Честь и хвала. У меня несколько иные были интересы (больше ассемблер + разное железо). И, как видим, этот алгоритм даже в вузах не дают.
Честь и хвала. У меня несколько иные были интересы (больше ассемблер + разное железо). И, как видим, этот алгоритм даже в вузах не дают.

Хз, у меня на 2 или 3 курсе его давали, причем на физфаке. Школьники-олимпиадники тоже его знают — в олимпиады любят такие задачки вставлять. Просто не все помнят, а кто-то может пробухал лекцию. Я вот, например, пробухал алгоритм Каргера как недавно выяснилось (спустя кучу лет). Просто подготовка у нас в стране очень-очень неравномерная. Но вообще компьютерная геометрия — это отдельная и очень большая часть математики на котрую по идее должны натаскивать только на определенных специальностях, ну вот, например, на кафедре автоматизации систем вычислительных комплексов ВМК МГУ, а вот чуваки с какой-нибудь механики мехмата МГУ вряд ли будут в курсе что там и как, зато им можно нейросети давать.

Т.е. специализация. Она у всех разная:
У меня несколько иные были интересы (больше ассемблер + разное железо)

Ну я вот как раз от этого и отошел в сторону программ где не надо соображать, как уложиться в 512 байт RAM (некоторый линейки MSP430 нас радают просто гигантскими размерами RAM и ROM)
Crossing number algorithm, Франклин (вроде даже еще живой), думаю это года 70-80, вытекает напрямую из теоремы Жордана (XIX век). Такой сейчас любой школьник на Паскале напишет и без гугла даже (внезапно). Ничего особенного.

Так я и не говорю, что тут — какой-то космос. Но вот — человек впервые алгоритм такой видел. Хотя в математике разбирается очень хорошо.

Плохо гоняли. Вы заставили меня усомниться в эффективности Ваших тестов


Я в курсе про ограничения. Формула хорошо работает на любых многоугольниках, кроме тех, у которых есть пересечения граней. И знаю причину — что непонятно, какую часть многоугольника считать внутренней, а какую — нет. Есть дополнительная проверка на пересечения. За ссылки спасибо — посмотрю.
Так я и не говорю, что тут — какой-то космос. Но вот — человек впервые алгоритм такой видел. Хотя в математике разбирается очень хорошо.

Все упирается в специлаизацию. Если человек никогда не слышал про компьютерную геометрию — первое что ему придет в голову, считать через скалярное произведение, работать правда будет только если многоугольник выпуклый (convex), то и фиг с этим, да и вообще лучше стараться сводить все задачи к выпуклым если можно — с ними жить проще :-)
Если погуглить дальше то можно будет найти метод трассировки лучей/метод пересечений, вот как раз у Вас из этой серии пример кода, а есть еще другой подход — на количество оборотов причем потенциально эта идея может работать вообще с фигурами, которые описаны гладкими кривыми.

За ссылки спасибо — посмотрю.

Могу и еще накидать. Все на самом деле зависит от целей и задач. Вот где-то рядом чувак отписывался, что ему хватает BLAS/uBLAS, соответственно — это MKL или C++ boost они бесплатные и достаточно быстрые (MKL ИМХО быстрее, но он на самом деле условно бесплатный). Есть еще ROOT, но я им никогда не пользовался.

А вот иногда бывают другие ситуации:
1) Разработчик/заказчик хочет чего-то странного. Обычно это всякие высокоуровневые вещи и хитрые солверы. Ну т.е. одно дело просто матрицы перемножить, другое дело нужно что-то посложнее (ну я хз, например какое-нибудь квадратичное программирование) и что бы не изобретать велосипед и не тратить время проще купить.
2) Нужна супер-пупер производительность. Люди наигрались с Python/NumPy и внезапно узнают, что на других ЯП и с другими библиотеками эти же задачи решаются в 20 раз быстрее (таки реальный замер).
3) Нужны всякие свистелки и перделки. Ну банально без графиков никуда.
4) Внезапно выясняется, что кругом одни Жаба и ДотНет кодеры и никто не хочет писать на С/С++, а уж про Fortran так вообще в РФ забыли (за бугром таки нет, практически вся запрограммированная математика идет от Фортрана). Можно найти халявную библиотеку, но платная библиотека будет лучше. А так был случай когда наткнулись на C#-враппер над C/C++ библиотекой, которая в итоге сама оказалась враппером над библиотекой, написанной на Фортране. При этом исходная фортрановская библиотека была под MIT (таки общенародной достояние), а С-враппер уже под GPL 0_0
5) Людям нужна среда разработки а еще лучше — быстрый компилятор, а еще лучше что бы было все и сразу

Но вообще все же лучше по возможности писать самому: во-первых, слишком много тонкостей по применению и использованию, во-вторых, иногда бывают такие ситуацию, когда единственный доступный гугл — это книжка за много денег
Спасибо. Раз вы такой ссылкообильный в математическом программировании :) Может есть ссылки на еще один довольно частный алгоритм. Пока найти не можем, но нужен. Опять же векторный движок. Задача стоит провести некую гладкую линию (сплайн), проходящую через заданные точки. Из инструментов есть только кривые Безье. Думаю, известно, что они не проходят через 'опорные' точки. Стоит задача пересчитать исходные точки в 'опорные' Безье. Может кто-то что-то такое видел?
Гы. Вот буквально несколько лет назад такую задачу решал. Да и сейчас маячит.
Я так предполагаю шо сплайн кубический (с квадратичным вроде как достаточно просто должен быть), т.е.
p(t)= (1-t)*(1-t)*(1-t)*x0
+3*t*(1-t)*(1-t)*x1
+3*t*t*(1-t)*x2
+t*t*t*x3;
т.к. контрольные точки x0 и x3 у нас вообще-то известные — они же a и d, а вот x1 и x2 уже будут хз. t = t0, t1, t2, t3, 0<t<1. Зато нам будут известны 2 другие точки, пусть b и c.
b = (1-t1) * (1-t1) * (1-t1) * x0 + 3 * (1-t1) * (1-t1) * t1 * x1 + 3 * (1-t1) * t1 * t1 * x2 + t1 * t1 * t1 * x3
c = (1-t2) * (1-t2) * (1-t2) * x0 + 3 * (1-t2) * (1-t2) * t2 * x1 + 3 * (1-t2) * t2 * t2 * x2 + t2 * t2 * t2 * x3

Ну (1-t1) * (1-t1) * (1-t1) * x0 + t1 * t1 * t1 * x3 и (1-t2) * (1-t2) * (1-t2) * x0 + t2 * t2 * t2 * x3 нам известны, так что можно это представить вот так
3 * (1-t1) * (1-t1) * t1 * x1 + 3 * (1-t1) * t1 * t1 * x2 = b — (1-t1) * (1-t1) * (1-t1) * x0 — t1 * t1 * t1 * x3

3 * (1-t2) * (1-t2) * t2 * x1 + 3 * (1-t2) * t2 * t2 * x2 = c —
(1-t2) * (1-t2) * (1-t2) * x0 — t2 * t2 * t2 * x3

Получаем систему линейных уравнений.

Обзовем правую часть как вектор-столбец Y = [y1,y2], т.е.
y1 = b — (1-t1) * (1-t1) * (1-t1) * x0 — t1 * t1 * t1 * x3
y2 = c — (1-t2) * (1-t2) * (1-t2) * x0 — t2 * t2 * t2 * x3
мы её можем однозначно вычислить.
Это с одной стороны, а вот с другой стороны
y1 = 3 * (1-t1) * (1-t1) * t1 * x1 + 3 * (1-t1) * t1 * t1 * x2
y2 = 3 * (1-t2) * (1-t2) * t2 * x1 + 3 * (1-t2) * t2 * t2 * x2

Назовем (для компактности) неизвестные переменные как вектор-столбец X = [x1, x2], мы их не знаем. Получится:
A*X=Y
Где A — это матрица
[ 3 * (1-t1) * (1-t1) * t1, 3 * (1-t1) * t1 * t1;
3 * (1-t2) * (1-t2) * t2, 3 * (1-t2) * t2 * t2]
Она тоже одназночно вычислима, соответственно получается, решая эту СЛАУ в матричном виде:
X = inv(A) * Y
inv — это инверсия матрицы.
Почему такие сложности? Та хрен его знает — формально так положено, красиво и компактно выглядит… ну еще потому что получается, что в матрице А торчат полиномы Берштейна и задача по поиску контрольных точек в итоге сводится к решению системы линейных уравнений. Собственно каждая точка сплайна Безье это и есть линейная комбинация контрольных точек и полиномов Брештейна и есть надежда, что так можно окучивать любые сплайны (надо попробовать).

А так для кубического сплайна получиться что-то типа такого (и без всякого обращения сплайнов)

        A11 = 3*(1-t1)*(1-t1)*t1; 
        A12 = 3*(1-t1)*t1*t1;
	A21 = 3*(1-t2)*(1-t2)*t2; 
        A22 = 3*(1-t2)*t2*t2;
        det = A11*A22 - A12*A21; //В этом месет мы можем проверить точно ли нам сплайн подсунули или циферки от балды

	y1.x = b.x - ( (1-t1)*(1-t1)*(1-t1)*a.x + t1*t1*t1*d.x);
	y1.y = b.y - ( (1-t1)*(1-t1)*(1-t1)*a.y + t1*t1*t1*d.y );
	
	y2.x = c.x - ( (1-t2)*(1-t2)*(1-t2)*a.x + t2*t2*t2*d.x );
	y2.y = c.y - ( (1-t2)*(1-t2)*(1-t2)*a.y + t2*t2*t2*d.y );

	pos[1].x = A22*y1.x - A12*y2.x;
	pos[1].y = A22*y1.y - A12*y2.y;
	pos[1].x /= det;
	pos[1].y /= det;

	pos[2].x = (-A21)*y1.x + A11*y2.x;
	pos[2].y = (-A21)*y1.y + A11*y2.y;
	pos[2].x /= det;
	pos[2].y /= det;

Можно еще учесть, что t1 = 1/3, а t=2/3, и обозвать A11… как-нибудь по-другому, тогда говнокод станет более читабельным. Можно даже еще проще поступить, сразу вставить t1=1/3 и t2=2/3 в параметрическое уравнение и там получиться без таких сложностей просто решить систему из двух уровнений.

Вроде сходу так получается, хотя могут быть ошибки, но мне уже лень проверять. Но в любом случае с этими сплайнами все можно свести с решению систем линейных уравнений. Такие солверы встречаются вроде как везде. Собственно тут и солвер не нужен Ax=y => x = pinv(A)*y — только матрицу обратить умножить на вектор и все, главное задачку к этому свести, но это будет иметь смысл если количество уравнений больше 3-4 ИМХО
Спасибо, постараемся разобраться.

Вообще если не выеживаться с мптрицами-шматрицами, то для кубчиской кривой Безье, если учесть что t1=1/3 и t2=2/3, то подставив все это в параметрическое уравнение получим систему из 2-х линейных уравнений:


b=(8/27)a + (4/9)x1 + (2/9) x2 + (1/27) d
c = (1/27)a + (2/9)x1 + (4/9)x2 + (8/27)d
a = x0
d = x3


Это систему можно решить в лоб как в школе учили: Берем выражаем x1 через первое уравнение:
X1=(-2/3)a+(9/4)b+(1/12)d-(1/2)x2
Подставляем x1 во второе выражение, ну а дальше мне лень т.к. с телефона (в общем во втором останется только x2 и a,b,c,d, т.е. Сможем выразить x2 через точки a,b,c,d, ну а дальше возвращаемся в первое), только это нудно и можно накосячить (много рутинных преобразований), но после всех вычислений, приведеней и сокращений на листочке, получится совсем простая функция с двумя формулами:
X1 = (-5a+18b-9c+2d)/6
X2 = (2a-9b+18c-5d)/6


Для квадратичного сплайна аналогично. А это 2 самых используемых, врядли на практике будут использоваться полиномы 4 и выше порядков. Но вот как раз для них (т.е. В общем виде) лучше сводить задачу к системе линейных уравнений в матричном виде. Еще с помощью перемножения матриц и векторов можно представить всю кривую сразу (а не по сегментам как я выше писал) и сразу скопом все решить. Вот для этого лучше уже использовать библиотеку, причем решение по всей кривой в матричном виде будет быстрее, чем считать по сегментам как я выше описал (просто векторизация матричных вычислений поддерживается процессором через SIMD инструкции, а ГПУ сами по себе являются векторными процессорами изначально). Главное задачу правильно в матричном виде представить, собственно для этого и нужны математики с их Matlab/Octave. Но! Тут еще надо смотреть для чего это вам нужно, например, если вы хотите найти контрольные точки что бы переместить сплайн из одной сетке в другую, то тут как раз такие функции включены в любые библиотеки в которых есть иниерполяторы сплайнами, например, в том же ALGLIB который я упоминал.


Вообще сплайнов много, есть еще всякие сплайны Эрмита, сплайны Катмулла-Рома и еще куча других. Они по-факту почти тоже самое что и Безье, только параметризованы по другому, что бывает иногда удобно.


Вообще мне по работе раньше часто приходилось со сплайнами встречаться и ВНЕЗАПНО это никак не связано с графикой.


И вот именно по вычислительной геометрии, самые нормальные книги это:
1) Ф.Препарата. Вычислительная геометри
2) Роджерс, Адамс.
Математические основы машинной графики
3) Роджера
Алгоритмические основы машинной графики
Вот собственно и все. Причем эти книги еще и фиг найдешь. Какие-то учебники издавал БХВ и ДМК(Вычислительная геометрия: Алгоритмы и приложения), но я хз чего там.

Работать будет только для простых многоугольников

Судя по используемой структуре данных, иных видов многоугольников в программе возникнуть не может по построению.

UFO just landed and posted this here
Т.е. 10 лет обходился без математики. Потенциально мог бы и еще 20 лет без нее работать.

Скажем так, за эти 10 лет математика иногда была нужна точечно, для "бизнес-логики". А вот в разработке игр она нужна постоянно и почти везде – от графического движка до логики геймплея и UI.

UFO just landed and posted this here
нужно определиться, куда идешь и изучать соответствующие темы

Я вот вспоминаю себя в годы последних классов школы/поступления в ВУЗ и практически не представляю, чтобы в том возрасте можно было более-менее осмысленно выбирать себе профессию на всю жизнь. Конечно, есть люди, которые чётко знают, кем они хотят быть, уже с детства, но ИМХО это скорее редкость.

UFO just landed and posted this here
UFO just landed and posted this here

Нужна программисту не математика, а умение строить модель из всего на свете.
А уже это умение проще всего воспитывается математикой.

на музыкальных сайтах они транспонируют тональность песен

Хотите полезный совет? Разберитесь в предметной области, прежде чем о ней писать.

Тональность не транспонируют, транспонируют композицию (или тему).

Мда. Я думал, будет какое-то откровение, а тут филолог в треде…

(да нет, что вы, что вы, такой же програмист, как и вы)


Вы никогда не слышали про необходимость выработать и строго придерживаться единой доменной терминологии?

Я, признаться, даже не знаю, что такое «доменная терминология». Пробовал гуглить — не помогло.

Но из вариантов:
1. на музыкальных сайтах они транспонируют тональность песен
2. на музыкальных сайтах они транспонируют песни
3. на музыкальных сайтах они транспонируют темы песен

для Хабра я лично выбираю первый, как баланс между точностью и понятностью (контекста). По-моему, вариант вполне нормальный.
Я, признаться, даже не знаю, что такое «доменная терминология». Пробовал гуглить — не помогло.

Гуглите ubiquitous language.


для Хабра я лично выбираю первый, как баланс между точностью и понятностью (контекста). По-моему, вариант вполне нормальный.

Вот только для специалиста он совершенно некорректен (и показывает, что автор варианта не понимает, что происходит). В статье, призывающей изучать предметную область, это плохой пример.

А какая тут математика? Сложение и вычитание
Сложение/вычитание, это если музыка записана в midi.
А если wave, то это Фурье/оконные функции.
В этом случае не то, чтобы Фурье, скорее умножение и деление, если речь о транспонировании музыки
Так-то, внутри у много чего умножение и деление. :)
А почему не Фурье?
Я знаю алгоритм, как это сделать без Фурье, но мне бы хотелось послушать ваши доводы — может мы о разном говорим.
Транспонирование — это перенос нот музыкального фрагмента на заданное целое число N полутонов вверх или вниз, т.е. сложение/вычитание в терминах нот. Или N-кратное умножение/деление частоты исходных звуков на 2^(1/12)
Или N-кратное умножение/деление частоты исходных звуков на 2^(1/12)

… это если у вас полностью равномерный строй, что в реальной жизни встречается крайне редко.

Равномерно-темперированный строй вы имеете ввиду? Всё как раз наоборот, встретить отличный от него в наше время довольно сложно. Но это вообще не имеет отношения к транспонированию. Умножать/делить частоту можно на коэффициент как кратный целому соотношению полутонов, так и не кратный, суть та же
Равномерно-темперированный строй вы имеете ввиду?

Его, родимо-ненавистный.


Всё как раз наоборот, встретить отличный от него в наше время довольно сложно.

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


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


Короче, истинно равномерная обычно только электроника, либо инструмент, над которым специально прыгали, чтобы он был равномерным. А все остальное — "хорошо" темперированное на вкус того, кто в этом месте за интонацию отвечает.


(вуф, я столько раз это уже написал, что скоро сделаю сниппет или пост под ссылку)


Умножать/делить частоту можно на коэффициент как кратный целому соотношению полутонов, так и не кратный, суть та же

Это зависит от того, вы транспонируете в рамках строя, или с его сохранением. Первое — это как если бы у вас был натуральный (или темперированный) рояль, и вы транспонировали руками (было in C, стало in G): благодаря тому, что вы перемещаетесь из одного места неравномерного строя в другое, окраска меняется. Это, кстати, ровно то, что происходит в ХТК.


А то, что вы описываете — это второе, т.е. у вас был натуральный инструмент in C, вы его выбросили, взяли натуральный инструмент in G, и сыграли на нем (любимое дело для духовиков, чего уж).

Уверяю вас, вы глубоко заблуждаетесь насчет неравномерно темперированного строя. 99.9999...% музыки, которую вы можете услышать в современном мире по радио, телевизору, живую (включая симфоническую) звучат в равномерно темперированном строе.

ХТК во времена Баха звучал скорее всего в «хорошей темперации» Вейкместера (неравномерная, но близкая, как раз цель такой темперации — более менее одинаковое звучание соотношений в разных тональностях), а сейчас на современных инструментах исполняется в равномерно-темперированном строе.

Задачу транспонирования без сохранения соотношений интервалов для записанной общей волны я бы да, стал решать, используя преобразование Фурье, но это работало бы только для синусоподобных тембров. Для живых инструментов эта задача не является решаемой
Уверяю вас, вы глубоко заблуждаетесь насчет неравномерно темперированного строя. 99.9999...% музыки, которую вы можете услышать в современном мире по радио, телевизору, живую (включая симфоническую) звучат в равномерно темперированном строе.

Основания для этого утверждения?

… полученное откуда? Верифицированное чем?


(А то я же вам тоже "знание" излагал, полученное из образования и личного опыта, и верифицированное, опять же, личным опытом, разговорами с исполнителями, ну и тривиальной логикой местами)

Ну как вам сказать. Вот были бы вы здесь мы бы с вами понажимали на клавиши синтезатора, запустили бы программку, посмотрели бы частоты, посчитали соотношения, взяли бы гитару, послушали ушами, что все ноты звучат одинаково, замерили бы частоты и вы бы во всем своими ушами/глазами убедились. А через интернет не знаю. Может здесь есть, кто в этом вопросе понимает, подтвердит, что вы не правы

Клавиши синтезатора — это как раз та "электроника", которая вполне может быть равномерной. А вот с гитарой интересно… начнем с того, что все гитары разные. Предположим, у вас честная равномерно-темперированная гитара. У вас квинтовый флажолет звучит строго-ровно на октаву выше, чем струна, зажатая на том же ладу?

Ну раз вы признаете синтезатор равномерно-темперированным — всё просто. Гитара у меня обычная, не натурально или еще как-то по особому темперированная. Настраиваю струны гитары по синтезатору — ми, си, соль, ре, ля, ми. Далее проверяем все унисоны по всем полутонам синтезатор и гитару. Всё совпадает. Берем записи других инструментов, оркестровые например и подбираем точные ноты на синтезаторе. Все унисоны звучат чисто, естественно кроме мест, где применяются соответствующие приёмы. А флажолеты не очень показательны, для флажолета струна не зажимается
Настраиваю струны гитары по синтезатору — ми, си, соль, ре, ля, ми.

На слух?..


Берем записи других инструментов, оркестровые например и подбираем точные ноты на синтезаторе.

Сольные или ансамбль/оркестр?


А флажолеты не очень показательны, для флажолета струна не зажимается

Флажолеты показательны именно потому, что они заведомо натуральные.

На слух?..

Да, какие проблемы, это же унисоны, небольшие отличия по частоте дают очень диссонантное звучание, легко отличить человеку даже без особого слуха. Вот если бы строй различался, это было бы слышно.

Вот вы утверждаете, что гитара неравномерно темперирована. Значит волчья квинта должна быть где-то? Нет, ее нет, все чистые квинты звучат одинаково чисто, как и полагается равномерным квинтам с еле слышными низкочастотными биениями чуть чаще 1 Гц.
Сольные или ансамбль/оркестр?
Без разницы. Включаю Скорпионс — снимаю гитары на синтезаторе — унисоны ок. Беру флейту из «Одинокого пастуха» Ласта — унисоны ок. Виолончели — тут под рукой у меня сериал «Игра престолов» там виолончель на заставке и трубы с волторнами есть в самой серии -унисоны чистые

Флажолеты показательны именно потому, что они заведомо натуральные
Вот как раз поэтому и не показательные. Гитара ладовый инструмент, а флажолет извлекается на струне которая не прижимается. С помощью такой техники можно извлекать звуки по высоте отстоящие друг от друга на интервалы меньше полутона и вопрос темперации инструмента в этом случае теряет смысл
Да, какие проблемы, это же унисоны, небольшие отличия по частоте дают очень диссонантное звучание, легко отличить человеку даже без особого слуха.

Да так… далеко не все люди так хорошо слышат унисоны между двумя разными инструментами.


Вот вы утверждаете, что гитара неравномерно темперирована. Значит волчья квинта должна быть где-то?

Почему? Просто не все полутона одинаковые.


Без разницы.

А как вы умудряетесь сверить унисон с заведомо грязным интервалом?


Вот как раз поэтому и не показательные.

Это зависит от того, что хотеть увидеть. Как вы думаете, если флажолеты отличаются от соответствующих зажатых нот, будет ли музыка звучать чисто?


С помощью такой техники можно извлекать звуки по высоте отстоящие друг от друга на интервалы меньше полутона

Я, вообще-то, и на зажатых струнах могу извлекать звуки с интервалами меньше полутона...


Правда, надо признать, что в тезисе "вопрос темперации инструмента [...] теряет смысл" вы правы. Просто потому, что каждый исполнитель своими руками делает ту темперацию, которая ему нравится. А дальше вопрос исключительно того, какому количеству людей нравится равномерная темперация...

UFO just landed and posted this here

К сожалению, сходу ничего. В голову приходит Способин, но я не уверен, что его осмысленно читать без практики.


(к моему стыду, я давно перестал преподавать)

UFO just landed and posted this here
кажется, на хабре была пара хороших топиков со ссылками
Почему? Просто не все полутона одинаковые.
но они одинаковые и совпадают с синтезатором

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

Ну, у меня не так.


А что вы хотите увидеть, извлекая флажолет?

Да я, собственно, выше спросил: "если флажолеты отличаются от соответствующих зажатых нот, будет ли музыка звучать чисто?"


он извлекается приемом без прижатия струн, им можно вообще любые звуки извлечь

Не любые, а только по обертоновому ряду (я о натуральных флажолетах говорю, конечно же).


На некоторых инструментах теоретически возможно играть в неравномерной темперации он теоретически мог бы, но этим занимаются ну может экспериментаторы какие-нибудь только

А вот и нет. Этим занимаются люди, которых волнует, как звучит то, что они играют. Например, все струнники (которые без ладов).


Это удобно и все уже привыкли

Вы так уверенно за "всех" говорите...

Ну, у меня не так.

Значит, что-то у вас не так с инструментами. Попробуйте поиграть на синтезаторе мелодии с записями других инструментов, на которые вы думаете, что они неравномерно-темперированные, должны получиться чистые унисоны, что докажет обратное
Да я, собственно, выше спросил: «если флажолеты отличаются от соответствующих зажатых нот, будет ли музыка звучать чисто?»

Флажолеты это украшение музыки, а не основа, они звучат коротко и не мешают. В музыке не обязательно все звуки должны опираться на звукоряд, например есть ударные и перкуссия которые могут широко применяться в музыке, не имея при этом определенной высоты звучания.
Не любые, а только по обертоновому ряду (я о натуральных флажолетах говорю, конечно же).

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

По вашему получается, что 99.9..% музыки произведено теми, кого не волнует
Например, все струнники (которые без ладов).

Это не так. Конструкция инструментов позволяет им играть в любом звукоряде и без звукорядов вообще. Но обычно они играют в равномерно-темперированном звукоряде. Попробуйте поиграть на синтезаторе с записью каких-нибудь композиций для струнных
Это удобно и все уже привыкли
Вы так уверенно за «всех» говорите...

Ну не придирайтесь. «Почти все» — вас так устроит?

Попробуйте поиграть на синтезаторе мелодии с записями других инструментов, на которые вы думаете, что они неравномерно-темперированные, должны получиться чистые унисоны, что докажет обратное

Я, на всякий случай, повторю, если это ранее не было очевидно: я не считаю "поиграть с синтезатором" достаточной проверкой даже для монодийных записей, а большая часть того, о чем я говорю — не монодийно.


В музыке не обязательно все звуки должны опираться на звукоряд, например есть ударные и перкуссия которые могут широко применяться в музыке, не имея при этом определенной высоты звучания.

Эмм, не надо путать звуки без определенной высоты и звуки с определенной высотой. Если вы воткнете рядом с натуральной квинтой равномерную, будет звучать плохо.


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

Натуральный (естественный) флажолет — это, по определению, извлеченный на открытой струне.


По вашему получается, что 99.9..% музыки произведено теми, кого не волнует

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


Попробуйте поиграть на синтезаторе с записью каких-нибудь композиций для струнных

Я, знаете ли, пробовал играть на струнных, это намного поучительнее.


Ну не придирайтесь. «Почти все» — вас так устроит?

Тоже нет. Оснований-то для этого утверждения нет.

проще говоря, все струнные с больше чем одной струной и ладами — тоже неравномерные (есть люди, которые строят равномерные гитары, но вы не хотите это видеть)
Вообще-то, гитара — инструмент с равномерно-темперированным стоем by design. Люди по-приколу строят как раз не равномерные, а натуральные гитары (вот у них гнутые лады). Не верите — возьмите тюнер и гитару! Понятное дело, инструмент (струны, пальцы, лады) не идеален, и на тюнере расхождения будут, но он задуман как равномерно-темперированный — и цифры на тюнере будут «плясать» около равномерного строя, а не натурального!
Вообще-то, гитара — инструмент с равномерно-темперированным стоем by design.

Бай какой-такой дизайн?


Не верите — возьмите тюнер и гитару!

Не верю. Взял. Настроил гитару строго по тюнеру (т.е., скажем, первая струна больше не равна флажолету на седьмом ладу пятой). Внезапно, двойные октавы (например, пятый лад второй — шестая) больше не чистые.

Бай какой-такой дизайн?
image
Бай такой: гитара задумана как равномерно темперированный инструмент.

Внезапно, двойные октавы (например, пятый лад второй — шестая) больше не чистые.
И что? Это стало похоже на натуральный строй? Или на какой-то другой определенный?..

Вы смешали мухи и котлеты. Все инструменты не идеальны. Но это не имеет отношения к тому, в каком строе (каким алгоритмом) транспонировать. Нам важно то, в каком строе инструмент задуман играть, а не то, насколько криво это вышло.

Сантиметровая линейка с погрешностью остается сантиметровой, а не дюймовой, иными словами.

И, таки да, подавляющая часть музыки (если считать, скажем по просмотрам на ютубе, то можем и 99.9999% насчитать, как ttools сказал, но пускай 99.9%) задумана равномерно-темперированной. И должна транспонироваться множителем 2^(N/12).

Бай такой: гитара задумана как равномерно темперированный инструмент.

Кем задумана? Вы про гитару Торреса, что ли? Так гитара старше, и начиналась она никак не позже Возрождения, когда равномерная темперация была немного не в ходу.


И что? Это стало похоже на натуральный строй? Или на какой-то другой определенный?..

Нет, а почему должно быть?


Все инструменты не идеальны. Но это не имеет отношения к тому, в каком строе (каким алгоритмом) транспонировать. Нам важно то, в каком строе инструмент задуман играть, а не то, насколько криво это вышло.

Нет, нам важно, как на инструменте реально играют. Чтобы, когда мы транспонируем, мы отдавали себе отчет, что именно происходит с инструментом:


  • исполнитель играет на том же инструменте, но другие ноты
  • исполнитель берет другой инструмент
  • исполнитель перестраивает существующий инструмент

подавляющая часть музыки задумана равномерно-темперированной.

Откуда дровишки? Я вот готов утверждать, что подавляющая часть музыки вообще не задумывается о темперации.

Кем задумана? Вы про гитару Торреса, что ли? Так гитара старше, и начиналась она никак не позже Возрождения, когда равномерная темперация была немного не в ходу.

Какая разница, когда что начиналось. Сейчас на гитаре лады расположены по какому закону? Для чего именно так?

И что? Это стало похоже на натуральный строй? Или на какой-то другой определенный?..
Нет, а почему должно быть?

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

Потому что должен быть какой-то строй. Иначе, о чем разговор… Вот какой строй у вашей гитары? Как он называется, если не «равномерно-темперированный»?

  • исполнитель играет на том же инструменте, но другие ноты
  • исполнитель берет другой инструмент
  • исполнитель перестраивает существующий инструмент
Исполнитель уже сыграл. А мы берем аудиофайл и транспонируем. Такой контекст. И вот совершенно не важно нам, насколько хорошо получилось настроить у него инструмент, важно то, что он был формально настроен в равномерно-тепмерированном (± погрешность). И по-этому аудиофайл мы будем транспонировать но законам равномерно-тепмерированого строя. Используя множитель 2^(N/12).
Или вы предлагаете иначе? Какой закон используем?

подавляющая часть музыки задумана равномерно-темперированной.
Откуда дровишки? Я вот готов утверждать, что подавляющая часть музыки вообще не задумывается о темперации.
Ну и о чем тогда весь сыр-бор?
Какая разница, когда что начиналось. Сейчас на гитаре лады расположены по какому закону? Для чего именно так?

Предположительно, равномерному. Чтобы можны было играть в любой тональности. Практически же это никогда не достигается, и исполнитель темперирует под то, где он играет, сам.


Исполнитель уже сыграл. А мы берем аудиофайл и транспонируем.

Так какая задача этой транспозиции? Мы предполагаем, что он играет на том же инструменте, но другие ноты, или на другом инструменте?


Ну и о чем тогда весь сыр-бор?

О том, как музыка звучит.

Предположительно, равномерному. Практически же это никогда не достигается, и исполнитель темперирует под то, где он играет, сам.
«Практически» и это тоже никогда не достигается, даже если музыкант — виртуоз. Только это всё, повторюсь, не имеет значения. Важно то, как музыка музыка была задумана быть сыгранной. Если гитарист играет (пусть плохо), темперируя в натуральном строе — значит строй считаем натуральным. И транспонируем соответственно. Без разницы, насколько хорошо у него это вышло. Но по умолчанию у гитары строй задуман равномерно-темперированным. Как и 99.9% музыки из радио.

Так какая задача этой транспозиции? Мы предполагаем, что он играет на том же инструменте, но другие ноты, или на другом инструменте?
Вы слышали как звучит питч-шифтер?
Задача — сменить тональность трека, чтобы можно было свести треки в одной тональности.
Важно то, как музыка музыка была задумана быть сыгранной. [...] Как и 99.9% музыки из радио [по умолчанию задумано равномерно-темперированным]

А откуда вы знаете, как она задумана?


Если гитарист играет (пусть плохо), темперируя в натуральном строе — значит строй считаем натуральным. И транспонируем соответственно.

О. И как вы это будете делать?..

А откуда вы знаете, как она задумана?
Бритва Оккама.
О. И как вы это будете делать?..
А никак. Ну, или можно попробовать механизм pitch-detection, как в автотюне, если мелодия монофоническая. Если сработает — то далее по стандартным правилам натурального строя. А в общем случае — никак.

Собственно, это и есть ещё одно доказательство того, что музыка «из радио» в основном — равномерно-темперированная. Потому что она без проблем транспонируется пост-фактум по линейному закону — спросите ди-джеев. Будь это не так — они этим бы не занимались.
Бритва Оккама

Согласно которой музыка задумана без темперации, да.


А в общем случае — никак.

Вот.


Собственно, это и есть ещё одно доказательство того, что музыка «из радио» в основном — равномерно-темперированная. Потому что она без проблем транспонируется пост-фактум по линейному закону — спросите ди-джеев. Будь это не так — они этим бы не занимались.

Это всего лишь значит, что результат, который они получают после транспонирования, их устраивает. О том, как написана музыка, это не говорит ничего.

«99.9% музыки из радио задуманы быть сыгранными без темперации» — ваши слова, верно?

«Без темперации» это какой строй?
«Без темперации» это какой строй?

Тот, который исполнителю приятнее на слух (то есть скорее всего, какой-то вариант "хорошей" темперации).

А сколько процентов, по-вашему, равномерно-темперированной?

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

Ок. Принято. Наверное, вы радио не слушаете…

Скажем так, ни на одном радио, которое мне попадается, описанная выше музыка не доминирует.

Уверяю вас, вы глубоко заблуждаетесь насчет неравномерно темперированного строя. 99.9999...% музыки, которую вы можете услышать в современном мире по радио, телевизору, живую (включая симфоническую) звучат в равномерно темперированном строе.

Кстати, а вы правда думаете, что старинная + народная музыка в сумме составляют меньше 0.0001 процента от радио, телевидения и живого исполнения?

Я думаю немного не так. Старинная и народная музыка сейчас исполняется в равномерно темперированном строе. Но никто не мешает взять какому-нибудь музыковеду взять настроить допустим фортепиано в неравномерной темперации и сделать передачу о том, как музыка звучала раньше. Это и будет меньше 0.00..1
Старинная и народная музыка сейчас исполняется в равномерно темперированном строе.

Откуда дровишки?


Но никто не мешает взять какому-нибудь музыковеду взять настроить допустим фортепиано в неравномерной темперации и сделать передачу о том, как музыка звучала раньше. Это и будет меньше 0.00..1

То есть вы не слышали про historically informed performance, факультеты (и академии) старинного исполнительства, Hesperion XX, Кронос-квартет и так далее? Вы считаете, что ирландцы, играя в drop D, сохраняют в бурдоне грязную квинту? Вы считаете, что ансабли духовной музыки (которых в России есть), исполняя партесные концерты, поют в акустически грязном строе, хотя им ничего не мешает петь в чистом?

Откуда дровишки?

записи Баха, Вивальди, Полистрино в исполнении современных музыкантов

То есть вы не слышали про historically informed performance, факультеты (и академии) старинного исполнительства, Hesperion XX, Кронос-квартет и так далее? Вы считаете, что ирландцы, играя в drop D, сохраняют в бурдоне грязную квинту? Вы считаете, что ансабли духовной музыки (которых в России есть), исполняя партесные концерты, поют в акустически грязном строе, хотя им ничего не мешает петь в чистом?

Вы странный. Напредполагали, что я что-то там считаю, о том, что от вас слышу впервые. Нет, я не слышал, о том, что вы говорите и не могу ничего считать
записи Баха, Вивальди, Полистрино в исполнении современных музыкантов

Вот уж Баха сейчас только ленивый не играет в разной темперации (с тех пор, как появились тюнеры и таблицы, это стало доступно любому студенту). А Палестрина (вы же его имели в виду?) — это вообще акапельные хоры, они поют так, как выгодно акустически (мне с месяц назад попадались наставления хормейстерам середины XX века, СССР, так там явно давались указания, нарушающие равномерную темперацию).


Вы странный. Напредполагали, что я что-то там считаю, о том, что от вас слышу впервые. Нет, я не слышал, о том, что вы говорите и не могу ничего считать

Так может того, о чем вы не слышали, немножко больше, чем какая-то там доля процента? В частности, в старинной музыке сейчас исторически-информированное (или аутентичное) исполнительство составляет большую часть — если, конечно, брать всю старинную музыку, а не маленький кусочек барокко, который на общем слуху; собственно, ощутимую часть старинной музыке (те же кантиги или Libro Vermel) кроме ансамблей старинной музыки никто и не исполняет.

Верно. Но в PCM аудиофайле ведь нет «частот». Там же time-domain. И чтобы получить эти частоты, нужен оконный Фурье.

(На всякий случай: если просто проиграть весь аудиофайл в 2^(N/12) раз быстрее, то это будет не то транспонирование, что нужно. Подразумевается, что нужно сохранить темп неизменным, так ведь?)

Есть вариант без Фурье. Нужно проиграть весь аудиофайл в 2^(N/12) раз быстрее, но не «просто», а циклически внутри окна, которое само перемещается по аудиофайлу с изначальной скоростью воспроизведения. Желательно в несколько итераций (смешивая в общий буфер) и обязательно под оконной функцией (нужно генерировать гауссиану). Не забудьте про кубическую интерполяцию.

Это всё, конечно умножения будут. Но не те. Не 2^(N/12) на частоту.
Всё проще. Сначала умножение 2^(N/12), потом передискретизация в новую частоту с постоянным коэффициентом.
То есть, Фурье всё же нужен, или я вас не понял? На что 2^(N/12) умножать будем?
Есть много алгоритмов без применения Фурье. Есть, например, софтовый эффект pitch, который этим занимается в реальном времени.

На что 2^(N/12) умножать будем?

На коэффициент умножается исходная частота дискретизации, сигнал передискретизируется в новой частоте и накладывается на исходную. Алгоритмов наложения разных очень много. Пример, который характеризует основу идеи может выглядеть так:

Допустим есть исходный сигнал в заданной частоте дискретизации и нужно уменьшить частоту вдвое:
пусть measures исходного сигнала будут ABCDEFG,
в выходном сигнале будет AACCEEGG

допустим надо увеличить частоту вдвое для исходного сигнала

AABBAABB
в выходном сигнале будет
ABABABAB

Зависит наверное от области программирования. И в любом случае нужен математический склад ума, если это можно так назвать

… а что такое "математический склад ума"?

Есть такой анекдот:
Встречает мастер своего преподавателя по вышке лет через восемь после
окончания вуза, разговорились, вспомнили время былое. Профессор
спрашивает:
— Вот я вам читал три года высшую математику, скажи, в жизни тебе мои
знания когда-нибудь пригодились?
Студент, подумав:
— А ведь был один случай.
— Очень интересно, расскажите, я его буду на лекциях рассказывать, что
высшая математика не такая абстрактная наука и в жизни бывает нужна.
— Шел я как-то по улице, и мне шляпу ветром в лужу сдуло. Так я взял
кусок проволоки, загнул его в форме интеграла и шляпу достал!

Вот ваш пример css фильтра matrix примерно такое отношение к линейной алгебре имеют. Вот честно скажите, вы правда думаете, что верстальщику нужна не много не мало, а линейная алгебра для работы и без нее никуда?

Программирование это огромная область, как и математика. И в этой огромной области (программировании) найдутся задачи где математика не нужна, где нужна с натяжкой и где никак без определенных разделов математики, и при этом остальная математика тоже окажется не нужна
UFO just landed and posted this here
Да и знание русского языка не помешает.
Чтобы в описании изменений в новой версии или комментариях в коде -тся и ться не путать.
UFO just landed and posted this here

А вы думаете, что человек, для которого русский родной, может писать по-английски грамотнее, чем по-русски?


(это безотносительно того, корректно ли ваше утверждение, в чем лично я не уверен)

UFO just landed and posted this here

Вот только знание естественного языка программисту нужно не только (гм) для того, чтобы понимать язык программирования. Так что грамотность все же "при чем".

UFO just landed and posted this here

Странно, вроде бы вы мне только что ответили...

А вы думаете, что человек, для которого русский родной, может писать по-английски грамотнее, чем по-русски?

Когда нет практики письма на русском (например, в эмиграции) — да. Простите за занудство.

С этим я, кстати, соглашусь, эмигранты мне уже позже пришли в голову как пример (собственно, сам наблюдал).

А вы думаете, что человек, для которого русский родной, может писать по-английски грамотнее, чем по-русски?

Легко! В школьные годы, мечтая стать инженером, забил на русский язык и прочую гуманитарщину. А затем, когда СССР рухнул и стал нужен английский язык, изучил английский язык (на который забивал в школе), и потому такой вот результат.

… и зачем ему понадобился грамотный английский язык?

Потому что когда учишь английский, то ему учат. Это не родной русский язык, которому учиться нет нужды, по той причине, что его и так знаешь, а потому возможно абсолютно не слушать учителя рассказывающего про грамотность.

Не складывается.


Вот вы выучили английский до состояния начинашки. Зачем вам дальше слушать про грамотность?

После "начинашки" = beginner, идут дальше уровни: elementary, pre-intermediate, intermediate, upper-intermediate, advanced.
И когда все их учишь, то ОЧЕНЬ ВНИМАТЕЛЬНО слушаешь препада, а не смотришь в окно и считаешь ворон, как это было на уроках русского языка, который ты и так знаешь, потому что он родной.

Во-первых, зачем учить дальше, не знаю, intermediate? Во-вторых, откуда берется "очень внимательно"? В-третьих, можно получить advanced и все равно писать неграмотно.

UFO just landed and posted this here

Так уже пробовали — вечно хрень какая-то получается. То истребитель "вверх ногами" переворачивается, то авионика зависает...

UFO just landed and posted this here

В данном примере математик, наверно, лучше запрограммирует какие-нибудь математические функции. А вот собрать целиком продукт (содержащий математический модуль), скорее всего, лучше получится всё же у программиста. Зато математик вполне может тесты для проекта подготовить.

Программисты уже давным-давно из абстрактных «гуру всего» делятся на достаточно узкоспециализированные направления. Тот, кто прекрасен для веба, например, увязнет в разработке драйверов, системщики не считают верстальщиков программистами и так далее.

БОльшая часть работы программиста может решаться грамотной постановкой задачи: если приходит задача, в которой нужно выдать результат сложения А и Б, описан тип и А и Б, а также есть техническое задание на способ сложения (А и Б не обязательно могут быть числами), то математика, может быть, и не понадобится. Другое дело, когда ставится задача сложить А и Б, а по условиям задачи, А и Б — это, например, векторы, вот тогда нужно вспомнить математику. И все эти споры «нужно ли программисту знать бухгалтерию, геометрию, банковское дело и т.д.» в итоге упираются в грамотного проект-менеджера. Другое дело, что лучший проект-менеджер это тот, кто досконально знает программирование текущих задач ;)
Ну если математика так нужна программисту, то почему математику так же сильно не нужно программирование?
Я объясню, почему раньше считалось, что математика нужна программисту — потому что раньше компьютеры использовались исключительно для вычислений, поэтому и нужны были люди, которые умели быстро вычислять на компьютере. Да и то, напомню, что раньше программисты компьютеры в глаза не видели — они писали программы, а вводили их в компьютер — операторы.
Ну и тем более, что программистами сегодня обзывают кого угодно, так что вы бы лучше сказали бы, а кто же такие программисты вообще? А то тут холивара уже столько развелось, а ведь образ программиста у каждого свой ;)
Абсолютно верно. Один кричит, что математика нужна и подразумевает под этим термином сложение и вычитание, а другой доказывает что не нужна, имея ввиду матан.

Многим математикам программирование очень нужно. Не даром есть Wolfram Language или R

Очень люблю математику и совершенно ее не знаю. Все, что было из институтского курса — благополучно забыл. Почему? Потому, что на практике так и не потребовалось. Зато потребовалась куча всякого другого, чему в институтах не учили и не учат. Однако, если попадется соответствующая задача — с удовольствием нырну в тему. Любой спор о том, что нужно или не нужно программисту чаще всего сводится к экстраполяции собственного опыта участников спора на всю отрасль, а это глупо.

htmlacademy: Нужна. А, кроме неё, нужна сферическая геометрия,

А что сферическая геометрия уже не математика? Или для Вас любая геометрия не математика? facepalm


Old_Chroft: Что программисту нужно 100% — это логика. Без этого — увы никак (если программированием не называть рисование формочек, само собой).
Математика же, обычно, нужна постольку-поскольку.

А что логика это уже не математика? facepalm


PS за что Old_Chroft так наминусовали?


Так что вопрос не в том "нужна ли математика программисту?", а в том "какие именно разделы математики наиболее полезны программисту?".

Можно разобрать по формальной логике некоторые утверждения автора:

«Нужна ли математика программисту? Нужна. А, кроме неё, нужна сферическая геометрия, география, музыка и банковское дело.?»

Утверждается, что математика нужна и не уточняется, что нужна не вся. Значит утверждается, что нужна вся. Что по моему мнению, не верно. Я согласен с вашим утверждением.
Дальше: утверждается, что кроме математики нужна сферическая геометрия, то есть автор относит математику и сферическую геометрию к разным наукам, что тоже неверно.

Когда же я утверждаю, что программистам не нужна математика, но нужна логика, я вполне могу иметь в виду, что нужна не вся математика, а только её часть — логика.

Впрочем, что бы окончательно не уйти в софистику, на том и закончим :)
PS за что Old_Chroft так наминусовали?

Кого-то здесь волнует карма? :) Будет неудобно писать, заведу еще один акк. Пусть минусуют, мне вообще пофиг. Зато могу свободно говорить то, что думаю, а не только то, что нравится толпе и она хочет от меня услышать.
Чем самому же ставить мало о чем не говорящие плюсы-минусы — то лучше отписать хоть что-то. Мне эта возможность тоже не нужна. Как и статьи. Лучше себе на сайт напишу что-то :)
за что Old_Chroft так наминусовали?

Idot: все нормально. Гуманитарии как всегда не могут успокоится. Логика — это же ИХНЕЕФСЕ! (Спросим с них в отместку про логику второго порядка?)

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

Я каждый раз радуюсь, когда на работе попадается математическая проблема. Примерно раз в шесть лет.
Конечно нужна, как же наклепать г*вно лэндинг без дискретной математики
Приедьте к нам в Малайзию и попробуйте пройти собеседование в более или менее приличную компанию без знания алгоритмов и структур данных. Погонят рваными тряпками. И это правильно. Сам насмотрелся на таких гаврил — приходит он, значит, и ты ему должен объяснять, почему здесь лучше сделать очередь с приоритетами, а не стек. От этого клинит реально. И не «немного дискретки», как выразился автор, а всю ДК, до изоморфизма графов включительно. Кто ниасилил — для вас творения Михаила Фленова из серии «ХХХХХ глазами хацкера»
P.S. Кто-то скажет, что алгоритмы и структуры данных — это не чистый math. Ладно, допустим. Но попробуйте объяснить новичку в JavaScript что такое closure без ряда Фибоначчи. Что вы будете использовать, какой надуманный пример? Да вообще говоря, и рекурсию понять без этого невозможно. В учебниках обычно пишут про манипуляции со стеком и адреса возврата. Но разве это суть рекурсии? А тут мы уже вплотную подходим к проблеме останова, теореме Клини и прочим интересным вещам. Вот вам и math в чистом виде! А то — «я пишу 40 лет и никогда не знал, что такое синус». С чем вас и поздравляю.

Ну и нафига нужен ряд Фибоначчи при объяснении замыканий? А рекурсию объяснять через него и вовсе не следует, разве что в виде: "а теперь посмотрите как делать нельзя".

Что делать нельзя? Ряд Фибоначчи считать используя рекуррентные соотношения?
Да. Рекурсию нужно объяснять так. Эта, типа, функция, которая вызывает себя. Но смотри следи за стеком, а то грохнется все. Ну есть еще типа хвостовая рекурсия, которой этот самый стек вообще по барабану, но с тебя хватит. Ты ж в html академию пришел, в конце концов

Для того, чтобы объяснить что-то на примере ряда Фибоначчи, достаточно быстро объяснить, что такое ряд Фибоначчи — а это, для прикладных задач, очень быстро.

Я, честно говоря, не вижу сложностей в объяснении closure в js. Оно там выглядит и работает совершенно естественным образом, просто исходя из областей видимости. Понятно даже ребёнку. Сложнее объяснить почему это НЕ работает, например, в С# так-же просто и немногословно (без делегатов).

А в качестве примера рекурсии я использую задачу поиска файла в дереве каталогов. Куда нагляднее, как мне кажется.

А откуда взялось ограничение "без делегатов"?


Не вижу отличий между вот этими программами:


// Javascript
var a = 5;
foo(() => a);

// C#
var a = 5;
Foo(() => a);
Без делегатов = так-же просто и немногословно.
Но со стрелочными функциями выглядит и вправду симметрично. Но я имел ввиду что-то вроде этого:
function outer() {
  let a = 1;
  function inner() {
    let b = 2;
    return a + b;
  }
  return inner();
}

В Шарпе так уже не поговнокодишь.
Оу, а я отстал от жизни. Добавили в C# 7, уже год назад, ура!
Func<int> Outer() {
    var a = 1;
    return delegate () {
        var b = 2;
        return a + b;
    }
}

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

Сишарп уже почти Делфи/Билдер :) Еще бы в нём дотнета не было — и можно было бы использовать.
Насчет C# могу подсказать, без делегатов. Closure в C# невозможен, потому что там отсутствуют функции первого порядка, в отличие от js. Новичку понравится

Что-что? В C# нет замыканий? Правда?

Я javascript разработчик с хорошим знанием матана, стрктур данных и алгоритмов.


Но я в душе не представляю зачем вы так усложнили рекурсию и замыкания.
А уж как часто она (рекурсия) применяется в жизни Frontend (не говоря уже про верстальщика). Наверное целых два раза в год.

К замыканиям ряды Фибоначчи вообще отношения не имеют, разве что как пример реализации. Плохой пример.
UFO just landed and posted this here
Итого: учите всё подряд, что попадётся вам под руку.
Смысл статьи одним предложением.
мы работаем в банковских сервисах, сервисах бронирования отелей, картографических сервисах и прочих Яндекс.Почтах.
Хмм… ничто не подходит, получается я работаю в Яндекс.Почте? Или не программист вообще?

Итого: извините конечно, но это просто ужасная статья, написанная каким-то начинающим узкомыслящим javascript-ером. Желтый заголовок прилагается.
получается я работаю в Яндекс.Почте? Или не программист вообще?

получается что так.
яндекс — самая унылая и жалостливая контора, которую я видел в мире. только она постоянно славливая неиллюзорных звиздюлей от гугла умудряется внутри одной страны находить административный ресурс и жаловаться антимонопольный комитет, указывая на какие-то свои будто бы ущемленные права… сами же в то же самое время устраивают полный жесткач хотя б в том же я.маркете, манипулируя, угрожая и вымогая своим монопольным положением на рынке!!!
будь я на месте гугла — уничтожил бы нах этот яндекс его же оружием — антимонополизацией рынка интернет торговли в россии, а то совсем охерели
ну гугл тоже не белый и пушистый. одни уловки с налогами чего стоят.
не понимаю честно говоря о каком монопольном положении на рынке идет речь — вы не можете установить поиск от гугла? сходите в сервис — научат.
жесткач в маркете? в чем именно? кто-то тащит вас туда силком? не нравится — не пользуйтесь. нравится — значит все-таки деньги и клиентов приносит. просто видимо не дает продавать с наценкой в 300 процентов рассказывая, что у конкурентов еще дороже. как покупатель я это наоборот приветствую.
единственный раз когда я действительно захэйтил яндекс был известный коллапс в метро Питера не так давно — когда цены на яндекс.Такси удвоились, а у конкурентов упали до нуля.
но больше таких случаев я не припомню, так что предположу, что имела место техническая ошибка вкупе с нерасторопностью менеджмента соответствующего подразделения.

ps пресеку полемику на предмет мотивации этого поста — с яндексом я никак не связан. никогда там не работал. да, пару раз пытался туда пройти, но не срослось. пытаться повторно уже скорее всего не буду — офис расположен для меня неудобно.
Итого: учите всё подряд, что попадётся вам под руку. Для начала изучите дискретку, потому что она будет вашим основным инструментом в работе, а потом сосредоточьтесь на задачах вашего бизнеса и вы откроете для себя очень много нового в бизнесе, математике, строительстве и медицине.

Вообще, «итого» должно быть с точностью до наоборот: «сначала сосредоточьтесь на задачах вашего бизнеса, а потом учите всё подряд, что попадётся под руку, если у вас останется на это время».
Лично я могу вопринимать математику только двумя способами:
— Язык. на котором говорят физики
— Сборник логических головоломок
А дальше всё зависит от того, как глубоко интересуешься физикой и как сильно любишь квесты.
Не надо математику знать, надо уметь разбираться в предметной области, в том числе и в математике. Проблема в том, что предметная область может быть очень большой, и потребуется время, чтобы запомнить все сущности и их взаимосвязи. Поэтому знать надо тот необходимый минимум, который позволит разобраться за приемлемое время.
Пример. Необязательно знать в подробностях все возможные теоремы и операции с матрицами. Надо знать, что матрицы есть и что многие вычисления можно сделать с их помощью. Например 3D-преобразования. Понадобилось — повторил, разобрался, сделал. Или не сделал, тут уж как получится.
В этом кстати польза университетов — они дают знакомство с разными областями.
Не надо математику знать, надо уметь разбираться в предметной области

Знание математики позволяет разобраться в других предметных областях.
Зная её Вы разберётесь и в физике, и в финансах, и в инженерии — везде, где есть какие-либо расчёты.
(А вот, зная физику, Вы в финансах не разберётесь, и наоборот, знание финансов, Вам никак не поможет разобраться в физике.)

Знание математики позволяет разобраться в тех областях, где используется математика. Это довольно логично. А вот разобраться в паттернах проектирования или банально CSS изучить она не поможет.
Ну если не придираться к словам, то да, так оно есть. Но другими словами:
1. Надо понимать, т.е. знать математику (это не имеет отношение к зазубриванию теорем, к слову сказать именно опыт в доказательстве теорем очень хорошо прокачивает мозги)
2. Надо вникать в предметную область.

Но тут все же есть разделы математики, которые надо обязательно. Я вот например, постоянно сталкиваюсь с тем, что мои знания дискретной математики мягко говоря неглубокие, линал я тоже зря прогуливал. А вот в тервере, матстатистике, ТФКП, функане, непрерывной оптимизации в силу своего первого образования вроде более-менее норм. Так что риски Фишера сходу кластеризирую, ТрыДэ фигурки тоже буду вертеть как хотеть, а вот решить задачу разбиения графа — придется долго и мучительно читать. А делать приходиться и первое, и второе, и третье...., и десятое — и абсолютно без разницы что ты пилишь: ERP, билинговую систему, CAD, ГИС и т.д.
а вот решить задачу разбиения графа — придется долго и мучительно читать

Но вам ведь это не мешает заниматься программированием и называться программистом? Я вот тоже с графами особо не знаком, а 3D интересовался только в универе. В работе это не приходилось применять, больше требуется анализ и проектирование.

Ну формально нет. Но вообще мода называться программистом после написания Hellow world — плохая практика. В итоге мы имеем — вычислительная мощность растет, а функционал — нет, зато патчем первого дня размером с программу уже никого не удивишь.

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

А анализ и проектирование — это больше для людей сидящих на верхнем уровне иерархии — архитектору, тимлиду. Но без этого вообще никуда. А тот же анализ будет ограничен компетенциями разработчика. Вот я, например, вроде как нормально разбираюсь в задачах оптимизации (пофиг чего вообще), так что достаточно легко могу сообразить как например написать программу, которая, например, оптимизирует логистику какой-нибудь здоровенной компании или отфильтровать радиосигнал/акустический сигнал от всякого мусора: эха, интермодуляций, утечек и прочей хрени, или обучить нейросеть убивать всех человеков объезжать препятствия. А вот буквально относительно недавно сделали меня на структурах и организации данных, так-то. Мне правда все равно, т.к. это все равно не мой профиль. В общем я не уверен что смогу успешно работать с хитрыми базами данных, да и не интересно мне это. А в сторону FPGA (тоже ведь прораммирование между прочим) я вообще стараюсь не лезть.

Короче как правильно скрестить человека и задачу — это та еще задача и как я обратил внимание, её не всегда успешно решают.

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

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

У конкретного программиста, который делает специальный сайт, должны быть специальные знания. А вовсе не у каждого.


Первое решение, которое может прийти в голову — это с помощью метода map собрать другой массив

Первое решение — посчитать в цикле. А там и до reduce недалеко, если очень хочется. А сложность обоих алгоритмов одинаковая (с точностью до множителя).

Имхо, у программиста должно быть понимание решаемой бизнес-задачи и куда рыть по областям этой самой бизнес-задачи, когда всего не знаешь.

Почему спрашивают нужно, а отвечают, о том что математика может помочь?
Математика нужна в GameDev'e.
Математика нужна в программирование какого-то узко специализированного софта.
В Сайтах — может помочь.
В мобильных приложениях — может помочь.
В любом виде деятельности — может помочь(ну серьезно, везде можно её применить)
Давай-те не будем говорить, что нужно, о том, без чего можно обходиться, ну то что желательно знать.
Если N помогает, ну не требуется, то N != нужно.
Математика это квинтэссенция программирования, математика анализирует окружающий мир, а программирование воплощает этот анализ в жизнь
Sign up to leave a comment.