Здравствуйте, LordMAD, Вы писали:
LMA>>>Это в каких?
I>>например avg (2,3) == avg (3,2) даёт false,
LMA>Да и это не проблема, потому что для получения среднего с заданной точностью (в виде int), естественно имеет место округление. Так как в задании не указан конкретный вид округления, случайное округление вполне подходит.
Дело не в погрешности, в том среднее арифметическое коммутативна, а твоя функция этому условию не удовлетворяет.
Потому avg с помощью приведения типа от int к double и обратно будет смотреться во первых проще, во вторых не будет ошибок
А с учетом "случайное округление вполне подходит" то x/2 + y/2 вполне подходит под это условие
I>>а надо true, иначе это не среднее арифметическое
LMA>Бред. LMA>Или Вы можете привести ссылку на такое требование к среднему арифметическому в общем случае?
Среднее арифметическое — коммутативная функция, что следует из её определения.
Тут даже матан и функан знать не нужно.
I>>Сколько раз ты её давал на собеседовании ?
LMA>Не считал, а что?
Здравствуйте, LordMAD, Вы писали:
I>>Самые простые — в твоем коде нужно много времени что бы найти ошибку.
LMA>Ну тогда по твоей логике, правильный ответ должен быть LMA>int avg(int x, int y) { return 0; } LMA>Ведь в нем очень легко найти ошибку!
(x+y)/2 (int)(((double)x+(double)y)/2)
любой из них будет проще
LMA>Если ты можешь предложить вариант решения, который (1) будет работать правильно для, как сказано в задании, "любых значений типа int"
твой то этому условию не удовлетворяет
и (2) будет проще (хотя бы с точки зрения поиска ошибок) и при этом (3) не будет привязан к конкретной платформе — придложи и мы его обсудим.
Я сделал это минима трижды в этом топике.
P.S. ты даешь задачу на собеседовании, а сам придумал какие то свои критерии правильности.
Откуда собеседуемому знать, что у тебя особое мнение на тему коммутативности?
Здравствуйте, LordMAD, Вы писали:
I>>Да и это очень важно. Потому как часто бывает проекты кочуют между бригадами. Одн начали, другие продолжили.
LMA>Это важно для IT-шных McDonald's-ов,
Я не знаю что означает этот термин и не понял идею твоего высказываня. Если проект кочует между бригадами, то на каждой фазе им занимаются люди, ранее незнакомые с кодом.
I>>Если код не прозрачный, то сразу начнется хаос
LMA>Вопрос, в том какой код считать прозрачным.
Я привел нормальный критерий, когда с проектами работают разные бригады, т.е. в каждой опытные девелоперы.
Здравствуйте, Олег К., Вы писали:
LMA>>Ну, это сейчас вообще на каждом углу. Мы убрали его из корпоративного документа по собеседованиям после того, как это написали в английской википедии и количество знающий ответ заранее возросло. Кстати, очень жаль, потому что вопрос действительно очень хороший. Мне до сих пор не известно кто впервые обратил внимание на эту связь. ОК>Все! Я понял. Вы там задались целью придумать вопросы на которые никто не ответит! Браво!
Здравствуйте, LordMAD, Вы писали:
LMA>Ничего подобного. Если человек просто сложит и поделит — это означает, что его код будет работать не в соответствии с тем заданием, которое он получил. То есть это баг. А зачем нужен программист, который на обычном сложении внесет в код баг? Единственная ситуация, при которой это допустимо — если команду в целом не сильно заботит — есть в программе баг или нет, ведь зато разработка обошлась чуть дешевле и бизнес проще масштабировать.
В своем решении ты лично внес в код баг, причем больший, чем те, кто просто складывает. Причем ты находился не в стрессовой ситуации, а в спокойной, и все равно ошибся. Почему тебе ошибаться можно, а остальным нет? Если требователен к другим, то надо быть требовательным и к себе, так?
Здравствуйте, elmal, Вы писали:
LMA>>Да и это не проблема, потому что для получения среднего с заданной точностью (в виде int), естественно имеет место округление. Так как в задании не указан конкретный вид округления, случайное округление вполне подходит. E>Ни черта себе случайное округление вполне подходит! Это потенциальный баг гораздо круче, чем если просто произошло бы переполнение. Переполнение то заметить легко.
Это ты про сферического коня в вакууме?
E>А тут от разного порядка входных данных получаем разный результат. Причем по логике, ожидается, что результат должен быть один, более того, вполне справедливо ожидается, что округление будет произведено именно так, как оно делается для целых типов.
Округление, чтобы ты знал, разными способами. Делает его программист и делает его он исходя из конкретной задачи. Например, для банковской задачи, будет логично везде в коде такой задачи подразумевать банковское округление (к ближайшему четному) и т.д.
E>На это вполне логично закладываться. И в данном случае на практике (именно на практике) вероятность огрести проблемы с этой мегафункцией гораздо больше, чем в случае, если просто сложить 2 числа и подетить на 2, без проверки на переполнение. Не так часто будут функцией пользоваться для достаточно больших данных, скорее всего, а вот вызывать ее с разным порядком параметров будут постоянно. И лично я предпочту пользоваться функций без проверки на переполнение, чем функцией, которая возвращает разные значения при разном порядке аргументов. У тебя ошибка гораздо грубее!!!
Ты опять пытаешься обсуждать сферического коня в вакууме. Пытаешься оправдать плохое решение какой-то статистикой. Как я уже писал в этой теме — решение посчитать просто, но сначала вставив assert — верное для этого примера. Ты просто не понимаешь, что задача имеет несколько решений, у каждого из них есть свои достоинства и недостатки. Я лишь привел вариант решения этой задачки, который я считаю достаточным для того, чтобы сделать соответствующий вывод о кандидате.
Здравствуйте, Ikemefula, Вы писали:
I>Дело не в погрешности, в том среднее арифметическое коммутативна, а твоя функция этому условию не удовлетворяет.
Ты наверное удивишься, но вариант функции avg, который я привел, удовлетворяет этом условию с заданной точностью (в данном случае с точностью до 1 так как имеет место округление до целых).
I>Потому avg с помощью приведения типа от int к double и обратно будет смотреться во первых проще, во вторых не будет ошибок
Это ты к чему?
I>А с учетом "случайное округление вполне подходит" то x/2 + y/2 вполне подходит под это условие
Я думаю, что если бы знал, что такое "случайное округление", ты бы такой глупости не написал. То что в названии присуствует слово "случайное", не означает, что округлять можно с любой точностью.
I>>>а надо true, иначе это не среднее арифметическое
LMA>>Бред. LMA>>Или Вы можете привести ссылку на такое требование к среднему арифметическому в общем случае?
I>Среднее арифметическое — коммутативная функция, что следует из её определения.
Здравствуйте, Ikemefula, Вы писали:
LMA>>Ну тогда по твоей логике, правильный ответ должен быть LMA>>int avg(int x, int y) { return 0; } LMA>>Ведь в нем очень легко найти ошибку!
I>(x+y)/2 (int)(((double)x+(double)y)/2)
I>любой из них будет проще
Ты правда не видишь разницы между совершенно неверным результатом и не тем вариантом округления, который ты почему-то предполагаешь?
LMA>>Если ты можешь предложить вариант решения, который (1) будет работать правильно для, как сказано в задании, "любых значений типа int"
I>твой то этому условию не удовлетворяет
Потому что округление до целых роисходит не так как ты предполагаешь?
I> и (2) будет проще (хотя бы с точки зрения поиска ошибок) и при этом (3) не будет привязан к конкретной платформе — придложи и мы его обсудим.
I>Я сделал это минима трижды в этом топике.
Ну так ткни носом, потому что я что-то таких не вижу.
I>P.S. ты даешь задачу на собеседовании, а сам придумал какие то свои критерии правильности.
А в чем проблема? Если он напишет решение, которое будет верно и с моей точки зрения, и округление будет как тебе хочется, я такое решение засчитаю.
I>Откуда собеседуемому знать, что у тебя особое мнение на тему коммутативности?
Во-первых, если у него есть сомнения, он может спросить. Во-вторых, как я уже написал, если он использует другой вариант округления, задача тоже будет решена верно.
Здравствуйте, elmal, Вы писали:
E>В своем решении ты лично внес в код баг, причем больший, чем те, кто просто складывает. Причем ты находился не в стрессовой ситуации, а в спокойной, и все равно ошибся. Почему тебе ошибаться можно, а остальным нет? Если требователен к другим, то надо быть требовательным и к себе, так?
Еще раз повторю: то, что ты называешь багом в моём примере — багом не является, по крайней мере, по моему мнению, и, по мнению моих коллег. Такой вариант решения, как привел я, из кандидатов давали десятки людей. Вариант решения с другим округлением давали всего несколько человек, и так как я не считаю его сильно лучше, здесь я его не привожу. Если требуется какой-то определенный вариант округления, у нас в спецификации об этом явно говорится, и я не думаю, что кто-то из кандидатов, решивших эту задачу тем способом, который привел я, если ему поставить условие применения конкретного варианта округления, не сделает этого.
Здравствуйте, LordMAD, Вы писали:
LMA>Еще раз повторю: то, что ты называешь багом в моём примере — багом не является, по крайней мере, по моему мнению, и, по мнению моих коллег. Такой вариант решения, как привел я, из кандидатов давали десятки людей. Вариант решения с другим округлением давали всего несколько человек, и так как я не считаю его сильно лучше, здесь я его не привожу. Если требуется какой-то определенный вариант округления, у нас в спецификации об этом явно говорится, и я не думаю, что кто-то из кандидатов, решивших эту задачу тем способом, который привел я, если ему поставить условие применения конкретного варианта округления, не сделает этого.
Здравствуйте, LordMAD, Вы писали:
LMA>Еще раз повторю: то, что ты называешь багом в моём примере — багом не является, по крайней мере, по моему мнению, и, по мнению моих коллег. Такой вариант решения, как привел я, из кандидатов давали десятки людей.
И что с того, что по твоему мнению не является? Баг никуда не делся. То, что по мнению твоих коллег не является, вполне логично, так как коллег набирал ты, или такие, как ты, на похожих задачках. Баг с переполнением тоже по мнению очень большого количества людей багом не является, и вариант такой даюь еще большее количество людей.
Вот еще одно скажу. Не страшно, если кандидат ошибся, гораздо сложнее, когда он не признает свои ошибки. Если кандидат ошибся — выясни, случайно он ошибся или потому, что не в курсе. И посмотри как он исправит свою ошибку. Если ошибся, признал, и исправил — ему плюс такой же, как если б не ошибался. А вот если настаивает что это не баг, это фича — я как то сомневаюсь что таких стоит брать.
Иначе как в одном проекте будет — в ключевой библиотеке, от которой зависят куча людей, ошибка, исходников нет, репортишь баг, так как поведение очень странно, нелогично, и вообще выглядит случайным. Говорят что не баг, разбирайтесь в своем коде, вообще вы идиоты, ни черта не можете, отстаньте, мы заняты важными делами. Простейшая фича висит 2 месяца в результате, перепробываются все обходные пути, не получается. Начинает интересоваться высший менеджмент, а что так долго (не просто типичный ПМ, а практически владелец конторы опускается до этого, причем спрашивает разработчиков лично)? В результате фичу просят сделать разработчиков библиотеки, и тут они признают, что ее никак не сделать, и наконец исправляют баг в библиотеке (перелопатив ее черти как, исправляют долго, и исправив обрушив другие места). И так постоянно. Реальный случай.
Здравствуйте, LordMAD, Вы писали:
I>>твой то этому условию не удовлетворяет
LMA>Потому что округление до целых роисходит не так как ты предполагаешь?
Потому что ты нарушил основное свойство функции — коммутативность.
I>>Я сделал это минима трижды в этом топике.
LMA>Ну так ткни носом, потому что я что-то таких не вижу.
Два из них было прямо в том сообщении на которое ты писал ответ. Более того — они был виден и в твоем тексте.
Мне интересно, на собеседовании ты тоже "скромно" не заметишь ответ ?
I>>P.S. ты даешь задачу на собеседовании, а сам придумал какие то свои критерии правильности.
LMA>А в чем проблема? Если он напишет решение, которое будет верно и с моей точки зрения, и округление будет как тебе хочется, я такое решение засчитаю.
С даблами то решение тебе не нравится почему то
I>>Откуда собеседуемому знать, что у тебя особое мнение на тему коммутативности?
LMA>Во-первых, если у него есть сомнения, он может спросить.
Во первых ты и сам не знал, что нарушил свойство коммутативности.
LMA>Во-вторых, как я уже написал, если он использует другой вариант округления, задача тоже будет решена верно.
Во вторых тогда x/2 + y/2 тоже всего лишь другой вариант округления
Здравствуйте, LordMAD, Вы писали:
LMA>Ты наверное удивишься, но вариант функции avg, который я привел, удовлетворяет этом условию с заданной точностью (в данном случае с точностью до 1 так как имеет место округление до целых).
в таком случае вариант x/2 + y/2 вообще идеальный. Погрешность в нем та же но он коммутативен.
При этом он занимает кода примерно на порядок меньше, чем твой шедевр
но вообще у тебя своя формулировка свойства коммутативности и алгоритмы, явно или неясно использующие эту коммутативность работать у тебя не будут.
т.е. крути не крути, а твоя функция не есть среднее арифметическое.
I>>Потому avg с помощью приведения типа от int к double и обратно будет смотреться во первых проще, во вторых не будет ошибок
LMA>Это ты к чему?
это я к тому, что ты нагородил кода и выдал неправильный результат
I>>А с учетом "случайное округление вполне подходит" то x/2 + y/2 вполне подходит под это условие
LMA>Я думаю, что если бы знал, что такое "случайное округление", ты бы такой глупости не написал. То что в названии присуствует слово "случайное", не означает, что округлять можно с любой точностью.
а здесь не любая, а вполне конкретная "(в данном случае с точностью до 1 так как имеет место округление до целых)"
I>>Среднее арифметическое — коммутативная функция, что следует из её определения.
LMA>См. выше по поводу коммутативности.
Я уже сказал, что у тебя свой, уникальный взгляд на коммутативность.
Здравствуйте, elmal, Вы писали:
E>И что с того, что по твоему мнению не является?
Тоже, что и с того, что по твоему мнение это баг.
E>То, что по мнению твоих коллег не является, вполне логично, так как коллег набирал ты, или такие, как ты, на похожих задачках.
Далеко не всех набирал я.
E>Баг с переполнением тоже по мнению очень большого количества людей багом не является, и вариант такой даюь еще большее количество людей.
На самом деле нет, просто потому что они соглашаются с тем, что их решение неверно, после того, как им показывают, что именно у них не так.
E>Вот еще одно скажу. Не страшно, если кандидат ошибся, гораздо сложнее, когда он не признает свои ошибки. Если кандидат ошибся — выясни, случайно он ошибся или потому, что не в курсе. И посмотри как он исправит свою ошибку. Если ошибся, признал, и исправил — ему плюс такой же, как если б не ошибался. А вот если настаивает что это не баг, это фича — я как то сомневаюсь что таких стоит брать.
Если ты намекаешь на меня — то очевидный факт, что функция дает разные результаты (±1) при смене порядка аргументов, мне был известен до того, как я впервые использовал этот вопрос на собеседовании. И именно потому, что я не вижу в этом проблемы, я этот пример использовал.
E>Иначе как в одном проекте будет — в ключевой библиотеке, от которой зависят куча людей, ошибка, исходников нет, репортишь баг, так как поведение очень странно, нелогично, и вообще выглядит случайным. Говорят что не баг, разбирайтесь в своем коде, вообще вы идиоты, ни черта не можете, отстаньте, мы заняты важными делами. Простейшая фича висит 2 месяца в результате, перепробываются все обходные пути, не получается. Начинает интересоваться высший менеджмент, а что так долго (не просто типичный ПМ, а практически владелец конторы опускается до этого, причем спрашивает разработчиков лично)? В результате фичу просят сделать разработчиков библиотеки, и тут они признают, что ее никак не сделать, и наконец исправляют баг в библиотеке (перелопатив ее черти как, исправляют долго, и исправив обрушив другие места). И так постоянно. Реальный случай.
Ну и в чем проблема, что то, что ты считаешь не логичным, они считают as designed? При здоровой обстановке в коллективе такие вопросы должны решаться исходя из аргументации, а не исходя из мнения кого-то, что выглядит плохо, а что выглядит хорошо. Вполне могу представить себе ситуацию, когда в подобном случае просто инструмент используют не по назначению.
Вообще мне не понятна ситуация, при которой у использующих библиотеку нет исходных кодов к библиотеке — это создает настолько критическую зависимость, что не понятно — куда вообще это годится. Если добровольно сели "на иглу", то чего возмущаться то?
Здравствуйте, Ikemefula, Вы писали:
LMA>>Потому что округление до целых роисходит не так как ты предполагаешь?
I>Потому что ты нарушил основное свойство функции — коммутативность.
Еще раз: коммутативность выполняется c заданной точностью (с точностью до округления до целых).
LMA>>Ну так ткни носом, потому что я что-то таких не вижу.
I> Два из них было прямо в том сообщении на которое ты писал ответ. Более того — они был виден и в твоем тексте.
I>Мне интересно, на собеседовании ты тоже "скромно" не заметишь ответ ?
Я кажется начинаю догадываться: ты на полном серьезе думаешь, что "(x+y)/2" "будет работать правильно для, как сказано в задании, "любых значений типа int", то есть когда среднее значение двух положительных чисел получается отрицательным? А "(int)(((double)x+(double)y)/2)" "не будет привязан к конкретной платформе", то есть ты правда думаешь, что для ILP64 преобразование из int в double будет корректным?
LMA>>А в чем проблема? Если он напишет решение, которое будет верно и с моей точки зрения, и округление будет как тебе хочется, я такое решение засчитаю.
I>С даблами то решение тебе не нравится почему то
Хотя бы потому что нет способа запихнуть 64 бита в 53 бита без потерь.
I>>>Откуда собеседуемому знать, что у тебя особое мнение на тему коммутативности?
LMA>>Во-первых, если у него есть сомнения, он может спросить.
I>Во первых ты и сам не знал, что нарушил свойство коммутативности.
?
LMA>>Во-вторых, как я уже написал, если он использует другой вариант округления, задача тоже будет решена верно.
I>Во вторых тогда x/2 + y/2 тоже всего лишь другой вариант округления
Округление до целых подразумевает округление с точностью ±1, или ты не согласен?
Здравствуйте, Ikemefula, Вы писали:
LMA>>Ты наверное удивишься, но вариант функции avg, который я привел, удовлетворяет этом условию с заданной точностью (в данном случае с точностью до 1 так как имеет место округление до целых).
I>в таком случае вариант x/2 + y/2 вообще идеальный. Погрешность в нем та же но он коммутативен.
В каком месте у него такая же погрешность? Среднее двух 1 точно равно 1, так как округления нет, а эта формула дает 0.
I>но вообще у тебя своя формулировка свойства коммутативности и алгоритмы, явно или неясно использующие эту коммутативность работать у тебя не будут.
Будут, если написаны правильно. Ты ведь, наверное, в курсе, что числа с плавающей точкой сравниваются с точностью до некой ненулевой величины?
I>т.е. крути не крути, а твоя функция не есть среднее арифметическое.
Я так понимаю, что если тебя попросят вычислить среднее с точностью до 100, то ты скажешь, что с точностью до 100 это уже будет не среднее арифметическое?
I>>>Потому avg с помощью приведения типа от int к double и обратно будет смотреться во первых проще, во вторых не будет ошибок
LMA>>Это ты к чему?
I>это я к тому, что ты нагородил кода и выдал неправильный результат
Про double и "не будет ошибок" см. выше.
LMA>>Я думаю, что если бы знал, что такое "случайное округление", ты бы такой глупости не написал. То что в названии присуствует слово "случайное", не означает, что округлять можно с любой точностью.
I>а здесь не любая, а вполне конкретная "(в данном случае с точностью до 1 так как имеет место округление до целых)"
То есть ты думаешь, что для (1, 1) получая 0 вместо 1, ты получаешь точность до 1?
I>avg(a,avg(b,avb(c,...)))
I>чувствуешь, куда я клоню ?
К тому, что (1/2 + (3/2 + 5/2)/2) == 1 для твоего "идеального" варианта "x/2 + y/2"?
Здравствуйте, modev, Вы писали:
M>Здравствуйте, Олег К., Вы писали:
M>>>Не всегда и float можно взять, не говоря уж про double. Long long и прочее тоже может не поощряться. Например, вычисления для мобильных платформ в fixed point. Там даже при несложной физике много тонких моментов вылезает. Правда, те же физические движки для моб. игр пишут одна-две конторы, остальным это не особо нужно. Готовым пользуются уже. ОК>>Твоя правда но мы не говорим тут о какой-то экзотике в большинстве своем. Потом, разве на плюсах пишут игры для мобилок? А еще там код ужасный и те кто этим занимается сами хотят свалить. Были тут посты.
M>Для "продвинутых" смартфонов пишутся на C или C++.
Если покажите мне игру написанную для "продвинутого" смартфона на С вышлю вам 100 баксов.
А вообще конечно даже для "продвинутрых" смартфонов подавляющее (думаю процентов 90% если считать от количества) игр пишется не на с++.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, shrecher, Вы писали:
S>>Здравствуйте, LordMAD, Вы писали:
LMA>>>Напишите функцию, вычисляющую среднее значение двух любых значений типа int: LMA>>>int avg(int x, int y);
S>>Есть люди теоретики, они ответят про переполнение и знаки. А есть люди — практики. Они просто сложат и поделят на два. Все-таки в программировании практики важнее, слишком приклодная отрасль. Для теоретиков тоже найдется работа, правда,не кодером.
LMA>Ничего подобного. Если человек просто сложит и поделит — это означает, что его код будет работать не в соответствии с тем заданием, которое он получил.
чесно говоря, я не понял, почему он не будет работать в соответствии с заданием? К примеруЮ
int avg( int a, int b)
{
return (a+b)/2;
}
int _tmain(int argc, _TCHAR* argv[])
{
printf( "test %d\n", avg( -2, -4) );
printf( "test %d\n", avg( 2, 4) );
printf( "test %d\n", avg( 2, -4) );
printf( "test %d\n", avg( -2, 4) );
return 0;
}
А еще там код ужасный и те кто этим занимается сами хотят свалить. Были тут посты.
