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

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

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



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

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

ps

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

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

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

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

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

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

СМ>

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

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

СМ>ps

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

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

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

Здравствуйте, 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>())

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

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

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

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

СМ>

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

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

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

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

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

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

RO>

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

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

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

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

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

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

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

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


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

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

Здравствуйте, 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]

Здравствуйте, 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 эти числа можно определить и попроще
Эт понятно, но там жеж русским по белому написано — "было скучно"

Здравствуйте, 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 число в пентюхе)