Re[6]: Факториал, почему его нет в стандартной библиотеке - Философия программирования

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

TK>Но я об этом уже говорил что мало область определения фактически очень маленькая. Однако на меня наседали и спрашивали так всё-таки почему?

Анекдот вспоминается:

Работал мужик стюардом на авиалиниях. И был там обычай -- когда пасажиры покидали самолет, они отдавали ему на трапе чаевые. Чем лучше он обслуживал пасажиров, тем больше чаевых получал. Кто-то давал $1, кто-то $5.

И вот однажды, набился полный самолет евреев, летевших на Святую Землю. Обрадовался стюард, видит, что все они люди обеспеченные, ожидает хороших чаевых. Весь рейс носился как угорелый, все желания выполнял, был вежливый и вообще чуть не пылинки сдувал.

Приземлились, подогнали трап. Он стоит радостный, ждет чаевых. Выходит первый пасажир говорит: "Молодой человек, ваша мама таки может вами гордиться. Спасибо!" и спускается по трапу ничего не дав. Второй говорит практически то же самое и так же ничего не дает. Так третий пасажир, четвертый, пятый и так до последнего. Последний останавливается перед потерявшим дар речи стюардом и говорит: "Вы так старались весь рейс, что мы решили отблагодарить вас достойно. Вот вам чек на $5000. Ваша мама таки может вами гордиться".

Когда стюард пришел в себя, он крикнул вслед удаляющимся пасажирам: "Евреи! Может это и не вы распяли Христа, но как же вы его мучали!"

Блин, хватит томить. Что тебе выдали за правильный ответ.

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

не понял какой-же все-таки ответ. но в голову приходит только: "потому что она на фиг никому не нужна"

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

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

TK>>кстати accumulate то хочет итераторы в качестве параметров. ИМХО не очень удобно его использовать для вычисления факториал числа. Думаю те кто его придумал всё-таки не предполагали его использовать

RO>

std::accumulate(boost::counting_iterator<int>(1), boost::counting_iterator<int>(n), 1, std::multiplies<int>())

А теперь представь что ты это увидел в доставшемя по наследству коде...

--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>

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

M>Тот кто умеет быстро решать простые задачи лучше того, кто ни быстро ни медленно ни простых ни сложных задач решать не умеет.

Может быть это и так, но:
* собеседование ограничено по времени, соответственно, нет возможности определить, может ли человек решать задачи медлено. Быстро не решил -- свободен, значит вообще решать не умеет;
* собеседование, как и экзамен -- это достаточно стресовая ситуация. Не так уж много людей могут концентрироваться должным образом в условиях стреса. А ведь людей, в большинстве случаев, нанимают для работы в спокойных, размеренных условиях. В которых многие способны нормально думать и вполне успешно справляться с заданиями, которые казались им неразрешимыми на экзаменах/собеседованиях;
* собеседование, во главу угла которого ставится выяснение способности решать сложные логические задачи, не способно выявить других важных качеств человека. Например, таких как обязательность, исполнительность, аккуратность, спокойствие, наличие здравого смысла. А по жизни такие люди способны принести команде и проектам больше пользы, чем неуравновешенные гении;
* логические задачи при своей сложности и оригинальности являются маленькими задачами. Тогда как в работе приходится сталкиваться с гораздо большими по объему задачами, пусть и менее сложными. И здесь, вообще-то говоря, нужен несколько иной набор навыков: т.е. способность держать в голове больше деталей, пусть и обрабатывая их намного медленнее.

Собственно, примерами вышеизложенных причин могут служить олимпиады по программированию. Не так уж часто доводилось видеть победителей олимпиад, которые затем становились хорошими программистами. Чаще было наоборот. Хотя это может быть мне так везло.

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

E>Или ты считсаешь, что функцию pow в стандартную библиотеку включили зря и по глупости?

Не надо мне приписывать то, чего я не говорил или делать неверные выводы из моих слов.

E>IMHO если А -- это частный случай В, то В -- это обощение А... Типа чиста по определению...

Типа, чиста с логикой у тебя траблы. Чиста так

Такой бред и комментировать излишне.

E>Ну вы может и не получаете, а у математиков давно уже получилась функция гамма. Мало того, если говорить только о самом факториале, то я не понимаю, почему считается некорректной задача "вычислить факториал с точностью 15 десятичных знаков"? Что в ней такого необычного? Так вроде бы со всеми большими числами принято работать... В этом смысле и с функцией pow мы при обощении её на вещественные числа ничего новго "кроме ошибок округления" не получим, пока не начнём подставлять в неё вещестывенные аргументы... Так и чем pow от гаммы, а целочисленное возаведение в степень от факториала отличаются?

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

TK>Ладно, всё не буду больше томить

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

TK>Ладно, всё не буду больше томить

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
TK>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

Похоже, что они просто приняли всерьёз шутку из какой-то статьи/воспоминаний/блога

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

TK>Ладно, всё не буду больше томить

)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>2) Таки ветку прочитай, возможно узнаешь что-то новое. Например про функцию гамма, а так же про то, что double позволяет точно представить факторилал большего числа, чем int32 и даже int64...

Использовать int64 для работы с большими числами тупизм примерно того же уровня что и использование fact: num -> double в тех случаях, когда нужна точность до единичного разряда включительно. Нормальные люди для этих задач используют http://gmplib.org и им подобные.

Если ты не понимаешь что double точность операций до единицы на больщих целых обеспечить не может — прими мои соболезнования. Клиника. В этом случае спорить действительно не о чем. В этом случае надо только лечить.

Предлагаю эксперимент

Мы же программисты, если ты посчитаешь хотябы 150! с точностью до единицы используя тип double (функция должна иметь вид fact ... -> double) — ты молодец. В противном случае — слив зосчитан

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

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
Вот так мы лишились поддержки BigInt в STD!!!

А вообще: В int32 вмещается только 12!, в int64 — 20!
В дабл если без потери точности — где то столько же.

Для 20ти значений можно тупо табличку забить. Без поддержки безразмерных чисел функция, вычисляющая простой факториал вообще не нужна.

["Было скучно" mode ON]
Любопытства ради набросал вычислялку факториалов. Кстати замечательный крэш-тест для кучи подсистем одной либы получился.
Теперь у меня есть файлик с hex значениями [1! — 65536!]. Никому не надо? Всего то 7'430'013'017 байт удовольствия!

Кстати: 65535! занимает 954037 бит или 287194 десятичные цифры (преобразование заняло минуты 3 в сравнении с 2мя секундами вычислений) и заканчивается 16380-ю нулями
["Было скучно" mode OFF]

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Ну самокритично так выступаешь

Я вообще-то тебя имел ввиду

E>А я и не утверждал, что в системе типов С++ можно легко вычислить хоть "400!" хоть "PI/2 в 400-й степени"... Я всего лишь утверждаю, что ДЛЯ ПРАКТИЧЕСКИХ ПРЕМЕНЕНИЙ достаточно вычислить приближённо, с точностью оступной в double. Чем, в конце концов факториал отличается от степени, синуса или корня? Почему все остальные функции приближать можно, а факториал обязательно вычислять точно... Ты что-то писал про то, что "вычислять факториал неточно" было бы верхом глупости. Ты можешь как-то этот тезис аргументировать? Примеры там привести, например, как вычислить фактоирал большого числа (скажем 100) и почему глупо его вычислять неточно?

Удачи тебе в практических прЕмениях факториала приближенно

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

Y>Ну опять же, речь шла про библиотечную функцию вычисления факториала. Надеюсь ты не будешь говорить как Егор о том, что ее тоже можно вычислять как double с потерей точности.

Буду. Потому что ее можно вычислять с потерей точности. И ты пока не привел ни одного обоснования почему этого делать нельзя. А наличие формулы Стирлинга просто проигнорировал.

Y> Ну вообщем все понятно.

Это точно.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>

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

Сообственно почему? ИМХО, куда более полезная вещь чем факториал

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

Если ответ как в SUBJ, то они настоящие панки

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

TK>Ну ссылок на C&R мне естественно не дали, наверно потому что немного растерялся и не попросил.
TK>Начал рассуждать, сказал что требования к функциям в стандартной библиотеке: эффективность и удобство. Привел два примера реализации на этапе компиляции и на этапе выполнения. Сказал что и тот и другой способ удовлетворяют обеим требованиям, хотя может быть не внесли потому что факториал можно посчитать только для небольшого количества натуральных чисел, иначе будет переполнение, а это в чём то неудобно. После этого на меня начали наседать так почему всё-таки не включили? Я начал ходить кругами вокруг того что сказал, мне сказали "ну что ж вы претендуете на Seniour Software developer/Team leader и не можете сказать почему стоит включать тут или иную функцию в библиотеку"

(что помоему не очень политкорректно) потом добавили в "...стандартную библиотеку"

Ну вообщем мне сказали то что хотели от меня услышать, он вполне логичен, и до него мне остался один шаг, хотя не очевидный. Вообще эту причину трудно понять, пока не попишешь сам STL.

Ну раз они такие подлые, то когда ты скажешь правильный ответ мы тебе придумаем 1000 и 1 причину, почему их ответ неправильный. Дабы у тебя свалился камень с души

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

И какой же он, этот правильный ответ? Не томите!

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

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

Ovl>>не понял какой-же все-таки ответ. но в голову приходит только: "потому что она на фиг никому не нужна"

TK>Хороший ответ, разумный и логичный. Действительно фактор как таковой нужен крайне редко.

TK>Но так отвечать на собеседовании не хорошо

тогда второй вариант: придется объяснять что такое факториал индусам

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
TK>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

Хорошо, тогда встречный вопрос к ним — почему в стандартной библиотеке нет класса больших чисел? Потому что его было бы геморрно поддерживать? Думаю, он был бы гораздо полезней этого факториала.

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

V>Это ты определись как будешь целое из дабл вытаскивать с абсолютной точностью?
round не подойдёт?

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

E>Раз ты ничего, кроме улыбочек не можешь ответить, переформулирую вопрос.
E>Чем факториал так сильно отличается от функции "N в степени M"? Почему вторую можно делать над вещественными числами, а первую нет?

Ну ладно, ты наверное про функцию pow или exp. Надеюсь с exp все понятно, т.к. это e в степени такой-то, причем показатель степени может быть рациональным, соответственно, результат у нас будет тоже рациональным.

Теперь разберемся с pow(a, b), где результат, есть а в степени b. В данном случае, в качестве аргументов, опять же могут выступать рациональные числа и результат у нас соответственно тоже будет рациональным.

А здесь ты можешь спросить, почему у pow при целочисленных аргументах, в результате у нас опять всегда рациональное число, ответ, показатель степени может быть отрицательной величиной.

Обе эти функции объединяет одно, их невозможно вычислить точно.

Теперь про злосчастный факториал, здесь все просто, при любых аргументах функции, да и функция сама в целом, всегда имеет целочисленный результат. А теперь про самое главное, почему ее не стоит использовать для хранения целочисленных значений. Не сохраняются свойства коммутативности и дистрибутивности арифметических операций. Очень легко нарваться на ошибки округления. Когда как, факториал можно и нужно вычислить точно, вычислять ее неточно, было бы верхом глупости. Не говоря уж о том, что это медленее и гораздо целесообразней вместо 52 разрядов мантиссы использовать 64х битный целочисленный тип.

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

Y>Теперь разберемся с pow(a, b), где результат, есть а в степени b. В данном случае, в качестве аргументов, опять же могут выступать рациональные числа и результат у нас соответственно тоже будет рациональным.

1) Видимо ты используешь слово "рациональный" вместо слова "вещественный"? Потому, что, например "0.5 в степени 0.5" нифига не рациональное число...

Y>Обе эти функции объединяет одно, их невозможно вычислить точно.
Разве? А что мешает вычислить число "4 в 7-й степени" точно?

Y>Теперь про злосчастный факториал, здесь все просто, при любых аргументах функции, да и функция сама в целом, всегда имеет целочисленный результат. А теперь про самое главное, почему ее не стоит использовать для хранения целочисленных значений. Не сохраняются свойства коммутативности и дистрибутивности арифметических операций. Очень легко нарваться на ошибки округления. Когда как, факториал можно и нужно вычислить точно, вычислять ее неточно, было бы верхом глупости. Не говоря уж о том, что это медленее и гораздо целесообразней вместо 52 разрядов мантиссы использовать 64х битный целочисленный тип.

Ну ты приведи пример как с факторияалом легко, а с pow не легко...
Кроме того можешь пояснить как вычислить точно число 400!

Здравствуйте, Сергей Мухин, Вы писали:

E>>>>Почему? Что не ясно в этом коде:

assert( n == 1 || n == 2 );
n = 3 - n;

СМ>>>ты что, считаешь сопровождать будешь ты, такой умный? Или Вася П.?
E>>Ну, то есть не ясно, что 3 = 2 + 1?

СМ>откуда тут +? Опять выдумки и передергивание
Как откуда? Ты не понимаешь откуда тут берётся константа 3?

E>>Аргументы про выбор из трёх решений, в случе 1 <=> 2 пока что так и не последовали...
E>>Про "нет вкуса" -- это конечно аргумент, только мутный какой-то. IMHO к умению программировать отношения непосредственного не имеет.

СМ>обрати внимание, сколько ИМХО ты написал при общении со мной,Ю штук 5. а аргументов нет!
СМ>НЕТ!
Да? Аргумнет был, ты его не заметил. Он состоял в том, что IMHO, хороший программист задал бы в ответ на твою задачу вопрос, что делать если переменная равна чему-то кроме 1 или 2. А все остальные рассуждения, что там типа лучше, а там хуже, и что инструкция по кодированию зло и т. д. -- это всё местечковые всякие замороки.

Ну а что касается "IMHO", то я, в отличи от тебя, просто не претендую на истину в последней инстанции...
Хотя и тебя пока что правым не считаю...

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

Y>Это называется полный финиш, приехали

Слив засчитан

... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>

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

AVK>>Нет. Логической цепочки не вижу — почему из того, что результат всегда положительное целое число, следует невозможзность применения представления числа не с абсолютной точностью.

Y>Вот я чуть пониже написал почему

Нет, не написал. А вот ты прямо заданный вопрос проигнорировал.

Y>Потому что приближенное значение запросто может оказаться не факториалом.

То есть плавучка вообще не имеет права на жизнь?

AVK>>А приближенный результат вычисления квадратного корня не подходит под определение корня? Ведь по определению pow(sqrt(2), 2) Должен бывть равен ровно 2, а по факту будет где то в районе 2, но не точно 2.

Y>Ну вообще-то да, ты сам себе же и ответил.

То есть функции sqrt и pow тоже не стоило делать, так что ли?

AVK>>Наличие формулы Стирлинга означает, что приближенное вычисление факториала имеет практический смысл.

Y>...для вычисления приближенного значения факториала

И?

Y>>>ну можно большие значения факториалов вычислить приближенно, это не так важно, т.к. результатом могут быть и факториал или его приближенное значение. Вот, я все сказал.

AVK>>Ты сам понял, что ты сказал?

Y>Я то понимаю, а вот ты к сожалению не понимаешь.

Если ты не можешь объяснить внятно, значит тебе только кажется, что ты понимаешь. А на самом деле нет.

Y> Извини, но я не могу продолжать больше беседу.

Слив в очередной раз засчитан.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

E>Зато я понимаю, что
E>1) там, где нужна "точность до единиц" double не используют, но в больших числах она нужна крайне редко.
E>2) Ты так и не прочитал всю ветку, так как ничего неового не пишешь

