Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione enrico franchi 
2016-05-27 16:22 GMT+01:00 alessandro medici :

> Credo intendesse pleonastiche.
>

No, intendevo non desiderabili. Pleonastiche sarebbe meglio.
Il problema e' che se scrivi set([f(x) for x in xs]) prima costruisci
interamente la lista, poi la passi a set.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione alessandro medici 
In effetti, cercando un termine più adeguato, forse 'categorie' sarebbe più
corretto.
E 'categorizzare' (odio queste parole in zzare), il lavoro che potrebbe
fare un metodo
della classe scritto in pyDialog.

Qualcosa di più di un set. Qualcosa in meno di un insieme.
​

Alex.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] pensierino della sera sul multiprocessing, sul cambiare le carte in tavola, sui seg-fault e sulla memoria già condivisa,

2016-05-27 Per discussione alessandro medici 
Stasera, giusto per prender sonno, stavo leggendo Python Parallel
Programm etc. etc. Comprato in una svendita online col 75% di sconto :-)

[NON E' PUBBLICITA': Scritto bene nella parte teorica e nello spiegare, a
parte qualche sassolino. Almeno per quel che ne posso dire io. Molto meno
bene (quasi pessimo?) nel codice stampato, poco meglio lo scaricabile. Poco
importa però e forse: sciocchezze e questioni di stile, e mi sembra anche
che da qualche parte scriva che il suo testo non sia proprio da neofiti]

Ma sorry: vedo anche due cose:

1° è l'uso estensivo dei dizionari creati nel processo padre ed aggiornati
dai processo figlio, sia nelle voci che nel contenuto. Un giro rapido e,
stupore, non solo i dizionari, ma anche liste. L'unica cosa che non ho
visto fare è applicare il metodo __del__, cosa comprensibile, peraltro,
almeno per la salute mentale del memory manager.
Ecco: basterebbe FORSE creare un'altro dizionario delle voci che andrebbero
cancellate e poi, magari, farlo dopo?
Ok, 1° compito prima delle vacanze: Ma i dizionari sono pressoché gli unici
oggetti composti che si possono aggiornare in multiprocess?

La 2° viene dall'altra idea:
Mi era venuto subito in mente quando lessi l'articolo che postai qualche
giorno addietro, quel qualcosa sul cambiare le ruote alla bici mentre si
pedala:
http://mathamy.com/python-wats-mutable-default-arguments.html
cosa succederebbe se cambiassi le variabili di default di una classe o di
un metodo mentre la loro progenie è occupata in un processo? Magari in una
ABC genitore?

Forse nulla. Forse dipenderà dal metodo con cui si lanceranno i processi? (
https://docs.python.org/3.5/library/multiprocessing.html#the-spawn-and-forkserver-start-methods
usa inherits ma non chiarisce se intende 'copiare' o 'linkare')

Forse salto in aria :)

