Какое-либо значение программисту для понимания ЦП в большей глубине?
Прежде всего, в следующий раз приведите воспроизводимый пример. Вы можете легко сделать это, например, с помощью dput(Male_adult_passenger).
В любом случае эта ошибка возникает из-за использования присваивания Survived = 'Yes' вместо сравнения Survived == 'Yes'.
Попробуйте исправить это, но я думаю, что count будет хлопотно. Если это не сработает, попробуйте:
Male_adult_passenger %>%
group_by(Class) %>%
summarise(S_rates = sum(Survived == 'Yes')/n())
Если это все еще не работает, предоставьте образец, отредактировав свой вопрос, и я буду рад его изучить.
11 ответов
Языки программирования являются виртуальными машинами. C, C#, Фортран, Основной, и т.д. является центральными процессорами в и себя, хотя портативный. Они говорят, что, если Вы программируете на Фортране, Вы программируете на своего рода машине Фортрана. Если Вы программируете на C, Вы программируете на своего рода машине C. Существует даже язык, реализованный на аппаратном уровне, LISP.
Существует даже шутка над C. Язык программирования C: язык, который комбинирует всю элегантность и питание ассемблера со всей удобочитаемостью и пригодностью для обслуживания ассемблера.
Можно достигнуть каждого укромные уголки и трещины указателей, ручного управления памятью, инструкций, указателей на функцию, и т.д. с языками как C или C# с небезопасной опцией.
Вы не пропускаете что-то, даже если Вы не знаете ЦП подробно.
Но если Вы действительно хотите сжать производительность из своей программы, существует действительное значение в знании, что идет под капотом, изучите ЦП/ассемблер, если программа заслуживает его.
Я узнал вполне немного о низкоуровневом программировании, и я думаю, что это было чрезвычайно полезно в каждом бите кода, который я пишу. Даже высокоуровневые языки имеют некоторую версию, скажем, основных примитивов синхронизации (взаимные исключения/блокировки, условия, семафоры); они все еще должны читать из диска или из сетевой платы; они все еще должны скопировать байты с одного места в памяти другому, и так далее... точка, то, что Вы используете высокоуровневый язык, не означает, что бесполезно знать, как те вещи работают. Если у Вас есть понимание того, как компьютер функционирует на самом низком уровне, можно всегда применять то знание для написания более эффективного и/или менее склонного к ошибке кода независимо от того, насколько абстрактный платформа. Знание низкоуровневых операций может даже учить Вам вещи, что Вы никогда, возможно, не учились иначе - нет никакого лучшего способа изучить, как правильно использовать что-то как взаимное исключение, чем должным быть реализовать то. (Хорошо, возможно, это немного преувеличено, но Вы понимаете мою мысль, я надеюсь),
Нижняя строка, я сказал бы, что да, это - абсолютно хорошая идея для программистов на всех уровнях абстракции для приобретения знаний об основных принципах. Но я не думаю, что это - обязательно такая хорошая идея запуститься с основных принципов. Программы на уровне ассемблера известно трудно понять, и я думаю, пытаясь навязать, это на новичке к программированию, просто, вероятно, обескуражит его. Я упомянул, что понимание основных операций поможет Вам написать более эффективный и/или меньше подверженного ошибкам кода, но, конечно, не необходимо написать код вообще. Так, по-моему, большинство людей, вероятно, сделало бы лучше всего запуск где-нибудь в середине, где они могут все еще фиксироваться на знакомых понятиях как объекты при знакомстве с процессом кодирования. После некоторого опыта в той области материал ЦП является справедливой игрой ;-)
Это идет обоими путями.
Например, много людей, которые запустились в более высоком уровне, понятия не имеет, почему сдвиги настолько быстрее, чем умножение и разделение или влияние ветвления, и т.д.
В результате они часто пишут код, который медленнее, но легче для среднего человека понять. (Обратите внимание, что для некоторых приложений, идя быстрее более важно, чем быть легким понять),
Кто-то, который имеет понимание того, что продолжается негласно (сколько берут такты различные операции, как конвейер ЦП работает, влияние кэширования, и т.д.) может часто писать код, который является очень быстрым, но может быть трудным для многих людей понять/поддержать. (Это особенно трудно в приложениях, где "оптимизация" не обладает никаким заметным преимуществом, и пригодность для обслуживания более важна),
Лично я чувствую, что знание, "что продолжается ниже", по крайней мере, дает мне способность знать влияние решений, которые я принимаю.
Честно, в этой точке, я не возражаю оставлять много низкоуровневых деталей/оптимизации до компилятора. Это, вероятно, делает лучшее задание, чем я был бы так или иначе:]
Я ожидаю, что мой доктор будет знать, как моя основа работает (но не обязательно смочь выполнить кардиохирургию), я ожидаю, что мой механик будет знать, как мой механизм работает (но не обязательно смочь создать механизм), и я ожидаю, что мой программист будет знать, как ЦП работает (но не обязательно смочь создать ЦП, или запишите корпоративное приложение в блоке. Однако обсуждение кэша ЦП или видящий некоторый ассемблерный код не должно отправлять его работающий за выступами ни один).
Мы - профессионалы. Мы, как ожидают, будем знать, как вещи работают "под капотом", даже если мы обычно не работаем на том уровне.
Существует все еще сообщество программистов, которые действительно изучали тот путь.
Нет никаких дебатов в моем уме, к которому наличие осведомленности об аппаратных средствах, с которыми Вы работаете, может дать Вам большое понимание как лучше всего для написания кода для тех аппаратных средств. Однако часть самого определенного для аппаратных средств кода я встретился (и записал), также было наименее читаемым и удобным в сопровождении.
Я думаю, что для программирования в целом, это не чрезвычайно важно. Однако, после того как Вы входите в производительность критические области, это - ключевой навык, чтобы иметь.
Высокоуровневые языки предназначены для абстракции нас от архитектуры низшего уровня системы, мы продолжаем работать. В то время как это не означает, что архитектурная информация должна быть проигнорирована, это действительно означает, что значение этой информации уменьшено. Архитектурно-зависимое знание может действительно помочь Вам усилить систему по-разному, но обычно эти пути включают обход абстракций, наши высокоуровневые языки предусматривают нас. Является ли это хорошей вещью, или не я уезжаю Вам.
Я думаю, что оценка базовой архитектуры полезна для любого программиста, и так слишком много абстракции может быть плохой вещью.
Я не знаю, является ли обрабатывание от низкого уровня хорошей идеей, поскольку современные центральные процессоры очень сложны - я изучил Visual Basic, сопровождаемый Java, но так рад, что изучил C и некоторые послесловия ассемблеров, как это помогло мне к производительности записи критический код.
Это - один из тех вопросов, где нет никакого ответа.
Практически, нет, там не полезен для этого, если Вы не делаете что-то очень определенное (в этом случае, Вы дали бы намного более конкретный вопрос).
Теоретически, и это - аргумент, который все будет использовать противопоставление, да, всегда хорошо знать (... в значительной степени все)..., пока это не сводится к программированию только с единицами и нулями :)
Если бы Вы запустили на самом низком уровне, Вы, вероятно, никогда не занимались бы этим 'высоким' уровнем - это - точно причина, почему языки 'высокого уровня' были записаны во-первых.
"Если мы запустили на уровне процессоров и преподавали оттуда, что мы могли бы найти, что можем понять, как управлять им на легче высоком уровне".
Ложь.
Я начал программировать в 70-х, где абсолютно необходимо было знать, как аппаратные средства работали, потому что выбором был Фортран (или Веселый) по сравнению с ассемблером.
Теперь я использую Java и Python на - хорошо - у меня нет действительно идеи. У меня есть Ноутбук Dell, MacBook, iMac и сервер, который я не могу положительно определить.
Они могли иметь процессоры Intel или PowerPC или - хорошо - я думаю, что сервер является 64-разрядным, но я не знаю который вид.
Знание много (реальная партия) о некоторых процессорах не помогло. Знание ничего о современных процессорах не препятствует.
Программное обеспечение получает знание. Определенная часть аппаратных средств имеет мало общего со знанием, полученным программным обеспечением.
Это вселило мне больше веры о том, что я делал и дал мне знание о том, когда сфокусироваться на производительности или пригодности для обслуживания (почти в 99% ситуаций, я выбираю последний :)
Я начал программировать в Основном (на перфоленте!), но одно из лучших событий в моей ранней карьере состояло в том, чтобы работать во встроенных системах, пишущий C и программах на языке ассемблера и часто кросс-компиляции. Знание, что делают аппаратные средства, как высокоуровневый язык отображается на ЦП, и так далее очень полезно. Это, конечно, помогает Вам понять указатели, указатель arithmentic, выравнивание структуры данных, расширение знака, и даже производительность программного обеспечения и поведение операционной системы, когда Вы понимаете аппаратные средства до некоторой степени.