Не прошло и пары дней как мы начали думать конструктивно. Теперь мы сделали правильное умозаключение: способ представления факториала определеяется теми требованиями, которые к нему выдвигаются. Для одних задач достаточно иметь fact: Double -> Double, в других нужен fact: Nat -> Nat. Какой случай чаще встречается на практике лично я не знаю. Статистикой не владею, к сожалению. Если ты владеешь, то линка будет достаточно.

Однако одно я знаю точно — fact: Nat -> Nat, где Nat — произвольно большое натур. число — наиболее универсальная реализация факториала. Имея fact можно получить fact_dbl : Nat -> double, fact_int: Nat -> int и прочее и прочее. В случае если имеешь только fact_dbl: Nat -> double функцию fact: Nat -> Nat ты не получищь. Просто потому из-за плавающей точки теряешь точность вычислений. Именно поэтому я говорю, что хранить факториал в double-ах не всегда правильно. При условии, что ты не знаешь как в дальнейшем будет использоваться значение факториала, надо выбирать наиболее универсальный вариант.

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

TK>>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
E>А почему нельзя факториал возвращать в double?..

О! Нужно такой вопрос взять на заметку, чтобы заранее отсеивать откровенно слабых кандидатов.

Здравствуйте, yumi, Вы писали:
Y>Это утверждение равносильно такому, что sin(0) = 0, значит мы можем sin вычислить точно, и => что мы можем написать такую сигнатуру для sin: int sin(int x); Что в корне неверно. ИМХО это уже клиника, без обид.
Во-первых, за рассуждения про клинику, ПТУ и прочее у нас принято подвергать принудительной коммуникативной аскезе. Крайне рекомендую во избежание сего, подобных высказываний избегать.
Во-вторых, нахальство в нашей области деятельности принято подкреплять технической квалификацией. Ты пока что не не продемонстрировал.
Резюме: вместо того, чтобы наезжать на умных людей, почитай что тебе пишут.

... << RSDN@Home 1.2.0 alpha rev. 677>>

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
TK>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

надеюсь вы им ответили что та же std::accumulate не удовлетворяет этому требованию? и куча остальных контейнеров — тоже?

короче, похоже им там совсем скучно. шли бы поработали.

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

Могу предположить:
В стандартную библиотеку включаются только те функции, которые имеют одно оптимальное решение, т.е. так сказать "без-вариантные", т.е. если бы кому-то пришла в голову идея реализовать такую функцию, то он всё равно бы реализовал аналогичным способом, т.е. не получил бы никакого выигрыша по сравнению со стандартной реализацией. В частности такими функциями являются функции, которые имеют аппаратную поддержку на большинстве платформ.
Для факториала явная неоднозначность — толи реализовывать через вычисления, толи через таблицу. Трейдоф скорость-память. Комитет по стандартизации просто не может взять на себя ответственность однозначно разрешить этот трейдоф для всех приложений.

з.ы. хотя, конечно, например для функции сортировки тоже приходится выбирать некий трейдоф, тут тоже не совсем однозначно. но для неё хотя бы определили, что что вычислительная сложность O(NlogN)...

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

Y>Не надо мне приписывать то, чего я не говорил или делать неверные выводы из моих слов.
Ну "верные" сделать пока не получается

Я так и не понял в чём состоит принципиальная разница между ситуациями:
pow( 2.0, 3.0 ) =def= 8.0 (AKA 2 ** 3 = 8)
и tgamma( 3.0 ) =def= 6.0 (AKA 3! = 6)

E>>IMHO если А -- это частный случай В, то В -- это обощение А... Типа чиста по определению...

Y>Типа, чиста с логикой у тебя траблы. Чиста так

Y>Такой бред и комментировать излишне.
Ну тогда можешь рассказать в каких взаимоотношениях находятся понятия "частный случай" и "обобщение"..

Или ты считаешьпонятия "общий случай" и "обобщение" принципиально разными?

Y>Ну вот опять пошло по новой, ты все продолжает гнать свое. Я устал, на этом я вынужден беседу закончить.
Ну в целом на личности ты уже перешёл, примеров не привёл, оскорблений понаписал. Действительно, показал себя во всей красе, можно, пожалуй, и заканчивать...

На всякий случай вопроса было два, и оба простые и направленные на уточнение твоей агрессивной позиции.
1) Зачем (в каких практических целях) нужно вычислять факториалы больших чисел абсолютно точно?
2) Почему факториалы нужно вычислять точно, а сепени, можно только с точностью 15 знаков?

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

E>И какой же он, этот правильный ответ? Не томите!

правильный может быть только со ссылкой на C & R. Иначе это в той или иной степени предположение.

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения
Как почему? Чтобы каждый мог проверить как работает хвостовая рекурсия!

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

E>>>А почему нельзя факториал возвращать в double?.. :)
LVV>>Потому что 1755! > 10^4932 (это max число в пентюхе)
V>Точность для факториала из целого числа должна закончится в [long] double гораздо раньше.

И что? Для каких задач настолько существенна разница между

0,34736046e4934

и

34736046171342926471950490448197231870919660715461259364355810230877
87936784926408720832804094578856378567243823512917824545321467479405
16759896874824921941613901498464521512079131063314193446115382048068
43792673363843461179511742084048916974937090952728398525241868065275
22507196165970287249774987616064609069162111028703609619116540318828
48828465289318717463965141527115381423248026680219497435022244931537
80490247623148395508489530122703943399027539945794613275001055966312
16532631875046254572281973604238003238250788563941951127980420617201
72012877096131984145804481172748779132981855730423465975321270740913
44316368040944319065494243794907991737361715095892631094264328596280
83818335520139756270701610878294350837292620227451571480691859274751
16435719814444079960553612856444043948136284887444854430139708114586
21619642095645137825334164207074555241021402995804017287034244160985
59253365202510960348147650239113732560870471813450456769666250204606
77575699946783008132146677771227205440384815855233743606971815926659
78091929504427380785720267020515673054140718916118220996215662157549
03770965380166358794016371220979077240129431885278999906814100787867
67222472481762188500852552856999413889589212772397498545896043771725
75026670357176121058216893648671591628641071390884588916991384672404
40476991492124115168767131271041048453933713016274560357214635582165
27538065180622140890594301820222365248001436214487135592706404702832
20936373497245023579233035260423173349413204217659795460334058432311
54624259490361871380231695454788968423623471806221627218570745720414
07512023597493789517394079385528199207355566265861604632380400931151
14507085439687838865363615164713205418394018941616834958350284463766
13687729773071112968274270610503525304024263859575165131151015482209
04400718423270695261576995213896588624975125991922802463661267199823
61375954863540285154078659586116485684151331624455373279217406413217
15111205114695585928808762700251323783660454949182305411447911891108
81340321980179539348493363082127240341689207826228296854962003911355
63873571482482933770347546763188591367335384316624416986991558323945
74134942571602384648589614698367767413352944450875540368061771718163
40903603304281276498245856265468651163514526847194666020632465925398
44940801589336918461756458910314654680981045882227354710921999775395
92688663306465972476356884645227312734065719319664425159764444791987
48692357791331020849877928101220886677287359386297493223624254570924
26946600231698563026174583267784181834924227058716708722315379034858
43783271617192313652287754667865108709809893504759771057593450546441
42227142737516312033246054401502088633173159008018889422073218340675
96843293618769940293368945297604410548525575853462119617569915674424
99514326852316251724206528645550481952578657307508845220564199069590
23444959151146260121317631209383246403913518021534286296005237302847
10046578233984799543970803424877916800644334856418002044470879748971
88405112418066638692623736343348877407142264853801811889470465901897
12506371373119248213806945901894959875671140799141873485900804411318
77602020164762724767797542928773083090803872091767666540605820090097
69816191190377690727977857375773438214847786965136805745577780495903
91383497134192084300312940776845803059606632990986744564398393534240
94012649203627189287405258016727313395463056641190391219116823350747
99096281663400407542014473261339939357540321705632734776050774402964
26291975101826959883862907533034429698752228558618045655414710755806
28432175149913619602676273966339322757634589050724461925015800303623
31301903631469390964895285791923029835343668659453888102319429990633
05471038271208758592900443350855139544182927674592495774014070686992
49469406009304286731959797984996254781220462877283558209685252449489
88732244198405617467398892403334912628013268572885067415113308216092
67768847613254004564197005594356950297745734933302363409233832257546
86273165682128780648610966288609637075448449654668222025551527790622
78406210874681716180866394065674766291944902103708937506734175554086
71807028842793522802851007835940137646585796379125882063366253601089
38629270749110014365727175116890221904711912361938937331373489609167
38885245520662884097911258536902966927712201375714405969429573819503
46872874227770736260883140127227413938998649681352589435818879693443
86965511668549646275905277627782253580421675388798667220720079341357
99394040294935383995788570406134302416473240889069988447985478472900
39047677104623207595805981414984599902374325672395329200947174910850
82991001600000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000

?

Здравствуйте, Сергей Мухин, Вы писали:

СМ>просто всем надоела задача про круглый люк, вот они и выдумывают, не всегда качественно.

А что это за задача?

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

M>Как мне кажется, если люди понимают истину, то они и друг друга смогут понять.
напугала эта фраза

и вспомнилось :

Идет святой отец по деревне, а ему на встречу бегут трое взъерошенных парней. Один из них говорит:
-Святой отец, рассуди нас, вот я говорю: "Вот так, так и так!".
— Ты прав, сын мой!
Второй, чуть не перебивая священника:
-Святой отец, но как же так ? Я говорю: Вот эдак, и так!"
-Ты прав сын мой!
Третий, с сомнением :
-Святой отец, да как это может быть? Ведь истина то, одна!
-И ты прав, сын мой!

PS Сильно камнями не кидаться, просто уж больно это экзотическое понятие, истина... далековато до нее в реальной жизни обычно....

Здравствуйте, elmal, Вы писали:
E>Я бы, как разработчик стандартной математической библиотеки для языка, у которого скорость выполнения программ на весьма приоритетном месте, опирался на возможности наиболее распространенного железа разных платформ. Железо у нас мат сопроцессор, если мне не изменяет память у него нет команды вычисления факториала, если бы была, при реализации библиотечной функции я бы использовал ассемблерные вставки с кучей ключей условной компиляции под разные платформы и разные сопроцессоры, в результате моя библиотечная реализация была бы лучше, чем написанная вручную без учета возможностей железа. Синусы, косинусы железом поддерживаются — вот они в библиотеке и есть в результате. А нет ее в железе потому, что собственно и не нужна особо похоже, выигрыша в скорости не дает. Так зачем включать тривиальную для реализацию функцию в библиотеку? Была б нужна, давно б включили уже, велосипеды бы в каждом проекте надоели быстро.
Что-то мне подсказывает, что в языке, заточенном на оптимальную производительность, факториалы для всех встроенных типов лучше всего будут работать в табличном виде. Даже для встраиваемого устройства расходы по памяти на таблицы факториалов сопоставимы с объемом кода вычисляющей его функции. Если сборка исполняемого кода выполняется оптимизирующим линкером, то неиспользуемые таблицы будут выброшены.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

M>>Ну дык, это ж непаханное поле — подсидеть начальников на три уровня

E>Ну я бы тебя на работу не взял...

Я бы не взял в первую очередь за утверждение, что истина одна единственная, и при этом ее можно чуять, а умом, конечно же, не понять. Крестовые походы, это не то, что мне бы хотелось видеть на работе.

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>офигеть, человек приходит со своей инструкцией кодирования и нестандартным assert на собеседование — гнать в шею.
E>Ну ты же на собеседовании соискателя со своей версией инструкции не знакомишь?

E>А в общечеловеческом смылсе полезность или вредность assert зависит от инструкции и от используемой реализации...

это твой бред. нет у меня инструкции и не будет. инструкцию к программе не подошьешь, а значит она вред

СМ>>в оригинале написано return 3-n; ГДЕ ТУТ throw? throw был в более правильном варианте
E>return 3-n; Вообще не ответ на исходный вопрос, "есть переменная, если у нее значение 1, присвоить ей значение 2, а если 2, то 1. (на любом языке прогр)."... Поведение в случае n == 8, кстати, неспецифицированно в задаче. IMHO хорошо, если соискатель спросит: "а что сделать, если равна 3?", а всё остальное не важно.

СМ>>>>3. из 3-n неясно что хотел программист
E>>>Почему? Что не ясно в этом коде:

assert( n == 1 || n == 2 );
E>>>n = 3 - n;

СМ>>ты что, считаешь сопровождать будешь ты, такой умный? Или Вася П.?
E>Ну, то есть не ясно, что 3 = 2 + 1?

откуда тут +? Опять выдумки и передергивание

СМ>>А ему надо будет вставлять преобразование 6->19 например.
E>Ну 25 найти уже сложнее. На я таки надеюсь, что в нормальной программе числа вроде 6 и 19 задаются не литералами, соответсвенно вариант превращается в перечисление и в switch.

E>>>Хотя, если 1 и 2 -- это элементы перечисления бы были, то я бы наверное switch написал, а вот для bool однозначно так напишу:

f = !f;

СМ>>вот как он относится к совету, после ответа что оба варианта — дело вкуса — значит нет вкуса у него.
E>Аргументы про выбор из трёх решений, в случе 1 <=> 2 пока что так и не последовали...
E>Про "нет вкуса" -- это конечно аргумент, только мутный какой-то. IMHO к умению программировать отношения непосредственного не имеет.

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

Наверное у вас большие очень зарплаты, раз можете себе такое позволить

обрати внимание, сколько ИМХО ты написал при общении со мной,Ю штук 5. а аргументов нет!
НЕТ!

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

E>IMHO, тоска в другом -- в терминах разработки ПО, как коммерческой деятельности, этот их "диспут до бесконечности" неэффективен.
E>Намного эффективнее команда из двух прагматиков, которые может быть сделают всё не так "близко к истине", но таки сделают что-то нужное людям, в том числе и клиентам

Если бы мир состоял из одних "прагматиков" прогресс рано или поздно остановился бы.

Вообще, группы надо строить так, чтобы был выраженный технический лидер, спорить с которым долго ни у кого не получалось.

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

FR>>Научись пожалуйста читать сообщения целиком

E>А я целиком прочитал. Видимо ты, как-то иначе чем я понимаешь фразу "выравниваем на XXX".
E>Я её понимаю так, что смещение адреса в сегменте (либо просто значение адреса, при плоской памяти) выбирается кратным XXX.

Ликбез не нужен, по сообщениям выше в этой теме видно что ты большой любитель поспорить, кстати я тоже, но не сейчас

Тем более я вполне с тобой согласен, просто нечайно вначале сказал "выравнивание" вместо sizeof, если и дальше хочешь прикавыатся и раздувать это и спорить, то делай это без меня

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

Y>Удачи тебе в практических прЕмениях факториала приближенно

О! А не изволит ли уважаемый дон перечислить практические применения факториала?

... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>

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

Y>Ну я вроде нигде не говорил о том, что он применяется на практике, но это действительно так. Точнее напрямую он сам не используется, но достаточно поглядеть на такой раздел математики как "Комбинаторика", как он косвенно используется в очень многих местах, например как сочетания, перестановки и биномиальный коэффициент.

1) IMHO считать биноминальные коэффициенты через факториал -- это новое слово о точности и эффективности вычислений

Я бы ещё понял, если через нисходящий факториал, и то слишком неэффективно получится, и переполнение получить легко.
2) Советую открыть для себя ещё и ]Бета-функцию, а не только гамму...
3) Ну и главное. Открой таки тайну, зачем вычислять биноминальный коэффициент точнее, чем точность с которой ты умеешь оперировать с числами?