E poi vedo Enrico leggermi, e che già chiede per me a viva voce un TSO,
pensare ancora più a ragione un 'ma chi me lo fa fare'? Eddai: forza e
coraggio Enrico, ormai sono sulla via della tomba, che quella con la r in
più ormai la vedo raramente :-(

E però sono curioso. E per due mani di pittura dovrebbero bastare poche
ore, come disse il pittore prima di scoprire che si trattava della torre
Eiffel.

Alex

ps: la vera perla però è che ho trovato anche che non mi occorrerà sprecare
tempo e denaro nel mare di sangue per avere un'area dati shared tra
processi, esiste già, si veda:
17.2.1.5. Sharing state between processes¶

nella pagina che cito poco sopra e poi si dia un ctrl-f su shared memory.

Evidentemente il timore del seg-fault non li ha fermati. Ed, a me, averla
organizzata come array mi va benissimo: il mappare dati in modo diverso nel
Cobol era una delle cose più divertenti da fare nell'epoca di quando ero un
ragazzino. Almeno quando ero vestito.
(Al riguardo dei vestiti il BDFL ed io il  abbiamo le stesse idee. E anche
la stessa età :-(  :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione alessandro medici 
Il giorno 27 maggio 2016 17:15, Andrea D'Amore  ha
scritto:

> On 27 May 2016 at 13:38, enrico franchi  wrote:
> >> s3 = set([i for i in s if una_terza_proprietà(i)])
>
> > Le quadre sono non desiderabili in questo.
>
> Intedi meglio le generator expression per evitare di istanziare tutti
> gli elementi?
>

Credo intendesse pleonastiche.

ps: si vede che mi sto annoiando a morte...
Venerdì del piffero... :(
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione Andrea D'Amore 
On 27 May 2016 at 13:38, enrico franchi  wrote:
>> s3 = set([i for i in s if una_terza_proprietà(i)])

> Le quadre sono non desiderabili in questo.

Intedi meglio le generator expression per evitare di istanziare tutti
gli elementi?


-- 
Andrea
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione alessandro medici 
Il giorno 27 maggio 2016 15:51, alessandro medici <
alexxandro.med...@gmail.com> ha scritto:

>
> Il giorno 27 maggio 2016 14:54, Roberto Polli  ha
> scritto:
>
>> Il 27 maggio 2016 14:41, enrico franchi  ha
>> scritto:
>> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>>
>> Con un broker ;)
>>
>> https://en.wikipedia.org/wiki/Software_transactional_memory
>>
>> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
>> io ovviamente so solo che esiste ;)
>
>
ecco, senza cercarlo:

http://pypy.readthedocs.io/en/latest/stm.html

Alex.
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione alessandro medici 
Il giorno 27 maggio 2016 14:54, Roberto Polli  ha
scritto:

> Il 27 maggio 2016 14:41, enrico franchi  ha
> scritto:
> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>
> Con un broker ;)
>
> https://en.wikipedia.org/wiki/Software_transactional_memory
>
> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
> io ovviamente so solo che esiste ;)
>

La pagina che ho appena passato nella mail precedente lo richiama, alla fine
di una serie di ottime ed interessanti osservazioni. Sul fatto che sia
croccante
non dubito.
Sul fatto che le mie ferie siano limitate, meno ancora :-(

Alex.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione alessandro medici 
Il giorno 27 maggio 2016 14:41, enrico franchi 
ha scritto:

>
>
> 2016-05-25 18:02 GMT+01:00 alessandro medici 
> :
>
>>
>>>
> Perche' scusa... se sai fare una libreria che ti consente di avere oggetti
> condivisi fra processi *senza* bisogno di lock, allora direi che sai anche
> fare una libreria che ti consente di condividere oggetti fra thread *senza*
> bisogno di lock.
> E a questo punto hai finito, hai vinto. Hai ucciso il GIL.
>

Magari. Sto solo cercando un modo che mi permetta di lavorare più
comodamente.
Se e come e quanto sarà possibile, vedrò.
E giuro sulla mia tessera di Giovane Marmotta che, quando tornerò dai bagni
rossi
relazionerò sul mio più che probabilmente certo fallimento :-)

ps:
http://python-notes.curiousefficiency.org/en/latest/python3/multicore_python.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione alessandro medici 
Il giorno 27 maggio 2016 14:20, enrico franchi 
ha scritto:

>
>
> Non ti seguo nel discorso logico e matematico: la mia formazione non
comprende
proprio l'insiemistica: tout court, quel poco che so non è di certo
avanzato o altro.
Io mi sono formato soloai sistemi di equazioni alle differenze finite.
Quindi prendo per buono quello che dici e mi fido.
Eh, no. Di certo non sono un matematico: mi piace e mi diverto se qualcuno
mi spiega
qualcosa di nuovo, ma non ho voglia di rimettermi davvero a studiare. Al
limite chiamo
qualche amico quando ne ho davvero bisogno.

Ah, prolog. Non era casuale se ieri citavo pyDialog. Sostanzialmente
implementa
in python una logica prolog e parte della sua sintassi.


