[Python] Test statistici

enrico franchi enrico.franchi a gmail.com
Gio 16 Ott 2014 00:07:06 CEST


2014-10-13 16:29 GMT+01:00 Mauro Alberti <alberti.m65 a gmail.com>:

>
>
> 2014-10-13 15:16 GMT+02:00 enrico franchi <enrico.franchi a gmail.com>:
>>
>>
>> 2014-10-12 22:17 GMT+01:00 Mauro Alberti <alberti.m65 a gmail.com>:
>>
>>>
>>> hai preso in considerazione R, che è il linguaggio statistico
>>> open-source più completo ed usato in accademia, e che volendo è anche
>>> interfacciabile con Python tramite rpy2? Per analisi statistiche è ottimo e
>>> fornisce tutte le possibili tecniche statistiche, credo ben più di Python..
>>>
>>
>> "Ben piu'" mi sembra eccessivo. Per inciso, sto vedendo un chiaro trend
>> di Python che soppianta R per molte delle tradizionali roccaforti di R.
>> Perche' e' semplicemente piu' facile lavorarci e piu' general purpose.
>>
>>
>
> Rimanendo ai numeri, per quel che son riuscito a ricuperare velocemente e
> facendo quindi la tara sia ai numeri sia alla loro interpretazione:
> - il repository ufficiale dei moduli R, CRAN - Packages (
> http://cran.r-project.org/web/packages/ ) riporta il numero di 5936
> packages
> - in un repository Python non ufficiale, ma abbastanza completo di moduli
> (generici) Python, l'Unofficial Windows Binaries for Python Extension
> Packages (http://www.lfd.uci.edu/~gohlke/pythonlibs/) ho contato circa
> 320 packages. Se i packages Python non considerati in questa collezione
> fossero un ordine di grandezza superiore a questo numero, il numero totale
> di moduli Python generali risulterebbe ancora inferiore a quello dei moduli
> R.
>

Non mi pare che questa cosa dica troppo. Potrei spendere parecchio tempo a
spiegare il motivo per cui questo confronto numerico non abbia particolare
senso, ma, sinceramente, non ne ho voglia perche' davvero, non credo di
essere in grado di convincertene. Per inciso, il senso del mio discorso e'
che vedo una grossissima crescita di Python nell'ambito da paper pubblicati
(hey, ma io non seguo molti journal di statistica e matematica applicata,
magari saro' biased... parecchia roba piu' o meno relativa al calderone
buzzwordaro del BigData pero' si) e quello che vedo in startup e simili.
Ovviamente dovrei trovare il modo di trovare hard data a sostanziare (il
che e' complicato... sia perche' molti dati non sono pubblicamente
disponibili, sia perche' molti altri sono particolarmente difficili da
aggregare -- chesso', scoprire che nelle resources dei paper ci sono script
in Python e/o che nel paper si menziona Python, *ma* in un contesto che fa
intendere che appunto ci stanno facendo sopra statistica). Per cui
teniamolo come gut feeling che non posso sostanziare...

Diciamo brevemente che stai comparando mele con pere e che quello che ci
interessa e' una ricetta per fare la carbonara.

In altre parole, il fatto che Python venga sempre piu' adottato per fare
cose che prima si sarebbero fatte con R non necessariamente ha raffronto
con l'intero numero di pacchetti prefabbricati che esistono per R (in cui
stiamo contando, verosimilmente, anche pacchetti per fare richieste http (o
qualunque altra cosa)) o con il numero di pacchetti utili per fare
statistica in Python secondo l'autore della lista che riporti.

R è meno semplice di Python, è vero, ed anche più lento, p.e. nei plot.
> Però ha tuttora vari vantaggi, come una buona espressività statistica, una
> ottima e ricca documentazione dei moduli fatta dagli statistici che creano
> i packages, e poi un ambiente di plot integrato, il che semplifica
> parecchio la creazione di plot anche molto sofisticati. Per avere il
> corrispondente di quest'ultimo in Python ci si deve rivolgere ad IPython.
>

E anche qui... niente da dire. Se ti trovi bene con R fai benissimo ad
usare R e passare a Python o qualunque altra cosa ti sembra piu' opportuna.
Per il resto, immagino che buona parte di chi voglia fare statistica in
Python usi appunto tutto lo stack che c'e' a disposizione e di conseguenza
non vedo problemi nel doversi rivolgere ad IPython; specie perche' ci sono
almeno 3 distribuzioni di Python per fare questo tipo di cose che includono
tutto il necessario (di cui almeno una interamente free).


> Che Python eroda R (e Matlab) è innegabile. D'altronde, rimanendo nel
> campo numerico, forse  in futuro Julia, grazie alla sua notevole velocità e
> semplicità, riuscirà a fare lo stesso con i tre precedenti linguaggi.
>

Io di mestiere faccio l'ingegnere (o per lo meno cosi' c'e' scritto nella
job description) e non l'indovino, per cui su quello che sara' il futuro
non so esprimermi.

Uno dei motivi per cui Python si sta allargando in favore di soluzioni
consolidate e' che Python e' un linguaggio general purpose *usato* come
linguaggio general purpose con una comunita' di persone che ci fanno,
appunto di tutto. Che vuole dire per dire che appunto tutte le volte che
devi incastrare intelligenza/statistica whatever in sistemi piu' complessi
sei piuttosto avvantaggiato. Le librerie per parlare con quasi qualunque
tipo di sistema ci sono gia', mantenute e usate da grosse community di
sviluppatori.

Se poi domani Julia si diffondera' a tal punto da condividere il tipo di
posizione che Python ha in questo momento, non te lo so dire. Ma il fatto
che possa fare *una* cosa meglio di Python e di R non sara' necessariamente
motivo sufficiente per soppiantare Python da tutti quei contesti in cui
l'ambiente-python e' vincente. Che vuole dire per esempio tutti i contesti
in cui non si fa ricerca pura ma si devono tenere in piedi sistemi che
hanno bisogno di statistica. Se poi questo fara' Julia, tanto meglio.

Per dire, se un collega mi facesse passare una draft per un sistema in
Julia (o in J o in quello che ti pare) guarderei il calendario per
assicurarmi che non sia il 1o di Aprile.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20141015/6251153a/attachment-0001.html>


Maggiori informazioni sulla lista Python