Как и зачем ты собираешься использовать такой сверхточный коэффициент?

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

XC>>Сообственно почему? ИМХО, куда более полезная вещь чем факториал
XC>>

Ovl>скорее уж сд-эджектор..

CD-Ejector в стандартную библиотеку собирались добавить много раз, но каждый раз автор функции понимал, какой же это шанс озолотиться, объявлял код проприетарным и начинал продавать...

вот такая вот грустная история.

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

C>Потому что, при больших x значение x! в double будет сильно отличаться от реального x! man числа с плав. запятой.
Блиииин

Щас же весь флейм по новой начнется!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Остынь и прочитай все таки всю ветку.
Там есть ответы на твои вопросы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>просто всем надоела задача про круглый люк, вот они и выдумывают, не всегда качественно.

E>А что это за задача?

гм. здесь

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>хотя решение 3-n имеет свои плюсы, но больше минусов.
E>А какие минусы ты в нём видишь? assert можно и в 3-n написать...

1. assert — зло
2. в ответе assert не было
3. из 3-n неясно что хотел программист

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения
Имхо, для факториала все "разумные" результаты проще посчитать заранее. Слишком быстро переполнение возникнет.

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
TK>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

ребята совсем не знают что такое языки программирования.

Типы гораздо более базовая вещь чем ф-ии библиотеки, и когда идет разработка/выбор библиотеки НЕ РАССМАТРИВАЮТ новые типы, а только те, которые уже есть в языке.

Так что ответ был дан правильный.

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

V>>Что что? Число неправильное получите вот что.
E>А что, для sin( 1 ) "правильное", что ли получу?

Синус получит плавающее, а здесь целое.

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>>просто всем надоела задача про круглый люк, вот они и выдумывают, не всегда качественно.

E>>>А что это за задача?

E>Интересная штука: у меня никогда не получалось решать подобные задачки быстро. Когда попадались сложные логические задачи (на разный вес настоящих или фальшивых монеток, три лампочки с выключателями, зашифрованные буквами числа при перемножении в столбик и пр), то многие из них я решал, но либо через несколько часов напряженных размышлений, либо на следующий день решение как-то само по себе находилось.

E>Со мной в университете, лет пятнадцать назад был показательный случай. Мой однокурсник задал нам задачку из коллекции Эдисона (мол Эдисон задавал ее потенциальным кандидатам на работу). Какая-то странная конструкция из бумаги, которую нужно было повторить за несколько минут из обычного тетрадного листа. Я эту задачу не решил, а этот однокурсник решил. В итоге -- я пишу программы, он владеет собственной торговой фирмочкой в Москве.

E>Так что может эти логические задачи и могут как-то определять какие-то способности человека. Но вот отбирать с их помощью программистов вряд ли имеет смысл

Вы сами проводили собеседование? И если да то сколько?
Рано или поздно понимаешь, что это время потрачено на 95% зря, и надо за 15-20 мин определиться с кандидатом. Поэтому задаешь ему все что в голову прийдет. И смотришь как он отвечает. А потом мб задания даешь. Один раз мы взяли чел, который не написал задание и не разочаровались. Необязательно правильно ответить, необязательно даже блико ответить. Я смотрю как чел ведет. Называет он слова "дрова" и тп, Большим плюсом, если он говорит "я не знаю как ответить на этот вопрос"!

С другой стороны мб в душе уже решили, но что бы убедить себя и тебя, задают каверзный вопрос.

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

Ovl>тут подумалось:
Ovl>мне почему-то кажется, что проблема в том, что функция допускает рекурсивную реализацию

Многие функции из STL написаны с помощью циклов и точно так же их можно реализовать рекурсивно.
Вообще я где-то слышал что будто бы доказано математически что рекурсия всегда может заменить цикл.
То есть из-за того, что она допускает рекурсивную реализацию её нельзя включить в STL? Ну не знаю, могу сказать что это совсем не то что я услышал

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

TK>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
А почему нельзя факториал возвращать в double?..

TK>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>ребята совсем не знают что такое языки программирования.

СМ>Типы гораздо более базовая вещь чем ф-ии библиотеки, и когда идет разработка/выбор библиотеки НЕ РАССМАТРИВАЮТ новые типы, а только те, которые уже есть в языке.

Согласен.
Если человек работает, например, с int. То "большой" тип, возвращаемый *одной* функцией нафиг не нужен.
А если человек хочет работать с "большим" типом, то одна функция, работающая с этим типом, тоже нафиг не нужна.

Т.е. имеет смысл делать либо факториал, работающий с существующими типами, либо полную поддержку нового типа.

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>про гамму ф-ию я уже говорил, но ее реализация м.б. не очень тривиальна.
E>Это повод её не включать?

E>Надо было у них спросить почему, по их мнению, гаму не включили

давайте сразу определим ВСЕ ф-ии, которые не включили. и начнем определять причины! их не включения

для начала остановимся на математических.

ps

я еще одну причину придумал про факториал! они хотели сделать соответствующую постфиксную операцию! но не успели.

pss
что то много воскл знаков у меня! Наверно тема навевает.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>про гамму ф-ию я уже говорил, но ее реализация м.б. не очень тривиальна.
E>>Это повод её не включать?

E>>Надо было у них спросить почему, по их мнению, гаму не включили

СМ>

СМ>давайте сразу определим ВСЕ ф-ии, которые не включили. и начнем определять причины! их не включения

СМ>для начала остановимся на математических.

СМ>ps

СМ>я еще одну причину придумал про факториал! они хотели сделать соответствующую постфиксную операцию! но не успели.

СМ>pss
СМ>что то много воскл знаков у меня! Наверно тема навевает.

Эээ, не много не в теме. А что такое гамма функция?

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

TK>Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?
TK>Вы бы ответили?

Обычно такие вопросы задают, чтобы уменьшить тебе зарплату.
В следующий раз скажут, что у тебя трусы не того цвета, а для компании это очень важно.

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

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

LVV>>>Вполне можно использовать vector...

CC>>и как вы себе это представляете?
LVV>Как работу с длинными числами...

вектор может подойти только в качестве хранилища — а все операции над такими числами кто и как будет реализовывать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>>>А почему нельзя факториал возвращать в double?..

LVV>>>Потому что 1755! > 10^4932 (это max число в пентюхе)
V>>Точность для факториала из целого числа должна закончится в [long] double гораздо раньше.
RO>И что?
Что что? Число неправильное получите вот что.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>а почему нет гамма ф-ии? ответили?
А>Как нет? А tgamma'у уже отменили?

Вы уверены, что она в стандарте С?

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

M>Я собеседований почти не проводил (не вдохновляет). Но вообще, склоняюсь к варианту "двухсекундное интерьвью". И, кстати, давал рекомендации шефу на прошлой работе (т.к. кандидаты первым делом всегда заходили в комнату, где я сидел). Шеф слушал с интересом. Но говорил, что так вот судить о людях — большая ошибка. В половине случаев, мол, ошибёшься. Согласен. 100% не гарантирую. Только принцип "лучьше не взять десять подходящих, чем взять одного неподходящего", практикуемый большинством контор при наборе персонала, предполагает ошибку в 90% случаев. Так что "двухсекундное интерьвью" обладает в 5 раз большей точностью.

ну тут 50% это на вскидку. а так сильно зависит от твоего умения разбираться в людях.

ps
надо тему закрывать, или переносить. от факториала далеко ушли

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

E>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>это легкая задача и известная.
СМ>>начитанный чел ее должен просто знать.

E>Ну то есть задачки такого типа тестируют опыт чела в посещении собеседований?

это задача известна из книжек, изданных еще при царе

(ну при СССР точно)
к собеседованию не имеет отношения. Я такие не задаю.

моя любимая задача (тоже известная):

есть переменная, если у нее значение 1, присвоить ей значение 2, а если 2, то 1. (на любом языке прогр).

только никому не говорите

E>А зачем нужно тестировать именно это, и хорошо ли, если тестирование выявит, что опыт есть?

значит часто меняет работу

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

E>>А почему нельзя факториал возвращать в double?..

Y>О! Нужно такой вопрос взять на заметку, чтобы заранее отсеивать откровенно слабых кандидатов.
Да? а почему таки нельзя? Тем более, что и на вещественный аргумент факториал хорошо обобщается...

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

E>Ну ты тут много разного писал в принципе...

Знаешь, если у работодателя хватит терпения добраться от резюме до этого пресловутого "разного" — это, видимо, как раз тот случай, когда отказ следует рассматривать позитивно.

Вообще, ты меня немного заинтриговал. Может это такой новый метод подбора персонала, расчитанный на крайних простаков?
— Я бы тебя не взял.
— Да ну, взял бы, как миленький.
— Не веришь? Ну давай, пиши заявление.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>офигеть, человек приходит со своей инструкцией кодирования и нестандартным assert на собеседование — гнать в шею.
Ну ты же на собеседовании соискателя со своей версией инструкции не знакомишь?

А в общечеловеческом смылсе полезность или вредность assert зависит от инструкции и от используемой реализации...

СМ>в оригинале написано return 3-n; ГДЕ ТУТ throw? throw был в более правильном варианте
return 3-n; Вообще не ответ на исходный вопрос, "есть переменная, если у нее значение 1, присвоить ей значение 2, а если 2, то 1. (на любом языке прогр)."... Поведение в случае n == 8, кстати, неспецифицированно в задаче. IMHO хорошо, если соискатель спросит: "а что сделать, если равна 3?", а всё остальное не важно.

СМ>>>3. из 3-n неясно что хотел программист
E>>Почему? Что не ясно в этом коде:

assert( n == 1 || n == 2 );
E>>n = 3 - n;

СМ>ты что, считаешь сопровождать будешь ты, такой умный? Или Вася П.?
Ну, то есть не ясно, что 3 = 2 + 1?

СМ>А ему надо будет вставлять преобразование 6->19 например.
Ну 25 найти уже сложнее. На я таки надеюсь, что в нормальной программе числа вроде 6 и 19 задаются не литералами, соответсвенно вариант превращается в перечисление и в switch.

E>>Хотя, если 1 и 2 -- это элементы перечисления бы были, то я бы наверное switch написал, а вот для bool однозначно так напишу:

f = !f;

СМ>вот как он относится к совету, после ответа что оба варианта — дело вкуса — значит нет вкуса у него.
Аргументы про выбор из трёх решений, в случе 1 <=> 2 пока что так и не последовали...
Про "нет вкуса" -- это конечно аргумент, только мутный какой-то. IMHO к умению программировать отношения непосредственного не имеет.

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

Наверное у вас большие очень зарплаты, раз можете себе такое позволить

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

M>Только принцип "лучьше не взять десять подходящих, чем взять одного неподходящего", практикуемый большинством контор при наборе персонала, предполагает ошибку в 90% случаев. Так что "двухсекундное интерьвью" обладает в 5 раз большей точностью.

Как у тебя с тервером и построением системам принятия решений?
Никого не волнует вероятность ошибки/успеха сами по себе, пойми ты это. Интересует произведение "вероятность ошибки * вес ошибки".

Пример, который мне надолго запомнился после лекций на военной кафедре.
Пишешь систему для работы РЛС, которая засекает баллистические ракеты. Суть — фильтрация белого шума и выделение сигналов. Можно ошибиться двояко — принять шум за ракету (ложная тревога) принять ракету за шум (пропуск атаки).

Так вот есть на пример варианта системы (с утрированными цифрами):
Одна при срабатывании тревоги имеет вероятность где-то 45% что она ложная. И где-то 1% вероятности пропуска ракеты.
Другая при срабатывании тревоги имеет вероятность где-то 5% что она ложная. И где-то 5% вероятности пропуска ракеты.

Что видим — ошибка первого рода в первой системе в 9 раз выше, ошибка второго рода — в 5 раз ниже. Итого в целом по вероятностям можно сказать что первая система дает где-то в ДВА раза меньше ошибок, то есть типа лучше.

Однако принимать, скорее всего стоит вторую систему — пусть лучше подергаются дежурные, поднятые по ложной тревоге, чем будут уничтожены несколько городов.

Примерно то же самое и с собеседованиями. Вес ошибки "не заметить хорошего" и "принять плохого" — различен.

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

E>>Вот, например, какой будет sizeof такой структуры:

struct number_with_id {
E>>    char id;
E>>    long double number;
E>>};

FR>16

Тогда, таки на 4 выравниваем...

Выравнивали бы на 12 -- было бы 24...

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

Y>>Обе эти функции объединяет одно, их невозможно вычислить точно.
E>Разве? А что мешает вычислить число "4 в 7-й степени" точно?

Перед вами яркий пример ПТУшного образования.

E>Ну ты приведи пример как с факторияалом легко, а с pow не легко...
E>Кроме того можешь пояснить как вычислить точно число 400!

Нет уж, сначала ты на double'е вычисли примерно 400!, округли с помощью round, распечатай это число и гордо повесь над своим столом результат, будешь внукам рассказывать о своем достижении, когда состаришься

Это утверждение равносильно такому, что sin(0) = 0, значит мы можем sin вычислить точно, и => что мы можем написать такую сигнатуру для sin: int sin(int x); Что в корне неверно. ИМХО это уже клиника, без обид.

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

Y>Это только при условии, что M >= 0.
А у факториала что-то иначе?

E>>При этом это обобщение оюладает таким свойством, что в области определения целочисленной функции обе они совпадают.
Y>Но зато область значений не обязательно совпадает из-за ошибок округления.
Я не совсем понимаю, что обозначает это утверждение

Если ты всё ещё говоришь о математических функциях, то совпадение точное. 2.0 в степени 2.0 это 4.0.
А если ты говоришь об ошибках округления при вычислении этих функций на С, то не совсем понятно в чём проблема? Если тебе нужен целый разультат и у тебя натуральные аргументы, то ты прекрасно получишь его округляя pow к ближайшему целому. А если теюе нужен результат в double, то тоже вроде нет проблем. Получишь с довольно большой точностью..

Или ты считсаешь, что функцию pow в стандартную библиотеку включили зря и по глупости?

E>>Кроме того есть функция N!, которая определяется как произведение из N сомножетелей, от N до 1. У неё тоже есть обобщение на поле вещественных чисел -- это так называемая гамма-функция. На области определения N! его значения совпадают со значениями гамма-функции.

Y>Ты забыл сказать, что только если вещественная часть аргумента положительна. И это совсем не обобщение факториала на множество R. Это просто частный случай гамма-функций.

IMHO если А -- это частный случай В, то В -- это обощение А... Типа чиста по определению...

E>>Вот и проясни пожалуйста, в чём состоит ПРИНЦИПИАЛЬНАЯ разница между ними?..

Y>Если мы будем обобщать факториал на множество R, то мы принципиально ничего не получаем, кроме арифметических ошибок с чисел с плавающей запятой. Еще раз, когда у нас функция при любых аргументах возвращает натуральные числа, у нас нет смысла обобщать ее на поле вещественных чисел. Особенно, когда мы теряем в точности. Более того, я считаю это некорректным, делать такие расширяющие обобщения. Т.к. с таким же успехом, мы могли бы расшириться и на множество комплексных чисел. Что есть ошибка, т.к. потом результат нужно переводить обратно в множество натуральных чисел, а в общем случае, такая операция у нас не определена.

