Divisione per interi ... una giungla

[DragoRosso]

Mi sono imbattuto in una diatriba matematica, irrisolta e irrisolvibile probabilmente.
Per adesso ho imposto la mia idea, ossia il calcolo in PASCAL (potevo farlo essendo il capo progetto) e la questione operativa è chiusa ... ma non è per niente risolta la problematica pratica.

Eseguendo una operazione matematica in pascal, tramite interi e resti (div e mod), i risultati delle operazioni sono a mio avviso chiare e non ho mai avuto dubbi, sino a quando non mi sono interfacciato con dei moduli in python (e mi dicono che anche con moduli google si ottengo risultati identici al python) in cui i risultati differiscono dal Pascal (ma anche dal C)

Esempio:

Codice: [Seleziona]

//Questa è equivalente per entrambe
var i, j: INT64;
begin
  i := 9;
  j := 5;
  ShowMessage(IntToString(i div j)) // ==> 1
 //Python: (9 // 5) ==> 1
end;

//Qui iniziano i dolori !!!
var i, j: INT64;
begin
  i := -9;
  j := 5;
  ShowMessage(IntToString(i div j)) // ==> -1
 //Python: (-9 // 5) ==> -2                                                    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
end;

Per il modulo vale ovviamente la stessa differenziazione (quindi i risultati sono differenti in base al fatto che i risultati siano negativi o positivi).
Ciò perchè le operazioni vengono effettuate sempre in float per alcuni linguaggi e i risultati vengono "arrotondati" per difetto o per eccesso (floor o ceil) a seconda delle convenzioni del linguaggio.

Avete informazioni su ciò? Ovvero avete notizia di come funzioni in altri linguaggi ?
Ulteriormente, secondo voi è più corretto una / altra o entrambe (ogni linguaggio si gestisce a modo proprio) ?

La mia opinione è che non ci dovrebbero essere dubbi su queste cose (e io non ce ne ho, sono convinto della mia idea magari antiquata), invece vedo che siamo ancora in alto mare ...

N.B.: lasciando perdere l'arrotondamento, il problema principale e che i risultati e le successive operazioni possono essere notevolmente dissimili tra due procedure effettuate con linguaggi differenti, ad esempio nel caso si debbano usare per vari motivi moduli diversi.

[bonmario]

Ciao,
premesso che non avevo mai analizzato questa problematica prima, secondo me dipende da cosa rappresenta quel numero ed il motivo per cui lo stai dividendo.

P.S. Ho provato a fare -9/5 con la calcolatrice di Windows 11, e mi da come risultato -1.8. Quindi, in alcune condizioni, (-9 div 5) dovrebbe dare -1 come risultato !


Ciao, Mario

[nomorelogic]

In effetti il risultato è emblematico.

L'operatore // in python (come si può vedere anche nel link sotto)
https://www.w3schools.com/python/trypython.asp?filename=demo_oper_floordiv
in realtà arrotonda il risultato all'intero più vicino.

Bene, però qualcosa non torna.
9/5, come dice bonmario fa 1.8
però mentre è corretto a questo punto che -9/5 dia come risultato -2, è errato che 9/5 dia come risultato 1!  Dovrebbe dare 2.

