Não consigo entender por que o Python não tem uma signfunção. Ele tem um absbuiltin (que eu considero signa irmã de), mas nãosign .

No python 2.6 há até uma copysignfunção (em matemática ), mas nenhum sinal. Por que se preocupar em escrever um copysign(x,y)quando você pode simplesmente escrever um signe depois obter o copysigndiretamente abs(x) * sign(y)? O último seria muito mais claro: x com o sinal de y, enquanto no copysign você deve se lembrar se é x com o sinal de y ou y com o sinal de x!

Obviamente sign(x), não fornece nada além disso cmp(x,0), mas seria muito mais legível que isso também (e para uma linguagem muito legível como python, isso seria uma grande vantagem).

Se eu fosse um designer de python, seria o contrário: não cmpembutido, mas a sign. Quando você precisar cmp(x,y), você pode simplesmente fazer um sign(x-y)(ou, melhor ainda, para coisas não numéricas, apenas um x> y - é claro que isso deveria exigir a sortedaceitação de um booleano em vez de um comparador inteiro). Isso também ficaria mais claro: positivo quando x>y(considerando que cmpvocê deve se lembrar da convenção positiva quando o primeiro for maior , mas pode ser o contrário). É claro que cmpfaz sentido por outras razões (por exemplo, ao classificar coisas não numéricas, ou se você deseja que a classificação seja estável, o que não é possível usando simplesmente com um booleano)

Então, a pergunta é: por que os designers de Python decidiram deixar a signfunção fora da linguagem? Por que diabos se incomoda com copysigne não com seus paissign ?

Estou esquecendo de algo?

EDIT - após o comentário de Peter Hansen. É justo o suficiente que você não o tenha usado, mas não disse para que usa o python. Em 7 anos que uso python, precisei inúmeras vezes, e o último é o canudo que quebrou as costas do camelo!

Sim, você pode passar o cmp por aí, mas 90% das vezes que eu precisava passá-lo estavam em um idioma como lambda x,y: cmp(score(x),score(y))aquele que funcionaria bem com o sinal.

Finalmente, espero que você concorde que isso signseria mais útil do que copysign, mesmo que eu comprei sua opinião, por que se preocupar em definir isso em matemática, em vez de assinar? Como o copysign pode ser tão útil quanto assinar?

EDITAR:

Na verdade, havia um patch incluído sign()na matemática , mas não era aceito, porque eles não concordavam com o que deveria retornar em todos os casos extremos (+/- 0, +/- nan, etc)

Por isso, eles decidiram implementar apenas o copysign, que (embora mais detalhado) pode ser usado para delegar ao usuário final o comportamento desejado para casos extremos - o que às vezes pode exigir a chamadacmp(x,0) .

Não sei por que não é um built-in, mas tenho alguns pensamentos.

copysign(x,y):
Return x with the sign of y.

Mais importante, copysigné um superconjunto de sign! Ligar copysigncom x = 1 é o mesmo que uma signfunção. Então você pode simplesmente usar copysigne esquecer .

>>> math.copysign(1, -4)
-1.0
>>> math.copysign(1, 3)
1.0

Se você ficar cansado de passar dois argumentos inteiros, poderá implementar signdessa maneira, e ainda será compatível com o material IEEE mencionado por outros:

>>> sign = functools.partial(math.copysign, 1) # either of these
>>> sign = lambda x: math.copysign(1, x) # two will work
>>> sign(-4)
-1.0
>>> sign(3)
1.0
>>> sign(0)
1.0
>>> sign(-0.0)
-1.0
>>> sign(float('nan'))
-1.0

Em segundo lugar, geralmente quando você quer o sinal de algo, acaba multiplicando-o por outro valor. E é claro que é basicamente o que copysignfaz.

Então, em vez de:

s = sign(a)
b = b * s

Você pode apenas fazer:

b = copysign(b, a)

E sim, estou surpreso que você esteja usando o Python por 7 anos e pense que cmppoderia ser facilmente removido e substituído por sign! Você nunca implementou uma classe com um __cmp__método? Você nunca ligou cmpe especificou uma função comparadora personalizada?

Em resumo, também me vi querendo uma signfunção, mas copysigncom o primeiro argumento sendo 1, funcionará bem. Discordo que signseria mais útil do que copysign, como mostrei que é apenas um subconjunto da mesma funcionalidade.

