[Python] Qu

[Enrico Franchi]

On Feb 13, 2010, at 2:58 PM, Pietro Battiston wrote:


> 2) argomentare con il fatto che se un programmatore, che è poi l'utente
> del linguaggio, si trova ad utilizzare oggetti matematici - e.g. numeri
> - dovranno comportarsi, per quanto possibile, come lui si aspetta.

Sono d'accordo. Sotto ti faccio vedere come di fatto cose inaspettate
salterebbero fuori comunque.

> A volte l'1 pone dei vincoli necessari al 2; ciononostante del Python mi
> piace che pone molta attenzione al 2 (vedi passare automaticamente da
> int a long, perché di nuovo, quando come programmatore penso a "int" in
> Python penso agli interi, non agli interi modulo INT_MAX).

Come nota a margine, in C non hai sugli interi aritmetica modulare. Hai
undefined behaviour quando sfori. L'aritmetica modulare la hai sugli
unsigned (e quindi ocn UINT_MAX). Non che sia importante, solo una
precisazione.

>> sono considerate *cattiva* pratica. Proporre di abbandonare la pratica
>> considerata "buona" di
>> 
>> if []: 
>> 
>> IMHO non è particolarmente sensato.
> 
> 
> Ma infatti non l'ho proposto, ed è la terza volta che cerco di
> chiarirlo...

Su questo punto quindi siamo d'accordo. In contesti di questo tipo 0
continuerebbe a valutare a False.
Che poi, per dire, in effetti e' False che valuta a 0. Chi comanda e' 
il metodo __nonzero__, ma ok.

>> Quindi spiegami meglio, tu proponi questa semantica.
>> 
>> 0 != False -> True
>> 0 == False -> False
> 
> certo
> 
>> 
>> Ora dimmi cosa vuoi fare in questi casi:
>> 
>> 10 * False  
>> 10 + False 
> 
> il bool è convertito automaticamente in int ==> rispettivamente 0 e 10

Eh... poi ci troviamo con questo. Indichiamo con b un booleano, con n,m,...
un intero e con a qualcosa che puo' essere indifferentemente un booleano
o un intero. Il nostro obiettivo e' definire le operazioni su Bool U Int, rispettivamente
l'insieme dei booleani e degli interi. 

Normalmente ci aspettiamo che:

n + m - m == n

siamo d'accordo? Lascio perdere le parentesi, poiche' in Python, grazie al
"salto" a long abbiamo la proprieta' associativa.

Supponiamo di estendere tale cosa agli "interi o booleani". Ricorda, vogliamo
che i booleani si possano ancora usare al posto degli interi.

False + m - m != False

Infatti la prima parte viene convertita ad intera. False + m -> m 
ed m - m va a 0. Essenzialmente il problema e' che il nostro insieme
Bool U Int si trova con due elementi neutri. L'algebra ci dice che
se questi sono distinti non abbiamo piu' un gruppo, ovvero l'insieme
(Bool U Int, +) non e' un gruppo.

Questo e', in essenza, uno degli assurdi di cui parlavo. Per eliminare una
cosa sgradevole matematicamente come avere False == 0, perdiamo
alcune proprieta' fondamentali sulla struttura algebrica delle operazioni.

Nota... per non dovere definire le operazioni su Bool U Int dobbiamo
proibire l'aritmetica mista (come dicevo) oppure cambiare le proprita'
di False e True, che non dovrebbero comportarsi come elementi
cosi' particolari algebricamente come 0 ed 1.

Il problema e' che non riusciamo a trovare nessun altro buon valore.
Non possiamo metterli "in mezzo" fra due interi. Dobbiamo lasciare
loro un valore tutto particolare e distinto da quello degli interi.

Matematicamente si fa, voglio dire. A naso direi che ci imbatteremmo
in qualche altro comportamento contro-intuitivo. Un'altra possibilita'
e' intendere tutte le operazioni come operazioni su UxT dove U
e' l'insieme di tutti i valori e T quello di tutti i tipi. Ma accidenti... IMHO
viene proprio una cosa tosta.

