algebra (era: Re: compilare QGIS-master su linux)

[Giuliano Curti]

Il giorno Fri, 2 Oct 2015 00:30:00 +0200
aperi2007 <[hidden email]> ha scritto:

ciao,
solo un piccolo dettaglio (e ne ho fatto un thread a parte) nella vostra
interessantissima discussione :-)

> ....
> Erroneamente ho parlato di principio commutativo.
> In realta' nell'aritmetica finita viene negato il principio
> distributivo e non quello commutativo.
> ....... ma in
> ogni caso quello che impiegavo nell'asserzione
>
> (A*B)/C <> A*(B/C)
>
> e' il principio distributivo.

sei sicuro? poiche '/' è l'operazione inversa di '*', siamo in presenza
di una sola legge di composizione (la moltiplicazione), non 2
(tipicamente moltiplicazione e addizione) fra le quali può valere
il principio distributivo;

mi sembra più un problema 'associativo' oppure di un insieme privo
dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
10*(3/2)=10;

 
> A.

ciao,
giuliano
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Luigi Pirelli-2]

10*(3/2)=10; ???? in que anello?

un problema di cast a interi?
Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************


2015-10-02 13:57 GMT+02:00 giulianc51 <[hidden email]>:

> Il giorno Fri, 2 Oct 2015 00:30:00 +0200
> aperi2007 <[hidden email]> ha scritto:
>
> ciao,
> solo un piccolo dettaglio (e ne ho fatto un thread a parte) nella vostra
> interessantissima discussione :-)
>
>
>> ....
>> Erroneamente ho parlato di principio commutativo.
>> In realta' nell'aritmetica finita viene negato il principio
>> distributivo e non quello commutativo.
>> ....... ma in
>> ogni caso quello che impiegavo nell'asserzione
>>
>> (A*B)/C <> A*(B/C)
>>
>> e' il principio distributivo.
>
> sei sicuro? poiche '/' è l'operazione inversa di '*', siamo in presenza
> di una sola legge di composizione (la moltiplicazione), non 2
> (tipicamente moltiplicazione e addizione) fra le quali può valere
> il principio distributivo;
>
> mi sembra più un problema 'associativo' oppure di un insieme privo
> dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
> 10*(3/2)=10;
>
>
>> A.
>
> ciao,
> giuliano
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 786 iscritti al 30.9.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Fri, 2 Oct 2015 14:19:23 +0200
Luigi Pirelli <[hidden email]> ha scritto:

> 10*(3/2)=10; ???? in que anello?
> un problema di cast a interi?

nessun anello(1) nè cast, semplicemente perchè nell'insieme dei
naturali (ed anche degli interi relativi(2)) non esiste l'inverso(3)
rispetto alla moltiplicazione e quindi 3/2 non ha senso (io ho forzato
l'operazione 10*(3/2) = 10*1 = 10, simulando quello che fa il python,
prova ad eseguire le due espressioni in una shell python);


> Luigi Pirelli

ciao,
giuliano


(1) non so cosa intendi, ma in algebra un anello è un gruppo commutativo
(rispetto ad una LdC) dotato di una seconda LdC (credo associativa); se
è gruppo commutativo anche rispetto alla seconda diventa un campo, ad
es. campo reale e campo complesso rispetto alle canoniche
moltiplicazione e addizione; quì però, in riferimento al post
originario di Andrea, si trattava di un insieme dotato di una sola LdC,
quindi più probabilmente un monoide o cmq un mancato gruppo: suggerivo
l'esame della mancata associatività o della mancanza dell'inverso,
rispetto al problema della distributività;

(2) gli interi relativi sono il gruppo più semplice rispetto
all'addizione, ma mancano dell'inverso moltiplicativo e quindi nemmeno
loro sono un gruppo rispetto a questa seconda operazione;

(3) ovviamente può esistere l'inverso di alcuni, ad es. 10/2 = 5, ma
non è garantito per tutti, ad es. 3/2 = ? o 13/7 = ? ... approfondendo
ci inoltreremmo nei misteriosi antri della teoria dei numeri e lì
purtroppo sarei cieco :-(
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Marco Guiducci-3]