Riguardo l'operatore div, secondo me il pascal risponde correttamente.
Ho voluto simulare quello che fa il python con Round (la Round del pascal arrotonda all'intero più vicino).
Infatti eseguendo il codice sotto, vedrete che i risultati sono esatti:

• Round(9/5) = 2
• Round(-9/5) = -2

Codice: [Seleziona]

program Hello;
var i, j: INT64;
begin
  writeln ('a)', 9 div 5);
  writeln ('b)', -9 div 5);
  writeln ('c)', Round(9 / 5));
  writeln ('d)', Round(-9 / 5));
end.

Direi che è chiaro che bisogna sapere che operazione si vuole svolgere, ma il python secondo me in questo caso non da risultati corretti.


Edit:
in effetti credo di aver preso una stecca 
l'operatore // del python "rounds the result down to the nearest whole number"
che in effetti significa che arrotonda all'interno minore

quindi l'intero minore di 1.8 è 1
mentre l'intero minore di -1.8 è -2

l'inghippo è che non si tratta solo di una divisione ma di una divisione con un arrotondamento all'intero minore
che comunque sono due operazioni che in effetti vengono svolte correttamente

NB:
la Round del pascal arrotonda all'interno più vicino

[DragoRosso]

L'operazione che fà Python è corretta dal suo punto di vista, lo afferma la definizione dell'operatore "//" ma secondo me illogica anche se dal punto di vista prettamente matematico sembra che ci siano delle prevalenze verso il Python.

Dal punto di vista informatico invece sembra che ci sia preponderanza verso il calcolo Pascal, per cui di fatto una divisione intera ha come risultato una divisione troncata con segno (o come meglio si definisce arrotondata allo ZERO).

Python invece arrotonda con "floor" o "ceil"  in funzione al "segno" del risultato (appunto all'intero minore, dove il limite non è lo ZERO ma sono bensì il + / - INFINITO). Quindi il minore è il valore verso il - INFINITO e il maggiore è il valore verso il + INFINITO.
Tendenzialmente l'informatico il valore "minore" in termini di arrotondamento lo intende come valore verso lo ZERO.

Per intenderci, un risultato in Python di questa divisione (e i matematici sembrano prevalere per questo ?) sarebbe è:

(-9 // 5) = -2                 (9 // -5) = -2         (-9 // -5) = 1           (9 // 5) = 1
(-9 % 5) = 1                 (9 % -5) = -1        (-9 % -5) = -4         (9 % 5) = 4


in Pascal (e gli informatici sono più concordi su ciò):

(-9 div 5) = -1              (9 div -5) = -1         (-9 div -5) = 1         (9 div 5) = 1
(-9 mod 5) = -4            (9 mod -5) = 4       (-9 mod -5) = -4      (9 mod 5) = 4   

Entrambi dal punto di vista pratico danno un risultato equivalente,  ma potete capire che la rappresentazione non è proprio così equivalente. A me sembrano più coerenti i risultati Pascal, però sicuramente i matematici hanno le loro ragioni.

Comunque per rispondere a @BonMario, il campo di applicazione da dove ciò è comparso e l'applicazione di analisi spettrografica, dove la rappresentazione era legata ad alcuni algoritmi che a me (in Pascal) davano i risultati aspettati mentre in Python no.
E sinceramente mi ci è voluto un pò per riuscire a fare quadrato, perchè mentre in Pascal è tutto come ti aspetti (quando cambiano i segni degli operandi cambiano i segni dei risultati ma i valori "assoluti" sono sempre gli stessi, in Python non è così).

E' come un pò dire che (3 * 5) = (10+5) oppure  (3 * 5) = (20 - 5), entrambi sono corretti però dal punto di vista logico il primo mi appare un pò più ... come si può dire ... logico ... 

[nomorelogic]

Per intenderci, un risultato in Python di questa divisione (e i matematici sembrano prevalere per questo ?) sarebbe:

(-9 // 5) = -2                 (9 // -5) = -2         (-9 // -5) = 1           (9 // 5) = 1
(-9 % 5) = 1                 (9 % -5) = -1        (-9 % -5) = -4         (9 % 5) = 4

onestamente questa cosa mi destabilizza un po'...   
non mi pare tanto normale, sarà che sono un informatico e non un matematico ma, questi calcoli, farei fatica a farmeli calare

[DragoRosso]

Per intenderci, un risultato in Python di questa divisione (e i matematici sembrano prevalere per questo ?) sarebbe:

(-9 // 5) = -2                 (9 // -5) = -2         (-9 // -5) = 1           (9 // 5) = 1
(-9 % 5) = 1                 (9 % -5) = -1        (-9 % -5) = -4         (9 % 5) = 4

onestamente questa cosa mi destabilizza un po'...   
non mi pare tanto normale, sarà che sono un informatico e non un matematico ma, questi calcoli, farei fatica a farmeli calare

A guarda, ti quoto e sottoscrivo in pieno, ma è quello che Python fà. E non solo, ma Google a ruota ... e prova la calcolatrice di Windows (ha solo il MOD) e vedrai gli stessi risultati.
Fortunatamente i fogli di calcolo lavorano ancora come in Pascal e come logica comanda.

Giusto per confermare la mia logica (anche se magari un pò demenziale  ) :
tralasciando lo ZERO se ho un qualcosa tipo -nx , sarà che il resto (ciò che resta  ) sia comunque un -ax, dove a è minore dir n ovviamente, ma minore in senso numerico assoluto.
Se ho -9 mi avanzerà qualcosa da -1 a -9 (tralasciando che può rimanere anche ZERO). E infatti in Pascal il resto mantiene il segno del dividendo, mentre il risultato "troncato" ha la combinazione dei segni del dividendo e del divisore.

Mi sembra sicuramente più ovvio e gestibile così. Non avrei mai pensato a qualcosa di diverso. Oltretutto, che senso ha che (9 div 5) o (9 mod 5) abbiano valori assoluti differenti con segni differenti ?

Mah, rimango basito soprattutto perchè ho sempre più spesso a che fare con terze parti e nascono continue sorprese.

Mandi

P.S.: non è che (-6 // 5) in Python abbia un risultato diverso, fà sempre -2 ... però con resto di 4 ....

[quack]

Credo che il "mod" di phyton faccia cosi:

-6//5 = -1.2 e lo arrotonda a -2

poi calcola l'intero più vicino come -2*5 = -10

trova il resto con -6 -(-10) = 4

Altro esempio

-9 // 5 = -1.8 arrotondato a -2

poi calcola l'intero più vicino come  -2*5 = -10

trova il resto con -9 -(-10) = 1

Per tornare al numero di partenza -2*5 + 1 = -9

Anche la calcolatrice di linux e openoffice danno gli stessi risultati.

[nomorelogic]

ok, giusto per curiosità
come calcolatrice di linux cosa usi?

io uso dal un bel po' la mia fida speedcrunch
e il risultato è quello Pascal - style

[quack]

Ho usato quella stock di gnome 46.

[nomorelogic]

è ufficiale, ci sono 2 scuole di pensiero...

forse c'è il modulo dei boomer e quello della gen Z 

[quack]

si mette male... anche su wolframalpha -9 mod 5 = 1

    

[DragoRosso]

Bhè, non siamo soli.

Divisione intera con segno processore Intel in assembler (idiv): -9 div 5 = -1 quoziente, -4 resto 

E fino qui tutto bene: o il Pascal è l'unico che esegue calcoli in interi, insieme ad Intel oppure sfugge qualcosa.

P.S.: il foglio di calcolo in LibreOffice esegue il "resto" come Python.

[nomorelogic]

https://www.omnicalculator.com/it/matematica/modulo

Provate questo calcolatore di modulo.
Prima con 9 mod 5, poi con -9 mod 5.

Col nr. negativo verranno restituiti 2 risultati.
E una breve spiegazione...

[quack]

Se cercate "Divisione Euclidea" su Wikipedia c'è la spiegazione. Pascal fa la divisione con troncamento phyton quella con parte intera.

Ciao

[DragoRosso]

https://www.omnicalculator.com/it/matematica/modulo

Provate questo calcolatore di modulo.
Prima con 9 mod 5, poi con -9 mod 5.

Col nr. negativo verranno restituiti 2 risultati.
E una breve spiegazione...

Spiegazione corta (ma anche quella più lunga) efficiente e coerente tutto sommato, ma che comunque non si addice ai risultati di Python e company, dove il resto è anche negativo.
L'unica regola che posso comprendere è che il resto matematicamente sia compreso tra ZERO e il valore del divisore (minore o maggiore di quest'ultimo in base al segno  .....).

Comunque diatriba senza fine probabilmente, perchè una buona parte dei programmatori (se non tutti) non accetteranno mai che una divisione intera tipo (-9 / 5) o (-6 / 5) dia -2 come risultato, come i matematici non accetteranno mai l'inverso.

Rimango della mia idea, e se mi accorgessi del cambiamento repentino in favore di quest'ultima soluzione (matematica), bhè farei le mie routine in assembler o userei altri metodi per comunque avere i risultati alla "vecchia" maniera.

Ho verificato ora sui mie sorgenti: divisioni e mod su interi ne uso una sbarcata, e una simulazione banale su quello che succederebbe ad applicare il calcolo come fà Python ... bhè disastro totale ... almeno nel mio mondo dell'industria.

Nel panorama industriale la stragrande maggioranza dei calcoli (a parte il machine learing) coinvolge dati "interi", quindi usare la logica del float e degli arrotondamenti "fantasiosi" ( ) non ha molto senso.

Sempre in un mio progetto ho conteggiato le dichiarazioni di variabile DOUBLE e INTEGER (senza contare i nativeint, i cardinal, le word, gli INTxx e gli UINTxx) quante volte comparivano: 87% integer e 13% double.

Ciao