Чесно говоря как раз про инженеров с 10+ лет стажа и 2-3 подчиненных я не знаю. Могу прикинуть, что SDE I могут получать 100-130k, SDE II до 5 лет опыта 120-150k. Но не стоит мои прикидки слишком серьезно воспринимать :) Кроме того я больше про свое подразделение говорю чем про Амазон в целом.
Думаю что если инженер работает уже давно на Амазоне (более 5 лет), то у него с акций должен быть неплохой доход, учитывая что акции Амазона выросли где-то в 3 раза по сравнению с докризисным уровнем и где-то в 7-8 раз по сравнению с посткризисным уровнем. Но под «доходом с акций» я имею ввиду если он захочет их продать, потому что дивидендов акции Амазона почти не приносят (почти всю прибыль компания инвестирует в рост).
На налоги у меня уходит около 20-22%. Я женат, холостяку выйдет больше, думаю на 3-5%. Сюдя входят federal tax, social security tax и medicare tax. Налога штата на прибиль в Вашингтоне нету.
Предложения были от Амазона в SFBA?
Да, я работаю на Амазоне. На момент принятия предложения о работе должность была SDE I. Акции были расписаны на несколько лет, выдаются частями раз в пол года. Количество акций я думаю сильно зависит от должности и умения торговаться, но скорее-всего для обычных SDE приблизительно ~20-25% от всей компенсации.
Тут еще надо учесть, что акции сильно выросли в последнее время (за последних 1.5 года около +70%). То есть цена акции на момент предложения о работе и цена на момент выпуска могут сильно отличаться.
Насколько я понимаю, этот хак не для избежания распознавания черт лица, а для избежания обнаружения лица на изображении, если программа использует для этого характеристики Хаара (haar-like features). Такие программы классифицирут изображение (то есть говорят лицо это или не лицо) исходя из разниц яркостей участков изображения.
В ACM — да. Но в KPI-Open свои правила, не похожие на ACM. И если в ACM 3 человека на команду это нормально, то в KPI-Open не очень понятно зачем там 3 человека. Дело в том, что в KPI-Open время сдачи задачи считается не с момента начала соревнований, а с момента открытия условия задачи (тоесть скачивания с сервера). И если сначала открыть все задачи, и решать по одной, то баллы за задачи будут очень низкими, даже если все задачи будут решены. Поэтому выходит, что если команда надеется на более-менее хороший результат, то больше одной задачи в один момент времени не можеть решать. И поэтому непонятно зачем там 3 человека в команде.
Вообще на KPI-Open организация самих соревнований там достаточно низкая (очень глючная система тестирования, про которую уже легенды ходят; на последнем KPI-Open второй тур вообще отменили из-за технических проблем и все результаты по первому взяли), а спонсоры и культурная программа нормальные, поэтому туда больше для развлечения ездят, чем для соревнования :)
Насколько я помню, то карма должна быть >=5. У вас уже 10. Попробуйте :)
А насчет определения, то если вы замените «чем ф-ия g(n)» -> «чем ф-ия c*g(n)», тогда действилетьно будет понятно, а то я долго смотрел, и не понимал откуда там «с = с1», если «c» вообще не используется.
Перенесите в блог «Алгоритмы», там статья будет явно не лишней.
В целом статья неплохая и ее полезно почитать для понимания.
Но при этом есть и замечания. Например ваше формальное определение (1.1). Во-первых оно реально взорвало мне мозг, и это при том, что я уже знал формальное определение. Во-вторых, насколько я понимаю, вместо «g(n) >=f(n)» должно быть «с*g(n) >=f(n)». Но это уже и не так важно, поскольку сомневаюся, что многие, кто не знал определение до прочтения статьи, осилят ваш вариант. Думаю, что лучше поменять это определение на другое, например из этой статьи: algolist.manual.ru/misc/o_n.php, или из книги Кормена.
По-моему Вы и со второго раза не так поняли. Или же сам автор до конца не понял, что он смоделировал, если согласился с Вами. Или же я чего-то не понимаю, и сильно туплю :) Но…
Вся соль «новых правил» состоит в том, что события идут подряд, а не сериями по 3, и мы сравниваем ставки с последними тремя выпавшими монетами в цепочке бросков, таким образом результат появления одной ставки зависит от другой ставки.
Поясню на простом примере: у нас есть две ставки (000 и 100). И если первые три монеты будут не 000, то последовательность 000 никогда не выпадет, потому-что перед ней будет стоят 100, и 100 сыграет. А последовательность 100 рано или поздно, но выпадет. Поэтому там вероятность 0.125.
Для других пар подсчет вероятности далеко не такой очевидный. Сходу могу разве-что сказать, что это можно рассматривать, как марковский процес и смоделировать марковскими цепями. Скорее всего для него можно будет найти матрицу перехода «в бесконечность», хотя на 100% не уверен. Но даже если найти и не получится, то посчитать матрицу с очень большой точностю очень быстро получится без проблем.
P.S. Кстати после прочтения топика я тоже ничего не понял, что хотел сказать автор, а только после копания в исходниках понял, что автор смоделировал. Мне только интересно, или автор именно этот процес хотел смоделировать, или же он просто ошибся в алгоритме.
Спасибо за подсказку :) В моей программе я забыл учесть ситуации, когда bruteforce вызывается с параметрами, что последний елемент больше оставшейся суммы, которые можно отсечь, потому-что к решению они не ведут. Если внести небольшие правки, тогда мой перебор будет только правильные варианты сразу искать.
Но все-равно, из-за тормозов вывода, на практике разницы мы почти не увидим.
Ну перебирать тоже надо правильно, что не отменяет самого факта перебора. Я предлагаю перебирать только правильные решения (см. код ниже). Оценка по времени выполнения — приблизительно O(N), где N — размер вывода, поэтому быстрее уже никак не получится. Собственно и оптимизировать тут уже нечего, поскольку главный тормоз здесь — вывод.
#include <iostream>
#include <vector>
#include <cstdio>
using namespace std;
void output(vector <int> &s)
{
// Используем printf для большей скорости вывода по сравнению с cout
for(int i=1; i<s.size(); i++)
printf(" %d", s[i]);
printf("\n");
}
void bruteforce (vector <int> &s, int sumLeft)
{
if (sumLeft == 0)
output (s);
// max(1, s[s.size()-1]) - последний елемент из стека s,
// или 1, если последний елемент равен 0.
for (int i=max(1, s[s.size()-1]); i<=sumLeft; i++)
{
s.push_back(i);
bruteforce(s, sumLeft - i);
s.pop_back();
}
}
int main()
{
int N;
vector <int> s; // Стэк для перебора
cin >> N;
s.push_back(0);
bruteforce(s, N);
return 0;
}
Получить то можно. Но как тогда вы предлагаете их выводить?
Если их вывести перечислением наборов чисел, то тогда в динамике вообще не будет смысла, поскольку при выводе вы все-равно будете все решения перебирать.
Слово «динамика» — это первое, что мелькнуло у меня в голове во время прочтения задачи :) Но увы, у нас не количество спрашивают, а все возможные наборы. Сложно вывести все возможные наборы, не перебирая их.
Эта задачка вообще мало похожа на ACM ICPC-задачку, но условие есть условие, так его автор сформулировал.
Я имел в виду, что оптимизация этого кода без привязки к конкретной задаче не имеет смысла.
А вообще я с вами согласен — алгоритмическая оптимизация рулит :) Но надо при этом быть осторожным, чтобы не изменился результат.
За счет вашей «банальной эрудиции» изменился ответ :) Происходит переполнение long'а.
А вообще не вижу смысла в оптимизации самого алгоритма — это же только синтетический тест. Если бы надо было оптимизировать этот кусок кода, то можно просто написать:
В Питоне надо вставить весь код в функцию. В вашем варианте переменные записываются в массив globals(), что сильно влияет на результат. После таких изменений, код начал работать более, чем в полтора раза быстрее. Ну и range надо заменить на xrange, который и следует использовать в таких циклах. С Psyco, как описано выше в комментах, код будет работать еще быстрее.
def main():
r = 0
for i in xrange(0, 10000):
for j in xrange(0, 10000):
r = (r + (i * j) % 100) % 47
print("answer: ", r)
main()
Не буду отвечать по пунктах, а то размеры постов разрастаются в арифметической прогрессии.
Я с вамы согласен, в том, что язык для начального обучения должен быть простым и человечным. Я не согласен с тем, что именно Питон как раз такой язык и привел вам пример его «нелогичности». Если хотите близкий к идеальному язык обучения — то я не думаю, что вы его найдете среди промышленных языков.
> Но я всё ещё не вижу преимущества в обучении, обусловленного этой строгостью.
Вы внимательно примеры прочли? Или отсутствие ошибки при внешне «кажущейся» одинаковости — это не является преимуществом? Я не говорю, что если мы используем строгий язык мы вообще избавимся от ошибок — но некоторые скрытые ошибки, от которых порой хочется ученику головой об стенку биться, могут ищезнуть. У меня лично были такие ошибки, когда я учил языки типа Python/PHP, что потом оставляло сильное впечетление «коварности» языка.
п. 1-3. Ну совсем не вижу необходимости рассказывать это сразу. Во-первых, если для вас это критично — используйте Pascal, там ничего из этого не надо. Во-вторых — вспомните, что в Python тоже надо будеть пояснять, что такое import, для такой «простой» функции, как, скажем, синус.
п. 4. А на Питоне на той же программе учителю придеться бегать по класу и пробелы расставлять — чем лучше точки с запятой?
п. 5. Во-первых не надо сразу вываливать на ученика все типы данных. Почему просто не сказать, что float — действительное число? Неужели так сложно?
Во-вторых даже вы, судя по тому, что хотя я и спрашивал, но вы нигде так и не ответили, не заметили, что в примере с Python — ошибка! А каково будет ученику? Эта ваша «простота» Питона выливается в состояние ученика «Почему у меня такая простая программа и неправильно работает?». А это состояние куда хуже чем пару строчек, на которые учитель сказал пока-что не обращать внимания.
п. 6-8. Согласен, тут С++ слишком сложен, но я привел С++ просто в качестве языка, который строже чем Питон, и показал в чем преимущество его строгости. Для обучения нужен более строгий, чем Питон язык, с более простым синтаксисом, чем в С++. Тот же Паскаль, например.
Но попробуем вернуться к сути моего поста. Зря я написал пример на С++, надо было выбрать более простой язык со статической типизацией (сообственно С++ действительно сложный язык — и я тоже считаю, что начинать сразу с него не надо), поскольку вы так кинулись мне доказывать что С++ слишком сложен, что забыли ответить на вопрос, ради которого я вообще писал эти примеры — почему ученик на Питоне будет искать ошибку, а у ученика на С++ (подставте сюда любой другой статически типизирований язык) будет все работать?
Думаю что если инженер работает уже давно на Амазоне (более 5 лет), то у него с акций должен быть неплохой доход, учитывая что акции Амазона выросли где-то в 3 раза по сравнению с докризисным уровнем и где-то в 7-8 раз по сравнению с посткризисным уровнем. Но под «доходом с акций» я имею ввиду если он захочет их продать, потому что дивидендов акции Амазона почти не приносят (почти всю прибыль компания инвестирует в рост).
На налоги у меня уходит около 20-22%. Я женат, холостяку выйдет больше, думаю на 3-5%. Сюдя входят federal tax, social security tax и medicare tax. Налога штата на прибиль в Вашингтоне нету.
Да, я работаю на Амазоне. На момент принятия предложения о работе должность была SDE I. Акции были расписаны на несколько лет, выдаются частями раз в пол года. Количество акций я думаю сильно зависит от должности и умения торговаться, но скорее-всего для обычных SDE приблизительно ~20-25% от всей компенсации.
Тут еще надо учесть, что акции сильно выросли в последнее время (за последних 1.5 года около +70%). То есть цена акции на момент предложения о работе и цена на момент выпуска могут сильно отличаться.
Вообще на KPI-Open организация самих соревнований там достаточно низкая (очень глючная система тестирования, про которую уже легенды ходят; на последнем KPI-Open второй тур вообще отменили из-за технических проблем и все результаты по первому взяли), а спонсоры и культурная программа нормальные, поэтому туда больше для развлечения ездят, чем для соревнования :)
А насчет определения, то если вы замените «чем ф-ия g(n)» -> «чем ф-ия c*g(n)», тогда действилетьно будет понятно, а то я долго смотрел, и не понимал откуда там «с = с1», если «c» вообще не используется.
В целом статья неплохая и ее полезно почитать для понимания.
Но при этом есть и замечания. Например ваше формальное определение (1.1). Во-первых оно реально взорвало мне мозг, и это при том, что я уже знал формальное определение. Во-вторых, насколько я понимаю, вместо «g(n) >=f(n)» должно быть «с*g(n) >=f(n)». Но это уже и не так важно, поскольку сомневаюся, что многие, кто не знал определение до прочтения статьи, осилят ваш вариант. Думаю, что лучше поменять это определение на другое, например из этой статьи: algolist.manual.ru/misc/o_n.php, или из книги Кормена.
Вся соль «новых правил» состоит в том, что события идут подряд, а не сериями по 3, и мы сравниваем ставки с последними тремя выпавшими монетами в цепочке бросков, таким образом результат появления одной ставки зависит от другой ставки.
Поясню на простом примере: у нас есть две ставки (000 и 100). И если первые три монеты будут не 000, то последовательность 000 никогда не выпадет, потому-что перед ней будет стоят 100, и 100 сыграет. А последовательность 100 рано или поздно, но выпадет. Поэтому там вероятность 0.125.
Для других пар подсчет вероятности далеко не такой очевидный. Сходу могу разве-что сказать, что это можно рассматривать, как марковский процес и смоделировать марковскими цепями. Скорее всего для него можно будет найти матрицу перехода «в бесконечность», хотя на 100% не уверен. Но даже если найти и не получится, то посчитать матрицу с очень большой точностю очень быстро получится без проблем.
P.S. Кстати после прочтения топика я тоже ничего не понял, что хотел сказать автор, а только после копания в исходниках понял, что автор смоделировал. Мне только интересно, или автор именно этот процес хотел смоделировать, или же он просто ошибся в алгоритме.
Но все-равно, из-за тормозов вывода, на практике разницы мы почти не увидим.
#include <iostream> #include <vector> #include <cstdio> using namespace std; void output(vector <int> &s) { // Используем printf для большей скорости вывода по сравнению с cout for(int i=1; i<s.size(); i++) printf(" %d", s[i]); printf("\n"); } void bruteforce (vector <int> &s, int sumLeft) { if (sumLeft == 0) output (s); // max(1, s[s.size()-1]) - последний елемент из стека s, // или 1, если последний елемент равен 0. for (int i=max(1, s[s.size()-1]); i<=sumLeft; i++) { s.push_back(i); bruteforce(s, sumLeft - i); s.pop_back(); } } int main() { int N; vector <int> s; // Стэк для перебора cin >> N; s.push_back(0); bruteforce(s, N); return 0; }Если их вывести перечислением наборов чисел, то тогда в динамике вообще не будет смысла, поскольку при выводе вы все-равно будете все решения перебирать.
Эта задачка вообще мало похожа на ACM ICPC-задачку, но условие есть условие, так его автор сформулировал.
А вообще я с вами согласен — алгоритмическая оптимизация рулит :) Но надо при этом быть осторожным, чтобы не изменился результат.
А вообще не вижу смысла в оптимизации самого алгоритма — это же только синтетический тест. Если бы надо было оптимизировать этот кусок кода, то можно просто написать:
:)
def main(): r = 0 for i in xrange(0, 10000): for j in xrange(0, 10000): r = (r + (i * j) % 100) % 47 print("answer: ", r) main()beslov книга
Я с вамы согласен, в том, что язык для начального обучения должен быть простым и человечным. Я не согласен с тем, что именно Питон как раз такой язык и привел вам пример его «нелогичности». Если хотите близкий к идеальному язык обучения — то я не думаю, что вы его найдете среди промышленных языков.
> Но я всё ещё не вижу преимущества в обучении, обусловленного этой строгостью.
Вы внимательно примеры прочли? Или отсутствие ошибки при внешне «кажущейся» одинаковости — это не является преимуществом? Я не говорю, что если мы используем строгий язык мы вообще избавимся от ошибок — но некоторые скрытые ошибки, от которых порой хочется ученику головой об стенку биться, могут ищезнуть. У меня лично были такие ошибки, когда я учил языки типа Python/PHP, что потом оставляло сильное впечетление «коварности» языка.
п. 4. А на Питоне на той же программе учителю придеться бегать по класу и пробелы расставлять — чем лучше точки с запятой?
п. 5. Во-первых не надо сразу вываливать на ученика все типы данных. Почему просто не сказать, что float — действительное число? Неужели так сложно?
Во-вторых даже вы, судя по тому, что хотя я и спрашивал, но вы нигде так и не ответили, не заметили, что в примере с Python — ошибка! А каково будет ученику? Эта ваша «простота» Питона выливается в состояние ученика «Почему у меня такая простая программа и неправильно работает?». А это состояние куда хуже чем пару строчек, на которые учитель сказал пока-что не обращать внимания.
п. 6-8. Согласен, тут С++ слишком сложен, но я привел С++ просто в качестве языка, который строже чем Питон, и показал в чем преимущество его строгости. Для обучения нужен более строгий, чем Питон язык, с более простым синтаксисом, чем в С++. Тот же Паскаль, например.
Но попробуем вернуться к сути моего поста. Зря я написал пример на С++, надо было выбрать более простой язык со статической типизацией (сообственно С++ действительно сложный язык — и я тоже считаю, что начинать сразу с него не надо), поскольку вы так кинулись мне доказывать что С++ слишком сложен, что забыли ответить на вопрос, ради которого я вообще писал эти примеры — почему ученик на Питоне будет искать ошибку, а у ученика на С++ (подставте сюда любой другой статически типизирований язык) будет все работать?