Ну вы может и не получаете, а у математиков давно уже получилась функция гамма. Мало того, если говорить только о самом факториале, то я не понимаю, почему считается некорректной задача "вычислить факториал с точностью 15 десятичных знаков"? Что в ней такого необычного? Так вроде бы со всеми большими числами принято работать... В этом смысле и с функцией pow мы при обощении её на вещественные числа ничего новго "кроме ошибок округления" не получим, пока не начнём подставлять в неё вещестывенные аргументы... Так и чем pow от гаммы, а целочисленное возаведение в степень от факториала отличаются?

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

Y>Теперь про злосчастный факториал, здесь все просто, при любых аргументах функции, да и функция сама в целом, всегда имеет целочисленный результат.

Матчасть

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

E>>Тогда, таки на 4 выравниваем...

E>>Выравнивали бы на 12 -- было бы 24...

FR>Научись пожалуйста читать сообщения целиком

А я целиком прочитал. Видимо ты, как-то иначе чем я понимаешь фразу "выравниваем на XXX".
Я её понимаю так, что смещение адреса в сегменте (либо просто значение адреса, при плоской памяти) выбирается кратным XXX.

То есть при выравнивании на 4 получаем адреса кратные 4, при выравнивании на 8 -- кратные 8 и т. д.
При этом, AFAIK, в современных архитектурах выравнивания на числа не являющие степенями двойки смыслв не имеют и не используются...
Так что что такое "выравнивание на 12" я не совсем понимаю... IMHO -- это просто обман трудящихся.

template<typename T> class AlignmentOf {
    struct with_t {
        char f;
        T t;

        with_t();
    };
    struct without_t {
        T t;

        without_t();
    }
public:
    enum { Value = sizeof( with_t ) - sizeof( without_t ) };
};

а ещё нестандартная функция align (вроде sizeof) в некоторых компиляторах бывает...

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

Y>>Теперь про злосчастный факториал, здесь все просто, при любых аргументах функции, да и функция сама в целом, всегда имеет целочисленный результат.

M>Матчасть

И? Где я неправ? Факториал может иметь вещественный аргумент или результат?

Факториал

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

S>>Во-вторых, нахальство в нашей области деятельности принято подкреплять технической квалификацией. Ты пока что не не продемонстрировал.

Y>Ну демонстрировать я ничего не собираюсь, думаю и так все понятно. Думаю тот, кто хочет вычислять факториалы приближенно, гораздо больше продемонстрировал

Ну ты можешь квалификацию и как-то ещё показать.
А вообще-то, IMHO, факториал вычислять вообще не особо надо, в том числе и приближённо. Но, например, вычисление значения факториала можно использовать для оценки до какого члена нужно суммировать какой-нибудь ряд Тейлора... Например ряд для синуса...

Y>Это ты про Егора?

Y>Да есть такое. Спасибо за предупреждение

IMHO, эти две реплики противоречат друг другу.

Y>Нет уж, лучше я Кнута почитаю, чем его, а то мало ли, захочу приближенно вычислять простые числа

Ну я Кнута уже почитал. Не подскажешь где там написано, что, например, "приближённое вычисление фактриала -- глупость"?

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

Y>И? Где я неправ? Факториал может иметь вещественный аргумент или результат?
Y>Факториал

Ты сам читал свою ссылку?

Связь с гамма-функцией
Факториал связан с гамма-функцией от целочисленного аргумента соотношением:

n! = Γ(n + 1)
Таким образом, гамма-функцию рассматривают как обобщение факториала для положительных вещественных чисел. Путём аналитического продолжения её также расширяют и на всю комплексную плоскость, исключая особые точки при n = -1; -2; -3...

Хинт: так же как гамма-функция является обобщением факториала, так и натуральные числа являются частным случаем вещественных...

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

AVK>О! А не изволит ли уважаемый дон перечислить практические применения факториала?

Ну я вроде нигде не говорил о том, что он применяется на практике, но это действительно так. Точнее напрямую он сам не используется, но достаточно поглядеть на такой раздел математики как "Комбинаторика", как он косвенно используется в очень многих местах, например как сочетания, перестановки и биномиальный коэффициент.

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

Y>достаточно поглядеть на такой раздел математики как "Комбинаторика"

Достаточно взглянуть на такой раздел математики, как теория вероятности, из которого факториал исходно произрос, чтобы понять, что приближенное значение факториала вполне имеет право на жизнь.
Еще можно вспомнить формулу Стирлинга, которая принципиально дает приближенный результат. Точное значение факториала важно только в теории чисел, но она почти не применяется в программировании.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>

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

AVK>Достаточно взглянуть на такой раздел математики, как теория вероятности, из которого факториал исходно произрос, чтобы понять, что приближенное значение факториала вполне имеет право на жизнь.
AVK>Еще можно вспомнить формулу Стирлинга, которая принципиально дает приближенный результат. Точное значение факториала важно только в теории чисел, но она почти не применяется в программировании.

Ну вроде исходно речь шла про определение факториала через (n+1)! = n! * (n+1). Вот ты мне можешь ответить на прямой вопрос, стоит ли факториал определенный таким образом вычислять через double и если стоит, то почему?

ЗЫ: Егор, ты можешь не отвечать на это сообщение, твои сообщения все равно мной игнорируются, а дурацкие минусы и смайлы ставь сколько влезет.

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

Y>Ну вроде исходно речь шла про определение факториала через (n+1)! = n! * (n+1). Вот ты мне можешь ответить на прямой вопрос, стоит ли факториал определенный таким образом вычислять через double и если стоит, то почему?

Тебе, кстати, сюда...

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

Y>> Вот ты мне можешь ответить на прямой вопрос, стоит ли факториал определенный таким образом вычислять через double и если стоит, то почему?

AVK>Стоит. Потому что факториал, применяемый для вычисления, скажем, вероятностей, вполне допустимо брать приближенный в плавучке.

Ну опять же, речь шла про библиотечную функцию вычисления факториала. Надеюсь ты не будешь говорить как Егор о том, что ее тоже можно вычислять как double с потерей точности. Ну вообщем все понятно.

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

Y>>Ну опять же, речь шла про библиотечную функцию вычисления факториала. Надеюсь ты не будешь говорить как Егор о том, что ее тоже можно вычислять как double с потерей точности.

AVK>Буду. Потому что ее можно вычислять с потерей точности. И ты пока не привел ни одного обоснования почему этого делать нельзя. А наличие формулы Стирлинга просто проигнорировал.

Это называется полный финиш, приехали

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

AVK>Буду. Потому что ее можно вычислять с потерей точности. И ты пока не привел ни одного обоснования почему этого делать нельзя. А наличие формулы Стирлинга просто проигнорировал.

Ладно, еще раз. Факториал, определен как (n+1)! = n!*(n+1) или n!=1*2*...*n (0!=1), как видно из определения результатом функции всегда будут неотрицательные целые числа. Я думал и думаю это достаточное обоснование, того, что нельзя в качестве результата иметь приближенное значение, т.к. иначе приближенный результат не будет подходить под данное определение.

А наличие формулы Стирлинга не играет большой роли, ну можно большие значения факториалов вычислить приближенно, это не так важно, т.к. результатом могут быть и факториал или его приближенное значение. Вот, я все сказал.

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

Y>>Ладно, еще раз. Факториал, определен как (n+1)! = n!*(n+1) или n!=1*2*...*n (0!=1), как видно из определения результатом функции всегда будут неотрицательные целые числа.

AVK>Ну и что?

Y>> Я думал и думаю это достаточное обоснование, того, что нельзя в качестве результата иметь приближенное значение

AVK>Нет. Логической цепочки не вижу — почему из того, что результат всегда положительное целое число, следует невозможзность применения представления числа не с абсолютной точностью.

Вот я чуть пониже написал почему, а ты его так ловко разделил на 2 части. Потому что приближенное значение запросто может оказаться не факториалом.

Y>>т.к. иначе приближенный результат не будет подходить под данное определение.

AVK>А приближенный результат вычисления квадратного корня не подходит под определение корня? Ведь по определению pow(sqrt(2), 2) Должен бывть равен ровно 2, а по факту будет где то в районе 2, но не точно 2.

Ну вообще-то да, ты сам себе же и ответил.

Y>>А наличие формулы Стирлинга не играет большой роли

AVK>Наличие формулы Стирлинга означает, что приближенное вычисление факториала имеет практический смысл.

...для вычисления приближенного значения факториала, которое запросто может оказаться не факториалом в исходном определении факториала.

Y>>ну можно большие значения факториалов вычислить приближенно, это не так важно, т.к. результатом могут быть и факториал или его приближенное значение. Вот, я все сказал.

AVK>Ты сам понял, что ты сказал?

Я то понимаю, а вот ты к сожалению не понимаешь. Извини, но я не могу продолжать больше беседу.

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

Не надо сомневатся, надо боротся, вот читаю сейчас что нового добавили в следующую версию питона http://www.python.org/download/releases/2.6/NEWS.txt и что я там вижу

- Issue #2138: Add factorial() the math module.

Так что надо писать в комитет, и в C++ тоже включат обязательно.

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

ответ не "правильный", а тот, который считают правильным интервьюеры.

дело не в типе данных, библиотеки для работы с большими числами отлично обходятся тем, что есть. дело в том, что сам по себе факториал нафиг никому не нужен. а если нужен, то нужны и другие функции для работы с большими числами. а это уже не дело crt.

странные ребята. ограниченные я б сказал.

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

E>А почему нельзя факториал возвращать в double?..

Потому что, при больших x значение x! в double будет сильно отличаться от реального x! man числа с плав. запятой.

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

C>Если ты не понимаешь что double точность операций до единицы на больщих целых обеспечить не может — прими мои соболезнования. Клиника. В этом случае спорить действительно не о чем. В этом случае надо только лечить.

Зато я понимаю, что
1) там, где нужна "точность до единиц" double не используют, но в больших числах она нужна крайне редко.
2) Ты так и не прочитал всю ветку, так как ничего неового не пишешь

C>Предлагаю эксперимент

Если ты пояснишь какой именно double (или какие именно) ты хотел бы получить в результате этого эксперимента, то можно было бы понять что же ты предлагаешь. IMHO твоё высказывание внутренне противоречиво

В целом ты пока что даже не понял, что факториал мало кому нужен вообще, и уж совсем не нужен факториал больших чисел вычесленный с точностью до единиц. Так же как и большие степени чисел не нужны абсолютно точно, даже целых чисел и т. д. Именно поэтому люди плавучкой и пользуются, что ЕЁ ХВАТАЕТ для большинства практических задач...

Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

05.06.08 16:31: Перенесено модератором из 'C/C++' — всеохватное обсуждение — и про гамма-функцию, и про методику интервью, и вообще... — Кодт

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

а почему нет гамма ф-ии? ответили?

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, eao197, Вы писали:

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

TK>>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

E>>И какой же он, этот правильный ответ? Не томите!

СМ>правильный может быть только со ссылкой на C & R. Иначе это в той или иной степени предположение.

Ну ссылок на C&R мне естественно не дали, наверно потому что немного растерялся и не попросил.
Начал рассуждать, сказал что требования к функциям в стандартной библиотеке: эффективность и удобство. Привел два примера реализации на этапе компиляции и на этапе выполнения. Сказал что и тот и другой способ удовлетворяют обеим требованиям, хотя может быть не внесли потому что факториал можно посчитать только для небольшого количества натуральных чисел, иначе будет переполнение, а это в чём то неудобно. После этого на меня начали наседать так почему всё-таки не включили? Я начал ходить кругами вокруг того что сказал, мне сказали "ну что ж вы претендуете на Seniour Software developer/Team leader и не можете сказать почему стоит включать тут или иную функцию в библиотеку"

(что помоему не очень политкорректно) потом добавили в "...стандартную библиотеку"

Ну вообщем мне сказали то что хотели от меня услышать, он вполне логичен, и до него мне остался один шаг, хотя не очевидный. Вообще эту причину трудно понять, пока не попишешь сам STL.

Скоро напишу то, что мне сказали. Кстати я собеседовался не в яндекс и не гугл и не микрософт и даже не в комитет по стандартизации С++ или С

но всё-таки на Seniour Software developer/Team leader

Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?
Вы бы ответили?

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

TK>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>Здравствуйте, eao197, Вы писали:

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

TK>>>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

E>>>И какой же он, этот правильный ответ? Не томите!

СМ>>правильный может быть только со ссылкой на C & R. Иначе это в той или иной степени предположение.

TK>Ну ссылок на C&R мне естественно не дали, наверно потому что немного растерялся и не попросил.
TK>Начал рассуждать, сказал что требования к функциям в стандартной библиотеке: эффективность и удобство. Привел два примера реализации на этапе компиляции и на этапе выполнения. Сказал что и тот и другой способ удовлетворяют обеим требованиям, хотя может быть не внесли потому что факториал можно посчитать только для небольшого количества натуральных чисел, иначе будет переполнение, а это в чём то неудобно. После этого на меня начали наседать так почему всё-таки не включили? Я начал ходить кругами вокруг того что сказал, мне сказали "ну что ж вы претендуете на Seniour Software developer/Team leader и не можете сказать почему стоит включать тут или иную функцию в библиотеку"

(что помоему не очень политкорректно) потом добавили в "...стандартную библиотеку"

Ну вообщем мне сказали то что хотели от меня услышать, он вполне логичен, и до него мне остался один шаг, хотя не очевидный. Вообще эту причину трудно понять, пока не попишешь сам STL.

TK>Скоро напишу то, что мне сказали. Кстати я собеседовался не в яндекс и не гугл и не микрософт и даже не в комитет по стандартизации С++ или С

но всё-таки на Seniour Software developer/Team leader

TK>Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?
TK>Вы бы ответили?

Добавлю что компания не пишет никаких библиотек на продажу или широкое пользование, обычный конечный продукт.

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

TK>Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?

Любой вопрос уместен. За 20-30 мин (а больше жалко на первой стадии собеседования) надо понять, что за человек, как себя ведет если не знает ответа, как мыслит и тп.

TK>Вы бы ответили?

тогда машины были 16битные и факториал был бы макс 8! (если я правильно его считаю). т.е. довольно не интересная ф-ия.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, TarasKo, Вы писали:

TK>>Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?

СМ>Любой вопрос уместен. За 20-30 мин (а больше жалко на первой стадии собеседования) надо понять, что за человек, как себя ведет если не знает ответа, как мыслит и тп.

TK>>Вы бы ответили?

СМ>тогда машины были 16битные и факториал был бы макс 8! (если я правильно его считаю). т.е. довольно не интересная ф-ия.

Да, даже для 64 битных машин особо большой факториал не посчитать. Не думаю что больше 100. Но я об этом уже говорил что мало область определения фактически очень маленькая. Однако на меня наседали и спрашивали так всё-таки почему?

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

Ovl>не понял какой-же все-таки ответ. но в голову приходит только: "потому что она на фиг никому не нужна"

Хороший ответ, разумный и логичный. Действительно фактор как таковой нужен крайне редко.

Но так отвечать на собеседовании не хорошо

СМ>тогда машины были 16битные и факториал был бы макс 8! (если я правильно его считаю). т.е. довольно не интересная ф-ия.

На технические вопросы предшествующие этому я ответил нормально. Сам собеседую людей, ни разу мне так подробно никто не отвечал, с альтернативными вариантами возможными проблемами доводами за и против. Этот вопрос был ближе к концу

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

Ovl>>>не понял какой-же все-таки ответ. но в голову приходит только: "потому что она на фиг никому не нужна"

TK>>Хороший ответ, разумный и логичный. Действительно фактор как таковой нужен крайне редко.

