Por que `int pow (int base, int expoent)` não está nas bibliotecas C ++ padrão?

Eu sinto que devo simplesmente ser incapaz de encontrar. Existe alguma razão para que a powfunção C ++ não implemente a função "power" para nada, exceto floats e doubles?

Eu sei que a implementação é trivial, apenas sinto que estou fazendo um trabalho que deveria estar em uma biblioteca padrão. Uma função de potência robusta (ou seja, lida com o estouro de alguma forma consistente e explícita) não é divertida de escrever.

A partir de C++11, casos especiais foram adicionados ao conjunto de funções de energia (e outros). C++11 [c.math] /11estados, depois de listar todas as float/double/long doublesobrecargas (grifo meu, e parafraseado):

Além disso, deve haver sobrecargas adicionais suficientes para garantir que, se qualquer argumento correspondente a um doubleparâmetro tiver tipo doubleou um tipo inteiro, todos os argumentos correspondentes aos doubleparâmetros serão efetivamente convertidos para double.

Portanto, basicamente, os parâmetros inteiros serão atualizados para duplos para realizar a operação.

Antes C++11(quando sua pergunta foi feita), não existiam sobrecargas de inteiros.

Desde que eu estava nem intimamente associada com os criadores C, nem C++nos dias de sua criação (embora eu estou bastante antigo), nem parte dos comitês ANSI / ISO que criaram os padrões, este é necessariamente opinião da minha parte. Eu gostaria de pensar que é uma opinião informada , mas, como minha esposa lhe dirá (freqüentemente e sem muito incentivo necessário), eu estive errado antes :-)

A suposição, pelo que vale, segue.

Eu suspeito que a razão do original pré-ANSI Cnão têm esta característica é porque era totalmente desnecessário. Em primeiro lugar, já havia uma maneira perfeitamente boa de fazer potências de inteiros (com duplas e simplesmente converter de volta para um inteiro, verificando se há estouro e estouro negativo antes da conversão).

Em segundo lugar, outra coisa que você deve lembrar é que a intenção original do Cera ser uma linguagem de programação de sistemas , e é questionável se o ponto flutuante é desejável nessa área.

Já que um de seus casos de uso inicial era codificar o UNIX, o ponto flutuante seria quase inútil. O BCPL, no qual o C foi baseado, também não tinha uso para potências (não tinha ponto flutuante, de memória).

Como um aparte, um operador de potência integral provavelmente teria sido um operador binário em vez de uma chamada de biblioteca. Você não adiciona dois inteiros com, x = add (y, z)mas com x = y + z- parte da linguagem adequada ao invés da biblioteca.

Terceiro, como a implementação do poder integral é relativamente trivial, é quase certo que os desenvolvedores da linguagem usariam melhor seu tempo fornecendo coisas mais úteis (veja abaixo os comentários sobre o custo de oportunidade).

Isso também é relevante para o original C++. Como a implementação original era efetivamente apenas um tradutor que produzia Ccódigo, ela carregava muitos dos atributos de C. Sua intenção original era C-com-classes, não C-com-classes-mais-um-pouco-extra-matemática-coisa.

Quanto ao motivo pelo qual ele nunca foi adicionado aos padrões antes C++11, você deve se lembrar que os órgãos de definição de padrões têm diretrizes específicas a seguir. Por exemplo, ANSI Cfoi especificamente encarregado de codificar a prática existente, não de criar uma nova linguagem. Caso contrário, eles poderiam ter enlouquecido e nos dado Ada :-)

As iterações posteriores desse padrão também têm diretrizes específicas e podem ser encontradas nos documentos de justificativa (justificativa de por que o comitê tomou certas decisões, não a justificativa para a linguagem em si).

Por exemplo, o C99documento de justificativa especificamente leva adiante dois dos C89princípios orientadores que limitam o que pode ser adicionado:

• Mantenha a linguagem pequena e simples.
  
• Fornece apenas uma maneira de fazer uma operação.

Diretrizes (não necessariamente aquelas específicas ) são estabelecidas para os grupos de trabalho individuais e, portanto, limitam os C++comitês (e todos os outros grupos ISO) também.

Além disso, os órgãos de definição de padrões percebem que há um custo de oportunidade (um termo econômico que significa o que você tem que abrir mão para uma decisão tomada) para cada decisão que tomam. Por exemplo, o custo de oportunidade de comprar aquela máquina de uber-gaming de $ 10.000 são relações cordiais (ou provavelmente todas as relações) com sua outra metade por cerca de seis meses.

Eric Gunnerson explica isso bem com sua explicação de -100 pontos sobre por que as coisas nem sempre são adicionadas aos produtos Microsoft - basicamente, um recurso começa 100 pontos no buraco, então tem que adicionar um pouco de valor para ser considerado.

