Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Олег К., Вы писали:
ОК>>Ну Си шарп вообще параноидальный. Бывает что переменная инициализируется при каких-то условиях, затем ниже по коду используется уже когда она была гарантированно иницализрованна, так он ругается что она не всегда инициализированна. Приходится при объявлении ставить какое-то начальное значение. E>Я вообще то в книгах по плюсам видел рекомендацию всегда ставить переменным начальное значение. Хотя бы NULL.
А потом запускаем FxCop aka пунктик "Analyze Code" и он сообщает, что рантайм инициализацию делает автоматически, что надо убрать.
В общем, про "всегда" я был бы осторожен. Можно рассматривать частные случаи, когда такое будет, когда нет, и пр.
Оно только потом запоминается: строчку, целое и пр. — инициализуем string.Empty, объект — не надо, будет автоматом.
Я в том, что написал сверху не уверен, надо вспоминать/проверять, но вроде так было в C#.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, WPooh, Вы писали:
WP>А потом запускаем FxCop aka пунктик "Analyze Code" и он сообщает, что рантайм инициализацию делает автоматически, что надо убрать.
Так если использовать автоматические инспекции, то про то, инициализировать или нет можно вообще не задумываться . Если матерится — править чтоб не материлось. Не матерится — значит все хорошо. У меня была в свое время привычка все инициализировать, когда инспекций не было. Как появились инспекции — им стал доверять, пока поводов для недоверия они мне не дали.
Здравствуйте, LordMAD, Вы писали:
I>>в таком случае вариант x/2 + y/2 вообще идеальный. Погрешность в нем та же но он коммутативен.
LMA>В каком месте у него такая же погрешность? Среднее двух 1 точно равно 1, так как округления нет, а эта формула дает 0.
В твоей формуле округление в одном месте, в моей в другом.
Мой вариант коммутативный, твой — нет, а точность одна и та же.
I>>но вообще у тебя своя формулировка свойства коммутативности и алгоритмы, явно или неясно использующие эту коммутативность работать у тебя не будут.
LMA>Будут, если написаны правильно.
Не будут. Потому что после твоего трикса придется сравнивать целые числа вот так
abs(avg1-avg2) <=1
Что однозначно есть бред.
LMA>Я так понимаю, что если тебя попросят вычислить среднее с точностью до 100, то ты скажешь, что с точностью до 100 это уже будет не среднее арифметическое?
дело не в точности, а в коммутативности, см. выше
I>>avg(a,avg(b,avb(c,...)))
I>>чувствуешь, куда я клоню ?
LMA>К тому, что (1/2 + (3/2 + 5/2)/2) == 1 для твоего "идеального" варианта "x/2 + y/2"?
нет, твоя функция будет выдавать уникальный набор результатов в зависимости от порядка следования числе
В моем же случае пострадает всего лишь точность.
И вообще говоря не ясно с чем ты споришь, тебе надо добавить сортировку параметров в начале функции и всех делов.
В моем случае — корректировку на нечетные аргументы.
В итоге как ни крути твой вариант все равно хромает, т.к. слишком много кода.
Здравствуйте, LordMAD, Вы писали:
I>>Потому что ты нарушил основное свойство функции — коммутативность.
LMA>Еще раз: коммутативность выполняется c заданной точностью (с точностью до округления до целых).
Это значит что коммутативность отсутствует.
Решение простое — сортировать аргументы. Одна строчка кода и проблемы как не бывало. Только при этом твой вариант однозначно становтся говнокодом, хотя и правильным.
LMA>Я кажется начинаю догадываться: ты на полном серьезе думаешь, что "(x+y)/2" "будет работать правильно для, как сказано в задании, "любых значений типа int", то есть когда среднее значение двух положительных чисел получается отрицательным?
Уже было сказано не единожды — ошибку с переполнением найти гораздо легче, чем твою мега-коммутативность.
Вот скажи, часто ли кандидатам приходится ставить тебя в известность типа "на этот вопрос ответ был даден дважды 15 и 5 минут назад" ?
LMA>А "(int)(((double)x+(double)y)/2)" "не будет привязан к конкретной платформе", то есть ты правда думаешь, что для ILP64 преобразование из int в double будет корректным? I>>С даблами то решение тебе не нравится почему то LMA>Хотя бы потому что нет способа запихнуть 64 бита в 53 бита без потерь.
Для 32х бит работает идеально.
LMA>>>Во-первых, если у него есть сомнения, он может спросить.
I>>Во первых ты и сам не знал, что нарушил свойство коммутативности.
LMA>?
Здравствуйте, LordMAD, Вы писали:
LMA>Только почему "Лискова"? Если уж коверкать на русский манер, то получится "Лисковой". Хотя она, конечно, Лисков.
LMA>Ну, под senior вообще каждый своё понимает. Начиная от варианта, что он, в отличие от рядового разработчика, просто еще и проектированием занимается, и, заканчивая тем, что он курирует junior'ов.
H>>Рискну предположить, что разрабатываете что-то программно-аппаратное.
LMA>Точно.
Да, особенно важно название принципов из книжек
Я вот использую много паттернов из GoF , но если бы не читал эту книгу, то мог бы вполне ошибиться в понимании подобных вопросов.
И на самом деле я множество книг не читал,а вопросики могут всплыть и выйдет, что набираются "читатели умных книг".
Здравствуйте, Ikemefula, Вы писали:
I>Мой вариант коммутативный, твой — нет, а точность одна и та же.
Одна и та же точность результата?
I>>>но вообще у тебя своя формулировка свойства коммутативности и алгоритмы, явно или неясно использующие эту коммутативность работать у тебя не будут.
LMA>>Будут, если написаны правильно.
I>Не будут. Потому что после твоего трикса придется сравнивать целые числа вот так
I>abs(avg1-avg2) <=1
Нет, не так. Догадаешься как сравнивать надо?
LMA>>Я так понимаю, что если тебя попросят вычислить среднее с точностью до 100, то ты скажешь, что с точностью до 100 это уже будет не среднее арифметическое?
I>дело не в точности, а в коммутативности, см. выше
Дело в точности.
I>В моем же случае пострадает всего лишь точность.
Да. как и для return 0;
I>И вообще говоря не ясно с чем ты споришь, тебе надо добавить сортировку параметров в начале функции и всех делов.
Я спорю с тем, что это НАДО добавить.
I>В моем случае — корректировку на нечетные аргументы.
I>В итоге как ни крути твой вариант все равно хромает, т.к. слишком много кода.
Здравствуйте, Ikemefula, Вы писали:
I>>>Потому что ты нарушил основное свойство функции — коммутативность.
LMA>>Еще раз: коммутативность выполняется c заданной точностью (с точностью до округления до целых).
I>Это значит что коммутативность отсутствует.
Да ну?
I>Решение простое — сортировать аргументы. Одна строчка кода и проблемы как не бывало. Только при этом твой вариант однозначно становтся говнокодом, хотя и правильным.
Интересно узнать, что за критерий для говнокода ты имеешь в виду?
LMA>>Я кажется начинаю догадываться: ты на полном серьезе думаешь, что "(x+y)/2" "будет работать правильно для, как сказано в задании, "любых значений типа int", то есть когда среднее значение двух положительных чисел получается отрицательным?
I>Уже было сказано не единожды — ошибку с переполнением найти гораздо легче, чем твою мега-коммутативность.
При чем тут — какую ошибку легче найти? По-твоему, если человек делает ошибку, но эту ошибку легко найти, это его оправдывает?
LMA>>А "(int)(((double)x+(double)y)/2)" "не будет привязан к конкретной платформе", то есть ты правда думаешь, что для ILP64 преобразование из int в double будет корректным? I>>>С даблами то решение тебе не нравится почему то LMA>>Хотя бы потому что нет способа запихнуть 64 бита в 53 бита без потерь.
I>Для 32х бит работает идеально.
Ну вот и пусть те, кто в состоянии мыслить только в пределах одной платформы, идут лесом.
Здравствуйте, blackhearted, Вы писали:
LMA>>Только почему "Лискова"? Если уж коверкать на русский манер, то получится "Лисковой". Хотя она, конечно, Лисков.
LMA>>Ну, под senior вообще каждый своё понимает. Начиная от варианта, что он, в отличие от рядового разработчика, просто еще и проектированием занимается, и, заканчивая тем, что он курирует junior'ов.
H>>>Рискну предположить, что разрабатываете что-то программно-аппаратное.
LMA>>Точно.
B>Да, особенно важно название принципов из книжек B>Я вот использую много паттернов из GoF , но если бы не читал эту книгу, то мог бы вполне ошибиться в понимании подобных вопросов.
B>И на самом деле я множество книг не читал,а вопросики могут всплыть и выйдет, что набираются "читатели умных книг".
Нет, набираются люди, которые помимо того, что обладают практическими знаниями, имеют и должную теоретическую подготовку. Последнее нужно хотя бы для того, чтобы иметь возможность говорить "на одном языке", и чтобы не возникало сомнения, в том, что та или иная тема знакома человеку в полном объеме (пусть даже и без практических навыков), а не кусочками, исходя из того, что с чем-то ему уже приходилось сталкиваться, а с чем-то нет.
Например, мне встречались программисты под Windows, которые достаточно часто пользовались CreateProcess, чтобы помнить порядок аргументов наизусть, но при этом не понимали четко, за что ответственны процессы, а за что потоки.
Здравствуйте, LordMAD, Вы писали:
I>>>>Потому что ты нарушил основное свойство функции — коммутативность.
LMA>>>Еще раз: коммутативность выполняется c заданной точностью (с точностью до округления до целых).
I>>Это значит что коммутативность отсутствует.
LMA>Да ну?
именно так. потому что в твоем случае после применения мега-функции i == j писать уже нельзя.
I>>Решение простое — сортировать аргументы. Одна строчка кода и проблемы как не бывало. Только при этом твой вариант однозначно становтся говнокодом, хотя и правильным.
LMA>Интересно узнать, что за критерий для говнокода ты имеешь в виду?
слшком много кода и слишком много логики для решения простой задачи.
LMA>При чем тут — какую ошибку легче найти? По-твоему, если человек делает ошибку, но эту ошибку легко найти, это его оправдывает?
Нет, но если человек сделал ошбку вроде твоей и не хочет признавать так же как и ты — его вина гораздо более серьезная.
LMA>>>А "(int)(((double)x+(double)y)/2)" "не будет привязан к конкретной платформе", то есть ты правда думаешь, что для ILP64 преобразование из int в double будет корректным? I>>>>С даблами то решение тебе не нравится почему то LMA>>>Хотя бы потому что нет способа запихнуть 64 бита в 53 бита без потерь.
I>>Для 32х бит работает идеально.
LMA>Ну вот и пусть те, кто в состоянии мыслить только в пределах одной платформы, идут лесом.
Здравствуйте, LordMAD, Вы писали:
I>>Мой вариант коммутативный, твой — нет, а точность одна и та же.
LMA>Одна и та же точность результата?
Дело не в точности результата, а в том, что коммутативность влияет например на операцию сравнения.
I>>abs(avg1-avg2) <=1
LMA>Нет, не так. Догадаешься как сравнивать надо?
при правильной реализации вот так, avg1 == avg2
а в твоем случае это вариант применить нельзя из за мега-коммутативности
I>>дело не в точности, а в коммутативности, см. выше
LMA>Дело в точности.
коммутативность влияет на операцию сравнения
I>>И вообще говоря не ясно с чем ты споришь, тебе надо добавить сортировку параметров в начале функции и всех делов.
LMA>Я спорю с тем, что это НАДО добавить.
еще раз — если ты использовал свою мега-функцию, то обязан пройт по коду и все явные или неявные сравнения результатов переписать, потому что код
avg1 == avg2
больше работать не будет по причине "коммутативности".
I>>В итоге как ни крути твой вариант все равно хромает, т.к. слишком много кода.
LMA>По сравнению с чем? С return 0 ?
Здравствуйте, Ikemefula, Вы писали:
LMA>>>>Еще раз: коммутативность выполняется c заданной точностью (с точностью до округления до целых).
I>>>Это значит что коммутативность отсутствует.
LMA>>Да ну?
I>именно так. потому что в твоем случае после применения мега-функции i == j писать уже нельзя.
А какое отношение "i == j" имеет к коммутативности?
I>>>Решение простое — сортировать аргументы. Одна строчка кода и проблемы как не бывало. Только при этом твой вариант однозначно становтся говнокодом, хотя и правильным.
LMA>>Интересно узнать, что за критерий для говнокода ты имеешь в виду?
I>слшком много кода и слишком много логики для решения простой задачи.
Если ты сумеешь таки привести решение корректное и не зависимое от платформы, которое будет содержать меньше кода, тогда сможешь такое утверждать, а пока это bullshit.
LMA>>При чем тут — какую ошибку легче найти? По-твоему, если человек делает ошибку, но эту ошибку легко найти, это его оправдывает?
I>Нет, но если человек сделал ошбку вроде твоей и не хочет признавать так же как и ты — его вина гораздо более серьезная.
Просто твои "аргументы", что в решении, которое я привел есть ошибка — просто смехотворны.
LMA>>>>А "(int)(((double)x+(double)y)/2)" "не будет привязан к конкретной платформе", то есть ты правда думаешь, что для ILP64 преобразование из int в double будет корректным? I>>>>>С даблами то решение тебе не нравится почему то LMA>>>>Хотя бы потому что нет способа запихнуть 64 бита в 53 бита без потерь.
I>>>Для 32х бит работает идеально.
LMA>>Ну вот и пусть те, кто в состоянии мыслить только в пределах одной платформы, идут лесом.
I>начни с себя.
Здравствуйте, Ikemefula, Вы писали:
I>>>Мой вариант коммутативный, твой — нет, а точность одна и та же.
LMA>>Одна и та же точность результата?
I>Дело не в точности результата, а в том, что коммутативность влияет например на операцию сравнения.
I>>>abs(avg1-avg2) <=1
LMA>>Нет, не так. Догадаешься как сравнивать надо?
I>при правильной реализации вот так, avg1 == avg2
Да ну?
LMA>>Я спорю с тем, что это НАДО добавить.
I>еще раз — если ты использовал свою мега-функцию, то обязан пройт по коду и все явные или неявные сравнения результатов переписать, потому что код I>avg1 == avg2 I>больше работать не будет по причине "коммутативности".
Так пусть тот, кто по глупости писал "avg1 == avg2" (потому что чего-то там себе напридумывал, чего в контракте нету) и исправляет свой баг. С тем же успехом он может и числа с плавающей точкой сравнивать через == ...
I>>>В итоге как ни крути твой вариант все равно хромает, т.к. слишком много кода.
LMA>>По сравнению с чем? С return 0 ?
I>по сравнению с другими вариантами
Так ты приведи хоть один корректный вариант, не привязанный к платформе... В частности, который не подразумевает, что int имеет размер 32 бита, как твой последний "шедевр"...
Здравствуйте, LordMAD, Вы писали:
LMA>>>Нет, не так. Догадаешься как сравнивать надо?
I>>при правильной реализации вот так, avg1 == avg2
LMA>Да ну?
LMA>
Именно так, потому что это сравнение целых.
LMA>Так пусть тот, кто по глупости писал "avg1 == avg2" (потому что чего-то там себе напридумывал, чего в контракте нету) и исправляет свой баг. С тем же успехом он может и числа с плавающей точкой сравнивать через == ...
О чем и речь — твой мега-код влияет на сравнение целых чисел.
Здравствуйте, LordMAD, Вы писали:
I>>именно так. потому что в твоем случае после применения мега-функции i == j писать уже нельзя.
LMA>А какое отношение "i == j" имеет к коммутативности?
Потому что например i и j может вернуть функция которая _неявно_ использует avg.
I>>слшком много кода и слишком много логики для решения простой задачи.
LMA>Если ты сумеешь таки привести решение корректное и не зависимое от платформы, которое будет содержать меньше кода, тогда сможешь такое утверждать, а пока это bullshit.
I>>Нет, но если человек сделал ошбку вроде твоей и не хочет признавать так же как и ты — его вина гораздо более серьезная.
LMA>Просто твои "аргументы", что в решении, которое я привел есть ошибка — просто смехотворны.
Да, не все понимают свойтсво коммутативности, с этим я ничего не могу поделать.
Здравствуйте, LordMAD, Вы писали:
LMA>Если ты сумеешь таки привести решение корректное и не зависимое от платформы, которое будет содержать меньше кода, тогда сможешь такое утверждать, а пока это bullshit.
Вроде уже было показано несколько недель назад, но на всякий случай еще раз
int avg(int a,int b)
{
return a/2 + b/2 + (a%2+b%2)/2;
}
Здравствуйте, Ikemefula, Вы писали:
LMA>>>>Нет, не так. Догадаешься как сравнивать надо?
I>>>при правильной реализации вот так, avg1 == avg2
LMA>>Да ну?
LMA>>
I>Именно так, потому что это сравнение целых.
Ладно, объясню на наглядном примере: представь девайс который измеряет температуру и у тебя есть функция которая возвращает показание прибора в °С в виде целого числа. Прибор пусть будет с низкой точностью (например, он на базе термопары на эффекте Зеебека) — возвращает результат с точностью до 1°С. Помещаем прибор в комнату, где поддерживается постоянная температура с достаточной точностью. Вопрос: исправен ли прибор, если функция возвращает тебе сначала 20, а потом 21? Корректно ли проверять правильность прибора, надеясь, что он будет возвращать одинаковые значения при неизменной температуре которую он измеряет?
LMA>>Так пусть тот, кто по глупости писал "avg1 == avg2" (потому что чего-то там себе напридумывал, чего в контракте нету) и исправляет свой баг. С тем же успехом он может и числа с плавающей точкой сравнивать через == ...
I>О чем и речь — твой мега-код влияет на сравнение целых чисел.
Он влиет не на сравнение целых чисел, а на сравнение результата этой функции с результатом этой функции. И ничего плохого в этом нет.
Здравствуйте, Ikemefula, Вы писали:
LMA>>А какое отношение "i == j" имеет к коммутативности?
I>Потому что например i и j может вернуть функция которая _неявно_ использует avg.
Здравствуйте, Ikemefula, Вы писали:
I>Вроде уже было показано несколько недель назад,
Вроде нет.
I>но на всякий случай еще раз
I>int avg(int a,int b) I>{ I> return a/2 + b/2 + (a%2+b%2)/2; I>}
Да, это хорошее решение.
Но на мой взгляд, по его внешнему виду менее очевидно (по сравнению с тем, что приводил я), что оно дает правильные значения на граничных значениях. Понятно, что это очень субъективно и для других — может быть с точностью наоборот.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, Ikemefula, Вы писали:
LMA>>>А какое отношение "i == j" имеет к коммутативности?
I>>Потому что например i и j может вернуть функция которая _неявно_ использует avg.
LMA>И что?
И то, что после введения твоей функции придтся использовать сравнение целых чисел с оглядкой на твою функцию
. Если матерится — править чтоб не материлось. Не матерится — значит все хорошо. У меня была в свое время привычка все инициализировать, когда инспекций не было. Как появились инспекции — им стал доверять, пока поводов для недоверия они мне не дали.