On Fri, 2 Oct 2015 16:09:59 +0200
giulianc51 <[hidden email]> wrote:

> Il giorno Fri, 2 Oct 2015 14:19:23 +0200
> Luigi Pirelli <[hidden email]> ha scritto:
>
> > 10*(3/2)=10; ???? in que anello?
> > un problema di cast a interi?
>
> nessun anello(1) nè cast, semplicemente perchè nell'insieme dei
> naturali (ed anche degli interi relativi(2)) non esiste l'inverso(3)
> rispetto alla moltiplicazione e quindi 3/2 non ha senso (io ho forzato
> l'operazione 10*(3/2) = 10*1 = 10, simulando quello che fa il python,
> prova ad eseguire le due espressioni in una shell python);
>
>

ma se python interpreta 2 come intero, mentre 2.0 come reale è un problema suo e di chi lo usa (anch'io...).
La regola è che 10*(3/2)=15 ed il programmatore python, sapendo come si comporta, deve fare in modo da avere 15.
oppure vogliamo riscrivere l'aritmetica in funzione della tipizzazione di python? :-)

--
Marco Guiducci <[hidden email]>
Firenze, via di Novoli 26
055 4383194
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Andrea Peri]

Puo' darsi.
Ho messo due operazioni differenti per coprire un caso piu' generale.

Si puo' scrivere anche questa:

(A*B)*C <> A*(B*C)

Vale comunque il principio che in aritmetica finita le due versioni possono dare risultati differenti.
A seconda dell'ordine in cui si esegue e aseconda dei valori rappresentati da A,B e C.

A.



Il 02/10/2015 13:57, giulianc51 ha scritto:

> Il giorno Fri, 2 Oct 2015 00:30:00 +0200
> aperi2007 <[hidden email]> ha scritto:
>
> ciao,
> solo un piccolo dettaglio (e ne ho fatto un thread a parte) nella vostra
> interessantissima discussione :-)
>
>
>> ....
>> Erroneamente ho parlato di principio commutativo.
>> In realta' nell'aritmetica finita viene negato il principio
>> distributivo e non quello commutativo.
>> ....... ma in
>> ogni caso quello che impiegavo nell'asserzione
>>
>> (A*B)/C <> A*(B/C)
>>
>> e' il principio distributivo.
> sei sicuro? poiche '/' è l'operazione inversa di '*', siamo in presenza
> di una sola legge di composizione (la moltiplicazione), non 2
> (tipicamente moltiplicazione e addizione) fra le quali può valere
> il principio distributivo;
>
> mi sembra più un problema 'associativo' oppure di un insieme privo
> dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
> 10*(3/2)=10;
>
>  
>> A.
> ciao,
> giuliano
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 786 iscritti al 30.9.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Andrea Peri]

NOn e' un problema dimancanza del'inverso.
Ma un problema diaritmetica finita.

Neicomputer e' piu' facile rappresentare numeri grandi piuttosto che
numeri piccoli.

Se poi sono molto piccoli allora devi accettare delle approssimazioni.

quando esegui una serie di operazioni , se vuoi inimizzare il problema
devi sempre privilegiare prima le operazioni che aumentano il valore
temporaneo e eseguire da ultimo quelle che riducono il valore.
Ovviamente sempre all'intenro della validita' della formula.

Per questo

A = 10.000.000
B = 0.0001
C = 20.000.000

A * (B / C ) = 10.000 * (0.0001 / 20.000.000)

il valore temporaneo e' 0.0001 / 20.000.000  che ti va a finre sotto il
limite di validita' e quindi diventa approssimato.
e anche se lo moltipli poi per 10.000.000 ormai e' approssimato e non lo
recuperi piu' al valore esatto.

Se invece te esegui:

A * B come prima operazione ottieni: = 10.000.000 * 0.0001 = 10.000

per cui quando vai a eseguire la successiva:

10.000 / 20.000.000 essendo eseguita con un numerato remaggiore ottieni
un risultato meno approssimato.

A.

Il 02/10/2015 13:57, giulianc51 ha scritto:
> mi sembra più un problema 'associativo' oppure di un insieme privo
> dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
> 10*(3/2)=10;

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Fri, 2 Oct 2015 17:49:47 +0200
Marco Guiducci <[hidden email]> ha scritto:

