В процессе создания nixie clock на ардуино на что я обратил внимание, так это на то, что счётчик, который считает millis(), переполняется иногда. Редко, раз в несколько десятков дней, но тем не менее. Возможно, если хотите надолго запускать эти часы, вам стоит учесть это в программе.
Когда джуниор первый раз напишет спагетти-код, а ещё лучше, когда он попытается разобраться в чужом спагетти-коде и поймёт, что так делать нельзя, тогда и придёт понимание этого single responsibility principle. Для этого не обязательно учиться в вузе вообще. Это вещи, с одной стороны, лежащие на поверхности, с другой — приходящие только с опытом. Для лучшего понимания таких вещей, для анализа примеров, есть книги от признанных авторитетов разработки, которые разработчик должен прочитать в дополнение к вузовской программе по собственному желанию. В вузе можно дать пару таких курсов в семестре перед дипломом (чтобы студенты просто знали, куда глядеть; достаточно, возможно, просто нескольких лекций), но базировать всё обучение на них ни в коем случае нельзя.
В примере с сеньором, не знающим указанного принципа, похоже, этому сеньору уже ничто не поможет (как не помог бы и курс по разработке ПО), а весь его сильный математический бэкграунд — миф, которым можно обманывать тех, кто сам в этой математике ничего не понимает.
Про то, что код метода не должен быть длиной 342 строки, инженеру сообщат на первой работе, пока он будет джуниором. Там же он познакомится ещё с тысячей других технических деталей, с которыми знакомиться там и место.
Что там у немцев знаю плохо, зато знаю, что наши инженеры востребованы по всему миру, причём часто потому, что с математикой у них более-менее, в отличие от многих их западных коллег. Но инженерия уходит вперёд, появляются новые концепции, многие из которых имеют сильные математические основания, и которые нужно применять с умом и понимать. Математика также развивается, а вот вузы наши отстают — это повод переработать существующие курсы и выкинуть кучу хлама (взятие 100 производных и интегралов руками на 1 курсе), добавить больше содержательной математики, полезной программисту (дискретная математика, алгоритмы, теория типов). Это проблема вузов, а не математики, что в них учат не тому.
Курсы про процесс разработки в вузах должны быть лишь кратким обзором того, с чем придётся столкнуться инженеру, а не ядром всего обучения, по двум причинам. Во-первых, потому что есть куча куда более важных концепций, которым можно научить в вузе. Во-вторых, потому что учить про то, как строить действительно большие проекты вместе с большой командой инженеров, можно только на примере больших проектов и большой команды инженеров. В таком проекте надо долго разбираться (ещё и в каждом по-своему; долго, но не концептуально трудно!), и это тема не короткого и базового университетского образования, а вполне боевая задача.
В этом смысле очень разумная идея — делать школы программирования при фирмах, что часто и делается. Там дают более специальные знания. В них учат тому, что у них получается лучше, в вузах — тому, что у них. Также, разумный будущий инженер будет сам читать книжки про процесс разработки. Работает это в сто раз лучше универских курсов. С математикой, кстати, такой трюк не проходит; ну либо проходит у очень малого числа людей.
Что такое математика для инженеров я понял, в вот что такое инженерия для математики я вообще плохо себе представляю (написание систем компьютерной алгебры?).
К последним двум абзацам существует специальная цитата.
Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, 'not far.' Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects.
Я избавляюсь не от trailing zeroes, а от leading zeroes. Если от них не избавляться, то любое число будет начинаться с бесконечного числа нулей и все рассуждения станут бессмысленными. Естественно, под «первой цифрой» везде понимается первая значащая цифра.
Скорее я бы сказал, что социальное явление состоит в том, что некоторые величины в мире действительно имеют либо одностороннее устойчивое распределение, либо экспоненциально растут. А уже из этого следует математическое явление — первые цифры распределены по закону Бедфорда.
Никак не меняется. Подставив двойку вместо N в формулу в начале статьи, получаем P(1)=log2(1+1/1)=1.
Внезапно, любое двоичное число действительно начинается с единицы.
Да, всё так, причём важно, что если все описанные функции и отношения удовлетворяют перечисленным требованиям, то в графе каждый непомеченный объект встречается один раз (собственно, для того, чтобы имелась возможность это доказать, и нужен этот формализм).
Лямбда-исчисление было придумано для того, чтобы можно было описывать произвольные вычисления на языке, формальное описание которого состоит из нескольких строк.
О столь простом языке гораздо проще вести математически точные рассуждения.
О прихотях программистов на С++ (или других языках) писать код покороче в то время не думали, ибо С++ ещё не был создан. Запись любого алгоритма в чистом лямбда-исчислении как раз безумно громоздка, но зато синтаксис очень прост.
Радиозавод Светлана (что, кстати, означает Световые Лампы Накаливания) находится в одном квартале от места моего жительства. Какой путь лампы этого завода преодолевают, прежде чем я их покупаю, не очень понятно…
У вас даже выпрямитель на ламповом кенотроне — намёк на максимальную аутентичность… как при этом в схеме мог оказаться полупроводниковый стабилизатор?!
Судя по исходной статье, вселенная «плоская» в смысле того, что имеет малую кривизну (и не поверхности, а пространства), а про то, что в одном из измерений она «уже», чем в других, там не сказано.
Хорошо) Тогда возьмём в качестве пространства, ну, например, квадрат (с евклидовой метрикой). Первый шар имеет центр в вершине квадрата (и в этом пространстве представляет собой сектор), центр второго — на некотором небольшом расстоянии от него. Его радиус можно выбрать чуть меньше и он всё равно покроет весь сектор.
Интересный случай, но более интересен ответ на вопрос про два шара:) Правда ли, что можно отвечать так: возьмём ограниченное метрическое пространство (например, сферу или поверхность тора), и выберем в нём два шара радиуса R_1 и R_2 большего, чем максимальное расстояние между точками в этом пространстве? Тогда эти шары совпадут (каждый заполнит всё пространство) и каждый будет лежать внутри другого. И есть ли более красивое решение?
В примере с сеньором, не знающим указанного принципа, похоже, этому сеньору уже ничто не поможет (как не помог бы и курс по разработке ПО), а весь его сильный математический бэкграунд — миф, которым можно обманывать тех, кто сам в этой математике ничего не понимает.
Что там у немцев знаю плохо, зато знаю, что наши инженеры востребованы по всему миру, причём часто потому, что с математикой у них более-менее, в отличие от многих их западных коллег. Но инженерия уходит вперёд, появляются новые концепции, многие из которых имеют сильные математические основания, и которые нужно применять с умом и понимать. Математика также развивается, а вот вузы наши отстают — это повод переработать существующие курсы и выкинуть кучу хлама (взятие 100 производных и интегралов руками на 1 курсе), добавить больше содержательной математики, полезной программисту (дискретная математика, алгоритмы, теория типов). Это проблема вузов, а не математики, что в них учат не тому.
Курсы про процесс разработки в вузах должны быть лишь кратким обзором того, с чем придётся столкнуться инженеру, а не ядром всего обучения, по двум причинам. Во-первых, потому что есть куча куда более важных концепций, которым можно научить в вузе. Во-вторых, потому что учить про то, как строить действительно большие проекты вместе с большой командой инженеров, можно только на примере больших проектов и большой команды инженеров. В таком проекте надо долго разбираться (ещё и в каждом по-своему; долго, но не концептуально трудно!), и это тема не короткого и базового университетского образования, а вполне боевая задача.
В этом смысле очень разумная идея — делать школы программирования при фирмах, что часто и делается. Там дают более специальные знания. В них учат тому, что у них получается лучше, в вузах — тому, что у них. Также, разумный будущий инженер будет сам читать книжки про процесс разработки. Работает это в сто раз лучше универских курсов. С математикой, кстати, такой трюк не проходит; ну либо проходит у очень малого числа людей.
Что такое математика для инженеров я понял, в вот что такое инженерия для математики я вообще плохо себе представляю (написание систем компьютерной алгебры?).
(Martin Newell, Adobe Fellow)
Скорее я бы сказал, что социальное явление состоит в том, что некоторые величины в мире действительно имеют либо одностороннее устойчивое распределение, либо экспоненциально растут. А уже из этого следует математическое явление — первые цифры распределены по закону Бедфорда.
Внезапно, любое двоичное число действительно начинается с единицы.
Да, всё так, причём важно, что если все описанные функции и отношения удовлетворяют перечисленным требованиям, то в графе каждый непомеченный объект встречается один раз (собственно, для того, чтобы имелась возможность это доказать, и нужен этот формализм).
О столь простом языке гораздо проще вести математически точные рассуждения.
О прихотях программистов на С++ (или других языках) писать код покороче в то время не думали, ибо С++ ещё не был создан. Запись любого алгоритма в чистом лямбда-исчислении как раз безумно громоздка, но зато синтаксис очень прост.
Просто один раз рассматриваем его как шар радиуса 1, а другой — как шар радиуса 2.