> E qui si scopre che uno dei primi concetti da gestire e' quello di modello
> stabile e poi di modello ben fondato (incidentalmente, la mia tesi
> magistrale era su sta roba). E si scopre anche che non ci sono modi
> efficienti per implementare la semantica di modello ben fondato in un
> linguaggio di programmazione. Wikipedia sostiene che ci siano algoritmi
> quadratici per calcolarlo (ma a suo tempo mi pare fosse ben piu'
> complicato, io ricordo che eravamo molto contenti di averlo fatto in modo
> cubico). E quindi si arriva ad answer set programming.
>
>
> Ma insomma... TL;DR
>
> MediciSet("is zero of Zeta Function") & MediciSet("is complex and has real
> part == 1/2")
>
> Se hai veramente implementato gli insiemi "come li vuoi tu", mi sai anche
> calcolare quella roba lassu'. Se sai calcolare quella roba lassu', hai
> appena dimostrato (o disprovato) l'ipotesi di Riemann e diventi il
> matematico piu' importante della nostra generazione. Si... ho saltato un
> botto di passaggi per arrivare dal pappardello a questa versione breve.
>

:-) magari, ma non credo proprio.

>
>
Ora... buona fortuna. Ma per un uso pratico degli insiemi, non ti serve
> niente di cui sopra... e li hai gia'. Per esempio... vuoi sapere se un ente
> matcha certe proprieta'? Banale. Ci sono anche librerie -- tipo hamcrest --
> che ti rendono facile scrivere le regole. Se le regole sono relativamente
> semplici computazionalmente e parti da un insieme finito, puoi anche
> calcolarlo facilmente. Se l'insieme e' infinito, beh... amen. Puoi comunque
> comporre regole e compagnia e testare ogni candidato.
>

hamcrest? Ok, in cartella anch'esso. Peccato che non ho mesi di ferie :-)

>
> Quindi non capisco cosa siano i tuoi insiemi. Non possono essere "i veri
> insiemi" (scusa, ma sono scettico sul fatto che in un estate rifondi tutta
> la logica computazionale risolvendo alcuni dei problemi piu' ardui della
> materia). E quindi che resta... quello che gia' abbiamo. O mi sono perso
> qualcosa?
>

Verissimo: non sono veri insiemi sal punto di vista matematico. Purtroppo
non ricordo
neppure esattamente il cosa, come e perché mi servivano.
Ricordo solo, e vagamente, che stavo scrivendo qualcosa relativo
alla previsione degli andamenti futuri di alcuni fatti aziendali. Ricordo
ancora
che utilizzavo sostanzialmente un metodo basato su medie mobili inventato
da un tizio
che, allora, lavorava per la Fiat, e che si chiamava Lewandoskj. E che
cercavo di accoppiare
diverse situazioni per vedere quanto, come e dove, si potevano trovare
indicatori storici
di previsione chiamiamoli A, B, ... per una ragionevole previsione di un
altro valore futuro Teta.

A quei tempi bastava e, stranamente, funzionava anche decentemente. Oggi,
con
il mondo che cambia così alla svelta, avrei dei dubbi molto grossi sulla
fattibilità
di previsioni di quel tipo non dico a 12 mesi, ma anche a 3/6.

Il che non toglie nulla al fatto che la voglia mi è rimasta e quindi
indagherò sul
tema. E credo non sia casuale, di nuovo, che cercando mi sia imbattuto in
pyDialog.

Il fatt'è, tutto sommato, che programmare ed imparare cose nuove mi diverte
oggi come allora.

Alex

ps: anche se non c'entra una mazza: a voi risulta che Anaconda implementi
il threading
in modo molto più efficiente (intendo veloce) di Cpython su Linux?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione Roberto Polli 
Il 27 maggio 2016 14:41, enrico franchi  ha scritto:
> Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?

Con un broker ;)

https://en.wikipedia.org/wiki/Software_transactional_memory

@alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
io ovviamente so solo che esiste ;)

Pax,
R.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione enrico franchi 
2016-05-27 13:41 GMT+01:00 enrico franchi :

> Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
> condivisa e poi passarti oggettini che sono solo riferimenti a
> quell'oggetto (ma che a loro volta non sono condivisi).
>

Ah, ça va sans dire, questo oggetto sarebbe eterno. Non ci puoi fare sopra
reference counting. Non puoi sapere chi lo sta usando. Vuole dire che nasce
e dura... finche' tutta la pagina non viene deallocata.

Che magari finche' e' *un* oggetto puoi anche permetterlo. Ma non mi e'
chiara quale sarebbe l'utilita'.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy

2016-05-27 Per discussione enrico franchi 
2016-05-25 18:02 GMT+01:00 alessandro medici :