ciao Marco,


> On Fri, 2 Oct 2015 16:09:59 +0200
> giulianc51 <[hidden email]> wrote:

> ma se python interpreta 2 come intero, mentre 2.0 come reale è un
> problema suo e di chi lo usa (anch'io...). La regola è che
> 10*(3/2)=15 ed il programmatore python, sapendo come si comporta,
> deve fare in modo da avere 15. oppure vogliamo riscrivere
> l'aritmetica in funzione della tipizzazione di python? :-)

ovviamente niente di tutto ciò, si trattava solo di contribuire ad
inquadrare un problema iniziato lodevolmente da Andrea cui ho cercato
di dare il mio piccolo contributo;

per quanto riguarda python, prova solo a battere in console 10*(3/2) e
se pensi di ottenere 15, avrai qualche sorpresa :-)

per il resto mi spiace aver disturbato la tua (pigra? :-) sicurezza
pensando che esiste una sola 'aritmetica', che immagino sia quella che
conosci tu; puoi continuare tranquillo, semmai ne avrai bisogno sappi
che ci sono molte "algebre" a seconda dell'insieme e delle regole di
composizione che trovi o stabilisci :-)


senza alcuna polemica, grazie, ciao,
giuliano

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Fri, 2 Oct 2015 18:56:45 +0200
aperi2007 <[hidden email]> ha scritto:

ciao,


> NOn e' un problema dimancanza del'inverso.
> Ma un problema diaritmetica finita.
> .....

su questo sono d'accordo; diciamo quindi che non è un problema
distributivo, associativo o altro, ma che la rappresentazione numerica
ha delle lacune che possono mettere in crisi anche le caratteristiche
viste sopra che siamo soliti considerare scontate;

sulle difficoltà del calcolo numerico però ho poca dimestichezza, per
cui sto a sentire :-)

 
> A.

grazie, ciao,
giuliano

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Marco Guiducci-3]

On Fri, 2 Oct 2015 19:27:38 +0200
giulianc51 <[hidden email]> wrote:

> Il giorno Fri, 2 Oct 2015 17:49:47 +0200
> Marco Guiducci <[hidden email]> ha scritto:
>
> ciao Marco,
>
>
> > On Fri, 2 Oct 2015 16:09:59 +0200
> > giulianc51 <[hidden email]> wrote:
>
> > ma se python interpreta 2 come intero, mentre 2.0 come reale è un
> > problema suo e di chi lo usa (anch'io...). La regola è che
> > 10*(3/2)=15 ed il programmatore python, sapendo come si comporta,
> > deve fare in modo da avere 15. oppure vogliamo riscrivere
> > l'aritmetica in funzione della tipizzazione di python? :-)
>
> ovviamente niente di tutto ciò, si trattava solo di contribuire ad
> inquadrare un problema iniziato lodevolmente da Andrea cui ho cercato
> di dare il mio piccolo contributo;
>
> per quanto riguarda python, prova solo a battere in console 10*(3/2) e
> se pensi di ottenere 15, avrai qualche sorpresa :-)
>
> per il resto mi spiace aver disturbato la tua (pigra? :-) sicurezza
> pensando che esiste una sola 'aritmetica', che immagino sia quella che
> conosci tu; puoi continuare tranquillo, semmai ne avrai bisogno sappi
> che ci sono molte "algebre" a seconda dell'insieme e delle regole di
> composizione che trovi o stabilisci :-)
>

forse non mi sono spiegato: rileggi quel che ho scritto.
so benissimo quanto fa 10*(3/2) in python.
Ma so anche che quello non è il risultato giusto. Non mi importa quel che dice python.
Il programmatore in python lo deve sapere ed agire di conseguenza per dare risultati giusti, non per python, ma per la matematica.
Quindi semplicemente: se python ti da un risultato quello è "il suo risultato".
Altro conto, ma non voglio entrare in questo argomento, è dire che non posso rappresentare tutti i numeri reali con numeri binari.
Qui semplicemente sto dicendo che python si prende un libero arbitrio (assumere come numero intero se mi sono dimenticato di metterci un puntino ed un decimale), rispettabilissimo, ma non va preso come "esempio" per avvalorare altre cose, tipo le molte "algebre" che tu citi.



