Реализация libm pow (float, float) ядра Android

Question

Я тестирую угловые случаи по вызову pow (#include <math.h>), в частности pow(-1, Inf).

На моем рабочем столе (Ubuntu) я получаю результат 1,0, это соответствует 2008Спецификация IEEE с плавающей точкой.

Я запускаю тот же тест, когда запускаю ядро ​​Android Gingerbread, и мне возвращается NaN.

Я оглянулся и вижу, что действительно существует множество реализаций pow в стандартных библиотеках для разных платформ и в случае pow(-1, Inf) они кодируются для получения разных результатов.

Вопрос в том, какую из них следует считать правильной?Есть идеи или мысли?

Прошу прощения, если я пишу не на том форуме, я перешел по ссылке из ресурсов разработчика Android и оказался здесь.

Answer 1

Стандарт C совершенно ясен в этом вопросе (§F.9.4.4); нет места для «идей или мыслей»:

pow (−1, ± ∞) возвращает 1.

Приложение F применяется, только если реализация определяет __STDC_IEC_559__, но нет никаких сомнений в том, что 1.0 является правильным ответом.

Я подозреваю, что это Java-изм, который просочился в NDK. (Java определяет pow(-1,infinity) как NaN):

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

Edit: Поскольку Маттео возражает, что это «не имеет смысла», я предложу несколько предложений, объясняющих, почему комитет сделал такой выбор. Хотя lim_ {n-> inf} (-1) ^ n не существует в действительных числах, мы должны помнить, что числа с плавающей точкой не являются действительными числами , и фактически для всех достаточно больших плавающих чисел номера точек y, pow(-1,y) равны +1. Это потому, что все достаточно большие числа с плавающей точкой являются четными целыми числами. С этой точки зрения вполне разумно определить pow(-1,infinity) как +1, и это, в действительности, приводит к более полезному поведению в некоторых вычислениях с плавающей точкой.

Существует удивительное количество чрезвычайно компетентных математиков (а также очень опытных программистов и составителей компиляторов), связанных с комитетами C и IEEE-754, и они не принимают эти решения легкомысленно. В каждом стандарте есть ошибки, но это не один из них.