In questo senso mi sembra che la semplicita' di False e' praticamente
un altro nome per 0 sia difficile da battere.


>> 0 < False
>> 0 > False
>> 0 < True
>> 0 > True
>> 
> 
> Per come l'ho sostenuta sinora, semplicemente l'ordering tra tipi
> diversi, ovvero int > bool in python 2.*, eccezione in python 3.* (se
> non sbaglio). Poi preferisco la prima, ma questo è un altro discorso.

Anche perche' se lanci eccezione, di fatto non e' vero che hai veramente
"aritmetica" mista. Alcune operazioni "banali" che fai con gli interi (confronto)
non puoi farle se uno dei due e' un booleano.

> Sì. Non che veda niente di proibito in
> 
> int < bool
>    definito come
> int < int(bool)
> 
> , ma non stavo pensavo a quello (che poi potrebbe essere pure più
> comodo, non so).

Sarebbe ovviamente l'unica scelta consistente con il "mischiare" interi
e booleani. Quale e' il problema?

A noi piace il principio del terzo escluso. Se due elementi non sono 
uno minore dell'altro (comunque li prendi), allora sono uguali. 

Eppure tu siccome vuoi che False "valuti" a 0 non puoi prenderlo ne
minore ne maggiore di 0, ma di fatto non hai nemmeno 0 == False.

Ovviamente, se per esempio prendi False > 0 poi ti saltano cose tipo

10 * False > 2 * False

che a rigore dovresti avere. Questo perche' False continua a comportarsi
come 0 e questo dovrebbe riflettersi nei confronti.

> Ma ti rendi conto che per nessuno di questi valori in Python si è
> ritenuto necessario introdurre un nuovo letterale (o una variabile)? Ti
> sembra veramente un caso?!

No, tutti questi valori hanno un nuovo letterale! I long li fai aggiungendo
la L in fondo, i float con il punto. Per il parser sono tutti nuovi letterali.
In Python 3 finalmente anche True e False sono letterali (o forse sono
Keywords... boh).

> 
> A me sembra un suggerimento, casomai ce ne fosse bisogno, del fatto che
> il programmatore comune considera i bool prima come valori di verità e
> solo in seguito come cose che possono "giocare" con/come i numeri.
> 
> 
>> 
>> ----
>> [0] fintanto che ci sono i long, ma possiamo estendere il concetto
>> a razionali e complessi e altri tipi numerici eventualmente definiti in seguito.
>> 
>>> Per me puoi chiamare "numero" anche una mela, se ti fa comodo, riesci a
>>> infilarlo in un certo numero di bit e riesci ad infilarci qualche
>>> operazione aritmetica.
>> 
>> No, davvero, ripeto. Di quanti bit hai bisogno per considerarlo numero? 
> 
> No, ho bisogno che sia un numero per considerarlo numero. Vorrei dire
> "nella realtà", ma ovviamente mi farei ridere dietro: diciamo nella
> mente del programmatore medio, quello per cui è stato deciso che
> esistessero False e True, nonostante la loro attuale ridondanza rispetto
> a 0 e 1.

Esatto. Sono ridondanti. Semanticamente si considera piu' chiaro scrivere
False che 0. Posso anche essere d'accordo. Poi per dire, per certe ottimizzazioni,
in Python 2.x devi usare 1.

Guarda il codice generato da 

while 1:
...

e quello da 

while True:
...


E no, non mi piace. Ma fintanto che si puo' ridefinire True... il giorno che mi
voglio fare buttare fuori a calci lo faro' scrivendo codice tipo

In [5]: i = 4

In [6]: while True:
   ...:   if i < 0: True = False
   ...:   else: i -= 1

> Non mi sembra ci sia _nessun_ altro caso, in qualsiasi tipo numerico in
> python, in cui si ha
> 
> b = a + a
> type(b) != type(a)
> a + a == b