>
>>
>> Scusa... parliamoci chiaro. Diciamo che hai scritto un allocatore che
>> lavora su un chunk di memoria condivisa.
>> Che vuole anche dire condivisa fra piu' processi (se no non e'
>> particolarmente interessante).
>>
>> Mi spieghi come hai intenzione di fare si che tutto questo non si rompa
>> male *senza* usare lock?
>>
>
> Scrivendoci sopra solo quando NON ho altri processi che ci lavorano.
>

Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?



> Per esempio lanciando
> gli altri processi dopo averci scritto sopra, ed ovviamente non parlo
> di allocare nello heap di python (faccio riferimento al primo esempio
> nella pagina).
>

Quindi stiamo parlando di un oggetto che scrivi in questa area condivisa
(qui c'e' un solo processo).
Poi crei altri processi, che pero' non possono fare *nulla* con
quell'oggetto. Perche'? Perche' anche semplicemente fare f(obj) ha effetto
sul reference counting.
Ma anche o = obj.

Quindi gli altri processi non possono manco referenziare sto oggetto; non
lo possono vedere.

Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
condivisa e poi passarti oggettini che sono solo riferimenti a
quell'oggetto (ma che a loro volta non sono condivisi).

Il problema sarebbe che non hai la semantica di Python (e.g., non puoi
aggiungere, togliere un attributo...). Sarebbe un oggetto puramente
immutabile. Immutabilissimo.
E allora quale e' il vantaggio di averlo cacciato in memoria condivisa?
Puoi fare cose piu' semplici.

E non puoi nemmeno avere cose tipo il creatore modifica. Perche'? Perche'
dovresti garantire che tutte le modifiche sono atomiche. Ora, siccome non
hai lock, non puoi "rendere atomica dal punto di vista di chi legge".
Puoi *solo* usare cose atomiche per davvero. Tipo, non puoi facilmente
avere un dizionario Python... in Python molte operazioni sui dizionari sono
atomiche, perche' hai il GIL. Ma in questo caso... il GIL non ce lo hai.
Quindi

Quindi per fare qualcosa di vagamente utile dovresti risolvere gli stessi
problemi che devono risolvere quelli che vogliono levare il GIL.

Perche' scusa... se sai fare una libreria che ti consente di avere oggetti
condivisi fra processi *senza* bisogno di lock, allora direi che sai anche
fare una libreria che ti consente di condividere oggetti fra thread *senza*
bisogno di lock.
E a questo punto hai finito, hai vinto. Hai ucciso il GIL.


>
-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione enrico franchi 
2016-05-26 17:09 GMT+01:00 alessandro medici :

> In effetti pensavo a qualcosa di assai più complesso ma, ovvio,
>

Io pero' sono un po' confuso. Ovvero, capisco la specifica "generica"
voglio qualcosa che si comporti come gli insiemi, ma... il punto e' che
nella pratica e' qualcosa che non vuoi (o ci sono gia' cose che fanno
quello che ti serve).

Ovvero... cosa e' un insieme? In matematica un insieme e' *semplicemente*
una collezione di "oggetti" (ovviamente non parliamo in questo caso di
programmazione ad oggetti... parliamo di oggetti matematici).
Questo e' un insieme. Niente di piu', niente di meno.

Quindi poi si apre la questione di "come specifico un insieme"? E veniamo
appunto alla descrizione intensionale o estensionale. Ma questo non e'
parte della *definizione* di insieme (ovvero del concetto di insieme), ma
della descrizione di uno specifico insieme. Sono solo modi di specificare
insiemi.

Ma la faccenda fondamentale e' che in matematica non c'e' reale differenza
fra manipolare enti finiti ed infiniti. Esattamente come in matematica non
ci sono grossi problemi ad avere teoremi "di esistenza". Poi certo, c'e'
tutta una polemica interna verso teoremi non costruzionisti... ma appunto,
la matematica va avanti. L'informatica, invece, ha grosse difficolta' con
cose non costruzioniste. Perche' vuole dire che non abbiamo l'algoritmo:
sappiamo che una certa cosa esiste, ma non sappiamo calcolarla. Tutto
questo e' anche legato (ci arriviamo dopo) al concetto di
turing-calcolabile.

