Вот это советы…
Матрицы 44 нету. И из чего состоит нету
Вращения по осям нету
Матрица камеры-взгляда, модели, проекции неу
Определение угла между векторами нету. С помощью atan2 и прочие.
Что cos/sin считает в радианах нету
Основных законов движения v = v0 + att/2 и p = p0 + vt нету
Преобразование local2global и global2local нету
Движение по сплайну и анимации нету
Интерполяции нету
Единичная, Обратная, Транспонированная матрица нету
Видел такой шорт-лист советов. Довольно дельный.
1) Вы не сможете запоминать лучше, чем уже умеете. Если будете пытаться, то возможно перегорание. Все техники ведут, обычно, к не-ухудшению уже имеющейся скорости. Той которая развилась в школе или получена при рождении.
2) Учите столько, сколько выучивается за 2-3 часа. Остальное перегорит по «кривой забывания».
3) Повторяйте перед сном и утром (как проснулись).
4) Пишите (по возможности) конспект.
5) Устраивайте себе недельный экзамен (например, в воскресенье).
6) Больше гуляйте. Это помогает переосмыслить материал.
7) Избегайте тяжелую пищу. Она расслабляет и вы теряете концентрацию.
8) Подзубрили, не значит выучили. Материал (если он новый) может усваиваться в течении недели-двух.
Это не совсем так. Чужая глупость может очень сильно сказаться на таком терпеливом пареньке. Очень не много компаний, где вы можете сказать, что ваш менеджер плохой. Это менеджер скажет, что вы плохой.
Менеджеры это люди, которых нанимает начальство чтобы не общаться с этими вашими программистами.
Менеджер не заставляет программиста работать, но они любят так считать. Работать заставляет нужда есть и ночевать.
Нет, не верно. Еслибы он не работал на результат, то его бы уволили. Он просто хорошо работал. Мы не знаем его скилл. Может он просто обычный среднечок. Не зря же его посадили писать легаси код, а не будущее всея гугла. Он мго просто сидеть, хорошо работать и получать свои деньги, премии и прочее. Хочешь больше — работай эффективнее для компании. Просто хороший челик — сиди пиши легаси.
Это нужно, когда у вас данных под миллиард приходит в функцию.
Например, вы пишите систему для Убер. Она определяет k ближайших к вам заказов. Нужно чтобы было ок на 100 000+. Так, для прикола. Типа ищем по всему миру. Такой тест-кейс. N*N не прокатит. Итого вы делаете квик селект по k, а потом ищите за N тех, кто ближе чем k. И получаете линейную сложность.
Фейсбук ищет обоими способами. Асинхронно. Но BFS работает быстрее и лучше. Тупа эмпирически на больших данных. Например, когда нужно найти кого-то в друзьях всех друзей. Всё зависит от данных и ситуации.
Поэтому есть 4 нерекурсивных обхода: preorder, inorder, postorder, BFS. И с ними нужно уметь работать из головы, сходу.
Ваши аргументы очень слабые, реально.
Если кто выше не понимает смысл таких вопросов, то вот объяснение.
Если вы в жизни не писали с нуля системы на миллионы терабайт данных, то и не поймете зачем это нужно. Даже если взять Кормена, то это ничто. Кормен очень поверхностная книга. В Кормене даже SuffixTree/SuffixArray нету. Тоесть такой человек не напишет эффективный поиск. Инвертированного индекса тоже нет. Поиска k ближайших точек за O(N) тоже не напишет. Как говорил мой знакомый из гугла:«Если хотите понять сущность алгоритмов, то увеличите число данных до миллиарда на 1 машине. И придумайте эффективный способ работы». У вас сразу полезет наружу всё. И коллизии в хешах. И поиск в ширину-глубину. И вообще всё перестанет работать. А с этим нужно еще как-то жить и дружить.
Загуглите
Distributed Computing Principles, Algorithms, and Systems
Ajay D. Kshemkalyani and Mukesh Singhal
или
Principles of Distributed Computing
Roger Wattenhofer
Вся проблема в том, что программировать не стало проще или сложнее. Программировать стало так же. Языки упрощаются. Но данные растут быстрее. Итого, для каких-нибудь VK или Одноклассников нужно писать на Java так, как писали на С++ в 90е-2000е. Теперь сервисы должны держать много-миллионный онлайн. Везде потоки и масштабируемость. Как всегда, в принципе. Только потоков-серверов не 5, а 500000. Программирование не стало проще, как этого ожидали.
1) Консоли
2) placement_new/memory pool
3) алокации для мелких и больших объектов могут делаться поразному
Тоесть я согласен с тем, что его не пишут руками по 100 раз на проект. Окей, по 1 разу на платформу пишут. Раз в 7-10 лет.
Матрицы 44 нету. И из чего состоит нету
Вращения по осям нету
Матрица камеры-взгляда, модели, проекции неу
Определение угла между векторами нету. С помощью atan2 и прочие.
Что cos/sin считает в радианах нету
Основных законов движения v = v0 + att/2 и p = p0 + vt нету
Преобразование local2global и global2local нету
Движение по сплайну и анимации нету
Интерполяции нету
Единичная, Обратная, Транспонированная матрица нету
1) Вы не сможете запоминать лучше, чем уже умеете. Если будете пытаться, то возможно перегорание. Все техники ведут, обычно, к не-ухудшению уже имеющейся скорости. Той которая развилась в школе или получена при рождении.
2) Учите столько, сколько выучивается за 2-3 часа. Остальное перегорит по «кривой забывания».
3) Повторяйте перед сном и утром (как проснулись).
4) Пишите (по возможности) конспект.
5) Устраивайте себе недельный экзамен (например, в воскресенье).
6) Больше гуляйте. Это помогает переосмыслить материал.
7) Избегайте тяжелую пищу. Она расслабляет и вы теряете концентрацию.
8) Подзубрили, не значит выучили. Материал (если он новый) может усваиваться в течении недели-двух.
Менеджер не заставляет программиста работать, но они любят так считать. Работать заставляет нужда есть и ночевать.
Например, вы пишите систему для Убер. Она определяет k ближайших к вам заказов. Нужно чтобы было ок на 100 000+. Так, для прикола. Типа ищем по всему миру. Такой тест-кейс. N*N не прокатит. Итого вы делаете квик селект по k, а потом ищите за N тех, кто ближе чем k. И получаете линейную сложность.
У гугла проблемы с количеством данных? Да, их слишком много. И с этим нужно что-то делать.
Поэтому есть 4 нерекурсивных обхода: preorder, inorder, postorder, BFS. И с ними нужно уметь работать из головы, сходу.
Кстати, DarkTiger, когда думаете догонять Амазон какой-нибудь?
Если кто выше не понимает смысл таких вопросов, то вот объяснение.
Если вы в жизни не писали с нуля системы на миллионы терабайт данных, то и не поймете зачем это нужно. Даже если взять Кормена, то это ничто. Кормен очень поверхностная книга. В Кормене даже SuffixTree/SuffixArray нету. Тоесть такой человек не напишет эффективный поиск. Инвертированного индекса тоже нет. Поиска k ближайших точек за O(N) тоже не напишет. Как говорил мой знакомый из гугла:«Если хотите понять сущность алгоритмов, то увеличите число данных до миллиарда на 1 машине. И придумайте эффективный способ работы». У вас сразу полезет наружу всё. И коллизии в хешах. И поиск в ширину-глубину. И вообще всё перестанет работать. А с этим нужно еще как-то жить и дружить.
Загуглите
Distributed Computing Principles, Algorithms, and Systems
Ajay D. Kshemkalyani and Mukesh Singhal
или
Principles of Distributed Computing
Roger Wattenhofer
Ну как читается? Легко?
Вы видели код библиотеки из какого-нибудь Facebook? Для работы, например с распределенными графами? Или что-то иное? Как средний индус будет писать тесты для вот этого:
github.com/facebook/rocksdb/blob/master/db/compaction_job.cc#L683
2) placement_new/memory pool
3) алокации для мелких и больших объектов могут делаться поразному
Тоесть я согласен с тем, что его не пишут руками по 100 раз на проект. Окей, по 1 разу на платформу пишут. Раз в 7-10 лет.