--
Marco Guiducci <[hidden email]>
Firenze, via di Novoli 26
055 4383194
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Mon, 5 Oct 2015 08:17:43 +0200
Marco Guiducci <[hidden email]> ha scritto:

ciao Marco,

> On Fri, 2 Oct 2015 19:27:38 +0200
> giulianc51 <[hidden email]> wrote:
>
> > Il giorno Fri, 2 Oct 2015 17:49:47 +0200
> > Marco Guiducci <[hidden email]> ha scritto:
> >
> > ciao Marco,
> >
> >
> > > On Fri, 2 Oct 2015 16:09:59 +0200
> > > giulianc51 <[hidden email]> wrote:
> >
> > > .....

> Ma so anche che quello non è il risultato giusto. Non mi importa quel
                                            ^^^^^^
> che dice python. Il programmatore in python lo deve sapere ed agire
> di conseguenza per dare risultati giusti, non per python, ma per la
> matematica.
  ^^^^^^^^^^

oops, fermo :-) il python era semplicemente un esempio, abbastanza
facile e concreto da consentire verifiche immediate a chiunque, il
problema invece è un altro e sta nelle due parole chiave che ho
sottolineato:

a) la "matematica" è una sola ma le strutture algebriche sono molte e
diverse: i naturali, gli interi, i razionali, ecc... hanno
comportamenti diversi a seconda della/e legge/i di composizione che
metti; e questo indipendentemente dal python o da qualsiasi altro
linguaggio vuoi considerare; tutte cose che sai già, beninteso :-)

b) il risultato che tu definisci non "giusto" è in realtà perfettamente
"coerente" ma viola una delle proprietà prime delle strutture
algebriche, la "associatività": questo deve preoccupare, come
giustamente dici, il programmatore, non il python;

ma la discussione

1) nata a seguito di un post di Andrea in cui parlava di "distributivo"

2) e da un mio intervento (forse un pò precisino?) in cui ricordavo il
significato formale del termine in matematica ed indirizzavo verso
altre aree di ricerca

è giunta a soluzione con l'ultimo post di Andrea nel quale si precisava
che il problema stava nella imperfezione del sistema in virgola mobile
di rappresentare il campo reale;


tutto quì, ciao,
giuliano

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[a.furieri]

On Mon, 5 Oct 2015 11:18:51 +0200, giulianc51 wrote:
> è giunta a soluzione con l'ultimo post di Andrea nel quale si
> precisava
> che il problema stava nella imperfezione del sistema in virgola
> mobile
> di rappresentare il campo reale;
>

... e giusto per un corretto inquadramento storico:
se le moderne CPU sono in grado di macinare quantita' mostruose di
calcoli complessi in tempi ragionevolmente rapidi lo si deve proprio
a quelle "imperfezioni" della notazione in virgola mobile.
e' un ragionevole compromesso che si porta dietro alcune conseguenze
"antipatiche" ma che consente di costruire circuiterie elettroniche
di spaventosa potenza a prezzi irrisori.

- 1993: Intel Pentium 66 MHz
   0.06 GFLOPS (giga operazioni floating point per secondo)

- 2004: Intel Pentium 4 2.8 GHz
   5.60 GFLOPS

- 2009: Intel Core2 Duo 2.2 GHz
   17.6 GFLOPS

- 2012: Intel Core i7 3.4 GHz
   > 108 GFLOPS

giusto per confronto: nel 1984 il Cray XP/M era il piu'
potente super-computer offerto sul mercato, occupava
un'intera stanza e costava circa 40 milioni di dollari;
e tutto questo baraccone arrivava a fatica a 0.9 GFLOPS.

in ultima analisi, se oggi basta un qualsiasi bussolotto
che costa meno di 1.000 euro per lanciare qualche complicata
analisi spaziale che viene risolta in pochi secondi/minuti
e' proprio perche' i numeri reali vengono rappresentati in
quel modo tanto "imperfetto" quanto facile ed economico da
implementare su silicio :-D

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Mon, 05 Oct 2015 12:31:26 +0200
[hidden email] ha scritto:

ciao Alessandro,

> On Mon, 5 Oct 2015 11:18:51 +0200, giulianc51 wrote:
> > è giunta a soluzione con l'ultimo post di Andrea nel quale si
> > precisava
> > che il problema stava nella imperfezione del sistema in virgola
> > mobile
> > di rappresentare il campo reale;
> >
>
> ... e giusto per un corretto inquadramento storico:
> ......
> e' proprio perche' i numeri reali vengono rappresentati in
> quel modo tanto "imperfetto" quanto facile ed economico da
> implementare su silicio :-D

se tu avessi tempo (e voglia) di dettagliare e ampliare questo
argomento, che si interseca con quello del calcolo numerico che mi sta
molto a cuore ma non riesco mai ad approcciare, mi farebbe mooooooolto
piacere e, ancor di più, mi sarebbe estremamente utile;

se temessi di disturbare la lista, sappi che sarei onorato di ricevere
in "privato" le tue interessantissime lezioni, ma, limitando un pò il
mio egoismo, credo che se trovassero una più utile collocazione, ad es.
nel nascituro sito dell'associazione, sarebbero di grande utilità per
tutti :-)


> ciao Sandro

grazie, ciao,
giuliano
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Marco Guiducci-3]

On Mon, 5 Oct 2015 12:44:24 +0200
giulianc51 <[hidden email]> wrote:


>
> se tu avessi tempo (e voglia) di dettagliare e ampliare questo
> argomento, che si interseca con quello del calcolo numerico che mi sta
> molto a cuore ma non riesco mai ad approcciare, mi farebbe mooooooolto
> piacere e, ancor di più, mi sarebbe estremamente utile;
>

per il calcolo numerico io ho studiato sul testo del professore di ingegneria.
un paio di decenni fa, io; il libro è datato ma vedo che è ancora in commercio.le basi credo siano ancora valide.


http://www.ibs.it/code/9788837100810/fontanella-ferruccio/calcolo-numerico-metodi.html

(volume 1 e volume 2)

--
Marco Guiducci <[hidden email]>
Firenze, via di Novoli 26
055 4383194
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[a.furieri]

On Mon, 5 Oct 2015 12:44:24 +0200, giulianc51 wrote:

> Il giorno Mon, 05 Oct 2015 12:31:26 +0200
> [hidden email] ha scritto:
>
> ciao Alessandro,
>
> se tu avessi tempo (e voglia) di dettagliare e ampliare questo
> argomento, che si interseca con quello del calcolo numerico che mi
> sta
> molto a cuore ma non riesco mai ad approcciare, mi farebbe
> mooooooolto
> piacere e, ancor di più, mi sarebbe estremamente utile;
>

Giuliano,

mi stai sopravvalutando: se ti interessa sviscerare i dettagli
fini delle implementazioni HW ti serve assolutamente un
ingegnere o un fisico specializzati in elettronica.
quello che posso suggerirti io e' di leggerti queste due
paginette di Wikipedia per iniziare a fissare le idee:

https://en.wikipedia.org/wiki/Floating_point
https://en.wikipedia.org/wiki/IEEE_floating_point

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Andrea Peri]

E' un argomento non semplice, e i ricordi quando si scende al
dettaglio, a volte tradiscono.

A grandi linee:
Si parla di "incertezza", come di quantita fisica che rappresenta la
differenza tra il valore "vero" e il valore rappresentato.