Em outras palavras, você prefere ter um operador de energia integral (que, honestamente, qualquer codificador decente poderia fazer em dez minutos) ou multi-threading adicionado ao padrão? Para mim, prefiro ter o último e não ter que me preocupar com as diferentes implementações no UNIX e no Windows.

Eu gostaria de ver também milhares e milhares de coleção da biblioteca padrão (hashes, btrees, árvores vermelhas e pretas, dicionário, mapas arbitrários e assim por diante), mas, como afirma a lógica:

Um padrão é um tratado entre implementador e programador.

E o número de implementadores nos organismos de padrões supera em muito o número de programadores (ou pelo menos aqueles programadores que não entendem o custo de oportunidade). Se tudo isso fosse adicionado, o próximo padrão C++seria C++215xe provavelmente seria totalmente implementado por desenvolvedores de compiladores trezentos anos depois disso.

De qualquer forma, essa é minha opinião (bastante volumosa) sobre o assunto. Se os votos fossem dados com base na quantidade e não na qualidade, eu logo tiraria todos os outros da água. Obrigado por ouvir :-)

Para qualquer tipo integral de largura fixa, quase todos os pares de entrada possíveis excedem o tipo, de qualquer maneira. Qual é a utilidade de padronizar uma função que não fornece um resultado útil para a grande maioria de suas entradas possíveis?

Você praticamente precisa ter um tipo de inteiro grande para tornar a função útil, e a maioria das bibliotecas de inteiro grande fornece a função.

Edit: Em um comentário sobre a questão, static_rtti escreve "A maioria das entradas causa o estouro? O mesmo é verdade para exp e double pow, não vejo ninguém reclamando." Isso está incorreto.

Vamos deixar de lado exp, porque isso não vem ao caso (embora na verdade tornasse meu caso mais forte) e focar double pow(double x, double y). Para qual porção dos pares (x, y) esta função faz algo útil (ou seja, não simplesmente estouro ou estouro negativo)?

Na verdade, vou me concentrar apenas em uma pequena parte dos pares de entrada para os quais powfaz sentido, porque isso será suficiente para provar meu ponto: se x for positivo e | y | <= 1, então pownão transborda ou underflow. Isso compreende quase um quarto de todos os pares de ponto flutuante (exatamente metade dos números de ponto flutuante não NaN são positivos, e pouco menos da metade dos números de ponto flutuante não NaN têm magnitude menor que 1). Obviamente, existem muitos outros pares de entrada para os quais powproduz resultados úteis, mas verificamos que é pelo menos um quarto de todas as entradas.

Agora vamos olhar para uma função de potência inteira de largura fixa (ou seja, não bignum). Para quais entradas de porção ele simplesmente não transborda? Para maximizar o número de pares de entrada significativos, a base deve ser assinada e o expoente não assinado. Suponha que a base e o expoente tenham nlargura de bits. Podemos facilmente obter um limite na parte das entradas que são significativas:

• Se o expoente 0 ou 1, qualquer base é significativa.
• Se o expoente for 2 ou maior, nenhuma base maior que 2 ^ (n / 2) produz um resultado significativo.

Assim, dos 2 ^ (2n) pares de entrada, menos de 2 ^ (n + 1) + 2 ^ (3n / 2) produzem resultados significativos. Se olharmos para o que é provavelmente o uso mais comum, inteiros de 32 bits, isso significa que algo na ordem de 1/1000 de um por cento dos pares de entrada não estouram simplesmente.

Porque não há como representar todas as potências inteiras em um int de qualquer maneira:

>>> print 2**-4
0.0625

Essa é realmente uma pergunta interessante. Um argumento que não encontrei na discussão é a simples falta de valores de retorno óbvios para os argumentos. Vamos contar as maneiras pelas quais a int pow_int(int, int)função hipotética pode falhar.

1. Transbordar
2. Resultado indefinido pow_int(0,0)
3. Resultado não pode ser representado pow_int(2,-1)

A função tem pelo menos 2 modos de falha. Os inteiros não podem representar esses valores, o comportamento da função nesses casos precisaria ser definido pelo padrão - e os programadores precisariam estar cientes de como exatamente a função lida com esses casos.

No geral, deixar a função de fora parece a única opção sensata. O programador pode usar a versão de ponto flutuante com todos os relatórios de erros disponíveis.

Resposta curta:

Uma especialização de pow(x, n)onde né um número natural costuma ser útil para o desempenho de tempo . Mas o genérico da biblioteca padrão pow()ainda funciona muito ( surpreendentemente! ) Bem para esse propósito e é absolutamente crítico incluir o mínimo possível na biblioteca C padrão para que possa ser o mais portátil e fácil de implementar possível. Por outro lado, isso não o impede de estar na biblioteca padrão C ++ ou no STL, que tenho certeza que ninguém está planejando usar em algum tipo de plataforma embarcada.