TK>>Но так отвечать на собеседовании не хорошо

Ну тогда "потенциальный круг пользователей данной ф-ией стремится к 0"

Ovl>тогда второй вариант: придется объяснять что такое факториал индусам

тогда их не было

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

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

Во-первых, область определения очень сильно ограничена.
Во-вторых, факториал не самая востребованная функция, ИМХО. Мне вот например ни разу не понадобилась

В-третьих, имеет элементарную реализацию.

тут подумалось:
мне почему-то кажется, что проблема в том, что функция допускает рекурсивную реализацию

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

R>Могу предположить:
R>В стандартную библиотеку включаются только те функции, которые имеют одно оптимальное решение, т.е. так сказать "без-вариантные", т.е. если бы кому-то пришла в голову идея реализовать такую функцию, то он всё равно бы реализовал аналогичным способом, т.е. не получил бы никакого выигрыша по сравнению со стандартной реализацией. В частности такими функциями являются функции, которые имеют аппаратную поддержку на большинстве платформ.
R>Для факториала явная неоднозначность — толи реализовывать через вычисления, толи через таблицу. Трейдоф скорость-память. Комитет по стандартизации просто не может взять на себя ответственность однозначно разрешить этот трейдоф для всех приложений.

R>з.ы. хотя, конечно, например для функции сортировки тоже приходится выбирать некий трейдоф, тут тоже не совсем однозначно. но для неё хотя бы определили, что что вычислительная сложность O(NlogN)...

R>

Да! Примерно это я тоже говорил, что одна реализация подходит для того случая другая для другого. Но на самом деле это не причина. Ведь есть же sort stable_sort. Одни используют одно, другие другое, в зависимости от задачи.

Ответ который мне дали, был другой

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

СМ>>тогда машины были 16битные и факториал был бы макс 8! (если я правильно его считаю). т.е. довольно не интересная ф-ия.

TK>Да, даже для 64 битных машин особо большой факториал не посчитать. Не думаю что больше 100. Но я об этом уже говорил что мало область определения фактически очень маленькая. Однако на меня наседали и спрашивали так всё-таки почему? :maniac:

100! ≈ 10¹⁵⁸ ≈ 2⁵²⁴.

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

B>Во-первых, область определения очень сильно ограничена.
это я говорил, в ответ мне сказали так всё-таки почему?

B>Во-вторых, факториал не самая востребованная функция, ИМХО. Мне вот например ни разу не понадобилась

Ну это не довод, мне например не раз не понадобилась функция nthelement из STL, но она ведь включена

B>В-третьих, имеет элементарную реализацию.

нууу многие алгоритмы имеют элементарную реализацию, тот же for_each реализуется в две-три строки.

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

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

Ovl>>тут подумалось:
Ovl>>мне почему-то кажется, что проблема в том, что функция допускает рекурсивную реализацию

TK>Многие функции из STL написаны с помощью циклов и точно так же их можно реализовать рекурсивно.
TK>Вообще я где-то слышал что будто бы доказано математически что рекурсия всегда может заменить цикл.
TK>То есть из-за того, что она допускает рекурсивную реализацию её нельзя включить в STL? Ну не знаю, могу сказать что это совсем не то что я услышал

ещё вариант: функция не сможет быть вызвана для всех (большинства?) примитивных (?) типов, только натуральные числа

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

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

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

Ovl>>>тут подумалось:
Ovl>>>мне почему-то кажется, что проблема в том, что функция допускает рекурсивную реализацию

TK>>Многие функции из STL написаны с помощью циклов и точно так же их можно реализовать рекурсивно.
TK>>Вообще я где-то слышал что будто бы доказано математически что рекурсия всегда может заменить цикл.
TK>>То есть из-за того, что она допускает рекурсивную реализацию её нельзя включить в STL? Ну не знаю, могу сказать что это совсем не то что я услышал

Ovl>ещё вариант: функция не сможет быть вызвана для всех (большинства?) примитивных (?) типов, только натуральные числа

это я тоже сказал, что даже не для целых, а только для натуральных она применима.

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

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

TK>>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

E>Если ответ как в SUBJ, то они настоящие панки

а вот это причину мы сегодня придумали с коллегами по работе

Но они назвали другую причину.
кстати accumulate то хочет итераторы в качестве параметров. ИМХО не очень удобно его использовать для вычисления факториал числа. Думаю те кто его придумал всё-таки не предполагали его использовать

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

TK>это я тоже сказал, что даже не для целых, а только для натуральных она применима.

Во-первых, есть корень
Во-вторых, есть unsigned
В-третьих, есть обощение факториала на вещественные числа...

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

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

TK>>это я тоже сказал, что даже не для целых, а только для натуральных она применима.

E>Во-первых, есть корень
E>Во-вторых, есть unsigned
не намного лучше
E>В-третьих, есть обощение факториала на вещественные числа...
про гамму ф-ию я уже говорил, но ее реализация м.б. не очень тривиальна.

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

R>Похоже, что они просто приняли всерьёз шутку из какой-то статьи/воспоминаний/блога

наверняка!

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, remark, Вы писали:

R>>Похоже, что они просто приняли всерьёз шутку из какой-то статьи/воспоминаний/блога

СМ>наверняка!

В стиле Страуструпа, кстати...

Здравствуйте, Сергей Мухин, Вы писали:

СМ>про гамму ф-ию я уже говорил, но ее реализация м.б. не очень тривиальна.
Это повод её не включать?

Надо было у них спросить почему, по их мнению, гаму не включили

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

СМ>>что то много воскл знаков у меня! Наверно тема навевает.

TK>Эээ, не много не в теме. А что такое гамма функция?

Википедию отменили?
http://ru.wikipedia.org/wiki/%D0%93%D0%B0%D0%BC%D0%BC%D0%B0-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F

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

СМ>>для начала остановимся на математических.

СМ>>ps

СМ>>я еще одну причину придумал про факториал! они хотели сделать соответствующую постфиксную операцию! но не успели.

СМ>>pss
СМ>>что то много воскл знаков у меня! Наверно тема навевает.

TK>Эээ, не много не в теме. А что такое гамма функция?

1. это просто развитие темы
2. мат аппарат у Вас слабоват
3. поиском не владеете

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

R>Т.е. имеет смысл делать либо факториал, работающий с существующими типами, либо полную поддержку нового типа.
А почему нельзя было сделать варианты факториала для всех встроенных типов, для которых имеет смысл его делать? А для нестандартных собственных пусть пользователи сами реализуют, кому понадобится.

Но вообще, я бы ответил так:

Я бы, как разработчик стандартной математической библиотеки для языка, у которого скорость выполнения программ на весьма приоритетном месте, опирался на возможности наиболее распространенного железа разных платформ. Железо у нас мат сопроцессор, если мне не изменяет память у него нет команды вычисления факториала, если бы была, при реализации библиотечной функции я бы использовал ассемблерные вставки с кучей ключей условной компиляции под разные платформы и разные сопроцессоры, в результате моя библиотечная реализация была бы лучше, чем написанная вручную без учета возможностей железа. Синусы, косинусы железом поддерживаются — вот они в библиотеке и есть в результате. А нет ее в железе потому, что собственно и не нужна особо похоже, выигрыша в скорости не дает. Так зачем включать тривиальную для реализацию функцию в библиотеку? Была б нужна, давно б включили уже, велосипеды бы в каждом проекте надоели быстро.

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

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

R>>Т.е. имеет смысл делать либо факториал, работающий с существующими типами, либо полную поддержку нового типа.
E>А почему нельзя было сделать варианты факториала для всех встроенных типов, для которых имеет смысл его делать? А для нестандартных собственных пусть пользователи сами реализуют, кому понадобится.

E>Но вообще, я бы ответил так:

E>Я бы, как разработчик стандартной математической библиотеки для языка, у которого скорость выполнения программ на весьма приоритетном месте, опирался на возможности наиболее распространенного железа разных платформ. Железо у нас мат сопроцессор, если мне не изменяет память у него нет команды вычисления факториала, если бы была, при реализации библиотечной функции я бы использовал ассемблерные вставки с кучей ключей условной компиляции под разные платформы и разные сопроцессоры, в результате моя библиотечная реализация была бы лучше, чем написанная вручную без учета возможностей железа. Синусы, косинусы железом поддерживаются — вот они в библиотеке и есть в результате. А нет ее в железе потому, что собственно и не нужна особо похоже, выигрыша в скорости не дает. Так зачем включать тривиальную для реализацию функцию в библиотеку? Была б нужна, давно б включили уже, велосипеды бы в каждом проекте надоели быстро.

crt поставляется под конкретную систему, так что тут проблем не будет

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

TK>кстати accumulate то хочет итераторы в качестве параметров. ИМХО не очень удобно его использовать для вычисления факториал числа. Думаю те кто его придумал всё-таки не предполагали его использовать

std::accumulate(boost::counting_iterator<int>(1), boost::counting_iterator<int>(n), 1, std::multiplies<int>())

E>>Надо было у них спросить почему, по их мнению, гаму не включили

СМ>

СМ>давайте сразу определим ВСЕ ф-ии, которые не включили. и начнем определять причины! их не включения

СМ>для начала остановимся на математических.

Ну этих уже похоже вплющило: http://en.wikipedia.org/wiki/Technical_Report_1#Mathematical_Functions
Современным состоянием проблемы, правда, не интересовался, но что-то мне кажется, что дзета-функция и ей подобные в стандартной библиотеке немного лишние.

--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>

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

TK>>>кстати accumulate то хочет итераторы в качестве параметров. ИМХО не очень удобно его использовать для вычисления факториал числа. Думаю те кто его придумал всё-таки не предполагали его использовать

RO>>

std::accumulate(boost::counting_iterator<int>(1), boost::counting_iterator<int>(n), 1, std::multiplies<int>())

SC>А теперь представь что ты это увидел в доставшемя по наследству коде...

The last item on the desktop was a mechanical contrivance.
‘Contrivance’ was exactly the right kind of word for it.

Terry Pratchett, Thief of Time

На самом деле нет тут ничего такого. Ты думаешь, что аналог из языков вроде J — что-то наподобие */1+!n — намного лучше? Код выше один к одному соответствует функциональному foldl(1..n, 1, *). Когда выйдет C++09, вообще будет std::accumulate(make_counting_range(1, n), 1, [](x, y) x * y).

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

CC>Кстати: 65535! занимает 954037 бит или 287194 десятичные цифры (преобразование заняло минуты 3 в сравнении с 2мя секундами вычислений) и заканчивается 16380-ю нулями

Все 3 эти числа можно определить и попроще :-)

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

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

TK>>Интересно услышать ваше мнение, насколько вопрос подобного плана уместен в обычной компании?
TK>>Вы бы ответили?

A>Обычно такие вопросы задают, чтобы уменьшить тебе зарплату.
A>В следующий раз скажут, что у тебя трусы не того цвета, а для компании это очень важно.

эээ

неверный ответ. или Вы общаетесь не с теми.

Найти повод понизить зп, може каждый, спрашивать много не надо.

Другой вопрос, что по КЗОТу понзить тяжело, легче не подымать

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

CC>>Кстати: 65535! занимает 954037 бит или 287194 десятичные цифры (преобразование заняло минуты 3 в сравнении с 2мя секундами вычислений) и заканчивается 16380-ю нулями

RO>Все 3 эти числа можно определить и попроще

Эт понятно, но там жеж русским по белому написано — "было скучно"

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

R>>Т.е. имеет смысл делать либо факториал, работающий с существующими типами, либо полную поддержку нового типа.
E>А почему нельзя было сделать варианты факториала для всех встроенных типов, для которых имеет смысл его делать? А для нестандартных собственных пусть пользователи сами реализуют, кому понадобится.

E>Но вообще, я бы ответил так:

E>Я бы, как разработчик стандартной математической библиотеки для языка, у которого скорость выполнения программ на весьма приоритетном месте, опирался на возможности наиболее распространенного железа разных платформ. Железо у нас мат сопроцессор, если мне не изменяет память у него нет команды вычисления факториала, если бы была, при реализации библиотечной функции я бы использовал ассемблерные вставки с кучей ключей условной компиляции под разные платформы и разные сопроцессоры, в результате моя библиотечная реализация была бы лучше, чем написанная вручную без учета возможностей железа. Синусы, косинусы железом поддерживаются — вот они в библиотеке и есть в результате. А нет ее в железе потому, что собственно и не нужна особо похоже, выигрыша в скорости не дает. Так зачем включать тривиальную для реализацию функцию в библиотеку? Была б нужна, давно б включили уже, велосипеды бы в каждом проекте надоели быстро.

эээ слишком много букв. не катит. Идея поняттна, но, например, тогда не было сопроцессоров.
и при чем тут ассемблерные вставки?

т.е. не зачет

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

CC>А вообще: В int32 вмещается только 12!, в int64 — 20!
CC>В дабл если без потери точности — где то столько же.

Вообще-то, я не знаю зачем нужен факториал, но вполне может так быть, что его можно вычислять и с точностью "всего" знаков 10 — 20, тогда можно просто брать на вход int и на выход давать double...
Ну а про гамму уже писали (можно ведь и её реализовать, в конце концов)

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

RO>Здравствуйте, Sergey Chadov, Вы писали:

TK>>>>кстати accumulate то хочет итераторы в качестве параметров. ИМХО не очень удобно его использовать для вычисления факториал числа. Думаю те кто его придумал всё-таки не предполагали его использовать

RO>>>

std::accumulate(boost::counting_iterator<int>(1), boost::counting_iterator<int>(n), 1, std::multiplies<int>())

SC>>А теперь представь что ты это увидел в доставшемя по наследству коде...

RO>

The last item on the desktop was a mechanical contrivance.
RO>‘Contrivance’ was exactly the right kind of word for it.

RO>Terry Pratchett, Thief of Time

RO>На самом деле нет тут ничего такого.
Я и не говорил, что здесь есть что-то такое

RO>Ты думаешь, что аналог из языков вроде J — что-то наподобие */1+!n — намного лучше? Код выше один к одному соответствует функциональному foldl(1..n, 1, *).

А теперь сравни количество букв. Нет, мне тоже функциональный стиль очень нравится, но надо же меру соблюдать.

RO>Когда выйдет C++09, вообще будет std::accumulate(make_counting_range(1, n), 1, [](x, y) x * y).
Боюсь это будет к нашей с тобой старости

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

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

TK>>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
E>А почему нельзя факториал возвращать в double?..

Потому что 1755! > 10^4932 (это max число в пентюхе)

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

TK>>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
TK>>Ну и соответственно этот тип надо было бы поддерживать, что довольно геморно.

LVV>Вполне можно использовать vector...

и как вы себе это представляете?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>А почему нельзя факториал возвращать в double?..

LVV>Потому что 1755! > 10^4932 (это max число в пентюхе)
WTF???
Для double максимальное значение ~ 1.7976931348623157 * 10^308 или ~ 2^1023 (макс значение экспоненты для double precision = 1023)
10^4932 это примерно 2^16384 — это long double
Казалось бы в теории все хорошо, но вот на практике крайне мало (я что то не припомню чтоб вообще его кто поддерживал на данный момент) компиляторов его поддерживают.
MSVC например не держит: http://blogs.msdn.com/ericflee/archive/2004/06/10/152852.aspx
Intel и тот не поддерживает:

These features are not supported:
* long double (128-bit representations)

Кстати, у кого есть под рукой MSVC9? Как там обстоит дела с long double?

