Newsgroup: it.lavoro.informatica
Titolo: La differenza tra gli scienziati e i politici italiani

E' che gli scienziati ci pensano tre anni e si rifanno i calcoli per sei mesi 
prima di dire pubblicamente qualcosa di sconvolgente che potrebbe essere una 
stronzata 
(
http://www.repubblica.it/scienze/2011/09/22/news/neutrini_pi_veloci_della_luce_studio_italiano_supera_einstein-22085384/
), 
mentre i politici non ci pensano tre secondi prima di aprire bocca per dire 
sei stronzate in una frase.

 sei stronzate in una frase.
Come mai nello sfolgorante mondo moderno un politico dalla parlantina
sciolta, un manager di qualche improbabile finanziaria o banca, un
rocker mezzo rimbambito anche senza droga vengono valutati (cioè
pagati) decine di volte di più del serio scenziato che fa la
scoperta?

 stronzata
 
questa e' veramente clamorosa.. speriamo non sia la solita "bufala dei
ricercatori italioti"....!!!!

 l'istruzione superiore pubblica gratuitahttp://
www.ilfattoquotidiano.it/2011/09/23/ad-amburgo-l'universita-to.
..
 
e soprattutto perche' gli italioti continuano a votare
"destrasinistracentroforzajuveforzamilan" perche' "senno' fai vincere
XXX" oppure "non vorrai mica votare una forza di governo non
credibile"....

 una papi girl
tira pi� (fa pi� audience) un pelo di patonza che un geniale informatico...


per quanto riguarda l 'amante della tipa si', ma per l' azienda e l'
economia italiana, putroppo no.

 ricercatori italioti"....!!!!
 
Sarà una coincidenza, ma è stata pubblicata lo stesso giorno in cui
hanno reso noto che il loro software è pieno di buchi e dà risultati
a minchia :)
 
http://m.theregister.co.uk/2011/09/22/cern_coverity/
 
 


Sviluppato da qualche 
co.co.pro
 con gara al ribasso ? :-)
 
PaF

 Sviluppato da qualche 
co.co.pro
 con gara al ribasso ? :-)
 
Probabilmente nemmeno quello, da qualche fisico con il pallino per
l'informatica :-)

"Netstat"  ha scritto nel messaggio news:j5hnb2$9hc$1...@speranza.aioe.org...

Francamente non so cosa sia peggiore nell'affossare definitivamente l'Italia 
(gli Scienziati o i politici) qualora la sconvolgente scoperta (come 
probabile che sia) si rivelasse un errore di misurazione reiterato.

PaF ha scritto:

Puo' essere, ma anche se qui tutti saranno convinti dell'esatto contrario,
ho la vaga sensazione che scrivere un software che ha lo scopo di misurare
la velocita' di "roba" che si muove a velocita' prossime a quella della
luce (se non direttamente di dimostrare l'esistenza del "bosone di Higgs",
cioe' una roba che non si sa nemmeno se esiste o meno) sia leggermente
piu' complesso che creare un paio di tabelle per contenere i dati del DB
di un calzaturificio.
E ho anche la vaga impressione che se il software suddetto fosse stato
sviluppato da qualche espertissimo web-oriented j2ee/SOA architecture o
qualche superesperto ERP-SAP (alcuni degli gli informatici piu' pagati al
momento) i risultati sarebbero stati si' diversi, ma dubito che sarebbero
stati migliori :-).
 
 
PS:
 
Domanda tecnica:
 
int f(float a , float b)
{
  if(a==b)  return 1
  else return 0;
}
 
cosa fa la precedente funzione ?
Il codice contiene bugs ?
 
Ciao,
Marco
 
Ciao,
Marco
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 probabile che sia) si rivelasse un errore di misurazione reiterato.
 
Sinceramente, a volte resto molto perplesso davanti a certi ragionamenti.
Secondo te "rubare dei quattrini palesemente non tuoi" e' equivalente a
sbagliare i calcoli che dimostrano l'esattezza della teoria della
relativita'?
 