Agora, para a longa resposta.

pow(x, n)pode ser feito muito mais rápido em muitos casos, especializando-se npara um número natural. Tive de usar minha própria implementação dessa função para quase todos os programas que escrevo (mas escrevo muitos programas matemáticos em C). A operação especializada pode ser feita em O(log(n))tempo, mas quando né pequena, uma versão linear mais simples pode ser mais rápida. Aqui estão implementações de ambos:

    // Computes x^n, where n is a natural number.
    double pown(double x, unsigned n)
    {
        double y = 1;
        // n = 2*d + r. x^n = (x^2)^d * x^r.
        unsigned d = n >> 1;
        unsigned r = n & 1;
        double x_2_d = d == 0? 1 : pown(x*x, d);
        double x_r = r == 0? 1 : x;
        return x_2_d*x_r;
    }
    // The linear implementation.
    double pown_l(double x, unsigned n)
    {
        double y = 1;
        for (unsigned i = 0; i < n; i++)
            y *= x;
        return y;
    }

(Saí xe o valor de retorno dobra porque o resultado de pow(double x, unsigned n)caberá em um dobro com a frequência necessária pow(double, double).)

(Sim, powné recursivo, mas quebrar a pilha é absolutamente impossível, pois o tamanho máximo da pilha será aproximadamente igual log_2(n)e né um inteiro. Se nfor um inteiro de 64 bits, isso dá a você um tamanho máximo de pilha de cerca de 64. Nenhum hardware tem tal extremo limitações de memória, exceto para alguns PICs duvidosos com pilhas de hardware que têm profundidade de 3 a 8 chamadas de função.)

Quanto ao desempenho, você ficará surpreso com o que uma variedade de jardim pow(double, double)é capaz. Testei cem milhões de iterações em meu IBM Thinkpad de 5 anos xigual ao número da iteração e nigual a 10. Nesse cenário, pown_lvenceu. glibc pow()levou 12,0 segundos do usuário, pown7,4 segundos do usuário e pown_lapenas 6,5 segundos do usuário. Portanto, isso não é muito surpreendente. Estávamos mais ou menos esperando isso.

Então, eu deixo xser constante (eu configurei para 2,5), e fiz um loop nde 0 a 19 cem milhões de vezes. Desta vez, de forma bastante inesperada, glibc powvenceu, e por um deslizamento de terra! Demorou apenas 2,0 segundos do usuário. Meu powndemorou 9,6 segundos e pown_l12,2 segundos. O que aconteceu aqui? Fiz outro teste para descobrir.

Eu fiz a mesma coisa acima apenas com xigual a um milhão. Desta vez, pownvenceu a 9.6s. pown_llevou 12,2s e glibc pow levou 16,3s. Agora está claro! glibc tem powmelhor desempenho que os três quando xestá baixo, mas pior quando xestá alto. Quando xestá alto, tem pown_lmelhor desempenho quando nestá baixo e tem pownmelhor desempenho quando xestá alto.

Portanto, aqui estão três algoritmos diferentes, cada um capaz de ter um desempenho melhor do que os outros nas circunstâncias certas. Então, em última análise, que a utilização mais provável depende de como você está pensando em usar pow, mas usando a versão correta é vale a pena, e com todas as versões é bom. Na verdade, você pode até automatizar a escolha do algoritmo com uma função como esta:

double pown_auto(double x, unsigned n, double x_expected, unsigned n_expected) {
    if (x_expected < x_threshold)
        return pow(x, n);
    if (n_expected < n_threshold)
        return pown_l(x, n);
    return pown(x, n);
}

Contanto que x_expectede n_expectedsejam constantes decididas em tempo de compilação, junto com possivelmente algumas outras advertências, um compilador de otimização que valha a pena removerá automaticamente a pown_autochamada de função inteira e a substituirá pela escolha apropriada dos três algoritmos. (Agora, se você realmente vai tentar usar isso, provavelmente terá que brincar um pouco com isso, porque eu não tentei exatamente compilar o que escrevi acima.;))

Por outro lado, glibc pow funciona e glibc já é grande o suficiente. O padrão C deve ser portátil, incluindo para vários dispositivos incorporados (na verdade, desenvolvedores incorporados em todos os lugares geralmente concordam que glibc já é muito grande para eles), e não pode ser portátil se para cada função matemática simples ele precisa incluir todos algoritmo alternativo que pode ser útil. Então, é por isso que não está no padrão C.

