кадровики совсем рехнулись - О работе

Здравствуйте, sergey2b, Вы писали:

S>>>и любимые Крейтором задачи по сортировки битов
CC>>Шта?

S>вы с Артемом спорили целый топик надо уметь оперировать отдельными битами или нет

Не так. Уметь выставлять биты нужно. Уметь считать биты- задачка на память. Ну креатор с единственно верным решением несогласен- спрашивает это "на поговорить" от избытка креативности наверное.

Здравствуйте, CodeMonkey, Вы писали:
CM>Сколько таких людей на весь мир наберется, для которых это действительно нужно? Ну допустим, не десяток. Тысяча. Может, даже десяток тысяч. Всё

То есть вас не смущает то, что вы ни MSIL, ни байткод JVM не можете читать даже со словарём?
Это если мы не будем копать седую древность типа того же Форта.
Ну ок. А если бы вас попросили написать вычислитель выражений в инфиксной нотации — что, это было бы как-то легче?
Я вот профильного образования не имею, компиляторы никогда не писал, но даже я знаю, что такое "перевод инфиксной нотации в постфиксную", что такое "стековый вычислитель" и прочие примитивные вещи.
Если в этой вакансии нужно мало-мальски применение алгоритмов — то да, такой вопрос на собеседовании уместен.
И вообще, инженер всегда должен уметь смотреть на один уровень вглубь — то есть, если пишешь на C#, надо понимать, в какой MSIL превращается код. Если пользуешься библиотекой — надо знать, как она устроена внутри.
До самого дна лезть не обязательно — там быстро упрёшься в инженерное применение квантовой механики, а его за полчаса в ютубе не освоишь.
Но вот обычный критерий хорошего инженера — любопытство, которое и приводит к тому, чтобы разобраться — что там "унутре". Если этого любопытства нет — то никаким надрачиванием фреймворков и паттернов ты его не заменишь, увы.

Здравствуйте, De-Bill, Вы писали:

DB>Неправда.
Но правда в том, что 90 процентов выпускников программерских специальностей об обратной польской записи не слышала.

DB>Эта задача не имеет никакого отношения ко всему вышеперечисленному. Но при желании, конечно, натянуть сову на глобус можно.
Интерпретатор выражения, записанного в обратной польской записи — это вообще самый тривиальный интерпретатор, который только можно придумать. Пишется вообще в лоб без малейших усилий, исключительно на остаточных знаниях. Просто вырожденный случай более сложных интерпретаторов. Я в свое время, если собеседовал студентов программерских специальностей, просил рассказать как программно вычислить (2 + 3) * 5 + 7. То есть как бы выглядел алгоритм, код писать не просил. Ни один кроме невнятного мычания ничего сказать не мог. Вообще ничего. Пять минут думал, и далее говорил сдаюсь. Когда сам был студентом, подобное писать приходилось. Причем совсем не в элитном ВУЗе. И если что (я потому и спрашивал это) — подобные интерпретаторы, только гораздо более сложные, вполне вероятно что могло бы понадобиться поддерживать, дорабатывать и т.д. Даже кандидат, несколько лет проработавший в JetBrains (неплохой, кстати, кандидат) — тот тоже сдался, никаких мыслей не было как подобную невозможную задачу можно было решить и какие подходы применить. Соответственно плюнул и уже такое не спрашиваю.

Здравствуйте, ·, Вы писали:
CM>>expr = -?[0-9]+
CM>>expr = expr expr [+-*/]

CM>>Например:
CM>>1 1 + 2 3 * -
CM>>должно получиться -4

CM>>Во первых, грамматика вообще неверна.
·>Вроде верна. Что не верно?

Не специалист в этой области, но разве вместо:

expr = expr expr [+-*/]

не должно быть:

expr = expr expr [+\-*/]

т.е. "-" не экранирован. И по предыдущему выражению видно что диапазоны в наборе символов используются.

Здравствуйте, T4r4sB, Вы писали:

TB>А где тут инфиксная нотация? Это ж обычная полька.

Не обычная, а обратная

Здравствуйте, CodeMonkey, Вы писали:

5 минут включая отладку (powershell, несколько многословно, без проверки на ошибки, но мне лень):

