Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, Abalak, Вы писали:
A>>Я вот только в одной конторе слышал про овертаймы ради идеи, в остальных никто не заставлял если работа сделана. Вот на последнем месте сразу предупредили, что овертаймы не оплачиваются, если это не выходные (тогда в двойном размере) и что изредка необходимость возникает (пока возникла пару раз по часу за два месяца). И отказываться от этой работы из-за такой гипотетической возможности было бы просто глупо, т.к. другие плюшки очень жирные. N_>Если они редкие ( час за два месяца) — то вчем проблема конторе заплатить эти копейки и не иметь друг другу мозг по поводу овертаймов. Если непременно хочет зарание оплатить — то можно оговорить их предельный размер( например, 5 часов в месяц уже включено в ЗП, все что сверху — дополнительно оплачивается).
Так почему бы не считать, что эти пять часов уже включены. Что за меркантильность. Понимаешь, я встаю с утра и мне лень ехать на работу или нужно в середине дня куда-нибудь сходить. Я пишу емейл, что дескать сегодня работаю из дома и скорее всего буду отсутствовать с 2-х до 4-х, на что в ответ получаю простое ок. И никто ничего не вычитает и вообще не считает. В конце недели в таймшите все равно стоит 40 часов и деньги на счету за 40 часов. Т.е. как бы договоренность, что я перерабатываю когда надо делу и ухожу, когда надо мне. Я даже предположить не могу будут цифры реально отработанных часов больше или меньше обговоренных 40 в неделю и вообще не парюсь по этому поводу. Имея работу которая мне нравится, в хорошей команде, удобно расположенной и хорошо оплачиваемой мне на фиг не сдалось сжирать себя из нутри мыслью, что меня используют как раба. Свободный человек в свободной стране, потому что не забиваю себе голову всякой фигней.
N_>Проблема какраз в том, что работодатели частенько хотят заставить дополнительно бесплатно поработать человека, опилируя к выделенному. Хотя то что запланированная работа не зделана за рабочий день в большестве случаев является не виной работника.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Abalak, Вы писали:
A>>Ну рассказывай тогда . Я ответил на твой вопрос точнее некуда. Или ты хотел увидеть реализацию дженерик мемоайзера? E>В Java это делается на аннотациях, в .Net забыл как называется, но синтаксис кажись в прямоугольных скобочках. Через аспекты, АОП в .NET быть просто обязано, язык богаче гораздл. Хотя, в .NET это необязательно делать, учитывая наличие делегатов и более подходящих конструкций, можно все гораздо прозрачнее сделать (теоретически, практики, увы, не имею).
Что-то вроде?
var fibonacci = Mem<BigInteger, BigInteger>(
fib =>
n =>
{
Console.WriteLine("Fib {0}", n);
return n == 0
? 0
: n == 1
? 1
: fib(n - 1) + fib(n - 2);
}
);
var q = from x in new[] {0, 1, 2, 10, 1000, 5000}
select new { n = x, fib = fibonacci(x)};
foreach (var v in q)
Console.WriteLine(v);
Mem пока останется за кадром. Словарь в ней.
E>А далее я хотел бы услышать о том, как можно написать такой мемоайзер, который при вызове рекурсивно не будет вызывать переполнение стека.
Нужно посчитать 1М? Что бы не сломать стек — надо считать последовательно 1..1М и ничего переписывать не надо
Что бы не сломать память — нужно переписать мемоайзер так,что бы он запоминал не все результаты, а лишь последние K.
fib(1M) я посчитал минут за 5-6. Результат тут писать не буду. Длинный.
Серьезно посчитал, но подход не вполне серьезный.
Если серьезнее, то рекурсивный вызов в C# стек отъедает практически без вариантов (зависит от множества факторов, в том числе платформы). Полагаю речь идет о записи, которая близка к рекурсивной, но таковой не является, как и формально в коде выше.
Если перекрутить код метода что бы прийти к линейной рекурсии — то можно и избавиться от поедания стека легко. В исходном виде — не уверен.
З.Ы. fib(0) должен давать 0.
Здравствуйте, Abalak, Вы писали:
A>Свободный человек в свободной стране, потому что не забиваю себе голову всякой фигней.
Все так, но делай скидку на то кто создал топик и что он имел ввиду Украину, а не штаты.
Может там (на Украине) отношения между работодаляеми и работниками в целом настолько фиговые,
что VovkaMorkovka вынужден сразу стучать по столу и диктовать свои условия.
Может там попытка договориться и найти компромисс воспринимается как слабость и работодатель сразу на галеры посылает...
Фиг его знает как оно там и почему VovkaMorkovka не может не забивать себе голову кажущейся тебе фигней
Здравствуйте, Nik_1, Вы писали:
N_>Проблема какраз в том, что работодатели частенько хотят заставить дополнительно бесплатно поработать человека, опилируя
Здравствуйте, Abalak, Вы писали:
E>>А далее я хотел бы услышать о том, как можно написать такой мемоайзер, который при вызове рекурсивно не будет вызывать переполнение стека.
A>В .NET на делегатах с тейл коллами. Написать не проси за разумное время не напишу, а в реальной жизни пойду в гугл за готовой реализацией.
ребята, может я что-то не понимаю? и с мемоизацией и без неё там будет всего 1000 уровней рекурсии, т.е. несколько килобайт стёка
просто без мемоизации вызовы образуют бинарное дерево глубины 1000, т.е. всего там будет порядка 2^1000 элементов, а при мемоизации мы налево пройдёмся на полную глубину, а направо будем сразу возвращаться, беря готовые значения из хеш-таблицы
Здравствуйте, Abalak, Вы писали:
A>Здравствуйте, elmal, Вы писали:
E>>А далее я хотел бы услышать о том, как можно написать такой мемоайзер, который при вызове рекурсивно не будет вызывать переполнение стека.
A>В .NET на делегатах с тейл коллами. Написать не проси за разумное время не напишу, а в реальной жизни пойду в гугл за готовой реализацией.
Что за делегаты с тейл коллами? Кроме того, тейл коллы требуют изменения кода.
Здравствуйте, samius, Вы писали:
S>Если перекрутить код метода что бы прийти к линейной рекурсии — то можно и избавиться от поедания стека легко. В исходном виде — не уверен.
А вот по поводу поедания стека есть у меня одна мысля интересная. Я сам пока не реализовал, если что, не было необходимости. Суть в том, что в мемоизаторе каждый вызов оригинального неизменного метода делать на вершине стека в другом потоке. И делать это все через ленивые вычисления. Вначале таким образом сформировать дерево вызовов (без дублирований), ну а затем пробежаться по этому дереву от начала до конца. А если сделать — получится автоматическое разворачивание любого рекурсивного алгоритма, по идее очень круто должно быть, пытался я гуглить подобные решения, к своему удивлению не нашел. И вроде не так уж это и сложно, за несколько дней написать реально. Конечно накладные расходы на взаимодействие потоков неслабо ресурсы пожрут, но зато можно практически неограниченную рекурсию городить, без собственной эмуляции стека.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Abalak, Вы писали:
E>>>А далее я хотел бы услышать о том, как можно написать такой мемоайзер, который при вызове рекурсивно не будет вызывать переполнение стека.
A>>В .NET на делегатах с тейл коллами. Написать не проси за разумное время не напишу, а в реальной жизни пойду в гугл за готовой реализацией.
BZ>ребята, может я что-то не понимаю? и с мемоизацией и без неё там будет всего 1000 уровней рекурсии, т.е. несколько килобайт стёка
Я так понимаю мы просто углубились в сугубо теоретические дебри — "а что если стек закончится".
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>Если перекрутить код метода что бы прийти к линейной рекурсии — то можно и избавиться от поедания стека легко. В исходном виде — не уверен. E>А вот по поводу поедания стека есть у меня одна мысля интересная. Я сам пока не реализовал, если что, не было необходимости. Суть в том, что в мемоизаторе каждый вызов оригинального неизменного метода делать на вершине стека в другом потоке. И делать это все через ленивые вычисления. Вначале таким образом сформировать дерево вызовов (без дублирований), ну а затем пробежаться по этому дереву от начала до конца. А если сделать — получится автоматическое разворачивание любого рекурсивного алгоритма, по идее очень круто должно быть, пытался я гуглить подобные решения, к своему удивлению не нашел. И вроде не так уж это и сложно, за несколько дней написать реально. Конечно накладные расходы на взаимодействие потоков неслабо ресурсы пожрут, но зато можно практически неограниченную рекурсию городить, без собственной эмуляции стека.
Какая-то сомнительная идея, если честно. Или я её просто не понял.
Вот мы начали считать fib(1000) в отдельном потоке и дошли до вызова fib(999). Вижу три варианта:
1. Запомнить текущее состояние и сделать goto в начало функции. В принципе, возможно, но во-первых это довольно сложно, а во-вторых — это собственная эмуляция стека, а вы утверждаете что её нет.
2. Запустить fib(999) в новом потоке. Никуда не годится, так как будет тысяча потоков.
3. Забить на текущее состояние, вычислить fib(999) в этом же потоке. Потом начать вычисление fib(1000) сначала. Не так уж плохо, кстати, во многих случаях это не ухудшит ассимптотику алгоритма.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Abalak, Вы писали:
A>>Здравствуйте, elmal, Вы писали:
E>>>А далее я хотел бы услышать о том, как можно написать такой мемоайзер, который при вызове рекурсивно не будет вызывать переполнение стека.
A>>В .NET на делегатах с тейл коллами. Написать не проси за разумное время не напишу, а в реальной жизни пойду в гугл за готовой реализацией. S>Что за делегаты с тейл коллами? Кроме того, тейл коллы требуют изменения кода.
И делегаты и тейл коллы по отдельности. Кстати твой пример внизу впоне так использует делегаты
Вот кстати сходил в гугл и узнал, что в С# с тейл колами не так все просто.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Nik_1, Вы писали:
N_>>Проблема какраз в том, что работодатели частенько хотят заставить дополнительно бесплатно поработать человека, опилируя
BZ>можно ли в одном слове сделать 3 ошибки?..
06.09.2011 17:46, Здравствуйте, Vzhyk : > Сформулирую четко свой вопрос и ответ, который ты ожидаешь услышать. > Надеюсь тут еще есть люди, знающие NET. Они, возможно, подтвердят > элементарность твоего вопроса и правильность твоего ответа.
Я не в курсе, чего там хочет услышать Abalak, но List<T> типизированный
аналог ArrayList. Так как на ArrayList (те же яйца, только неудобно и
медленнее) все забили после выхода второго фреймворка лет шесть назад,
боюсь хоть какой-то ответ на этот вопрос действительно может дать один
из десяти.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Безон, Вы писали:
Б>Если бы не соответствовали, то да — пора спускаться. Но, о чудо, соответствуют.
Всякое бывает. Во Франции вон, говорят, едят лягушек, в Таиланде — тараканов. А еше есть люди которые умеют петь песни о своэм этузиазме и преданности конторе (каждый раз новой). Это не отменяет их способностей хорошо работать, но возможно тебе стоит пересмотреть твоэ "о чудо")
Б> Есть люди, которым нравится программировать, а не только получать деньги. (Деньги и остальные плюшки важны, но не являются определяющими)
Ну что тут сказать. Такой большой, а в сказки верит. Или руководил табунами дресированных студней. В реальности это звучит так:
Людям нужны деньги, програмирование и все остальное — может быть интересным, но деньги являются определяюшими.
N_>>>>А эти многие конторы наверно не вкурсе, что рабство унас давно отменили? И что я делаю в нерабочее время — не их собачье дело. Б>>>Почему собачье дело? Проблемы (в том числе переработки) за пределами рабочего места влияют на работоспособность человека. Причем настолько сильно, что старший разработчик становится хуже младшего. А, значит, кому то придется работать и за "того парня-нераба".
"Что я делаю во внерабочее время — не ваше собачье дело" vs "Ты должен на работе работаь, после работы отдыхать готовясь к новому рабочему дню". Эта болезнь называется "жеребячество". у меня оно прошло на 2м курсе. Говорят у некоторых еше в школе проходит. Сабачье дело, или даже кошачее — не важно Главный принцип — говорить правильные слова, сильно не наглеть и не попадаться.
Б>Прям таки сможешь в лицо послать человека? Он же не вмешивается в твою жизнь, а рекомендует, что нужно делать, чтобы стать более полезным (более оплачиваемым ) на текущем месте работы.
Конечно же нет. Тем более на работе. ответ должен быть вежливым, в стиле "спасибо за советы, ваши рекомендации очень важны и полезны для меня"
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, DKM_MSFT, Вы писали: DKM>>1) Во-первых, и в главных, если человек выражается ультиматумами, это, безусловно, говорит о его общей неадекватности. N_>Если человека, отказывающегося работать за бесплатно ты называешь неадекватным, то тут под большим вопросом твоя адекватность. N_>Назави уже скорей нам название твоей конторы, чтоб знать куда никогда не стоит слать резюме.
Здравствуйте, Abalak, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Что за делегаты с тейл коллами? Кроме того, тейл коллы требуют изменения кода.
A>И делегаты и тейл коллы по отдельности. Кстати твой пример внизу впоне так использует делегаты
Использует, но тейл коллами там не пахнет.
A>Вот кстати сходил в гугл и узнал, что в С# с тейл колами не так все просто.
Как раз в C# с ними все просто. Их там нет и в обозримом будущем не будет. Умеет тейл коллить JIT, правда с ним все равно что играть в рулетку.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>Если перекрутить код метода что бы прийти к линейной рекурсии — то можно и избавиться от поедания стека легко. В исходном виде — не уверен. E>А вот по поводу поедания стека есть у меня одна мысля интересная. Я сам пока не реализовал, если что, не было необходимости. Суть в том, что в мемоизаторе каждый вызов оригинального неизменного метода делать на вершине стека в другом потоке. И делать это все через ленивые вычисления. Вначале таким образом сформировать дерево вызовов (без дублирований), ну а затем пробежаться по этому дереву от начала до конца.
Из того что я понял — выделить две фазы: построение графа вызовов и выполнение его с редукцией. Про другие потоки пока забудем.
Проблема в том, что что бы получить граф вызовов, нужно уметь останавливать выполнение в местах рекурсивных вызовов и получать их параметры. Но этого мало. fib(n-1) + fib(n-2) — это два вызова. На первом мы остановимся, а о наличии второго узнаем после того как выполним первый. Либо оператор сложения должен быть умнее:
return new AddOperation(RecCall(n-1), RecCall(n-2);
Однако это не решает проблему, т.к. в рекурсивных алгоритмах число операндов над результатами может быть неизвестно и зависеть от результатов рекурсивных вызовов.
В общем случае я это вижу как сведение к CPS и избавление от линейной рекурсии аки в Rx.
E>А если сделать — получится автоматическое разворачивание любого рекурсивного алгоритма, по идее очень круто должно быть, пытался я гуглить подобные решения, к своему удивлению не нашел. И вроде не так уж это и сложно, за несколько дней написать реально. Конечно накладные расходы на взаимодействие потоков неслабо ресурсы пожрут, но зато можно практически неограниченную рекурсию городить, без собственной эмуляции стека.
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Понимаешь, я уже наелся сказок о перспективах и светлом будущем, теперь меня прагматично интересует бабло.
Я тебя понимаю.
VM>Не вопрос: двойная оплата за овертайм или отгул и я остаюсь.
Попробуй подумать о том, почему так мало контор практикуют подобный подход. Логика подсказывает, что при фиксированном зарплатном бюджете лучше потратить деньги на бонус продуктивному сотруднику, приносящему хорошие результаты, чем сотруднику, проводящему на работе много времени и хороших результатов не приносящему.
Вот представь, есть ты, оставшийся после работы исправлять свои собственные косяки, и есть твой напарник, который делает втрое больше тебя, а сидит меньше. По твоей логике ты должен получать больше напарника. А я вот думаю, что тебя надо уволить
И твой менеджер, скорее всего, тоже так думает. И менеджер твоего менеджера. А также большинство разумных людей, желающих максимизировать результат при фиксированных ресурсах. Поэтому люди, подобные тебе, не приветствуются и условия, где бы им было хорошо, для них не создаются. Ты, конечно, можешь пробовать менять человечество, но я бы тебе рекомендовал поменять мировоззрение. Глядишь, и денег больше заработаешь
Здравствуйте, TimurSPB, Вы писали:
TSP> Реально талантливые люди зачастую не совсем адекватны в общечеловеческом понимании.
А вот мой опыт показывает что профессионализм и адекватность в целом коррелируют. Очень редко встречается хороший профессионал, при этом совершенный отморозок. Гораздо чаще бывает наоборот
Адекватный человек в данном контексте – это не душа компании, а тот, кто не мешает жить окружающим. А делает жизнь окружающих лучше. Такой человек не лезет в бутылку, признает свои ошибки, помогает, когда его попросят, заранее ставит в известность о своих планах, и не подкладывает никому собак.
TSP> Что делать, если тебе нужен именно такой специалист, который повернут на определенной технической теме? Эта повернутость с одной стороны позволяет делать то, на что способен 1 из 1000, а с другой социальные навыки такого человека ниже всех приемлимых норм.
Я подожду второй тысячи. Ты совершенно неправильно расставляешь акценты. Отличного технического специалиста раньше или позже найти можно. А вот если ты примешь в команду чудака на букву ‘м’, то он испортит жизнь тебе и всей команде, при этом ваша продуктивность, как команды, упадет, а некоторые из уже давно работающих отличных специалистов могут вообще уйти.
Поэтому если есть даже небольшое подозрение на то, что человек неадекватен, на работу он принят не будет. Вне зависимости от его технического уровня.
Здравствуйте, samius, Вы писали:
S>>>Если перекрутить код метода что бы прийти к линейной рекурсии — то можно и избавиться от поедания стека легко. В исходном виде — не уверен. E>>А вот по поводу поедания стека есть у меня одна мысля интересная. Я сам пока не реализовал, если что, не было необходимости. Суть в том, что в мемоизаторе каждый вызов оригинального неизменного метода делать на вершине стека в другом потоке. И делать это все через ленивые вычисления. Вначале таким образом сформировать дерево вызовов (без дублирований), ну а затем пробежаться по этому дереву от начала до конца. S>Из того что я понял — выделить две фазы: построение графа вызовов и выполнение его с редукцией. Про другие потоки пока забудем. S>Проблема в том, что что бы получить граф вызовов, нужно уметь останавливать выполнение в местах рекурсивных вызовов и получать их параметры. Но этого мало. fib(n-1) + fib(n-2) — это два вызова. На первом мы остановимся, а о наличии второго узнаем после того как выполним первый. Либо оператор сложения должен быть умнее:
Приблизительно как это вижу я. Костыль на костыле конечно, но прямо не сделать .
Я вызываю из своего кода fib(10000). Срабатывает вызов мемоизатора. Он проверяет кеш, в кеше нету, надо вычислять. Соответственно он вызывает оригинальный метод. Но ... вызов оригинального метода мы делаем не напрямую, а через сторонний сервис, работающий в другом потоке (поток 1, их не будет плодиться 10000). Тот метод вызывает сам себя, но, при вызове срабатывает тот же самый мемоизатор. В мемоайзере какой то флаг выставляем, типа переведен в режим обработки рекурсии. Вызов уже с параметром fib(9999). Нужно вызывать уже его. Мы говорим стороннему сервису другого, что хотим вызвать метод, но в качестве результата нам нужно не значение, а следующий рекурсивный параметр. Соответственно как только мы в обработчике мемоайзера видим, идет обработка рекурсии, он сразу добавляет следующий сетод в очередь выполнения и возвращает управление (как не ужасно, похоже придется кидать исключение, да, тоже тормоза). Соответственно таким образом мы получим параметры вызова fib(9998) и до нуля. Все, дерево построено. Теперь пробегаем снизу вверх, и запоминаем значения. От нуля, от одного, от двух — это достанется из памяти. А от трех будет уже снова рекурсивный вызов мемоайзера, но уже вычислений не потребуется, все уже закешировано.
Возможно сумбурно рассказал, но вроде выглядит похожим на работоспособным.
PS Мож в этюды эту ветку перенести, кстати ? Аль в философию? Интересная задача вообще то.
. Я ответил на твой вопрос точнее некуда. Или ты хотел увидеть реализацию дженерик мемоайзера?
