Форумы-->Форум для внеигровых тем-->
1|2|3
| Автор | Сложные и красивые задачи по программированию |
|---|
для Relesa:
; и . от лукавого? Зато "w" в hello их прекрасно компенсирует. )) | для Number34:
чтобы не париться насчет переполнения?
Да можно, но результат тогда знаковый должен быть, а значит все равно на результат нужно выделять памяти больше, чем входные данные, но все же меньше, чем общая сумма, согласен. | для Number34:
Хз, у меня прога работает | для Daemonic:
чтобы не париться насчет переполнения?
Скорее, просто чтобы не бегать по массиву дважды. Переполнение сложением достигается нечасто.
Под результат не массив, а единичная переменная выделяется, так что по памяти при выделении под знак не ударит. | для Number34:
по памяти при выделении под знак не ударит
int32 - -2^31..2^31-1
uint32 - 0..2^32-1
Как видно, все же пределы у переменных разные (мне приходится с этим долбаться чуть ли не через день из-за отсутствии беззнаковых переменных в среде хранения данных).
Когда Вы объявляете переменную, разве не происходит выделение памяти? Пускай и на стеке (что значит, что ее у Вас еще меньше), но все же. | для Daemonic:
Все верно, но это ведь происходит для единичной локальной переменной rez, а не для массива (вектора) длиной в N элементов.
Несколько байт машинка должна выделить имхо. | для Number34:
Вот это тот самый случай, о котором я говорил про собеседование.
Я знаю о чём ты говорил. Проблема в том, что умение решать олимпиадные задачки говорит только о умении решать олимпиадные задачки. Это как игра в шахматы, интересно, но практического смысла не имеет.
Вот такой олимпиадник решит задачку, потом числа окажутся не натуральные. А потом и вовсе не числа, а объект из пары чисел и строки. Потом к ним дата добавится. А потом это станет джэйсоном.
И задача вместо одного раза решится несколько. А время разработки дороже процессорного. Намного. Особенно в современном мире, когда проще ещё кластер добавить, чем увеличивать время разработки.
Не, где-то и этот метод хорош. При разработке кодеков например, или при работе с контроллерами. Но это хорошо если процент от рынка труда. И уж кичиться этим точно смысла нет, и называть не ооимпиадников дураками. | для FireSwarm:
Это всё как раз понятно, и со всем сказанным Вами я согласен.
В некоем идеальном мире, где программисты являются бэк-офисом и выполняют исключительно плановую поверсионную работу, всё действительно так. Но в реальном мире во многих фирмах программист оказывается на передовой, когда (скажем, жирнющему vip-клиенту) требуется максимально быстро реализовать заказную хотелку или грамотно закрыть столетнюю дыру. На кону и большие деньги (как за заказ, так и штрафы за время работы на подтвержденной дыре), и имидж. Оптимизация чаще всего выполняется уже потом.
Опять же подобная прыть и смекалка ценны для "репортовиков", а это жирнющий пласт задач в любой корпоративной системе с СУБД и для любого фронт-офиса. Доводилось не раз перехватывать клиента у конкурентов просто потому, что чужую написанную обработку, которая выполнялась "в ночь", нв месте заменяли кодом, работавшим считанные секунды. Клиент ценит свое время и готов платить за его экономию, но при условии, что получает желаемое здесь и сейчас, по щелчку пальцев. | И задача вместо одного раза решится несколько. А время разработки дороже процессорного. Намного. Особенно в современном мире, когда проще ещё кластер добавить, чем увеличивать время разработки.
Сколько раз зарекался делать УНИВЕРСАЛЬНЫЕ решения. Как Вы верно указали, время разработки дорого, но УНИВЕРСАЛЬНЫЕ решения дольше и на этапе разработки и жрут больше процессорного времени и памяти, а понадобится это УНИВЕРСАЛЬНОЕ решение еще не факт, итого:
- потрачено больше времени на разработку;
- решение сильней нагружает систему;
- универсальность не пригодилась.
Такое вот стремление и приводит, что голая ось постоянно чего-то делает, отжирая 500-600 МБт, вместо положенных 100. | для FireSwarm:
Раз тут тема про задачки, вот пример таковой. Поначалц она казалась тривиальной, но теперь я даю ее на собеседованиях, т.к. решают эффективно ее немногие кандидаты.
Итак, есть простая табличка с данными за год и дохрениллионом строк вида:
Клиент(Id), дата покупки, сумма покупки
Для простоты о реляционности забываем, работаем только с id.
Задача: собрать столь любимый финансистами-международниками отчет вида
Клиент, продажи за... (январь), (февраль), ..., (декабрь), "игого за весь год".
То есть, в отчете будет по строке на каждого клиента с помесячными и годовым итогами продаж.
Решается на любом диалекте sql, но ее же можно рассматривать в рамках любого классического языка программирования и для простоты даже будем считать, что таблица (массив) упорядочена по клиентам и датам в порядке возрастания.
Очевидно, что решение достигается за 1 проход по таблице (массиву). На удивление, почти все кидаются решать задачу через многократный проход и захлебываются в тестовом примере на "дохрениллион строк". | Доводилось не раз перехватывать клиента у конкурентов просто потому, что чужую написанную обработку, которая выполнялась "в ночь", нв месте заменяли кодом, работавшим считанные секунды.
Ну это уже конкретная некомпетентность.
Клиент ценит свое время и готов платить за его экономию, но при условии, что получает желаемое здесь и сейчас, по щелчку пальцев.
Разумеется никому не нужно тупое решение. Я же не про это.
для Daemonic:
Конечно универсальное решение не везде нужно, более того - не всегда возможно. Но читаемость кода и его поддерживаемость зачастую важнее оптимальности. Примеров за и против можно привести кучу. Я привык работать в больших проектах, а там не всегда супер быстрое но сложное в понимании решение ревью пройдёт. Твой код будут поддерживать другие, а из тысячи прогеров в компании вряд ли все олимпиадники и математики. Так что ост будет жрать 500, но обновлять её будут дважды в год, а не 100 с обновлением раз в два года. Это не позволительно в современном мире. | для FireSwarm:
Клиент, продажи за... (январь), (февраль), ..., (декабрь), "игого за весь год".
То есть, в отчете будет по строке на каждого клиента с помесячными и годовым итогами продаж.
Я слишком много работал с отчётами, чтобы для меня это была сложная задачка. Для тестовой задачи скл я даю задачку разнообразнее. В которой нужно создать таблицы, запрос по тз и индексы для этого запроса. | для FireSwarm:
Чёт я начинаю в кнопки не попадать) | Клиент, продажи за... (январь), (февраль), ..., (декабрь), "игого за весь год".
То есть, в отчете будет по строке на каждого клиента с помесячными и годовым итогами продаж.
Я, кстати, видел наверно самое неоптимальное решение этой задачи - на каждый столбец по джойну. | для FireSwarm:
Я, кстати, видел наверно самое неоптимальное решение этой задачи - на каждый столбец по джойну.
Причем, видимо, full outer join-у. )))
И вишенкой на торте 13-й с итогом за год. )))
Кстати, любовью к неявно видному декартову произведению таблиц грешат почти все встроенные макроязыки, отсюда и разгон от часов до секунд при замене этого великолепия встроенным sql. |
1|2|3К списку тем
|
