No puedo entender por qué Python no tiene una signfunción. Tiene un absincorporado (que considero signla hermana), pero nosign .

En python 2.6 hay incluso una copysignfunción (en matemáticas ), pero no hay signo. ¿Por qué molestarse en escribir un copysign(x,y)cuando podría simplemente escribir un signy luego obtener el copysigndirectamente abs(x) * sign(y)? Lo último sería mucho más claro: x con el signo de y, mientras que con copysign debe recordar si es x con el signo de y o y con el signo de x.

Obviamente sign(x)no proporciona nada más quecmp(x,0) , pero sería mucho más legible que esto también (y para un lenguaje muy legible como python, esto habría sido una gran ventaja).

Si yo fuera un diseñador de Python, sería lo contrario: no cmpincorporado, sino a sign. Cuando lo necesite cmp(x,y), podría hacer un sign(x-y)(o, mejor aún para cosas no numéricas, solo una x> y, por supuesto, esto debería haber requerido sortedaceptar un booleano en lugar de un comparador de enteros). Esto también sería más claro: positivo cuando x>y(mientras cmpque hay que recordar la convención positiva cuando la primera es más grande , pero podría ser al revés). Por supuestocmp tiene sentido en sí mismo por otras razones (por ejemplo, al ordenar cosas no numéricas, o si desea que la clasificación sea estable, lo que no es posible usar simplemente con un valor booleano)

Entonces, la pregunta es: ¿por qué los diseñadores de Python decidieron dejar la signfunción fuera del lenguaje? ¿Por qué se molestan los diablos copysigny no su padre sign?

¿Me estoy perdiendo de algo?

EDITAR - después del comentario de Peter Hansen. Es justo que no lo haya usado, pero no dijo para qué usa Python. ¡En 7 años que uso Python, lo necesité incontables veces, y la última es la gota que colmó el vaso!

Sí, puedes pasar cmp, pero el 90% de las veces que tuve que pasar fue en un idioma como lambda x,y: cmp(score(x),score(y))ese hubiera funcionado bien con el signo.

Finalmente, espero que esté de acuerdo en que signsería más útil que copysign, así que incluso si compré su vista, ¿por qué molestarse en definir eso en matemáticas, en lugar de firmar? ¿Cómo puede ser tan útil Copysign que Sign?

EDITAR:

De hecho, había un parche que incluíasign() en las matemáticas , pero no fue aceptado, porque no estaban de acuerdo en lo que debería devolver en todos los casos extremos (+/- 0, +/- nan, etc.)

Por lo tanto, decidieron implementar solo copysign, que (aunque más detallado) se puede usar para delegar al usuario final el comportamiento deseado para casos extremos , que a veces pueden requerir la llamadacmp(x,0) .

No sé por qué no está integrado, pero tengo algunas ideas.

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

Lo más importante, copysignes un superconjunto de sign! Llamar copysigncon x = 1 es lo mismo que una signfunción. Entonces puedes usarlo copysigny olvidarte de él .

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

Si te cansas de pasar dos argumentos completos, puedes implementar sign esta manera, y seguirá siendo compatible con el material IEEE mencionado por otros:

>>> 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

En segundo lugar, generalmente cuando desea el signo de algo, simplemente termina multiplicándolo con otro valor. Y, por supuesto, eso es básicamente lo que copysignhace.

Entonces, en lugar de:

s = sign(a)
b = b * s

Solo puedes hacer:

b = copysign(b, a)

Y sí, ¡me sorprende que hayas estado usando Python durante 7 años y creo que cmppodría eliminarse y reemplazarse tan fácilmente sign! ¿Nunca ha implementado una clase con un__cmp__ método? ¿Nunca ha llamado cmpy especificado una función de comparación personalizada?

En resumen, me he encontrado queriendo una signfunción también, pero copysigncon el primer argumento siendo 1 funcionará bien. No estoy de acuerdo con que signsería más útil copysign, ya que he demostrado que es simplemente un subconjunto de la misma funcionalidad.

"copysign" está definido por IEEE 754 y forma parte de la especificación C99. Por eso está en Python. La función no se puede implementar en su totalidad por abs (x) * signo (y) debido a cómo se supone que debe manejar los 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
>>> 

Eso hace que copysign () sea una función más útil que sign ().

En cuanto a las razones específicas por las que el signbit (x) de IEEE no está disponible en Python estándar, no lo sé. Puedo hacer suposiciones, pero sería adivinar.

El módulo matemático en sí usa copysign (1, x) como una forma de verificar si x es negativo o no negativo. Para la mayoría de los casos, tratar con funciones matemáticas que parece más útil que tener un signo (x) que devuelve 1, 0 o -1 porque hay un caso menos a tener en cuenta. Por ejemplo, lo siguiente es del módulo matemático de 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);

Allí puede ver claramente que copysign () es una función más efectiva que una función de signo de tres valores ().

Tu escribiste:

Si fuera un diseñador de Python, sería al revés: no cmp () incorporado, sino un signo ()

Eso significa que no sabes que cmp () se usa para otras cosas además de los números. cmp ("This", "That") no se puede implementar con una función sign ().

Editar para recopilar mis respuestas adicionales en otro lugar :

