Non riesco a capire perché Python non abbia una signfunzione. Ha un absbuiltin (che considero signla sorella), ma no sign.

In python 2.6 c'è anche una copysignfunzione (in matematica ), ma nessun segno. Perché preoccuparsi di scrivere un copysign(x,y)quando si potrebbe semplicemente scrivere un signe quindi ottenere copysigndirettamente da abs(x) * sign(y)? Quest'ultimo sarebbe molto più chiaro: x con il segno di y, mentre con copysign devi ricordare se è x con il segno di y o y con il segno di x!

Ovviamente sign(x)non fornisce nulla di più cmp(x,0), ma sarebbe molto più leggibile anche questo (e per un linguaggio molto leggibile come Python, questo sarebbe stato un grande vantaggio).

Se fossi un designer di pitone, sarei il contrario: nessun cmpbuiltin, ma a sign. Quando ne hai bisogno cmp(x,y), potresti semplicemente fare un sign(x-y)(o, ancora meglio, per cose non numeriche, solo un x> y - ovviamente questo avrebbe dovuto sortedaccettare un valore booleano invece di un comparatore intero). Questo sarebbe anche più chiaro: positivo quando x>y(mentre con cmpte devi ricordare la convenzione positiva quando il primo è più grande , ma potrebbe essere il contrario). Naturalmente cmpha senso per altri motivi (ad esempio quando si ordinano cose non numeriche o se si desidera che l'ordinamento sia stabile, cosa impossibile con un semplice valore booleano)

Quindi, la domanda è: perché i designer Python hanno deciso di lasciare la signfunzione fuori dal linguaggio? Perché diavolo preoccuparsi copysigne non dei suoi genitori sign?

Mi sto perdendo qualcosa?

EDIT - dopo il commento di Peter Hansen. Abbastanza giusto da non averlo usato, ma non hai detto per cosa usi Python. In 7 anni che uso Python, ne avevo bisogno innumerevoli volte, e l'ultima è la goccia che ha spezzato la schiena del cammello!

Sì, puoi passare cmp in giro, ma il 90% delle volte che ho dovuto passare era in un idioma del genere lambda x,y: cmp(score(x),score(y))avrebbe funzionato con il segno bene.

Infine, spero che tu sia d'accordo sul fatto che signsarebbe più utile di copysign, quindi anche se avessi acquistato il tuo punto di vista, perché preoccuparsi di definirlo in matematica, invece di firmare? Come può copysign essere così utile che firmare?

MODIFICARE:

In effetti c'era una patch inclusa sign()in matematica , ma non era accettata, perché non erano d'accordo su cosa dovesse tornare in tutti i casi limite (+/- 0, +/- nan, ecc.)

Così hanno deciso di implementare solo il copysign, che (sebbene più dettagliato) può essere utilizzato per delegare all'utente finale il comportamento desiderato per i casi limite - che a volte potrebbe richiedere la chiamata acmp(x,0) .

Non so perché non sia un built-in, ma ho alcuni pensieri.

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

copysignAncora più importante, è un superset di sign! Chiamare copysigncon x = 1 equivale a una signfunzione. Quindi potresti semplicemente usarlo copysigne dimenticartene .

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

Se ti ammali di passare due interi argomenti, puoi implementarlo in signquesto modo, e sarà comunque compatibile con le cose IEEE menzionate da altri:

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

In secondo luogo, di solito quando vuoi il segno di qualcosa, finisci per moltiplicarlo con un altro valore. E ovviamente questo è fondamentalmente ciò che copysignfa.

Quindi, invece di:

s = sign(a)
b = b * s

Puoi semplicemente fare:

b = copysign(b, a)

E sì, sono sorpreso che tu stia usando Python da 7 anni e penso che cmppossa essere rimosso e sostituito così facilmente sign! Non hai mai implementato una classe con un __cmp__metodo? Non hai mai chiamato cmpe specificato una funzione di confronto personalizzata?

In sintesi, mi sono trovato a desiderare anche una signfunzione, ma copysigncon il primo argomento 1 funzionerà bene. Non sono d'accordo sul fatto che signsarebbe più utile di copysign, poiché ho dimostrato che si tratta semplicemente di un sottoinsieme della stessa funzionalità.

"copysign" è definito da IEEE 754 e fa parte della specifica C99. Ecco perché è in Python. La funzione non può essere implementata per intero dal segno abs (x) * (y) a causa di come dovrebbe gestire i valori 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
>>> 

Ciò rende copysign () una funzione più utile di sign ().

Per quanto riguarda i motivi specifici per cui il signbit di IEEE (x) non è disponibile in Python standard, non lo so. Posso fare ipotesi, ma sarebbe indovinare.

Lo stesso modulo di matematica utilizza copysign (1, x) come un modo per verificare se x è negativo o non negativo. Nella maggior parte dei casi si tratta di funzioni matematiche che sembrano più utili che avere un segno (x) che restituisce 1, 0 o -1 perché c'è un caso in meno da considerare. Ad esempio, quanto segue proviene dal modulo di matematica di 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ì puoi vedere chiaramente che copysign () è una funzione più efficace di una funzione sign () a tre valori.

Hai scritto:

Se fossi un designer Python, sarei il contrario: nessun cmp () incorporato, ma un segno ()

Ciò significa che non sai che cmp () è usato per cose oltre ai numeri. cmp ("This", "That") non può essere implementato con una funzione sign ().

Modifica per raccogliere le mie risposte aggiuntive altrove :

Basi le tue giustificazioni su come abs () e sign () sono spesso visti insieme. Dato che la libreria C standard non contiene una funzione "sign (x)" di alcun tipo, non so come giustificare le tue opinioni. C'è un abs (int) e fabs (doppio) e fabsf (float) e fabsl (long) ma nessuna menzione di segno. Esistono "copysign ()" e "signbit ()" ma quelli si applicano solo ai numeri IEEE 754.

Con numeri complessi, cosa significherebbe (-3 + 4j) tornare in Python, se fosse implementato? abs (-3 + 4j) restituisce 5.0. Questo è un chiaro esempio di come abs () può essere usato in luoghi in cui sign () non ha senso.

Supponiamo che il segno (x) sia stato aggiunto a Python, come complemento di abs (x). Se 'x' è un'istanza di una classe definita dall'utente che implementa il metodo __abs __ (self), allora abs (x) chiamerà x .__ abs __ (). Per funzionare correttamente, per gestire abs (x) allo stesso modo, Python dovrà ottenere uno slot segno (x).

Questo è eccessivo per una funzione relativamente non necessaria. Inoltre, perché il segno (x) dovrebbe esistere e non negativo (x) e non positivo (x) non esistere? Il mio frammento dell'implementazione del modulo matematico di Python mostra come copybit (x, y) può essere usato per implementare nonnegative (), cosa che un semplice segno (x) non può fare.

Python dovrebbe supportare un supporto migliore per la funzione matematica IEEE 754 / C99. Ciò aggiungerebbe una funzione signbit (x), che farebbe quello che vuoi in caso di float. Non funzionerebbe con numeri interi o numeri complessi, tanto meno stringhe, e non avrebbe il nome che stai cercando.

Chiedete "perché" e la risposta è "il segno (x) non è utile". Afferma che è utile. Tuttavia, i tuoi commenti mostrano che non sai abbastanza per poter fare questa affermazione, il che significa che dovresti mostrare prove convincenti del suo bisogno. Dire che NumPy lo implementa non è abbastanza convincente. Dovresti mostrare i casi in cui il codice esistente sarebbe migliorato con una funzione di segno.

E questo al di fuori dell'ambito di StackOverflow. Portalo invece in una delle liste di Python.

Un altro liner per sign ()

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

Se vuoi che ritorni 0 per x = 0:

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

Poiché cmpè stato rimosso , puoi ottenere la stessa funzionalità con

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

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

Funziona per float, inte anche Fraction. Nel caso di float, avviso sign(float("nan"))è zero.

Python non richiede che i confronti restituiscano un valore booleano, quindi forzare i confronti a bool () protegge dall'implementazione consentita, ma non comune:

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

Solo una risposta corretta conforme alla definizione di Wikipedia

La definizione su Wikipedia recita:

Quindi,

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

Che a tutti gli effetti può essere semplificato per:

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

Questa definizione di funzione esegue rapidamente e fornisce risultati corretti garantiti per 0, 0,0, -0,0, -4 e 5 (vedere i commenti ad altre risposte errate).

Si noti che zero (0) non è né positivo né negativo .

numpy ha una funzione di segno e ti dà anche un bonus di altre funzioni. Così:

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

Fai solo attenzione che il risultato sia numpy.float64:

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

Per cose come json, questo è importante, poiché json non sa come serializzare i tipi numpy.float64. In tal caso, potresti fare:

float(np.sign(y))

per ottenere un galleggiante normale.

Prova a eseguire questo, dove x è un numero qualsiasi

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

La coercizione a bool () gestisce la possibilità che l'operatore di confronto non restituisca un booleano.

Sì, una sign()funzione corretta dovrebbe essere almeno nel modulo di matematica, dato che è intorpidito. Perché uno spesso ne ha bisogno per il codice orientato alla matematica.

Ma math.copysign()è anche utile indipendentemente.

cmp()e obj.__cmp__()... hanno generalmente una grande importanza indipendentemente. Non solo per il codice orientato alla matematica. Considera di confrontare / ordinare tuple, oggetti data, ...

Gli argomenti dev su http://bugs.python.org/issue1640 riguardanti l'omissione di math.sign()sono strani, perché:

• Non c'è separato -NaN
• sign(nan) == nan senza preoccupazioni (come exp(nan))
• sign(-0.0) == sign(0.0) == 0 senza preoccupazioni
• sign(-inf) == -1 senza preoccupazioni

- come è in numpy

In Python 2, cmp()restituisce un numero intero: non è necessario che il risultato sia -1, 0 o 1, quindi sign(x)non è lo stesso di cmp(x,0).

In Python 3, cmp()è stato rimosso a favore di un confronto intenso. Per cmp(), Python 3 suggerisce questo :

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

che va bene per cmp (), ma di nuovo non può essere usato per sign () perché gli operatori di confronto non devono restituire valori booleani .

Per far fronte a questa possibilità, i risultati del confronto devono essere forzati a booleani:

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

Questo funziona per tutti quelli typeche sono totalmente ordinati (compresi valori speciali come NaNo infiniti).

Non ne hai bisogno, puoi semplicemente usare:

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

Semplicemente no.

Il modo migliore per risolvere questo problema è:

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

Il motivo per cui "segno" non è incluso è che se includessimo tutti gli utili one-liner nell'elenco delle funzioni integrate, Python non sarebbe più facile e pratico con cui lavorare. Se usi questa funzione così spesso, allora perché non la consideri tu stesso? Non è come se fosse lontanamente difficile o addirittura noioso farlo.