The upside is that for the next version of the product (VC9.0 that is), we will probably support 80 bit long doubles.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>>А почему нельзя факториал возвращать в double?..

LVV>>Потому что 1755! > 10^4932 (это max число в пентюхе)
CC>Для double максимальное значение ~ 1.7976931348623157 * 10^308 или ~ 2^1023 (макс значение экспоненты для double precision = 1023)
CC>10^4932 это примерно 2^16384 — это long double
CC>Казалось бы в теории все хорошо, но вот на практике крайне мало (я что то не припомню чтоб вообще его кто поддерживал на данный момент) компиляторов его поддерживают.
CC>MSVC например не держит: http://blogs.msdn.com/ericflee/archive/2004/06/10/152852.aspx
10^4932 — это максимальное значение 80-битного плавающего числа в Intel. Регистры сопроцессора — 80-битные с распределением разрядов: 1-15-64. Скрытой 1 нет.
На 80 бит отображал long double компилятор С++Builder 6.

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

LVV>>Вполне можно использовать vector...

CC>и как вы себе это представляете?
Как работу с длинными числами...

Здравствуйте, LaptevVV, Вы писали:
TK>>>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
E>>А почему нельзя факториал возвращать в double?..

LVV>Потому что 1755! > 10^4932 (это max число в пентюхе)

Ну, то есть, ты хочешь сказать, что функцию exp надо из станадартной библиотеки выикнуть?..

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

LVV>На 80 бит отображал long double компилятор С++Builder 6.
Случайно сегодня набрел в доках на интел компилер:

/Qlong-double
This option changes the default size of the long double data type to 80 bits.

However, the alignment requirement of the data type is 16 bytes, and its size must be a multiple of its alignment, so the size of a long double on Windows is also 16 bytes. Only the lower 10 bytes (80 bits) of the 16 byte space will have valid data stored in it.

Note that the Microsoft compiler and Microsoft-provided library routines (such as printf) do not provide support for 80-bit floating-point values. As a result, this option should only be used when referencing symbols within parts of your application built with this option or symbols in libraries that were built with this option.

Кстати с 80битным плавающим огорчение одно есть — оно FPU only. Если для 32 и 64 битных плавающих есть SSE поддержка, то для 80тки только на FPU.
Да и с выравниванием как было замечено у intel — 80-ка не сильно дружит — DWORD+DWORD+WORD.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

TK>>>Мне ответили, что тогда надо было бы придумать новый тип для возвращаемого значения факториала. Поскольку в int он вмещается только на небольшой области определения.
E>>А почему нельзя факториал возвращать в double?..

LVV>Потому что 1755! > 10^4932 (это max число в пентюхе)
Точность для факториала из целого числа должна закончится в [long] double гораздо раньше.

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

M>Так это... тебе повезет, если они тебя не возьмут работать

)
Я, кстати, тоже считаю, что справедливо ли собеседование не очень важно. Важно, тчобы оно было стабильным.
Так как обычно люди, которые прошли *альтернативное* собеседование и люди которые его не прошли всё равно друг друга понимают плохо...

Короче прошёл ты там собеседование или не прошёл -- это не проверка на твою годность в принципе, а всего лишь проверка того, что компания, куда ты собеседовался подходит тебе, а ты ей...

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

V>Что что? Число неправильное получите вот что.

А что, для sin( 1 ) "правильное", что ли получу?

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

V>Синус получит плавающее, а здесь целое.
Ты уж блин определись какую функцию обсуждаешь, которая double возвращает или которая int...

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

CC>Кстати с 80битным плавающим огорчение одно есть — оно FPU only. Если для 32 и 64 битных плавающих есть SSE поддержка, то для 80тки только на FPU.

Угу но 80 только ms компилятор и не держит intel, gcc, borland, DigitalMars подерживают.

CC>Да и с выравниванием как было замечено у intel — 80-ка не сильно дружит — DWORD+DWORD+WORD.

gcc по умолчанию на 12 байт ее выравнивает.

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

CC>Кстати, у кого есть под рукой MSVC9? Как там обстоит дела с long double?
CC>

CC>The upside is that for the next version of the product (VC9.0 that is), we will probably support 80 bit long doubles.

Также не подерживает.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>чудаки.

Раздражает то, что для привлекательных числом значащих цифр в зарплате вакансий, такие вопросы являются скорее нормой, чем исключением. Например, вопрос о количестве возможных TCP соединений. Отвечаешь, мол, на вскидку тысяч десятков несколько. "А почему?" Да х.з. "А вот потому, что номер порта то 16 разрядный." Где тут причина, а где следствие, ещё разобраться надо.
Напридумывают каких-то причинно-следственных связей. И потом начинают проверять, "умеет ли кандидат думать".

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

M>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>чудаки.

M>Раздражает то, что для привлекательных числом значащих цифр в зарплате вакансий, такие вопросы являются скорее нормой, чем исключением. Например, вопрос о количестве возможных TCP соединений. Отвечаешь, мол, на вскидку тысяч десятков несколько. "А почему?" Да х.з. "А вот потому, что номер порта то 16 разрядный." Где тут причина, а где следствие, ещё разобраться надо.
M>Напридумывают каких-то причинно-следственных связей. И потом начинают проверять, "умеет ли кандидат думать".

просто всем надоела задача про круглый люк, вот они и выдумывают, не всегда качественно.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>а почему нет гамма ф-ии? ответили?
Как нет? А tgamma'у уже отменили?

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>а почему нет гамма ф-ии? ответили?
А>>Как нет? А tgamma'у уже отменили?

СМ>Вы уверены, что она в стандарте С?
[sarcasm]
ТЫНЦ

Conforming to
C99.

ТЫНЦ

STANDARDS
     The tgamma() , and lgamma() functions conform to ISO/IEC 9899:1999(E).

Нет конечно, всё это заговор среди создателей компиляторов.
[sarcasm]

А если серьезно то стандартов под рукой нет, поэтому назвать точный параграф счас не могу

Здравствуйте, Аноним, Вы писали:

А>А если серьезно то стандартов под рукой нет, поэтому назвать точный параграф счас не могу

я посмотрел в *.h MS2005, там нет. врядли они прпустили.

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

CC>>Да и с выравниванием как было замечено у intel — 80-ка не сильно дружит — DWORD+DWORD+WORD.
FR>gcc по умолчанию на 12 байт ее выравнивает.
На 12-то за что? Может всё-таки на 4?

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

M>>Так это... тебе повезет, если они тебя не возьмут работать

)
Повезёт тем дегенератам, которые присосались к жирному инвестору, пудрят ему мозги по поводу своей гениальности и отсутствию профессионалов на рынке труда и не пропускают в компанию никого, кто мог бы их сковырнуть.

E>Я, кстати, тоже считаю, что справедливо ли собеседование не очень важно. Важно, тчобы оно было стабильным.
E>Так как обычно люди, которые прошли *альтернативное* собеседование и люди которые его не прошли всё равно друг друга понимают плохо...
Как мне кажется, если люди понимают истину, то они и друг друга смогут понять. А если не понимают, то порождают какие-то нелепые чудовищные архитектуры.

E>Короче прошёл ты там собеседование или не прошёл -- это не проверка на твою годность в принципе, а всего лишь проверка того, что компания, куда ты собеседовался подходит тебе, а ты ей...
Такие рассуждения хороши, чтоб себя успокаивать. Если же смотреть на вещи трезво, то пока пройдёшь от вершины приоритетного списка привлекательности компаний до того места, где тебя берут, в пересчёте на рубли не один десяток тысяч потеряешь. Каждый месяц. Плюс следует учитывать разницу в профессиональном росте, влияние которой растягивается и после следующей смены работы на всю жизнь.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>просто всем надоела задача про круглый люк, вот они и выдумывают, не всегда качественно.

E>>А что это за задача?

СМ>гм. здесь

Интересная штука: у меня никогда не получалось решать подобные задачки быстро. Когда попадались сложные логические задачи (на разный вес настоящих или фальшивых монеток, три лампочки с выключателями, зашифрованные буквами числа при перемножении в столбик и пр), то многие из них я решал, но либо через несколько часов напряженных размышлений, либо на следующий день решение как-то само по себе находилось.

Со мной в университете, лет пятнадцать назад был показательный случай. Мой однокурсник задал нам задачку из коллекции Эдисона (мол Эдисон задавал ее потенциальным кандидатам на работу). Какая-то странная конструкция из бумаги, которую нужно было повторить за несколько минут из обычного тетрадного листа. Я эту задачу не решил, а этот однокурсник решил. В итоге -- я пишу программы, он владеет собственной торговой фирмочкой в Москве.

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

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, Аноним, Вы писали:

А>>А если серьезно то стандартов под рукой нет, поэтому назвать точный параграф счас не могу

СМ>я посмотрел в *.h MS2005, там нет. врядли они прпустили.
<sarcasm>А то! Всем известно что комитет лгёт когда говорит о
tgamma в стандарте
</sarcasm>

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

E>Интересная штука: у меня никогда не получалось решать подобные задачки быстро. Когда попадались сложные логические задачи (на разный вес настоящих или фальшивых монеток, три лампочки с выключателями, зашифрованные буквами числа при перемножении в столбик и пр), то многие из них я решал, но либо через несколько часов напряженных размышлений, либо на следующий день решение как-то само по себе находилось.

Ночью, когда спишь, мозг больше энергии расходует, чем днём. Нерешённые задачи решает перебором.

E>Со мной в университете, лет пятнадцать назад был показательный случай. Мой однокурсник задал нам задачку из коллекции Эдисона (мол Эдисон задавал ее потенциальным кандидатам на работу). Какая-то странная конструкция из бумаги, которую нужно было повторить за несколько минут из обычного тетрадного листа. Я эту задачу не решил, а этот однокурсник решил. В итоге -- я пишу программы, он владеет собственной торговой фирмочкой в Москве.

E>Так что может эти логические задачи и могут как-то определять какие-то способности человека. Но вот отбирать с их помощью программистов вряд ли имеет смысл

Тот кто умеет быстро решать простые задачи лучше того, кто ни быстро ни медленно ни простых ни сложных задач решать не умеет. Насчёт корреляции между быстрыми и медленными сказать ничего не могу. Наверное, есть. Положительная или отрицательная — вопрос. В любом случае, тестирование предпочтительнее "рассказа о проектах". Т. к. в рассказе человек просто присваивает себе заслуги всего коллектива разработчиков. Тест на неделю некоторые компании дают. Но вызывает недовольство у соискателей. Так что хорошей методики тестирования просто не существует.

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

M>Как мне кажется, если люди понимают истину, то они и друг друга смогут понять. А если не понимают, то порождают какие-то нелепые чудовищные архитектуры.

А кто тебе сказал, что, даже если она существует, то они её понимают?

M>Такие рассуждения хороши, чтоб себя успокаивать. Если же смотреть на вещи трезво, то пока пройдёшь от вершины приоритетного списка привлекательности компаний до того места, где тебя берут, в пересчёте на рубли не один десяток тысяч потеряешь. Каждый месяц. Плюс следует учитывать разницу в профессиональном росте, влияние которой растягивается и после следующей смены работы на всю жизнь.

Почему успокаивать? Не успокаивать, а смотреть внимательно на собеседование и думать точно ли ты хочешь работать в конторе, где все коллеги прошли такое же собеседование и согласились работать?

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

M>В любом случае, тестирование предпочтительнее "рассказа о проектах". Т. к. в рассказе человек просто присваивает себе заслуги всего коллектива разработчиков.

1) Они ни в какой степени не взаимозаменяемы и даже не конкурируют
2) В "рассказе о проектах" главное не то, что соискатель себе припишет, а то, как и про что он рассказывает, на что обращает вниманеи, а на что нет, что понимает, а что нет и т. д.

TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

да потому что она нахрен не нужна , кроме студенческих задач

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Вы сами проводили собеседование? И если да то сколько?

Да, проводил и провожу до сих пор. Через меня прошло, наверное, человек 15-20. Нескольких завернули.

СМ>Рано или поздно понимаешь, что это время потрачено на 95% зря, и надо за 15-20 мин определиться с кандидатом. Поэтому задаешь ему все что в голову прийдет. И смотришь как он отвечает. А потом мб задания даешь. Один раз мы взяли чел, который не написал задание и не разочаровались. Необязательно правильно ответить, необязательно даже блико ответить. Я смотрю как чел ведет. Называет он слова "дрова" и тп, Большим плюсом, если он говорит "я не знаю как ответить на этот вопрос"!

У меня два основных вопроса, на основании ответов на которые я пытаюсь создать впечатление о человеке:
— просьба рассказать о проектах, в которых ему доводилось участвовать и о тем, что именно этот человек делал в проекте. Если человек вменяемый, то он может связно, четко и без лишних деталей объяснить чем ему приходилось заниматься;
— просьба рассказать о проекте(ах) или о какой-то штуке, которой именно он гордится больше всего. По-моим наблюдениям, если человек вкладывает душу в свой труд, то у него обязательно остануться хотя бы о чем-то хорошие впечатления (даже если место работы ему не нравилось).

Задачек я стараюсь не давать именно на собеседовании. Когда бывало необходимо определить уровень человека, мы давали ему задание на дом. Иногда это задание совмещалось с испытательным сроком.

Ну иногда бывает необходимо что-то спросить сразу на собеседовании. Например, сидят передо мной несколько студентов, пальцы гнут, мол мы C++ знаем. Ну задаешь им вопрос какой-нибудь или какую-нибудь простенькую задачку (вроде как бы вы спроектировали иерархию исключений, если бы писали какую-нибудь библиотеку). Чисто для того, чтобы они сами признались, что не очень знают про исключения и не понимают зачем нужны иерархии исключений.

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

E>А кто тебе сказал, что, даже если она существует, то они её понимают?

Ну в общем да, истину нужно чуять. А попытка её понять как раз и приводит в конечном счёте к уходу от истины.

M>>Такие рассуждения хороши, чтоб себя успокаивать. Если же смотреть на вещи трезво, то пока пройдёшь от вершины приоритетного списка привлекательности компаний до того места, где тебя берут, в пересчёте на рубли не один десяток тысяч потеряешь. Каждый месяц. Плюс следует учитывать разницу в профессиональном росте, влияние которой растягивается и после следующей смены работы на всю жизнь.

E>Почему успокаивать? Не успокаивать, а смотреть внимательно на собеседование и думать точно ли ты хочешь работать в конторе, где все коллеги прошли такое же собеседование и согласились работать?

Ну дык, это ж непаханное поле — подсидеть начальников на три уровня

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

E>Может быть это и так, но:
E>* собеседование ограничено по времени, соответственно, нет возможности определить, может ли человек решать задачи медлено. Быстро не решил -- свободен, значит вообще решать не умеет;

в общем согласен, но пусть хоть наметит план, покажет сложности и тп.

E>* собеседование, как и экзамен -- это достаточно стресовая ситуация. Не так уж много людей могут концентрироваться должным образом в условиях стреса. А ведь людей, в большинстве случаев, нанимают для работы в спокойных, размеренных условиях. В которых многие способны нормально думать и вполне успешно справляться с заданиями, которые казались им неразрешимыми на экзаменах/собеседованиях;

совершенно верно, это обязательно надо учитывать

E>* собеседование, во главу угла которого ставится выяснение способности решать сложные логические задачи, не способно выявить других важных качеств человека. Например, таких как обязательность, исполнительность, аккуратность, спокойствие, наличие здравого смысла. А по жизни такие люди способны принести команде и проектам больше пользы, чем неуравновешенные гении;

ага

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