Comunque type(bool) == type(int). Che ovviamente discende dall'essere
un bool un int. Comunque riprendo... poi stacco che mi sa che il pezzo i
interessante del messaggio lo ho gia' scritto.

Credo che la chiave sia accettare che == e' un uguaglianza *semantica*
in Python, non un'uguaglianza sintattica. In un linguaggio ad oggetti,
siamo abbastanza liberi di avere == che ci dice ok su oggetti di tipi diversi.

Io poi confesso che questa parte di programmazione ad oggetti non la amo.
Ma puo' avere un suo senso, dopotutto.

> Poi in matematica puoi dire che le ha, ma in un modo tale che, ristrette
> ai booleani, siano assolutamente stupide (e non per questo sbagliate
> formalmente). Ossia _non_ le considero operazioni sui booleani.

Non sono operazioni sui booleani. Come dicevo prima, un'operazione e'
AxA -> A, qui invece siamo 
Bool x Bool -> Int

*MA* sia A = Int U Bool, allora sono operazioni
AxA -> A

Allo stesso modo in cui in effetti le operazioni sugli interi, in Python,
sconfinano nei long. Di fatto sono definite su (IntULong^2)->IntULong


> OK, ammetto che come quoting può essere stato equivoco, ma non è un
> "trucchetto misero"... io ho tirato in ballo xor e compagnia per fare
> _notare_ che le operazioni classiche dei bool sono diverse da quelle
> degli altri numeri. 

Si, ma per un *informatico* xor e compagnia sono assolutamente operazioni
definite e definibili sugli interi, comunque. Proprio sfruttando la loro natura
binaria a basso livello.

Oggi ci si gioca meno, in univerista' non ci si lavora tantissimo. Forse le usano di
piu' ad ingegneria e magari non vengono naturali agli altri, ma di per se
sono tutte cose che ci aspettiamo da una qualunque ALU. Anzi.. conosco
ALU che hanno xor e non hanno la moltiplicazione generica. Non scherzo. :)

Roba vecchia, eh.Avevi moltiplicazione solo per due
(visto che era uno shift) e la moltiplicazione generica era una procedura.
La scrittura della quale e' lasciata per esercizio a chi voleva scriverci.

Dalla mia memoria avevo estratto che forse la CPU del game boy aveva questa
caratteristica, ma wikipedia non conferma e non smentisce, *ma* sembra piu' 
vicino a smentire.

> Mi spiego meglio: ovviamente non stavo dicendo che, data A sottoclasse
> di B, mi aspetterei
> 
> is_instance(B(), A) --> True
> 
> , ma che se A non introduce _niente_ di nuovo rispetto a B (e mi sembra
> questo il caso per i booleani nei confronti degli int - a parte la
> rappresentazione diversa, ovviamente), tanto vale abolirla...
> 
> ... a meno che non siamo tanto affezionati alla rappresentazione proprio
> perché per noi False e True _non_ sono 0 e 1.

1. se False e True fossero solo nomi per 0 e 1 sarei d'accordissimo. 
2. la differenza "semantica" la vedi per esempio su __str__ che e' ridefinito per
stampare False invece di 0
3. possibile ci siano altre cose che non mi vengono in mente, essenzialmente.

Chiaramente se in C(99|++) i bool sono motivati anche dal consumo di spazio,
questo non vale in Python, che io sappia. Spiace.



> No, ti dicevo solo che per me in questo caso Ruby è OT perché sul fatto
> che
> if [] : print "ciao"   ->   ...
> 
> è una bella cosa sono perfettamente d'accordo con te (e se ho capito
> bene - ma ci avrò scritto 10 righe in vita mia - in Ruby non è così).

Beh, Ruby propone un modello in cui interi e booleani non sono interoperabili.
Come avevo scritto 0 + false da eccezione. Era uno dei modelli proposti.
Io personalmente preferisco quello di Python, ma preferisco quello di Ruby
a quello che proponi tu (ovvero aritmetica con booleani ma False != 0).
Il perche' lo ho essenzialmente spiegato sopra.