Mah ?!
 
Ciao,
Marco.



 
 
E' per questo che, dato che sono scienziati, hanno aspettato tre anni di 
prove  e riprove, calcoli e ricalcoli, prima di INVITARE il resto del 
mondo a VERIFICARE i risultati.
 
QUESTO è il percorso della scienza.
 
Non è che hanno semplicemente anunciato di aver fatto iuna scoperta 
sensazionale.
 
Anche se (mia opinione personale) se questa scoperta si rivelasse vera, 
qui un Nobel ci scappa senzaltro.
 
 
 
 
 
 

qui un Nobel ci scappa senzaltro.
 
Me lo auguro. 
 
 
 
 

relativita'?
 
No, ma passare tre anni a fare calcoli sbagliati e verificati come tali in 
meno di tre anni sarebbe quasi uguale al rubare dei quattrini palesemente 
non tuoi.
 
 

 Il codice contiene bugs ?
 
Manca un punto e virgola! :-D
Senza conoscere cpu e compilatore?
 
Almeno comparalo con epsilon, o usa le implementazioni di boost
o gtest:
 
http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-internal.h
 
 
 
-- 
Mirko
 

 qui un Nobel ci scappa senzaltro.
 
Se hanno anche dato una possibile contro-teoria di Einstein, che
spiega il perche' di questa misurazione mantenendo inalterate le
previsioni che la teoria di Einstein permette di fare, sicuramente.
 
 

 (come probabile che sia) si rivelasse un errore di misurazione reiterato.
 
Cosa di preciso ti da motivo di pensarlo?

"YesNoCancel"  wrote in message news:j5ilr8$3mo$1...@tdi.cu.mi.it...

Alcuni neutrini dell'esperimento si sono fermati a casa mia e fra un 
bicchiere e l'altro mi hanno detto che loro in realtà stavano usando la 
propulsione a curvatura :-)
 
 
 
 


Con un programma di fatturazione  piu' veloce della luce
le fatture andrebbero all'indietro nel tempo, come i tachioni di Faynman...
 
Ovvero al 30/09/2011 il calzaturificio stamperebbe le fatture del settembre 
1997 con l'iva al 19% .....:-))))
 
 
ciao
fm 
 
 

 
http://m.theregister.co.uk/2011/09/22/cern_coverity/
 
 
eeeh la vedo molto, moltoooo maleeeeee.. :)
Tutto e' possibile e' spero che il risultato sia genuino.. ma se
dovessi scommettere scommetterei che questa storia andra' a far
compagnia alle varie fusioni fredde italiote... i neutrini che
viaggiano a un po' piu' della velocita' della luce ha qualcosa di
intrisecamente ripugnante dal punto di vista dell "estetica
fisica"..:) Ma staremo a vedere...

 stati migliori :-).
 
ABSOLUTELY.
Il risultato sarebbe che avrebbe il quadruplo delle linee di codice,
sarebbe costato cento volte tanto, utilizzerebbe nmila strati e
framework inutili e ci metterebbe tre ore solo per avviarsi.. :)

 Almeno comparalo con epsilon,
 
L'ho scritto apposta senza epsilon.
Quanti credi che siano gli informatici esperti che non si accorgerebbero
dell'errore ? Ho dei dubbi (per la verita' dubbi ne ho pochi) che siano
tanti, specialmente se presi tra gli esperti sviluppatori j2ee o tra i
superesperti ERP/SAP. E ti posso garantire (per esperienza personale) che
anche chi dovrebbe essere abituato a certe considerazioni (ingegneri,
matematici, fisici) le prime volte ci casca. 
 
Ho la vaga impressione che i problemi di un software come quello oggetto
del thread siano leggermente piu' complessi di questo.
 
Ciao,
Marco
 
 
 
 
-- 
Per i lavoratori a bordo dei cacciabombardieri non esistono sabati, ne'
domeniche. Mai un momento di pausa.
"Per costruire 12 ospedali servono 250 milioni di dollari, quel che ci
costano 8 ore di guerra in Iraq...si prendessero un giorno di ferie!".
Gino Strada


 matematici, fisici) le prime volte ci casca.
 
