2 White Owl:

White Owlkab18Возможно кто-нибудь подскажет каким образом можно извлечь корень в нечетной степени из отрицательного числа.Не бывает такого.
Бывает, например

2 kab18:

Пара замечаний:

kab18


Деление -- не самый лучший способ получить знак числа. Лучше использовать стандартную функцию copysign , она от первого параметра берёт абсолютное значение, а от второго -- знак.

kab18


Если важна точность, то лучше не умножать на одну треть (которая не представима точно типом double), а делить на 3.

С учётом замечаний, я бы написал так:



Ну и конкретно для кубического корня есть стандартная функция cbrt (аналог sqrt). В MinGW 4.4.1 она нормально работает с отрицательными числами. Как в остальных компиляторах -- не знаю.

2 Edd.Dragon:
Edd.DragonА чем if не подходит?
Для получения знака числа? Подходит, но это же ветвление (branch), а для современных процессоров чем меньше ветвлений, тем лучше. А функцию copysign можно реализовать как раз без ветвлений, просто механическое перекладывание битов (для типа double, знак хранится в старшем бите, абсолютное значение -- в оставшихся 63-ёх битах).

2 Диклевич Александр:

Диклевич Александра чем второй пост в теме не ответ?
Вполне ответ, спасибо ZyK_BotaN-у, но, возможно, автор вопроса (kab18) хотел увидеть конкретный код.

2 mikhail_n:

mikhail_nЕсли важна точность, то лучше не умножать на одну треть (которая не представима точно типом double), а делить на 3.

А что, результат деления одного double на 3 всегда и везде точно представим другим double, т.е. не имеет ошибки округления?
Я, возможно, не очень удачно использовал слово «точность». Я не имел в виду, что, для типа double, деление на 3 всегда даёт точный результат. Мои слова «Если важна точность» надо понимать как «Если хочется погрешность поменьше».

Например, у меня есть число 1.25 (представимое точно типом double) и я хочу посчитать треть от него. Я могу сделать это двумя способами:


Вывод (MinGW 4.4.1, без оптимизаций):
Теперь забываем про тип double и пишем абстрактные математические числа (некоторые из которых записываются бесконечным количеством цифр в десятичной системе счисления):
То есть оба способа дали неточный результат, но погрешность при делении (err_div = 2.33...·10 ^-17 ) оказалась меньше, чем погрешность при умножении (err_mul = 3.66...·10 ^-17 ). То есть, для типа double, деление на 3 может дать более «хороший» (в плане погрешности) результат, чем умножение на 1/3, о чём уже написали Anatoly Moskovsky и jmp.

2 mayton:

maytonКаждая операция над double/float вносит некую абсолютную погрешнось.
Строго говоря, не каждая. Стандарт IEEE 754 требует, что если точный результат арифметической операции представим точно floating-point типом, то именно этот точный результат и должен быть получен, без всякой погрешности, например:


Источник: What Every Computer Scientist Should Know About Floating-Point Arithmetic .
The IEEE Standard
...
Formats and Operations
...
Operations

The IEEE standard requires that the result of addition, subtraction, multiplication and division be exactly rounded. That is, the result must be computed exactly and then rounded to the nearest floating-point number (using round to even).

2 Edd.Dragon:
Edd.DragonПётр СедовТо есть оба способа дали неточный результат, но погрешность при делении (err_div = 2.33...·10 ^-17 ) оказалась меньше, чем погрешность при умножении (err_mul = 3.66...·10 ^-17 ).
Да одинаковая. 17-ый порядок.
Если для достижения конечного результата надо делать одну/две арифметические операции, то действительно разница несущественная. Но если операций надо делать много (какой-нибудь итерационный метод, например), то погрешность будет накапливаться, и в некоторых задачах есть смысл позаботиться о её минимизации.