совершенно верно! еще стратегия и технология!

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

я один раз видел, не взяли.

Здравствуйте, Сергей Мухин, Вы писали:

E>>* собеседование ограничено по времени, соответственно, нет возможности определить, может ли человек решать задачи медлено. Быстро не решил -- свободен, значит вообще решать не умеет;

СМ>в общем согласен, но пусть хоть наметит план, покажет сложности и тп.

Где-то в 2000-м году, в командировке в Москве мне рассказали, что в этом году в первый раз в каком-то московском ВУЗе (название не помню, что что-то престижное, вроде МГТУ Баумана) на экзамене задали логическую задачу:

Есть две комнаты. В одной три лампочки и табуретка. Во второй три выключателя, каждый из которых включает лампочку из первой комнаты. Комнату с лампочками из комнаты с выключателями не видно. В комнату с лампочками можно зайти только после того, как проделаешь все манипуляции с выключателями.

Задача: определить, какой выключатель, какую лампочку включает.

Мне просто интересно, как можно наметить план и указать сложности, если ее решение заранее тебе не известно?

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

E>Здравствуйте, Сергей Мухин, Вы писали:

E>>>* собеседование ограничено по времени, соответственно, нет возможности определить, может ли человек решать задачи медлено. Быстро не решил -- свободен, значит вообще решать не умеет;

СМ>>в общем согласен, но пусть хоть наметит план, покажет сложности и тп.

E>Где-то в 2000-м году, в командировке в Москве мне рассказали, что в этом году в первый раз в каком-то московском ВУЗе (название не помню, что что-то престижное, вроде МГТУ Баумана) на экзамене задали логическую задачу:
E>

E>Есть две комнаты. В одной три лампочки и табуретка. Во второй три выключателя, каждый из которых включает лампочку из первой комнаты. Комнату с лампочками из комнаты с выключателями не видно. В комнату с лампочками можно зайти только после того, как проделаешь все манипуляции с выключателями.

E>Задача: определить, какой выключатель, какую лампочку включает.

E>Мне просто интересно, как можно наметить план и указать сложности, если ее решение заранее тебе не известно?

это легкая задача и известная.
начитанный чел ее должен просто знать.

план такой:
понять зачем тут табуретка! она явно нужна, а раз нужна то....

при это немного не то. это логическая задача на сообразительность и выход из стандартов. а я имел ввиду задачи программирования.

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

M>>В любом случае, тестирование предпочтительнее "рассказа о проектах". Т. к. в рассказе человек просто присваивает себе заслуги всего коллектива разработчиков.

E>1) Они ни в какой степени не взаимозаменяемы и даже не конкурируют
Если время на собеседование не ограничено.

E>2) В "рассказе о проектах" главное не то, что соискатель себе припишет, а то, как и про что он рассказывает, на что обращает вниманеи, а на что нет, что понимает, а что нет и т. д.
А если человек понимает ровно столько, сколько подчерпнул от общения с коллегами? В принципе, где-то этого достаточно. Но если требуется какой-то креатив, решение новых нестандартных задач, то этого будет мало. Поэтому конторы, находящиеся на передовых позициях в разработке предыдущий опыт особо не изучают и концентрируются на выявлении умственных способностей кандидатов. Конечно, дело это непростое. И я не слышал об особо эффективных методиках.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Рано или поздно понимаешь, что это время потрачено на 95% зря, и надо за 15-20 мин определиться с кандидатом. Поэтому задаешь ему все что в голову прийдет. И смотришь как он отвечает. А потом мб задания даешь. Один раз мы взяли чел, который не написал задание и не разочаровались. Необязательно правильно ответить, необязательно даже блико ответить. Я смотрю как чел ведет. Называет он слова "дрова" и тп, Большим плюсом, если он говорит "я не знаю как ответить на этот вопрос"!

Я собеседований почти не проводил (не вдохновляет). Но вообще, склоняюсь к варианту "двухсекундное интерьвью". И, кстати, давал рекомендации шефу на прошлой работе (т.к. кандидаты первым делом всегда заходили в комнату, где я сидел). Шеф слушал с интересом. Но говорил, что так вот судить о людях — большая ошибка. В половине случаев, мол, ошибёшься. Согласен. 100% не гарантирую. Только принцип "лучьше не взять десять подходящих, чем взять одного неподходящего", практикуемый большинством контор при наборе персонала, предполагает ошибку в 90% случаев. Так что "двухсекундное интерьвью" обладает в 5 раз большей точностью.

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

E>>1) Они ни в какой степени не взаимозаменяемы и даже не конкурируют
M>Если время на собеседование не ограничено.
Даже если ограничено. ЦЕЛИ разные...

M>А если человек понимает ровно столько, сколько подчерпнул от общения с коллегами? В принципе, где-то этого достаточно. Но если требуется какой-то креатив, решение новых нестандартных задач, то этого будет мало.
Креативный чел и который от коллег нахватался и основательный чел, который всю смежную тему заботал будут рассказывать совершенно по разному. Обратят внимание на разные аспекты, разное посчитают важным, достойным упоминания. По разному будут отвечать на доп. вопросы (типа, "А почему тут вот было вот так вот? А что вы делали с этим? Я вижу тут такую вот трудность, как вы её решали?")
Правда для этого и сам собеседующий должен быть достаточно курт. Кроме того результаты такого собеседоваия плохо формализуются, соответсвенно и плохо укладываются в бюолкратическую схему работы HR...

M>Поэтому конторы, находящиеся на передовых позициях в разработке предыдущий опыт особо не изучают и концентрируются на выявлении умственных способностей кандидатов. Конечно, дело это непростое. И я не слышал об особо эффективных методиках.
Ну, насколько я знаю, передовые конторы делают так. Сначала HR терзает соискателей задачками(очно либо заочно), а потом предполагаемый начальник чела имеет с ним собеседование "по проектам"...

Здравствуйте, Сергей Мухин, Вы писали:

СМ>это легкая задача и известная.
СМ>начитанный чел ее должен просто знать.

Ну то есть задачки такого типа тестируют опыт чела в посещении собеседований?

А зачем нужно тестировать именно это, и хорошо ли, если тестирование выявит, что опыт есть?

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

M>Ну дык, это ж непаханное поле — подсидеть начальников на три уровня

Ну я бы тебя на работу не взял...

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

V>>Синус получит плавающее, а здесь целое.
E>Ты уж блин определись какую функцию обсуждаешь, которая double возвращает или которая int...
Это ты определись как будешь целое из дабл вытаскивать с абсолютной точностью?

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

M>>Ну дык, это ж непаханное поле — подсидеть начальников на три уровня

E>Ну я бы тебя на работу не взял...

А откуда ты знаешь? Эта шутка вовсе не предназначена для собеседований.

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

E>На 12-то за что? Может всё-таки на 4?

sizeof(long double) == 12

Здравствуйте, Сергей Мухин, Вы писали:

СМ>есть переменная, если у нее значение 1, присвоить ей значение 2, а если 2, то 1. (на любом языке прогр).
подозреваю, что ожидаемый ответ что-то вроде

return 3 - n;

но чем это лучше чем

if (n == 1)
    return 2;
else if (n == 2)
    return 1;
else
    throw new ArgumentOutOfRange("n");

придумать не могу.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

SAV>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>есть переменная, если у нее значение 1, присвоить ей значение 2, а если 2, то 1. (на любом языке прогр).
SAV>подозреваю, что ожидаемый ответ что-то вроде
SAV>

SAV>return 3 - n;
SAV>

SAV>но чем это лучше чем
SAV>

SAV>if (n == 1)
SAV>    return 2;
SAV>else if (n == 2)
SAV>    return 1;
SAV>else
SAV>    throw new ArgumentOutOfRange("n");
SAV>

SAV>придумать не могу.

ну тут нет присвоения! а в задании сказано ясно "присвоить ей значение"

тут опять же не важен ответ, а почему так. чем этот лучше и тп
я бы написал

switch(n){
case 1:
  n=2;
  break;
case 2:
  n=1;
  break;
default:
  throw new ArgumentOutOfRange("n", n);
}

хотя решение 3-n имеет свои плюсы, но больше минусов.

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

E>>На 12-то за что? Может всё-таки на 4?
FR>sizeof(long double) == 12

Ну и что?
Вот, например, какой будет sizeof такой структуры:

struct number_with_id {
    char id;
    long double number;
};

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

M>А откуда ты знаешь? Эта шутка вовсе не предназначена для собеседований.
Ну ты тут много разного писал в принципе...

Здравствуйте, Сергей Мухин, Вы писали:

СМ>хотя решение 3-n имеет свои плюсы, но больше минусов.
А какие минусы ты в нём видишь? assert можно и в 3-n написать...

Здравствуйте, Сергей Мухин, Вы писали:

СМ>я посмотрел в *.h MS2005, там нет. врядли они прпустили.

Они пропустили весь ISO9899. И врядли уже когда-нибудь вспомнят.

7.12.8.4 The tgamma functions

Здравствуйте, Сергей Мухин, Вы писали:

E>>А какие минусы ты в нём видишь? assert можно и в 3-n написать...

СМ>1. assert — зло
Зло или добро определяется инструкцией кодирования + используемой реализацией assert'а...