Da ignorante, quale sarebbe l'errore (a parte il semicolon mancante)?

 matematici, fisici) le prime volte ci casca.
 
Nah, per chi tra fisici e matematici ha fatto anche un corso
elementare di calcolo numerico quella e' una cosa ovvia. E' la prima
cosa che ti insegnano...
Per gli "sviluppatori di gestionali per calzaturifici" e' in effetti
un problema, a meno che non abbiano avuto a che fare con calcoli
"finanziari".
Credo che siano ben coscienti del problema anche la maggior parte dei
DBA...

 cosa che ti insegnano...
 
Scusa sono ignorante e curioso, qual'è l'errore?

 Scusa sono ignorante e curioso, qual' l'errore?
 
L'errore e' che mentre i numeri interi sono rappresentabili in maniera
esatta (ovviamente all' interno di un certo range) i numeri floating
point non riescono a rappresentare esattamente tutti i numeri reali.
Quindi se usi un semplice paragone come == trovi che due numeri che
sono in effetti "uguali" risultano "diversi", perche' sono
"accidentalmente" diversi nella ennesima cifra decimale, a causa di
errori di rappresentazione e arrotondamento..
 
prova qualcosa di simile a questo (scritto in c# perche' in questo
momento ho VS aperto..) per "toccare il problema con mano.."
 
     double x1 = 0.1;
      double x2 = 0.1;
      double epsilon = 1e-10;
      Console.WriteLine((x1 * x2) == 0.01);
      Console.WriteLine((x1 * x2) - 0.01);
      Console.WriteLine((x1 * x2) > 0.01 - epsilon &&
                          (x1 * x2) < 0.01 + epsilon);

 fisica"..:) Ma staremo a vedere...
 
C'e' anche un piccolo dettaglio che sembra tutti vogliano ignorare.
La differenza di velocita' riscontrata e' "fissa".
Potrebbe essere "semplicemente" che la velocita' della luce ha
un'altro valore diverso da quello ritenuto finora.
Sicuramente una scoperta importante, ma non minerebbe nessuna teoria.
 
Diverso se si scoprisse la possibilita' di accelerare i neutrini a
"qualsiasi" velocita' maggiore di quella della luce, ma non sembra il
caso finora.
 
C'ya
  STeve


 
...chissà, dopo questa esperienza si trasformerà il 'detettore' del Gran 
Sasso, a sua volta in un 'acceleratore' di particelle 'en passant'.
Pensa che figo.  Il tutto coi fondi che Berlusconi metterà a 
disposizione della ricerca.
 
Forse se invece di Margherita Hack ci va una nuova 'papi girl' da lui, 
ci riesce a convinverlo....
 

GDelGiovine ha scritto:

Ho come la vaga impressione che tu non abbia grandi idee su cosa sia la
ricerca.
 
In caso contrario, mi sapresti dire, secondo te, quanto tempo richiede
"dimostrare la teoria della relativita'?".
 
Ma anche senza arrivare a questo, secondo te, quanto tempo richiede
risolvere un qualsiasi "problema aperto" nell'ambito della ricerca di
qualsiasi genere ?
 
E' ovvio che si passano anni a fare "calcoli". 
Ed e' altrettanto ovvio che e' piu' facile sbagliare che farli corretti,
cosi' come il fatto che "verificare che i calcoli sono sbagliati" richiede
meno tempo che non fare i calcoli. Prova a pensare al seguente esempio:
 
Io affermo che 773635445x74748495905 fa 12.
Quanto tempo ci metti a fare il calcolo ? E quanto tempo ci metti a dire
che 12 e' il risultato sbagliato ?


che 12 e' il risultato sbagliato ?
Mi sa che hai scelto l'esempio sbagliato.... 

 Mi sa che hai scelto l'esempio sbagliato....
Fanne pure uno corretto.


 cosa che ti insegnano...
 
rileggi bene il mio post, nella parte "per esperienza personale".
Ricordo molto bene un giorno di tanti anni fa (molto piu' di 10, forse 13)
in cui ne' io, giovane ingegnere al primo progetto post-laurea, ne' una
collega, giovane neolaureata in scienza dell'informazione con poca piu'
esperienza di me, ne' il nostro capo di allora (giovane anche lui, ma con
molta piu' esperienza di noi, anche perche' laureato molto prima e con
voti molto piu' brillanti [e io ho preso 110/110, sebbene senza lode]) ne'
il marito della collega, laureato in scienza dell'informazione e, in un
certo senso, "genio informatico" (gia' allora aveva una sua azienda
informatica, in seguito ha sviluppato in proprio sistemi rivenduti ad
operatori telefonici [in un certo senso facendo concorrenza ad ericsson,
almeno per un periodo], oggi credo che lavori presso IBM in Irlanda) in un
pomeriggio, guardando e riguardando centinaia di migliaia di linee di
codice, riuscivamo a capire perche' non funzionasse. Il problema era
riconducibile a quello dell'esempio, ripetuto n-mila volte nel codice e
tranquillamente sotto i nostri occhi senza che ce ne accorgessimo.
E tutti quanti avevamo passato l'esame di calcolo numerico. Anzi, in 3 su
4 lavoravamo in un laboratorio di sistemi real-time.
E fu poi il marito della collega (l'unico che non lavorava in quel
laboratorio), il giorno successivo, che si rese conto che il problema era
quello. E ci saremmo presi a bastonate l'uno con l'altro per aver passato
un pomeriggio senza renderci conto di quel problema idiota.


C'hai ragione.
 

YesNoCancel ha scritto:

Il problema e' legato alla precisione del calcolatore.
I numeri reali costituiscono un insieme continuo, mentre i numeri
rappresentabili in memoria del calcolatore (anche quelli float o double)
sono un insieme discreto. Il che significa che i calcoli in virgola mobile
eseguiti dal calcolatore sono soggetti ad errori di arrotondamento.
 
Se hai:
 
int g()
{
  float f1,f2;
  ...
  ...
 
  f1=funzioneCheCalcolaf1(...);
  f2=funzioneCheCalcolaf2(...);
  return f(f1,f2);
}
 
dove f e' quella del post precedente (ma senza l'errore del ;)
 
immagina che funzioneCheCalcolaf1 debba fare un calcolo e restituire
ad esempio f1=1*10^(-15) se il calcolo fosse perfettamente corretto
e che anche funzioneCheCalcolaf2 dovesse restituire f2=1*10^-15 se il
calcolo fosse corretto.
 
Ma ammetti che, a causa di errori di arrotondamento, funzioneCheCalcolaf1
restituisca f1=1,001*10^(-15) e funzioneCheCalcolaf2 restituisca
f2=0.9999*10^(-15).
 
Quando chiami f questa potra' restituire 0, anche se i numeri sono diversi
solo a causa di errori di arrotondamento introdotti dal calcolatore, non
perche' le grandezze fisiche rappresentate da f1 ed f2 siano diverse
(metti che f1 sia la velocita' calcolata di un neutrino e f2 sia la
velocita' di propagazione della luce in un certo mezzo, costante o meno
che sia).
 
Quindi, in generale, quando si hanno due float (o due double), e' corretto
definire una costante EPSILON (piccola ma in valore assoluto maggiore di
zero) e poi, per verificare se i due float (o double) sono uguali o meno
usare un confronto del tipo
 
if(abs(f1-f2) < EPSILON)
{
  //f1 ed f2 sono uguali
}
else
{
  //f1 ed f2 sono diversi
}
 
mentre un confronto diretto del tipo
 
if(f1==f2)
{
  //f1 ed f2 sono uguali
}
else
{
  //f1 ed f2 sono diversi
}
porta praticamente sempre ad un risoltato errato, a differenza
di quanto accadrebbe se f1 ed f2 fossero interi (direi che questo e'
proprio uno di quegli eventi in cui con probabilita' "a priori" del 100%
si entra nel ramo else, anche se e' possibile che si entri nel ramo if
(anzi, se si assegnano a f1 ed f2 sempre valori "interi" (tipo 1.0, 2.0,
ecc.) e i calcoli sono semplici e' probabile che si entri nel ramo if
quasi sempre, se i numeri sono uguali. Pero' questa non e' una
"probabilita' a priori" ma una probabilita' "sapendo che alle variabili
vengono assegnati numeri interi e che i calcoli sono "semplici". Se nei
calcoli si cominciano ad introdurre radici quadrate o cubiche o logaritmi
o simili, e' probabile che nel ramo if non ci si entri mai, nemmeno quando
si dovrebbe).


 sei stronzate in una frase.
 
la mia impressione e' che,  nonostante ci siano dubbi
sull'esattezza dei calcoli, gli scienziati siano stati costretti
per motivi di prestigio e di finanziamenti, a sbilanciarsi e fare
comunque l'annuncio pubblico...
per timore che qualcun altro, as usual,  si prenda il merito e gli onori
della "scoperta".
 
I dubbi riguardano sia la misura della distanza sia quella
del tempo.
Altri dubbi ancora sono stati sollevati sulla metodologia
statistica adoperata.
 
Insomma.....e' tutto da verificare....
riprodurre e ricontrollare.
 
 
ciao
fm
 
 
 
 
 
 

 stronzata
la prudenza non e' mai troppa:
http://www.borborigmi.org/
ciao
fm 


senti questa , a proposito...
http://www.tzetze.it/tzetze_news.php?url=http%3A%2F%2Fnonleggerlo.blogspot.com%2F2011%2F09%2Ffare-peggio-era-impossibile-ci-sono.html
povera italiotilandia .. in che mani l' hanno messa....


ma questo non e' una prova dell' ignoranza delle problematiche
relative alla rappresentazione dei reali...e' uno dei tanti casi di
"bug da distrazione"...e' perfettamente normale che anche un bravo
programmatore introduca un bug stupido nel suo lavoro ogni tanto, ed
e' pure perfettamente normale e comprensibile che rimanga per un
giorno a fissare il codice senza vederlo... e' successo  a tutti.. ed
e' uno dei motivi per cui il pair programming e' cosi' utile. La
differenza tra un bravo programmatore e un cazzone non e' che il bravo
programmatore non fa mai errori, ma che il lavoro del cazzone *e'
tutto un errore* ..
L'unico programmatore che non fa errori e' quello che ha smesso di
programmare.. e programmare e' umano, debuggare divino :)

 statistica adoperata.
un' altra cosa che mi fa dubitare fortemente della validita' della
scoperta e' il "mostruoso" numero di autori della pubblicazione...
174..
http://www.ilfattoquotidiano.it/2011/09/23/neutrini-piu-veloci-della-luce-einstein-sbagliava/159557/
Approfitto anche per notare come Il Fatto almeno  faccia scrivere i
suoi articoli a tema scientifico ad uno che con la scienza ha a che
fare..e che ha il background per capire quello che
scrive,contrariamente a molti altri giornali.. anche se avrei
preferito un "fisico vero" o comunque un ricercatore vero invece di un
dirigente di finmeccanica.. ma e' gia' qualcosa...


 
Beh, infatti il CERN 'invita' ufficialmente a ulteriori controlli dei 
calcoli  :
 
www.cern.ch
 
 

 un'altro valore diverso da quello ritenuto finora.
 
ma no, è solo un banale errore di geografia: hanno misurato la distanza in 
superficie mentre i neutrini hanno preso la corda tra i due punti, e 
andando alla stessa velocità arrivano prima ... oppure hanno misurato la 
distanza prima del terremoto che la ha accorciata di 20 cm ... :P
 
-- 
DES

 l'informatica :-)
 
per mia piccola esperienza, mi asterrei da perculare chi si occupa di 
informatica negli enti citati. In particolare:
- l'informatico più spaccaballe sulla documentazione e cercatore di peli 
nell'uovo (i suoi debug erano definitivi), con cui ho lavorato è stato 
assunto come DBA al CERN;
- i fisici INFN, lasciati senza soldi per comprare i supercalcolatori sul 
mercato, in poco tempo hanno ideato e sviluppato HW e SW di APE che gli 
permetteva di fare gli stessi calcoli ad un decimo del costo: 
http://www.eurotech.com/it/news.aspx?pg=news&id=41
 
 
Questo non vuol dire che tutti i fisici sono anche informatici. Un 
brillante ragazzo che conosco, con in tasca offerte da tre università 
americane ancora prima di laurearsi con lode alla Normale, specialista di 
buchi neri, è talmente altrove con la testa che la manutenzione sw dei 
suoi pc ho dovuto farla io...
 
-- 
DES

 Il codice contiene bugs ?
 
Non hai specificato cosa dovrebbe fare quel codice quindi non è detto che 
abbia bachi.
 
Fare float == float può essere perfettamente legittimo e sensato.
 
Senz'altro è brutto a vedersi, ma non è rilevante :)
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

 Senz'altro è brutto a vedersi, ma non è rilevante :)
 
Ma anche no. L'uguaglianza stretta tra float , a meno di casi
estremamente semplici o fortunati, porta inevitabilmente a risultati
diversi da quelli che ti aspetti. E semmai e' "l eguaglianza modulo
epsilon" che e' brutta a vedersi, ma e' necessaria se vuoi evitare
"sorprese"..

 diversi da quelli che ti aspetti.
 
Cosa ne sai di quali sono i risultati che mi aspetto?
 
Ripeto, se non è specificato COSA deve fare quel codice non PUOI dire che 
sia giusto o sbagliato.
 
 
...e nello specifico, per esempio, ci sono dei casi in cui un float ha una 
rappresentazione ben determinata e non soggetta ad arrotondamenti.


 rappresentazione ben determinata e non soggetta ad arrotondamenti.
 
grazie al cazzo, ma come fai ad essere sicuro di rientrare sempre in
quei casi a meno di non non essere confinato in casi di una banalita'
o di una settorialita' estrema?
La domanda era piu' che legittima, perche' chiunque conosca il
problema lo individua immediatamente , compresi eventuali casi limite
in cui problema non e', mentre chi non lo conosce e' destinato a
prendere sonore facciate :)

 o di una settorialita' estrema?
 
Ripeto per la terza volta, data una funzione:
 
int f(float a , float b)
{
  if(a==b)  return 1
  else return 0;
}
 
NON PUOI dire che sia bacata se PRIMA non dici *COSA DEVE FARE*.
 
Magari questa funzione serve proprio a dirmi quando due float coincidono bit 
a bit.


 a bit.
 
perdonami, pensavo di parlare ad una persona, non avevo capito che eri
un compilatore ...:)

 un compilatore ...:)
 
Appunto, manca la descrizione in linguaggio naturale di quello che vorresti 
che la funzione faccia.
 
Un compilatore infatti non si lamenta e ti produce del codice che fa 
esattamente cosa gli stai chiedendo.


 esattamente cosa gli stai chiedendo.
 
appunto...con lo stesso livello di  intuizione,elasticita' mentale,
buon senso ed intelligenza che stai mostrando tu ora ..... :)
Ma speravo di non doverti spiegare pure le battute...

 buon senso ed intelligenza che stai mostrando tu ora ..... :)
 
A casa mia essere rigorosi è utile in questo mestiere


 A casa mia essere rigorosi è utile in questo mestiere
 
Quando programmi sicuramente.
Quando discuti con qualcuno sarebbe meglio attivare la funzionalita'
"human being" .. almeno a casa mia funziona cosi' :-)
 
C'ya
  STeve

 "human being" .. almeno a casa mia funziona cosi' :-)
 
Si stava analizzando un pezzo di codice no? Mi sembra una buona situazione 
in cui essere rigorosi.