"copysign" é definido pela IEEE 754 e faz parte da especificação C99. É por isso que está em Python. A função não pode ser implementada integralmente pelo sinal abs (x) * (y), devido à forma como deve lidar com os valores de NaN.

>>> import math
>>> math.copysign(1, float("nan"))
1.0
>>> math.copysign(1, float("-nan"))
-1.0
>>> math.copysign(float("nan"), 1)
nan
>>> math.copysign(float("nan"), -1)
nan
>>> float("nan") * -1
nan
>>> float("nan") * 1
nan
>>> 

Isso torna o copysign () uma função mais útil do que sign ().

Quanto a razões específicas pelas quais o signbit do IEEE (x) não está disponível no Python padrão, eu não sei. Eu posso fazer suposições, mas seria adivinhar.

O próprio módulo matemático usa o copysign (1, x) como uma maneira de verificar se x é negativo ou não negativo. Na maioria dos casos, lidar com funções matemáticas parece mais útil do que ter um sinal (x) que retorna 1, 0 ou -1 porque há um caso a menos a ser considerado. Por exemplo, o seguinte é do módulo de matemática do Python:

static double
m_atan2(double y, double x)
{
        if (Py_IS_NAN(x) || Py_IS_NAN(y))
                return Py_NAN;
        if (Py_IS_INFINITY(y)) {
                if (Py_IS_INFINITY(x)) {
                        if (copysign(1., x) == 1.)
                                /* atan2(+-inf, +inf) == +-pi/4 */
                                return copysign(0.25*Py_MATH_PI, y);
                        else
                                /* atan2(+-inf, -inf) == +-pi*3/4 */
                                return copysign(0.75*Py_MATH_PI, y);
                }
                /* atan2(+-inf, x) == +-pi/2 for finite x */
                return copysign(0.5*Py_MATH_PI, y);

Lá você pode ver claramente que copysign () é uma função mais efetiva que uma função sign () de três valores.

Você escreveu:

Se eu fosse um designer de python, seria o contrário: nenhum cmp () embutido, mas um sinal ()

Isso significa que você não sabe que cmp () é usado para outras coisas além de números. O cmp ("This", "That") não pode ser implementado com uma função sign ().

Editar para agrupar minhas respostas adicionais em outro lugar :

Você baseia suas justificativas em como abs () e sign () são frequentemente vistos juntos. Como a biblioteca padrão C não contém uma função 'sign (x)' de qualquer espécie, não sei como você justifica seus pontos de vista. Há um abs (int) e fabs (double) e fabsf (float) e fabsl (long), mas nenhuma menção de sinal. Há "copysign ()" e "signbit ()", mas eles se aplicam apenas aos números IEEE 754.

Com números complexos, o que o sinal (-3 + 4j) retornaria em Python, se fosse implementado? abs (-3 + 4j) retorna 5.0. Esse é um exemplo claro de como o abs () pode ser usado em lugares onde sign () não faz sentido.

Suponha que o sinal (x) foi adicionado ao Python, como um complemento ao abs (x). Se 'x' for uma instância de uma classe definida pelo usuário que implementa o método __abs __ (self), o abs (x) chamará x .__ abs __ (). Para funcionar corretamente, para lidar com abs (x) da mesma maneira, o Python precisará obter um slot de sinal (x).

Isso é excessivo para uma função relativamente desnecessária. Além disso, por que o sinal (x) existe e o não negativo (x) e o não positivo (x) não existem? Meu snippet da implementação do módulo matemático do Python mostra como o copybit (x, y) pode ser usado para implementar o nonnegative (), o que um simples sinal (x) não pode fazer.

O Python deve suportar um suporte melhor para a função matemática IEEE 754 / C99. Isso adicionaria uma função signbit (x), que faria o que você deseja no caso de carros alegóricos. Não funcionaria para números inteiros ou complexos, muito menos cadeias, e não teria o nome que você está procurando.

Você pergunta "por que" e a resposta é "o sinal (x) não é útil". Você afirma que é útil. No entanto, seus comentários mostram que você não sabe o suficiente para fazer essa afirmação, o que significa que você teria que mostrar evidências convincentes de sua necessidade. Dizer que o NumPy implementa isso não é suficientemente convincente. Você precisaria mostrar casos de como o código existente seria aprimorado com uma função de sinal.

E que está fora do escopo do StackOverflow. Leve-o para uma das listas de Python.

Outro forro para sinal ()

sign = lambda x: (1, -1)[x<0]

Se você deseja retornar 0 para x = 0:

sign = lambda x: x and (1, -1)[x<0]

Desde a cmp que foi removido , você pode obter a mesma funcionalidade com

def cmp(a, b):
    return (a > b) - (a < b)

def sign(a):
    return (a > 0) - (a < 0)

Trabalha para float , inte mesmo Fraction. No caso de float, avisosign(float("nan")) é zero.

O Python não exige que as comparações retornem um valor booleano; portanto, coagir as comparações a bool () protege contra a implementação permitida, mas incomum:

def sign(a):
    return bool(a > 0) - bool(a < 0)

Somente resposta correta compatível com a definição da Wikipedia

A definição na Wikipedia diz:

Conseqüentemente,

sign = lambda x: -1 if x < 0 else (1 if x > 0 else (0 if x == 0 else NaN))

Que, para todos os efeitos, pode ser simplificado para:

sign = lambda x: -1 if x < 0 else (1 if x > 0 else 0)

Essa definição de função executa rapidamente e produz resultados corretos garantidos para 0, 0,0, -0,0, -4 e 5 (consulte os comentários para outras respostas incorretas).

Observe que zero (0) não é positivo nem negativo .

o numpy tem uma função de sinal e também oferece um bônus de outras funções. Assim:

import numpy as np
x = np.sign(y)

Apenas tome cuidado para que o resultado seja um numpy.float64:

>>> type(np.sign(1.0))
<type 'numpy.float64'>

Para coisas como json, isso importa, pois o json não sabe como serializar tipos numpy.float64. Nesse caso, você pode fazer:

float(np.sign(y))

para obter uma flutuação regular.

Tente executar isso, onde x é qualquer número

int_sign = bool(x > 0) - bool(x < 0)

A coerção para bool () lida com a possibilidade de o operador de comparação não retornar um booleano.

Sim, uma sign()função correta deve estar pelo menos no módulo de matemática - como é numpy. Porque freqüentemente é necessário para código orientado a matemática.

Mas math.copysign()também é útil de forma independente.

cmp()e obj.__cmp__()... geralmente têm alta importância independentemente. Não apenas para código orientado a matemática. Considere comparar / classificar tuplas, objetos de data, ...

Os argumentos dev em http://bugs.python.org/issue1640 sobre a omissão de math.sign()são estranhos, porque:

• Não há separado -NaN
• sign(nan) == nan sem preocupação (como exp(nan))
• sign(-0.0) == sign(0.0) == 0 Sem se preocupar
• sign(-inf) == -1 Sem se preocupar

- como está entorpecido

No Python 2, cmp()retorna um número inteiro: não é necessário que o resultado seja -1, 0 ou 1; portanto, sign(x)não é o mesmo quecmp(x,0) .

No Python 3, cmp()foi removido em favor da comparação rica. Pois cmp(), o Python 3 sugere o seguinte :

def cmp(a, b):
    return (a > b) - (a < b)

o que é bom para cmp (), mas novamente não pode ser usado para sign () porque os operadores de comparação não precisam retornar booleanos .

Para lidar com essa possibilidade, os resultados da comparação devem ser coagidos aos booleanos:

 def sign(a):
    return bool(x > 0) - bool(x < 0)

Isso funciona para qualquer um typeque seja totalmente ordenado (incluindo valores especiais como NaNou infinitos).

Você não precisa de um, basta usar:

If not number == 0:
    sig = number/abs(number)
else:
    sig = 0

Simplesmente não.

A melhor maneira de corrigir isso é:

sign = lambda x: bool(x > 0) - bool(x < 0)

A razão pela qual "sign" não está incluída é que, se incluíssemos todas as linhas úteis na lista de funções internas, o Python não seria mais fácil e prático de se trabalhar. Se você usa essa função com tanta frequência, por que não faz isso sozinha? Não é remotamente difícil ou mesmo tedioso fazê-lo.