То же с сортировкой — зачем знать помнить внутреннее устройство QuickSort, если в любом приличном языке он уже реализован в библиотеке?
Например затем, чтобы суметь написать многопоточную сортировку, которой нету в известных мне фреймворках. Или суметь написать неполный QuickSort если из массива в миллион нужно найти Top 100, или написать QuickSort в виде StateMachine, потому что компаратор — это пользователь веб-страницы.
Прошу обратить внимание, что это не абстрактные примеры, все это мне реально приходилось делать.
А Senior Developer вы не считаете профессиональным развитием? Senior это не обязательно руководящие обязанности. В моем понимании Senior это человек за которым не надо следить. Которому можно дать задачу, и расслабиться, потому что будешь уверен, что он все сделает как надо, без квадратичных алгоритмов, с элегантной архитектурой классов и все это без Code Review. К сожалению, набрать команду целиком из Senior'ов удовольствие дорогое, как по зарплате, так и по времени на поиск. Поэтому если речь идет о Regular/Junior уровне, то преимущество будет у тех, кого есть надежда дорастить до уровня Senior. И еще большее преимущество у тех, кто способен учиться сам.
Правда, я говорю с позиции Research and Development. Возможно, в сфере SL3 будет другой подход.
Отвечу с точки зрения руководителя, набирающего людей себе в команду.
Представим двух кандидатов, один через год работы с Java уже Regular Developer, а второй через 5 лет в Java все еще Regular Developer (по ответам, а не по должности). Естественно, я предпочту первого.
Или от человека с кучей сертификатов от Oracle/Sun итд я будут ожидать соответсвующего уровня ответов. Если взять двух человек, одного с сертификатами, а второго без, одинково не блестяще отвечающих на одинаковые вопросы — то я возьму того, у кого нет сертификатов — его незнание хотя бы можно объяснить.
Ваш многолетний опыт, сдвигает ожидание работодателей, вынуждая предъявлять к Вам более высокие требования. Чем выше ожидания, тем сильнее разочарование. Junior не могущий ответить на вопрос про сортировку производит менее негативное впечатление, чем Senior не способный дать ответ на такой же вопрос.
Гугль спрашивает в таком же ключе. Яндекс и Гугль оперируют терабайтами данных, сотнями тысяч запросов в секунду. В таких условиях знания эффективных алгоритмов гораздо важнее знаний конкретного языка и платформы.
Приведу пример.
Данные взяты из ипотечного калькулятора одного из банков.
Сравним два кредита на сумму 2 Млн
1. 5 лет, ставка 13.35%, платеж 45 тыс в месяц. Переплата 5*12*45000 — 2000000 =700.000
2. 30 лет, ставка 13.95, платеж 23 тыс в месяц. Переплата 30*12*23000-2000000=6 280 000
Естественно если второй кредит выплачивать строго по графику, то переплата будет жуткой. Однако, если вы собираетесь платить вперед графика, то можно очень сильно сократить переплату.
Как известно, при аннуитетном способе оплаты, первые платежи почти целиком идут на погашение процентов по кредиту.
Если вы в состоянии платить 45 тыс в месяц, то лучше взять кредит на 30 лет с платежом в 23 тыс, но платить по 45. Тогда лишние 23 будут идти в погашение основного долга. Что по идее должно заставлять банк делать перересчет ежемесячных платежей.
Возможно переплата будет чуть больше чем если брать кредит на 5 лет, но в обмен вы получаете страховку от неожиданностей по жизни типа потери работы, болезни итд — обязательный то платеж в два раза меньше.
Суммарная премия за риск выше. Но ежемесячный обязательный платеж меньше.
Т.е. грубо говоря, можно взять кредит на 30 лет и платить 20к в месяц. А можно взять на 10 лет и платить 40к в месяц.
Даже если ты можешь платить 40к, лучше подписаться на кредит обязательный платеж 20к. Но платить 40к… Лишние 20 пойдут в погашение основного долга.
Идея в том, чтобы подстраховать самого себя, и оградить от больших платежей когда это неудобно.
Сегодня ты можешь платить 40к, а завтра ты заболел, уволился, родил ребенка… И внезапно 40к уже неподъемный платеж.
Как Вам ответили ниже, как правило, для таких задач достаточно одного скрытого слоя,
а за счет рекурретности нейроны знают, как о текущих входных данных, так и о своем преыдущем состоянии.
Рекуррентный слой, по сути, это State Machine, которая переходит из состояния в состояние под действием входных сигналов.
По своему опыту знаю, что рекуррентная нейросеть вполне может научиться выдавать периодический сигнал даже с одним скрыты слоем…
Однажды делал нечто подобное, только генетикой подбирал параметры типа сила, ловкость, здоровье итд. И тоже рулили берсерки с большой ловкость, большим damage и почти без защиты и с одним хит-поинтом
Кстати насчет обезболивания… Чисто теоретически, можно использовать штуку на подобие Транскраниальной магнитной стимуляции http://ru.wikipedia.org/wiki/Транскраниальная_магнитная_стимуляция на спинном мозге, чтобы заблокировать нервные сигналы… Если конечно переменное магнитное поле их наоборото не стимулирует.
Да, рефакторинг выходил за пределы возможностей IDE. Например была одна структура, которая умела себя строить по определенному образцу. Мне нужно было сделать ее более пассивной — только для хранения данных, а построение доверить классу сборщику. Тесты у меня довольно высокоуровневые — тестируют в основном контракты высокоуровневых интрефейсов, которые не менялись, переписывать их почти не пришлось, но пара тестов свалилась из за ошибок при переносе.
Плюс еще в одном месте пришлось переписать MergeSort на QuickSort — вроде рефакторинг, с сохранением внешного контракта, а IDE ничем помочь не может. Тут тоже тест помог отловить баги.
Например затем, чтобы суметь написать многопоточную сортировку, которой нету в известных мне фреймворках. Или суметь написать неполный QuickSort если из массива в миллион нужно найти Top 100, или написать QuickSort в виде StateMachine, потому что компаратор — это пользователь веб-страницы.
Прошу обратить внимание, что это не абстрактные примеры, все это мне реально приходилось делать.
Правда, я говорю с позиции Research and Development. Возможно, в сфере SL3 будет другой подход.
Представим двух кандидатов, один через год работы с Java уже Regular Developer, а второй через 5 лет в Java все еще Regular Developer (по ответам, а не по должности). Естественно, я предпочту первого.
Или от человека с кучей сертификатов от Oracle/Sun итд я будут ожидать соответсвующего уровня ответов. Если взять двух человек, одного с сертификатами, а второго без, одинково не блестяще отвечающих на одинаковые вопросы — то я возьму того, у кого нет сертификатов — его незнание хотя бы можно объяснить.
Ваш многолетний опыт, сдвигает ожидание работодателей, вынуждая предъявлять к Вам более высокие требования. Чем выше ожидания, тем сильнее разочарование. Junior не могущий ответить на вопрос про сортировку производит менее негативное впечатление, чем Senior не способный дать ответ на такой же вопрос.
Данные взяты из ипотечного калькулятора одного из банков.
Сравним два кредита на сумму 2 Млн
1. 5 лет, ставка 13.35%, платеж 45 тыс в месяц. Переплата 5*12*45000 — 2000000 =700.000
2. 30 лет, ставка 13.95, платеж 23 тыс в месяц. Переплата 30*12*23000-2000000=6 280 000
Естественно если второй кредит выплачивать строго по графику, то переплата будет жуткой. Однако, если вы собираетесь платить вперед графика, то можно очень сильно сократить переплату.
Как известно, при аннуитетном способе оплаты, первые платежи почти целиком идут на погашение процентов по кредиту.
Если вы в состоянии платить 45 тыс в месяц, то лучше взять кредит на 30 лет с платежом в 23 тыс, но платить по 45. Тогда лишние 23 будут идти в погашение основного долга. Что по идее должно заставлять банк делать перересчет ежемесячных платежей.
Возможно переплата будет чуть больше чем если брать кредит на 5 лет, но в обмен вы получаете страховку от неожиданностей по жизни типа потери работы, болезни итд — обязательный то платеж в два раза меньше.
Т.е. грубо говоря, можно взять кредит на 30 лет и платить 20к в месяц. А можно взять на 10 лет и платить 40к в месяц.
Даже если ты можешь платить 40к, лучше подписаться на кредит обязательный платеж 20к. Но платить 40к… Лишние 20 пойдут в погашение основного долга.
Идея в том, чтобы подстраховать самого себя, и оградить от больших платежей когда это неудобно.
Сегодня ты можешь платить 40к, а завтра ты заболел, уволился, родил ребенка… И внезапно 40к уже неподъемный платеж.
а за счет рекурретности нейроны знают, как о текущих входных данных, так и о своем преыдущем состоянии.
Рекуррентный слой, по сути, это State Machine, которая переходит из состояния в состояние под действием входных сигналов.
По своему опыту знаю, что рекуррентная нейросеть вполне может научиться выдавать периодический сигнал даже с одним скрыты слоем…
Можел лучше просто скрытый слой сделать рекуррентным?
Плюс еще в одном месте пришлось переписать MergeSort на QuickSort — вроде рефакторинг, с сохранением внешного контракта, а IDE ничем помочь не может. Тут тоже тест помог отловить баги.