Ora... per un po' mi sono occupato di programmazione logica. E tutto questo
discorso e' terribilmente relato a cose come assunzione di mondo
chiuso/mondo aperto (OWA/CWA) e alla negazione come fallimento (NAF) e alle
logiche non-monotone. E questi sono problemi di ricerca *molto* sentiti.
Perche' appunto... sappiamo fare linguaggi di programmazione logici che
fanno CWA... ma per avere NAF (che e' relativamente comoda) si esce dalla
logica del primo-ordine (tipo in Prolog). Nota anche che questa parte di
Prolog e' fuori dalla parte strettamente dichiarativa di Prolog e diventa
invece procedurale.

Ora perche' tutto sto pappardello? Per dire che dimenticati Python (per
semplicita'). Tutto questo discorso degli insiemi, fallo in Prolog. Fallo
in Prolog perche' Prolog *li ha*, di fatto -- anche se non nella forma che
ti aspetti --. Poi capisci quali sono le limitazioni che Prolog ti da su
sta roba (niente affatto banali). Tutto questo puoi farlo in modo
"relativamente semplice" anche in Python -- relativamente semplice vuole
dire che in pratica devi scrivere un motore grosso modo equivalente a
Prolog... il che vuole dire che si puo' fare e si sa come farlo, non che
sia effettivamente rapido da fare --.

Ecco... e scoprirai che il concetto di insieme in Prolog e' comunque
sostanzialmente diverso dal concetto "intuitivo" di insieme che hai (ed e'
diverso pure dal concetto di insieme della logica matematica -- ricordiamo
che prolog implementa "completamente" la first-order logic, ma di fatto ha
bisogno di features extra-logiche, che diventano anche procedurali -- per
fare il resto, fra cui naf, che appunto e' importante parte del discorso).

E qui si scopre che uno dei primi concetti da gestire e' quello di modello
stabile e poi di modello ben fondato (incidentalmente, la mia tesi
magistrale era su sta roba). E si scopre anche che non ci sono modi
efficienti per implementare la semantica di modello ben fondato in un
linguaggio di programmazione. Wikipedia sostiene che ci siano algoritmi
quadratici per calcolarlo (ma a suo tempo mi pare fosse ben piu'
complicato, io ricordo che eravamo molto contenti di averlo fatto in modo
cubico). E quindi si arriva ad answer set programming.


Ma insomma... TL;DR

MediciSet("is zero of Zeta Function") & MediciSet("is complex and has real
part == 1/2")

Se hai veramente implementato gli insiemi "come li vuoi tu", mi sai anche
calcolare quella roba lassu'. Se sai calcolare quella roba lassu', hai
appena dimostrato (o disprovato) l'ipotesi di Riemann e diventi il
matematico piu' importante della nostra generazione. Si... ho saltato un
botto di passaggi per arrivare dal pappardello a questa versione breve.

Ora... buona fortuna. Ma per un uso pratico degli insiemi, non ti serve
niente di cui sopra... e li hai gia'. Per esempio... vuoi sapere se un ente
matcha certe proprieta'? Banale. Ci sono anche librerie -- tipo hamcrest --
che ti rendono facile scrivere le regole. Se le regole sono relativamente
semplici computazionalmente e parti da un insieme finito, puoi anche
calcolarlo facilmente. Se l'insieme e' infinito, beh... amen. Puoi comunque
comporre regole e compagnia e testare ogni candidato.

Quindi non capisco cosa siano i tuoi insiemi. Non possono essere "i veri
insiemi" (scusa, ma sono scettico sul fatto che in un estate rifondi tutta
la logica computazionale risolvendo alcuni dei problemi piu' ardui della
materia). E quindi che resta... quello che gia' abbiamo. O

Re: [Python] Insiemi e multiprocessor.

2016-05-27 Per discussione enrico franchi 
2016-05-26 16:21 GMT+01:00 Pietro Battiston :

> s = set(un_poco_di_roba)
> s1 = set([i for i in s if una_qualche_proprietà(i)])
> s2 = set([i for i in s if una_seconda_proprietà(i)])
> s3 = set([i for i
> in s if una_terza_proprietà(i)])
>

Le quadre sono non desiderabili in questo.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python