Per cui una quantita' A reale, viene rappresentata in un computer come
"A+e"  (uso e ma dovrebbe essere epsilon".

Per cui quando vai a fare:

A*B el mondo reale, nel mondo del computer te in realta' esegui:

(A+e1)*(B+e2) = AB + Ae2 + e1B + e1e2

Non ricordo se e quando si poteva supporre che come ordine di
grandezza e1 = e2, ma supponendo che sia ammissibile, finsci per
avere:

AB + Ae + Be + e^2

poi , poiche' e e' una quantita' piccolina , puoi supporre che e^2 sia
trascurabile per cui semplifichi in :

AB + Ae + Be
e quindi alla fine ottieni:

Che A*B reale nella aritmetica finita equivale a:  AB + (A+B)*e

Questo e' la prima parte, quella che ricordo, il resto e' troppo annebbiato....
Ricordo che si riscuva a dare una stima dell' incertezza "e" e quindi
sulla base dei due valori A,B si riusciva a stimare di quanto era
l'errore commesso nell'eseguire la moltiplicazione in aritmetica
finita.

La cosa interessante era che l'incertezza si propagava.
Ovvero se poi portavi questo risultato in una ulteriore operazione successiva,

Quello che dovevi portare non era il risultato di A*B, ma bensi' il
risultaot di "AB+(A+B)*e" e cosi' via.
Per cui alla fine quando facevi calcoli complessi, riuscivi a stimare
l'incertezza del risultato.
La cosa interessante era stado attenti all'ordine con cui si
eseguivano le operazioni , si vedeva che si riusciva a diminuire
l'incertezza complessiva.


A.


Il 5 ottobre 2015 12:44, giulianc51 <[hidden email]> ha scritto:

> Il giorno Mon, 05 Oct 2015 12:31:26 +0200
> [hidden email] ha scritto:
>
> ciao Alessandro,
>
>
>> On Mon, 5 Oct 2015 11:18:51 +0200, giulianc51 wrote:
>> > è giunta a soluzione con l'ultimo post di Andrea nel quale si
>> > precisava
>> > che il problema stava nella imperfezione del sistema in virgola
>> > mobile
>> > di rappresentare il campo reale;
>> >
>>
>> ... e giusto per un corretto inquadramento storico:
>> ......
>> e' proprio perche' i numeri reali vengono rappresentati in
>> quel modo tanto "imperfetto" quanto facile ed economico da
>> implementare su silicio :-D
>
> se tu avessi tempo (e voglia) di dettagliare e ampliare questo
> argomento, che si interseca con quello del calcolo numerico che mi sta
> molto a cuore ma non riesco mai ad approcciare, mi farebbe mooooooolto
> piacere e, ancor di più, mi sarebbe estremamente utile;
>
> se temessi di disturbare la lista, sappi che sarei onorato di ricevere
> in "privato" le tue interessantissime lezioni, ma, limitando un pò il
> mio egoismo, credo che se trovassero una più utile collocazione, ad es.
> nel nascituro sito dell'associazione, sarebbero di grande utilità per
> tutti :-)
>
>
>> ciao Sandro
>
> grazie, ciao,
> giuliano
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 786 iscritti al 30.9.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Giuliano Curti]

Il giorno Mon, 05 Oct 2015 13:18:30 +0200
[hidden email] ha scritto:

> On Mon, 5 Oct 2015 12:44:24 +0200, giulianc51 wrote:
> > Il giorno Mon, 05 Oct 2015 12:31:26 +0200
> > [hidden email] ha scritto:
> >
> > ciao Alessandro,
> >
> > se tu avessi tempo (e voglia) di dettagliare e ampliare questo
> > argomento, che si interseca con quello del calcolo numerico che mi
> > sta
> > molto a cuore ma non riesco mai ad approcciare, mi farebbe
> > mooooooolto
> > piacere e, ancor di più, mi sarebbe estremamente utile;
> >
>
> Giuliano,
>
> mi stai sopravvalutando: se ti interessa sviscerare i dettagli
> fini delle implementazioni HW ti serve assolutamente un
> ingegnere o un fisico specializzati in elettronica.
> quello che posso suggerirti io e' di leggerti queste due
> paginette di Wikipedia per iniziare a fissare le idee:
>
> https://en.wikipedia.org/wiki/Floating_point
> https://en.wikipedia.org/wiki/IEEE_floating_point

quando si vogliono prendere due piccioni(*) con una fava(**) spesso si
rimane a mani vuote, d'altronde chi non risica non rosica ... :-)


> ciao Sandro

grazie lo stesso (anche a Marco e Andrea), ciao,
giuliano


(*) piccioni: la mia personale conoscenza e il contributo al sito
dell'associazione

(**) fava: la tua conoscenza;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015