Basas tus justificaciones en cómo a menudo se ven juntos abs () y sign (). Como la biblioteca estándar de C no contiene ningún tipo de función 'sign (x)', no sé cómo justifica sus puntos de vista. Hay un abs (int) y fabs (doble) y fabsf (flotante) y fabsl (largo) pero no se menciona el signo. Hay "copysign ()" y "signbit ()", pero solo se aplican a los números IEEE 754.

Con números complejos, ¿qué signo (-3 + 4j) volvería en Python, si se implementara? abs (-3 + 4j) devuelve 5.0. Ese es un claro ejemplo de cómo abs () se puede usar en lugares donde sign () no tiene sentido.

Supongamos que se agrega el signo (x) a Python, como complemento de abs (x). Si 'x' es una instancia de una clase definida por el usuario que implementa el método __abs __ (self), entonces abs (x) llamará a x .__ abs __ (). Para funcionar correctamente, para manejar abs (x) de la misma manera, Python tendrá que obtener un signo espacio de (x).

Esto es excesivo para una función relativamente innecesaria. Además, ¿por qué debería existir el signo (x) y no existir el negativo (x) y el no positivo (x)? Mi fragmento de la implementación del módulo matemático de Python muestra cómo se puede usar copybit (x, y) para implementar nonnegative (), lo que no puede hacer un simple signo (x).

Python debería admitir tener un mejor soporte para la función matemática IEEE 754 / C99. Eso agregaría una función signbit (x), que haría lo que quieras en el caso de flotadores. No funcionaría para enteros o números complejos, mucho menos cadenas, y no tendría el nombre que está buscando.

Usted pregunta "por qué", y la respuesta es "el signo (x) no es útil". Afirmas que es útil. Sin embargo, sus comentarios muestran que no sabe lo suficiente como para poder hacer esa afirmación, lo que significa que tendría que mostrar evidencia convincente de su necesidad. Decir que NumPy lo implementa no es lo suficientemente convincente. Debería mostrar casos de cómo se mejoraría el código existente con una función de signo.

Y eso está fuera del alcance de StackOverflow. Llévelo a una de las listas de Python.

Otro trazador de líneas para sign ()

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

Si desea que devuelva 0 para x = 0:

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

Como cmpse ha eliminado , puede obtener la misma funcionalidad con

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

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

Funciona para float, inte incluso Fraction. En el caso de float, avisosign(float("nan")) es cero.

Python no requiere que las comparaciones devuelvan un valor booleano, por lo que obligar a las comparaciones a bool () protege contra la implementación permitida, pero poco común:

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

Solo la respuesta correcta cumple con la definición de Wikipedia

La definición en Wikipedia dice:

Por lo tanto,

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

Que a todos los efectos puede simplificarse para:

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

Esta definición de función se ejecuta rápidamente y produce resultados correctos garantizados para 0, 0.0, -0.0, -4 y 5 (ver comentarios a otras respuestas incorrectas).

Tenga en cuenta que cero (0) no es ni positivo ni negativo .

numpy tiene una función de signo, y también le brinda una ventaja de otras funciones. Entonces:

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

Solo tenga cuidado de que el resultado sea numpy.float64:

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

Para cosas como json, esto es importante, ya que json no sabe cómo serializar los tipos numpy.float64. En ese caso, podrías hacer:

float(np.sign(y))

para obtener un flotador regular.

Intenta ejecutar esto, donde x es cualquier número

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

La coerción a bool () maneja la posibilidad de que el operador de comparación no devuelva un booleano.

Si un correcto sign() función debería estar al menos en el módulo matemático, ya que está en numpy. Porque uno lo necesita con frecuencia para el código orientado a las matemáticas.

Pero math.copysign()también es útil de forma independiente.

cmp()y obj.__cmp__()... tienen generalmente una gran importancia independientemente. No solo para el código orientado a las matemáticas. Considere comparar / ordenar tuplas, objetos de fecha, ...

Los argumentos de desarrollo en http://bugs.python.org/issue1640 con respecto a la omisión de math.sign()son extraños, porque:

• No hay por separado -NaN
• sign(nan) == nan sin preocupaciones (como exp(nan))
• sign(-0.0) == sign(0.0) == 0 sin preocupación
• sign(-inf) == -1 sin preocupación

- como está en numpy

En Python 2, cmp()devuelve un entero: no hay requisito de que el resultado sea -1, 0 o 1, por sign(x)lo que no es lo mismo quecmp(x,0) .

En Python 3, cmp()se ha eliminado a favor de una comparación rica. Para cmp(), Python 3 sugiere esto :

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

lo cual está bien para cmp (), pero nuevamente no se puede usar para sign () porque los operadores de comparación no necesitan devolver booleanos .

Para lidiar con esta posibilidad, los resultados de la comparación deben ser obligados a booleanos:

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

Esto funciona para cualquiera typeque esté totalmente ordenado (incluidos valores especiales como NaNo infinitos).

No necesita uno, solo puede usar:

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

Simplemente no lo hace.

La mejor manera de solucionar esto es:

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

La razón por la que el "signo" no está incluido es porque si incluyéramos todas las líneas útiles en la lista de funciones integradas, Python ya no sería fácil y práctico trabajar con ellas. Si usa esta función con tanta frecuencia, ¿por qué no la factoriza usted mismo? No es que sea remotamente difícil o incluso tedioso hacerlo.