Risultato espressione in Python

[EdmondDantes]

Ci sono stati aggiornamenti importanti tra le release Python 2.7.x e Python 3.8.x. Il comportamento di uno stesso codice elaborato con le due release può essere abbastanza diverso da quello atteso.
Per esempio nell'ambito dell'aritmetica in virgola mobile la funzione built-in round() non si comporta allo stesso modo. Provate con

Codice: Seleziona tutto

round(0.5)

Questo è solo un preambolo per introdurre il mio fatto.
Calcolare la seguente espressione

Codice: Seleziona tutto

(40*(40/3))/(40+40/3)

in Python 3.8.10 e in Python 2.7.18, e, se avete tempo anche in R version 4.4.0

Ritorno a leggere che è meglio,va

PS
In sintesi: mai distrarsi perché il floating-point è lì che ti aspetta , anche senza invocarlo. Le dichiarazioni obbligatorie avevano il loro perché

[lelerelele]

Certamente, hai ragione, (anche se non uso python), sul PC programmo windows in VB.NET.

Ricordo quel poco che ho programmato microcontrollori, in C, nelle espressioni ho quasi sempre dichiarato il tipo numerico usato nell'espressione, altrimenti avevo errori, appunto perché il compilatore vada ad eseguire il calcolo che mi aspetto.

Certo che è un problema rognoso avendo gia il programma testato e funzionante.

[EdmondDantes]

Oltre alla dichiarazione del tipo di variabile e al significato assegnato alle operazioni, abbiamo anche il problema sull'ordine dei calcoli eseguiti. Prova a sistemare diversamente le parentesi, togliendo per esempio quelle superflue, lasciando ovviamente inalterata l'identità dell'espressione. Otterrai valori diversi tra le due release e diversi rispetto alla prima elaborazione.
Estendendo l'argomento, bisogna considerare anche l'aritmetica di macchina e l'analisi degli errori. Ho aperto questo argomento solo per sottolineare quanto possa essere deleterio risolvere i problemi fisici mediante un approccio informatico senza un'opportuna e necessaria riflessione. Purtroppo questo approccio è troppo spesso consigliato anche in questo forum.

Estendendo ancora una volta l'argomento, diciamo che il risultato di un'operazione fra due numeri di macchina non è detto che sia a sua volta un numero di macchina e che la moltiplicazione di macchina non gode della proprietà associativa.
In sintesi il problema non sussiste solo fra due release di uno stesso software o fra software diversi, ma anche all'interno di uno stesso programma.

[boiler]

Python è di gran lunga il peggior linguaggio con cui abbia mai lavorato (e un paio di linguaggi li ho visti)!

Gli operatori logici cosa ritornano? Un valore booleano True o False? No! Sarebbe troppo semplice. Troppo poco "pythonico":

Codice: Seleziona tutto

print(True and 75.1)    # --> 75.1

print("False" or True)  # --> False

Sintassi del genere dovrebbero essere proibite. E invece è il modo considerato "elegante" per ottenere questi risultati:

Codice: Seleziona tutto

numbers = [1, 2, 3]
for num in numbers:
    if num == 5:
        print("It's 5!")
        break
else:
    print('5 was not listed')


Due funzioni con uso simile, ambedue built-in. Una ritorna un oggetto, l'altra un iteratore:

Codice: Seleziona tutto

initial_list = [2, 1, 5]

reversed_list = reversed(initial_list)
print(reversed_list)  # --> <list_reverseiterator object at 0x7f3fde9128b0>

sorted_list = sorted(initial_list)
print(sorted_list)  # --> [1, 2, 5]

(non c'è bisogno che mi spieghiate che il sorting deve per forza di cose generare un nuovo oggetto e quindi posso ritornarlo senza perdita di efficienza, mentre restituire l'iteratore per invertire la lista è piú efficiente. Lo so già. Si poteva benissimo restituire in ambo i casi un iteratore, senza significative perdite e aumentando notevolmente la coerenza)

Codice: Seleziona tutto

my_list = [3, 9, 27, 81, 243, 729, 2187]
print(my_list[-999])        # --> IndexError
print(my_list[3:-999:-1])   # --> [81, 27, 9, 3]

Sprezzo, per Python ho solo sprezzo.

[EdmondDantes]

La mia non è una critica al linguaggio Python. Ogni linguaggio ha vantaggi e svantaggi.

print("False" or True) # --> False

La maggior parte degli oggetti con "contenuto" è valutato come True. Le stringe sono tutte True tranne quella vuota. Tutti i numeri sono valutati True tranne lo zero.
L'operatore OR valuta il secondo argomento (il tuo True) solo se il primo è False.
Il False ottenuto è la stringa "False" non il valore booleano.

type("False" or True)
<class 'str'>

Dunque

Codice: Seleziona tutto

print("False" or True)  # --> False
print("casa" or True)  # --> casa
print(100 or True)  # --> 100
print(False or True)  # --> True
print(0 or True)  # --> True


e così via.
Ha la sua logica

PS
Non è una critica al linguaggio, ma alla risoluzione dei problemi tramite calcolatore senza un'adeguata e sufficiente preparazione. Ho voluto mostrare che anche un caso semplice, un parallelo fra due resistenze, può nascondere delle insidie di natura numerica. In secondo luogo, Python ci mette lo zampino con le differenze significative fra le due release.

[boiler]

La mia non è una critica al linguaggio Python. Ogni linguaggio ha vantaggi e svantaggi.

Avevo capito.

La maggior parte degli oggetti con "contenuto" è valutato come True. Le stringe sono tutte True tranne quella vuota. Tutti i numeri sono True tranne lo zero.
L'operatore OR valuta il secondo argomento (il tuo True) solo se il primo è False.

La teoria e la logica che ci stanno dietro le conosco.
Ed è proprio per questo che trovo che sia un abominio.

Non è che non capisco. È che capisco e disprezzo.

Il False ottenuto è la stringa "False" non il valore booleano.

Che è parte del problema. Perché mai un operatore logico dovrebbe accettare in ingresso una stringa?

C# da questo punto di vista è rigorosissimo ed è una cosa che apprezzo.

Boiler

[EdmondDantes]

capisco il tuo punto di vista e potrei anche essere d'accordo.

Ho un problema dove ricorre spesso la domanda: stringa vuota?
Con C# lo risolvo in n righe, in Python una riga e fine della storia. Ovviamente, di contro, senza un'adeguata preparazione rischierei di fare danno, danno che eviterei usando un linguaggio rigoroso.

[boiler]

Ho un problema dove ricorre spesso la domanda: stringa vuota?
Con C# lo risolvo in n righe

dove n=1

Codice: Seleziona tutto

string myString = "xxxx";

if (String.IsNullOrEmpty(myString))
    // do something


Se mi dici che con Python devi scrivere meno, è vero.
Ma nel 2024 gli ambienti di sviluppo hanno una cosa che si chiama autocompletion e le due parole in piú secondo me valgono la chiarezza e immediatezza del codice.

Boiler

[EdmondDantes]

le due parole in piú secondo me valgono la chiarezza

In passato io ho usato il FORTRAN. Poi mi sono evoluto e ho imparato il Fortran (attenzione: case sensitive)
Penso di essermi spiegato