nota de rodapé: no teste de desempenho de tempo, dei às minhas funções sinalizadores de otimização relativamente generosos ( -s -O2) que provavelmente são comparáveis, senão piores do que o que provavelmente foi usado para compilar glibc em meu sistema (archlinux), então os resultados são provavelmente justo. Para um teste mais rigoroso, eu teria que compilar glibc mim e eu reeeally não sentir vontade de fazer isso. Eu costumava usar o Gentoo, então me lembro quanto tempo leva, mesmo quando a tarefa é automatizada . Os resultados são conclusivos (ou melhor, inconclusivos) o suficiente para mim. É claro que você pode fazer isso sozinho.

Rodada de bônus: A especialização de pow(x, n)para todos os inteiros é instrumental se uma saída inteira exata for necessária, o que acontece. Considere alocar memória para uma matriz N-dimensional com p ^ N elementos. Tirar p ^ N igual a um resultará em um segfault que pode ocorrer aleatoriamente.

Uma razão para C ++ não ter sobrecargas adicionais é ser compatível com C.

C ++ 98 tem funções semelhantes a double pow(double, int), mas foram removidas do C ++ 11 com o argumento de que o C99 não as incluía.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3286.html#550

Obter um resultado um pouco mais preciso também significa obter um resultado ligeiramente diferente .

O mundo está em constante evolução, assim como as linguagens de programação. A quarta parte do C decimal TR ¹ adiciona mais algumas funções a <math.h>. Duas famílias dessas funções podem ser de interesse para esta questão:

• As pownfunções, que recebem um número de ponto flutuante e um intmax_texpoente.
• As powrfunções, que pegam dois números de pontos flutuantes ( xe y) e calculam xa potência ycom a fórmula exp(y*log(x)).

Parece que os caras padrão eventualmente consideraram esses recursos úteis o suficiente para serem integrados na biblioteca padrão. No entanto, o racional é que essas funções são recomendadas pelo padrão ISO / IEC / IEEE 60559: 2011 para números de ponto flutuante binários e decimais. Não posso dizer com certeza qual "padrão" era seguido na época do C89, mas as evoluções futuras do <math.h>serão provavelmente fortemente influenciadas pelas evoluções futuras do padrão ISO / IEC / IEEE 60559 .

Observe que a quarta parte do TR decimal não será incluída no C2x (a próxima revisão C principal) e provavelmente será incluída posteriormente como um recurso opcional. Não há nenhuma intenção que eu conheça de incluir esta parte do TR em uma revisão futura do C ++.

¹ Você pode encontrar alguma documentação de trabalho em andamento aqui .

Talvez porque a ALU do processador não implementou tal função para inteiros, mas existe tal instrução FPU (como Stephen aponta, é na verdade um par). Portanto, era realmente mais rápido lançar para dobrar, chamar pow com duplos, testar o estouro e lançar de volta do que implementá-lo usando aritmética de inteiros.

(por um lado, os logaritmos reduzem as potências à multiplicação, mas os logaritmos de inteiros perdem muita precisão para a maioria das entradas)

Stephen está certo que nos processadores modernos isso não é mais verdade, mas o padrão C quando as funções matemáticas foram selecionadas (C ++ apenas usava as funções C) tem agora o que, 20 anos?

Aqui está uma implementação O (log (n)) realmente simples de pow () que funciona para qualquer tipo numérico, incluindo inteiros :

template<typename T>
static constexpr inline T pown(T x, unsigned p) {
    T result = 1;

    while (p) {
        if (p & 0x1) {
            result *= x;
        }
        x *= x;
        p >>= 1;
    }

    return result;
}

É melhor do que a implementação O (log (n)) do enigmaticPhysicist porque não usa recursão.

Também é quase sempre mais rápido do que sua implementação linear (desde que p> ~ 3) porque:

• não requer nenhuma memória extra
• ele faz apenas cerca de 1,5x mais operações por loop
• ele só faz aproximadamente 1,25x mais atualizações de memória por loop

Na verdade, sim.

Desde C ++ 11, há uma implementação pow(int, int)modelada de --- e casos ainda mais gerais, consulte (7) em http://en.cppreference.com/w/cpp/numeric/math/pow

EDITAR: os puristas podem argumentar que isso não é correto, pois na verdade é usada uma digitação "promovida". De uma forma ou de outra, obtém-se um intresultado correto , ou um erro, nos intparâmetros.

Um motivo muito simples:

5^-2 = 1/25

Tudo na biblioteca STL é baseado nas coisas mais precisas e robustas que se possa imaginar. Claro, o int voltaria a zero (de 1/25), mas essa seria uma resposta imprecisa.

Eu concordo, é estranho em alguns casos.