function ReversedPolish-Solver($expr) {
    $tokens = $expr -split '\s+'

    $stack = [System.Collections.Stack]::new()

    $tokens | % { 
        switch -Regex ($_) {
            '^-?[\d]+$' { $stack.Push($_) }
            '^\+$' { 
                    $b = $stack.Pop()
                    $a = $stack.Pop()
                    $stack.Push([float]$a + [float]$b)
                 }
            '^-$' { 
                    $b = $stack.Pop()
                    $a = $stack.Pop()
                    $stack.Push([float]$a - [float]$b)
                 }
            '^\*$' { 
                    $b = $stack.Pop()
                    $a = $stack.Pop()
                    $stack.Push([float]$a * [float]$b)
                 }
            '^/$' { 
                    $b = $stack.Pop()
                    $a = $stack.Pop()
                    $stack.Push([float]$a / [float]$b)
                 }
        }

    }

    return $stack.Pop()
}

ReversedPolish-Solver "1 1 + 2 3 * -"

PS. В примере ТС вместо "-" стоит тире, будте внимательны.

Здравствуйте, reversecode, Вы писали:

R>это абсудр
R>если вести такую логику
R>то ввп должен уметь печь вкусные булочки (для разогрева) а иначе как он тогда управляет страной ?

Нет, если использовать вашу логику, то ВВП не должен знать азов экономики — он же не экономист, он выше этого.

Здравствуйте, ·, Вы писали:

·>Тут важно не обратная польская нотация, а способ представления и обработки древовидной структуры данных.

Но её же (древовидной структуры) нет в RPN? У RPN как раз плюс что не нужно парсить выражение и строить его дерево — можно просто последовательно его вычислить (пример)

E>Интерпретатор выражения, записанного в обратной польской записи — это вообще самый тривиальный интерпретатор, который только можно придумать. Пишется вообще в лоб без малейших усилий, исключительно на остаточных знаниях.

Никаких остаточных знаний здесь не нужно. Эту задачу прекрасно сможет решить школьник, увлекающийся программированием, без каких либо остаточных знаниях о теории вообще. Достаточно ему объяснить, что это вообще такое. Натягивание теории "парсеров, лексеров и синтаксических деревьев" на решение этой задачи — это натягивание совы на глобус. А вот в обратную сторону может быть и верно: для объяснения теории можно в качестве примера привести эту задачу.

Здравствуйте, De-Bill, Вы писали:

DB>Никаких остаточных знаний здесь не нужно. Эту задачу прекрасно сможет решить школьник, увлекающийся программированием, без каких либо остаточных знаниях о теории вообще. Достаточно ему объяснить, что это вообще такое. Натягивание теории "парсеров, лексеров и синтаксических деревьев" на решение этой задачи — это натягивание совы на глобус. А вот в обратную сторону может быть и верно: для объяснения теории можно в качестве примера привести эту задачу.
Вот именно. Но реально я охреневаю, когда такая задача оказывается непроходной для реального программиста. Я не понимаю, как такой детсад можно забыть. Единственное у меня объяснение — в школе программированием не увлекался. Институт в основном в ночных клубах просиживал, на лекциях не появляясь, а сессия куплена. А на работе нужно формочки клепать да в базу вставлять.

E>Вот именно. Но реально я охреневаю, когда такая задача оказывается непроходной для реального программиста.

Человек прежде всего не понял условия. Вне всякого сомнения — это минус. Если он не смог в ходе беседы выяснить, что от него требуется — это большой минус. Если же собеседующие просто не стали отвечать на его уточняющие вопросы, то значит они чудаки (на букву М), с такими лучше не работать.

CC>Это примерно как уметь посчитать в уме сколько будет 2**100500 / 2**100490

Ух ты. Даже я в состоянии посчитать.

DB>Если же собеседующие просто не стали отвечать на его уточняющие вопросы, то значит они чудаки (на букву М), с такими лучше не работать.

А если собеседующие для контакта с кандидатами используют хрюшу-передаста, которой что экстаз, что унитаз, и она вопрос и ответ передает с использованием своего затейливого ума?

G>А если собеседующие для контакта с кандидатами используют хрюшу-передаста, которой что экстаз, что унитаз, и она вопрос и ответ передает с использованием своего затейливого ума?

Тоже хороший фильтр. Не смог договориться с HR, прозвучали хоть какие-нибудь уничижительные нотки по отношению к ней — no hire однозначно.