СМ>2. в ответе assert не было
Ну там была анологичная конструкция, с throw. (см. про разные реализации assert'а)

СМ>3. из 3-n неясно что хотел программист
Почему? Что не ясно в этом коде:

assert( n == 1 || n == 2 );
n = 3 - n;

Хотя, если 1 и 2 -- это элементы перечисления бы были, то я бы наверное switch написал, а вот для bool однозначно так напишу:

f = !f;

А как для int писать -- IMHO, дело вкуса. Не совсем понятно чем один вариант хуже другого.
Соответсвенно не очень хороший вопрос для собеседования, IMHO.
Кроме всего прочего не понятно на чём спрашивающий хочет поиметь...

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

M>- Не веришь? Ну давай, пиши заявление.
Всё равно бы не взял. Меня крайне смущают люди, которые считают тех, кого не понимают, дегенератами, да ещё и "чуют истоину"...
По моим наблюдениям такие сотрудники не умеют действовать прагматически, а именно это в первую очередь и требуется от инженера, в том числе и от программиста...

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

Y>>О! Нужно такой вопрос взять на заметку, чтобы заранее отсеивать откровенно слабых кандидатов.
E>Да? а почему таки нельзя? Тем более, что и на вещественный аргумент факториал хорошо обобщается...

Раз ты ничего, кроме улыбочек не можешь ответить, переформулирую вопрос.
Чем факториал так сильно отличается от функции "N в степени M"? Почему вторую можно делать над вещественными числами, а первую нет?

Здравствуйте, TarasKo, Вы писали:
TK>Сообственно почему? Спросили на собеседовании, потом сказали правильный ответ. Но сейчас меня начали одолевать кое-какие сомнения

Вообще надо проще к такому относиться. Да мало ли кто и что спросит на собеседование, если по каждому идиотскому или пусть спорному вопросу заморачиваться — это нервов никаких не хватит. Лично если мне бы задали такой вопрос, а потом начали упрекать в том что я претендую на senior developer, я бы просто встал, попрощался с этими людьми, потом постарался бы довести до начальства свой субъективный feedback о таких интервьюверах, после чего забыл бы этот случай и не расстраивался и не заморачивался бы.

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

E>Здравствуйте, Сергей Мухин, Вы писали:

E>>>А какие минусы ты в нём видишь? assert можно и в 3-n написать...

СМ>>1. assert — зло
E>Зло или добро определяется инструкцией кодирования + используемой реализацией assert'а...

офигеть, человек приходит со своей инструкцией кодирования и нестандартным assert на собеседование — гнать в шею.

СМ>>2. в ответе assert не было
E>Ну там была анологичная конструкция, с throw. (см. про разные реализации assert'а)

в оригинале написано return 3-n; ГДЕ ТУТ throw? throw был в более правильном варианте

СМ>>3. из 3-n неясно что хотел программист
E>Почему? Что не ясно в этом коде:

assert( n == 1 || n == 2 );
E>n = 3 - n;

ты что, считаешь сопровождать будешь ты, такой умный? Или Вася П.?
А ему надо будет вставлять преобразование 6->19 например.

E>Хотя, если 1 и 2 -- это элементы перечисления бы были, то я бы наверное switch написал, а вот для bool однозначно так напишу:

f = !f;

E>А как для int писать -- IMHO, дело вкуса. Не совсем понятно чем один вариант хуже другого.
E>Соответсвенно не очень хороший вопрос для собеседования, IMHO.
E>Кроме всего прочего не понятно на чём спрашивающий хочет поиметь...

вот как он относится к совету, после ответа что оба варианта — дело вкуса — значит нет вкуса у него.

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

E>>>На 12-то за что? Может всё-таки на 4?
FR>>sizeof(long double) == 12

E>Ну и что?

Ничего, все и получается выровненым по четырехбайтной границе.

E>Вот, например, какой будет sizeof такой структуры:

struct number_with_id {
E>    char id;
E>    long double number;
E>};

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

E>Меня крайне смущают люди, которые считают тех, кого не понимают, дегенератами,

А ты считаешь дегенератами только тех, кого понимаешь?

E>да ещё и "чуют истоину"...

Т.е., те, у кого развита интуиция, не годятся в инженеры?

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

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

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Найти повод понизить зп, може каждый, спрашивать много не надо.
СМ>Другой вопрос, что по КЗОТу понзить тяжело, легче не подымать

Имелось в виду понизить з/п, на которую сторонам удастся договориться при найме. Это ж собеседование о приеме на работу.

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

F>Я бы не взял в первую очередь за утверждение, что истина одна единственная,
Было бы интересно подробней познакомиться с точкой зрения о том что истин несколько (или, может, 0?)

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

F>Крестовые походы, это не то, что мне бы хотелось видеть на работе.

Спокойно, тампильеры ускакали.

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

F>Примерно то же самое и с собеседованиями. Вес ошибки "не заметить хорошего" и "принять плохого" — различен.

Только при разных подходах к организации бизнеса разные ошибке "тяжелее"...
Если испытываешь кадровый город, то тяжелее ошибка "не заметить хорошего", а если испытываешь дефицит заказов, то "принять плохого"...

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

M>Ты сильно обобщаешь. Не знаю, какими задачами ты занимаешься. И были бы мне интересны твои вакансии. Но "такие сотрудники не умеют действовать прагматически" можно переформулировать как "такие руководители не умеют использовать таких сотрудников".
Ну разве что на нетворческих совсем работах...

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

F>>Я бы не взял в первую очередь за утверждение, что истина одна единственная,
M>Было бы интересно подробней познакомиться с точкой зрения о том что истин несколько (или, может, 0?)
Читай Гегеля, например..

F>>и при этом ее можно чуять, а умом, конечно же, не понять.
M>Понимание истины умом — это всего лишь приближение к истине. Понять всё до конца невозможно. Однако обладая интуицией можно находить правильное решение и не имея логического обоснования.

От сотрудника хотелось бы умения внятно объяснить принимаемые решения.
Иначе два таких сотрудника, каждому из которых "кажется немного разное", никогда не смогут сдеалать ничего совместимого...

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

Y>Это утверждение равносильно такому, что sin(0) = 0, значит мы можем sin вычислить точно, и => что мы можем написать такую сигнатуру для sin: int sin(int x); Что в корне неверно. ИМХО это уже клиника, без обид.

Про синус -- это клиника, я согласен, мало того, я могу обосновать почему я считаю такой синус неудачным решением.
Суть моего возражения в том, что синус аргумента выраженного в радианах не имеет естественного сужения на целые числа.
Мало того, и аргумент и результат синуса может быть целым одновременно только в одной точке.

Но возможно ты слыхал, что бывает вполне целочисленная функция "N в степени M"?
Она опредляется как призведение из M сомножетелей, каждый из которых равен N.

Есть её обобщение на поле вещественных чисел. В этом случае и N и M и результат являются вещественными числами.

При этом это обобщение оюладает таким свойством, что в области определения целочисленной функции обе они совпадают.

Кроме того есть функция N!, которая определяется как произведение из N сомножетелей, от N до 1. У неё тоже есть обобщение на поле вещественных чисел -- это так называемая гамма-функция. На области определения N! его значения совпадают со значениями гамма-функции.

Вот и проясни пожалуйста, в чём состоит ПРИНЦИПИАЛЬНАЯ разница между ними?..

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

Y>>>Обе эти функции объединяет одно, их невозможно вычислить точно.
E>>Разве? А что мешает вычислить число "4 в 7-й степени" точно?

Y>Перед вами яркий пример ПТУшного образования.

Ну самокритично так выступаешь

В принципе, я согласен, что человек, который путает вещественные числа с рациональными, не в состоянии внятно пояснить чем возведение в сетпень отличается от факториала, а в качестве аргументов в споре использует переход на личности, имеет очень невысокое образование. Хотя зачем при этом оскорблять ПТУ я тоже не понимаю

E>>Ну ты приведи пример как с факторияалом легко, а с pow не легко...
E>>Кроме того можешь пояснить как вычислить точно число 400!

Y>Нет уж, сначала ты на double'е вычисли примерно 400!, округли с помощью round, распечатай это число и гордо повесь над своим столом результат, будешь внукам рассказывать о своем достижении, когда состаришься

А я и не утверждал, что в системе типов С++ можно легко вычислить хоть "400!" хоть "PI/2 в 400-й степени"... Я всего лишь утверждаю, что ДЛЯ ПРАКТИЧЕСКИХ ПРЕМЕНЕНИЙ достаточно вычислить приближённо, с точностью оступной в double. Чем, в конце концов факториал отличается от степени, синуса или корня? Почему все остальные функции приближать можно, а факториал обязательно вычислять точно... Ты что-то писал про то, что "вычислять факториал неточно" было бы верхом глупости. Ты можешь как-то этот тезис аргументировать? Примеры там привести, например, как вычислить фактоирал большого числа (скажем 100) и почему глупо его вычислять неточно?

Ты что-то писал про "ее не стоит использовать для хранения целочисленных значений. Не сохраняются свойства коммутативности и дистрибутивности арифметических операций. Очень легко нарваться на ошибки округления.". Опять же не мог бы ты привести примеры когда все эти беды происходят с N! и не происходят с pow( N, M )?

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

E>Но возможно ты слыхал, что бывает вполне целочисленная функция "N в степени M"?
E>Она опредляется как призведение из M сомножетелей, каждый из которых равен N.

Это только при условии, что M >= 0.

E>Есть её обобщение на поле вещественных чисел. В этом случае и N и M и результат являются вещественными числами.

E>При этом это обобщение оюладает таким свойством, что в области определения целочисленной функции обе они совпадают.

Но зато область значений не обязательно совпадает из-за ошибок округления.

E>Кроме того есть функция N!, которая определяется как произведение из N сомножетелей, от N до 1. У неё тоже есть обобщение на поле вещественных чисел -- это так называемая гамма-функция. На области определения N! его значения совпадают со значениями гамма-функции.

Ты забыл сказать, что только если вещественная часть аргумента положительна. И это совсем не обобщение факториала на множество R. Это просто частный случай гамма-функций.

E>Вот и проясни пожалуйста, в чём состоит ПРИНЦИПИАЛЬНАЯ разница между ними?..

Если мы будем обобщать факториал на множество R, то мы принципиально ничего не получаем, кроме арифметических ошибок с чисел с плавающей запятой. Еще раз, когда у нас функция при любых аргументах возвращает натуральные числа, у нас нет смысла обобщать ее на поле вещественных чисел. Особенно, когда мы теряем в точности. Более того, я считаю это некорректным, делать такие расширяющие обобщения. Т.к. с таким же успехом, мы могли бы расшириться и на множество комплексных чисел. Что есть ошибка, т.к. потом результат нужно переводить обратно в множество натуральных чисел, а в общем случае, такая операция у нас не определена.

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

F>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>Найти повод понизить зп, може каждый, спрашивать много не надо.
СМ>>Другой вопрос, что по КЗОТу понзить тяжело, легче не подымать

F>Имелось в виду понизить з/п, на которую сторонам удастся договориться при найме. Это ж собеседование о приеме на работу.

нуЮ я не понял о чем это ты? все уже сказано

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

Y>Удачи тебе в практических прЕмениях факториала приближенно

За пожелание удачи спасибо. Но мне кажется, что факториал вообще функуия не особо нужная. Но если уж и нужная, то можно и приближённо вычислять. Точно надо будет только если где-то факториалы из чего-то вычитаются. Но я такой формулы пока припомнить не смог, только умножение/деление. А там точность не критична...

Про отличие pow и гаммы ты тоже, как я понял, решил тему не равивать?

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

E>Тогда, таки на 4 выравниваем...

E>Выравнивали бы на 12 -- было бы 24...

Научись пожалуйста читать сообщения целиком

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

E>Только при разных подходах к организации бизнеса разные ошибке "тяжелее"...

Угу. Как и с ракетами. В военное время вполне допустимо сбить десяток аэробусов во избежание.

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

M>>Понимание истины умом — это всего лишь приближение к истине. Понять всё до конца невозможно. Однако обладая интуицией можно находить правильное решение и не имея логического обоснования.

E>От сотрудника хотелось бы умения внятно объяснить принимаемые решения.
E>Иначе два таких сотрудника, каждому из которых "кажется немного разное", никогда не смогут сдеалать ничего совместимого...

О, если два таких сотрудника разошлись в чём-то, они до бесконечности могут находить аргументы и контраргументы. Но в том то и тоска, что в терминах существующих понятий порой приблизиться к истине бывает невозможно.

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

M>О, если два таких сотрудника разошлись в чём-то, они до бесконечности могут находить аргументы и контраргументы. Но в том то и тоска, что в терминах существующих понятий порой приблизиться к истине бывает невозможно.

IMHO, тоска в другом -- в терминах разработки ПО, как коммерческой деятельности, этот их "диспут до бесконечности" неэффективен.
Намного эффективнее команда из двух прагматиков, которые может быть сделают всё не так "близко к истине", но таки сделают что-то нужное людям, в том числе и клиентам

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

S>Во-первых, за рассуждения про клинику, ПТУ и прочее у нас принято подвергать принудительной коммуникативной аскезе. Крайне рекомендую во избежание сего, подобных высказываний избегать.

Да есть такое. Спасибо за предупреждение

S>Во-вторых, нахальство в нашей области деятельности принято подкреплять технической квалификацией. Ты пока что не не продемонстрировал.

Ну демонстрировать я ничего не собираюсь, думаю и так все понятно. Думаю тот, кто хочет вычислять факториалы приближенно, гораздо больше продемонстрировал

S>Резюме: вместо того, чтобы наезжать на умных людей, почитай что тебе пишут.

Это ты про Егора?

Нет уж, лучше я Кнута почитаю, чем его, а то мало ли, захочу приближенно вычислять простые числа

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

M>Вообще, группы надо строить так, чтобы был выраженный технический лидер, спорить с которым долго ни у кого не получалось.
Мне такой стиль отношений в группе не нравится. Я предпочиаю, чтобы сотрудники слушали аргументы, а не человека, и чтобы все сами могли принимать решения в рамках своей компетенции, ровно как и чувствовать, когда решение выходит за эти рамки

А наличие "несущего невыразимую словами истину" гуру прямо противоречит обоим идеям

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

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

E>А наличие "несущего невыразимую словами истину" гуру прямо противоречит обоим идеям

Ну что ж, кто отвечает за проект, тому и выбирать.

Единственно, не очень красиво писать в кавычках фразу, которой нигде в тексте не было.

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

E>>А наличие "несущего невыразимую словами истину" гуру прямо противоречит обоим идеям

M>Ну что ж, кто отвечает за проект, тому и выбирать.
+1

M>Единственно, не очень красиво писать в кавычках фразу, которой нигде в тексте не было.
Прошу прощения, если ввёл в заблуждение. Я не хотел сказать, что это цитата. Я просто не знаю как проще выразить эту идею. Хорошо бы слово какое-то использовать вместо фразы в кавычках, "изотерического", скажем. Но хорошего слова с таким значением я не знаю

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

Y>ЗЫ: Егор, ты можешь не отвечать на это сообщение, твои сообщения все равно мной игнорируются, а дурацкие минусы и смайлы ставь сколько влезет.

и тебя достал?

он вообще-то белый и пушистый, просто не может остановиться

Здравствуйте, Сергей Мухин, Вы писали:

СМ>и тебя достал?

Yep

СМ>он вообще-то белый и пушистый, просто не может остановиться

Зато я остановился, все его сообщения будут игнориться мной

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

Y>Ну вроде исходно речь шла про определение факториала через (n+1)! = n! * (n+1).

Это ты сам выдумал. Речь шла просто про функцию факториала и применимость приближенного его значения.

Y> Вот ты мне можешь ответить на прямой вопрос, стоит ли факториал определенный таким образом вычислять через double и если стоит, то почему?

Стоит. Потому что факториал, применяемый для вычисления, скажем, вероятностей, вполне допустимо брать приближенный в плавучке.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>

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

Y>Ладно, еще раз. Факториал, определен как (n+1)! = n!*(n+1) или n!=1*2*...*n (0!=1), как видно из определения результатом функции всегда будут неотрицательные целые числа.

Ну и что?

Y> Я думал и думаю это достаточное обоснование, того, что нельзя в качестве результата иметь приближенное значение

Нет. Логической цепочки не вижу — почему из того, что результат всегда положительное целое число, следует невозможзность применения представления числа не с абсолютной точностью.

Y>т.к. иначе приближенный результат не будет подходить под данное определение.

А приближенный результат вычисления квадратного корня не подходит под определение корня? Ведь по определению pow(sqrt(2), 2) Должен бывть равен ровно 2, а по факту будет где то в районе 2, но не точно 2.

Y>А наличие формулы Стирлинга не играет большой роли

Наличие формулы Стирлинга означает, что приближенное вычисление факториала имеет практический смысл.

Y>ну можно большие значения факториалов вычислить приближенно, это не так важно, т.к. результатом могут быть и факториал или его приближенное значение. Вот, я все сказал.

Ты сам понял, что ты сказал?

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

AVK>Нет. Логической цепочки не вижу — почему из того, что результат всегда положительное целое число, следует невозможзность применения представления числа не с абсолютной точностью.

Конкретно для факториалов забавно ещё и то, что double позволяет точно представить больше факториалов, чем int64, и, тем более, больше чем int... То есть, даже если бы факториалы приближённо вычислять было бы нельзя, всё равно результат в double был бы лучше...

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

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

XC>Сообственно почему? ИМХО, куда более полезная вещь чем факториал
XC>

скорее уж сд-эджектор..

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

C>Потому что, при больших x значение x! в double будет сильно отличаться от реального x! man числа с плав. запятой.
Но точность представления числа x! всё равно будет на уровне чисел в double (man туда же

)

E>Но точность представления числа x! всё равно будет на уровне чисел в double (man туда же

)

О том и речь. Это будет нечто похожее на факториал. Но не факториал. Причем ошибка будет расти с увеличением x. Такая реализация для стандартной функции типа Nat -> Nat вообще говоря — нонсенс.

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

C>О том и речь. Это будет нечто похожее на факториал. Но не факториал. Причем ошибка будет расти с увеличением x. Такая реализация для стандартной функции типа Nat -> Nat вообще говоря — нонсенс.

Ну тут уже один мужчина так что-то доказывал, но тогда приходится признать и то, что функция pow тоже нонсенс...
Скажем pow( 5, 20 ) тоже довольно далёк от точного значения 5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5
И что? Вся вычматематика нонсенс?

Прочитай всю ветку, будет что нового сказать -- пиши

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

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

C>>О том и речь. Это будет нечто похожее на факториал. Но не факториал. Причем ошибка будет расти с увеличением x. Такая реализация для стандартной функции типа Nat -> Nat вообще говоря — нонсенс.

E>Ну тут уже один мужчина так что-то доказывал, но тогда приходится признать и то, что функция pow тоже нонсенс...
E>Скажем pow( 5, 20 ) тоже довольно далёк от точного значения 5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5*5
E>И что? Вся вычматематика нонсенс?

Есессно, pow : double x double -> double . Применять его для целочисленных задач — глупость. Там нужна своя функция возведения в степень. Аналогично, fact: double -> double (или ее ублюдочный вариант fact: Nat -> double) и fact: Nat -> Nat — две разные функции, с разными областями применения. Что касается вычмата там как раз методы построены так, что погрешность, возникающая при использовании чисел с плавающ. точкой, в большинстве случаев допустима. Для целочисленных задач такая погрешность в общем случае допустимой не является

По крайней мере я не стал бы подменять функцию fact: Nat -> Nat на fact: double -> double когда надо работать с большими целыми числами x.

	От:	TarasKo
	Дата:	30.05.08 15:33
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	30.05.08 15:22
Оценка:	2 (2) +3

	От:	Ovl
	Дата:	30.05.08 15:00
	Оценка:	1 (1) +9

	От:	Sergey Chadov
	Дата:	30.05.08 18:57
	Оценка:	+3

От:	eao197	http://eao197.blogspot.com
Дата:	05.06.08 09:04
Оценка:	+7

	От:	Сергей Мухин
	Дата:	30.05.08 15:36
	Оценка:	+6

От:	remark	http://www.1024cores.net/
Дата:	30.05.08 15:40
Оценка:	+6

	От:	minorlogic
	Дата:	01.06.08 09:18
	Оценка:	3 (3) +2

	От:	CreatorCray
	Дата:	30.05.08 19:40
	Оценка:	4 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	08.06.08 20:50
Оценка:	+2 -1

От:	Sinclair	https://github.com/evilguest/
Дата:	07.06.08 02:31
Оценка:	14 (1) +1

	От:	Roman Odaisky
	Дата:	01.06.08 09:42
	Оценка:	+1 -1

От:	Vain	google.ru
Дата:	04.06.08 10:04
Оценка:	1 (1)

От:	MozgC	http://nightcoder.livejournal.com
Дата:	06.06.08 00:24
Оценка:

	От:	chukichuki
	Дата:	26.06.08 06:53
	Оценка:	-4

	От:	x-code
	Дата:	09.06.08 18:12
	Оценка:	+1

	От:	chukichuki
	Дата:	26.06.08 12:30
	Оценка:	-2

The last item on the desktop was a mechanical contrivance. ‘Contrivance’ was exactly the right kind of word for it. Terry Pratchett, Thief of Time

The last item on the desktop was a mechanical contrivance. RO>‘Contrivance’ was exactly the right kind of word for it. RO>Terry Pratchett, Thief of Time

The last item on the desktop was a mechanical contrivance.
‘Contrivance’ was exactly the right kind of word for it.

Terry Pratchett, Thief of Time

The last item on the desktop was a mechanical contrivance.
RO>‘Contrivance’ was exactly the right kind of word for it.

RO>Terry Pratchett, Thief of Time