Python - n numeri random con somma uguale a 1

[gabmac2]

E' possibile generare n numeri la cui somma sia uguale a 1?
ad esempio passando n=4
generi 0.25,0.25,0.25,0.05
oppure 1,0,0,0
oppure 0.5,0,0.5,0
ecc.....
generare un insieme generico di n numeri con somma uguale a 1
Grazie in anticipo e Buon Anno a tutti

[DoctorT]

ho scritto questa soluzione ... i numeri non saranno esattamente random ma dipende da cosa vuoi farci potrebbero andare bene. Non ho testato la soluzione, ma credo che potrai farlo facilmente.

import random;

def SumOfRandom(n):
    average = 0.0;
    left = 1.0;
    while n > 1:
        average = left / n;    
        item = random.uniform(0,average*2);
        left = left - item;
        print(item);
        n=n-1;
    print(left);
    return;


if __name__ == "__main__":
    n = SumOfRandom(10);

[gabmac2]

davvero molto gentile, volendo che queste soluzioni siano accettate solo se i valori non sono nulli
es. n=4
0.4,0.4,0.1,0.1
0.5,0.3,0.1,0.1
ecc.....
è sufficiente impostare average=0.1?
Grazie ancora

[DoctorT]

per avere valori non nulli basta questa piccola modifica

item = random.uniform(0.000001,average*2);

[oNaSsIs]

Personalmente preferirei una soluzione di questo tipo, più concisa e facile da leggere.
Fammi sapere cosa ne pensi.

>>> import random
>>> l = [random.random() for _ in xrange(4)]
>>> s = sum(l)
>>> l = map(lambda x: x/s, l)
>>> l
[0.1035144436624971, 0.27769461883420643, 0.35351426676953723, 0.2652766707337592]
>>> sum(l)
1.0

[cdimauro]

Sarebbe meglio non usare la funzione map definendo una lambda al suo interno. Meglio la classica list comprehension (più pythonica e leggibile).

La tua soluzione è molto elegante, ma non tiene conto del caso in cui tutti e 4 i numeri generati siano 0: estremamente raro, ma possibile.

Inoltre per problemi di approssimazione / imprecisione dei numeri in virgola mobile, è possibile che i numeri così ottenuti non diano 1.0 come somma.

@DoctorT: il codice scritto è poco pythonico. Ad esempio i ; non sono necessari.

Comunque prima di fornire la soluzione bella e pronta, avrei chiesto quanto meno una bozza. A volte capitano da queste parti studenti che richiedono la soluzione a esercizi; cosa proibita dal regolamento.

[oNaSsIs]

Originariamente inviato da cdimauro

Sarebbe meglio non usare la funzione map definendo una lambda al suo interno. Meglio la classica list comprehension (più pythonica e leggibile).

Non sono un esperto di Python, potresti dirmi qual è il problema di definire una lambda al'interno di una map?
Al contrario, usare una map però dovrebbe avere il vantaggio di essere più performante perché eseguita in parallelo, o sbaglio?

La tua soluzione è molto elegante, ma non tiene conto del caso in cui tutti e 4 i numeri generati siano 0: estremamente raro, ma possibile.

Giusto. Bisognerebbe usare la funzione uniform come è stato suggerito in un post precedente.

Inoltre per problemi di approssimazione / imprecisione dei numeri in virgola mobile, è possibile che i numeri così ottenuti non diano 1.0 come somma.

Sono d'accordo, dipende dalla criticità del problema.

Comunque prima di fornire la soluzione bella e pronta, avrei chiesto quanto meno una bozza. A volte capitano da queste parti studenti che richiedono la soluzione a esercizi; cosa proibita dal regolamento.

Pardon, da poco mi sono appassionato a questo linguaggio e mi sono lasciato scappare quelle due righe. Farò più attenzione la prossima volta.

[cdimauro]

Originariamente inviato da oNaSsIs

Non sono un esperto di Python, potresti dirmi qual è il problema di definire una lambda al'interno di una map?

E' soltanto una questione di leggibilità. Con una list comprehension "la funzione di mappatura" è molto più semplice da definire e leggere.

Questo non significa che non si debba mai usare map. Il consiglio (e il generale consenso all'interno della comunità) è quello di definire una funzione normale, dunque dotata di nome, oppure utilizzare una funzione predefinita (ad esempio str) che faccia capire immediatamente cosa si sta facendo.

Se t'interessa l'argomento, puoi cercare un articolo di Guido van Rossum a riguardo (prima dell'introduzione di Python 3), oppure dare un'occhiata alle linee guida / coding convention di Google.

Al contrario, usare una map però dovrebbe avere il vantaggio di essere più performante perché eseguita in parallelo, o sbaglio?

No, non c'è nessuna parallelizzazione, perché potrebbe succedere un errore durante l'applicazione della "mappa"; dunque l'elaborazione dev'essere effettuata in maniera strettamente sequenziale.

Pardon, da poco mi sono appassionato a questo linguaggio e mi sono lasciato scappare quelle due righe. Farò più attenzione la prossima volta.

Non mi ero rivolto direttamente a te. Qualcuno t'aveva già preceduto offrendo subito una soluzione. A questo punto non ha senso evitare di pubblicarne altre: il "danno" è già stato fatto.

[ingframin]

Originariamente inviato da cdimauro

E' soltanto una questione di leggibilità. Con una list comprehension "la funzione di mappatura" è molto più semplice da definire e leggere.

Non solo, in python 3 non funziona perché map restituisce un iterator e non una lista.

import os

def rand_seq(length):
    numbers = [x/256.0 for x in [ord(os.urandom(1)) for n in range(length)]]
    
    return [n/sum(numbers) for n in numbers]

Penso che lídea fosse questa (ancche senza definire la funzione rand_seq magari...)

[cdimauro]

Sì, credo che l'idea fosse quella, ma la tua soluzione soffre degli stessi problemi di quella di oNaSsIs.

Comunque anche questa è una soluzione elegante. Suggerisco soltanto qualche piccolo cambiamento (stilistico):

import os

def rand_seq(length):
    numbers = [ord(ch)/256.0 for ch in os.urandom(length)]
    
    return [n/sum(numbers) for n in numbers]

[oNaSsIs]

Scusate ma perché usate

ord(os.urandom(1))

per generare numeri casuali quando esiste l'apposita funzione random? In questo modo c'è un lower bound (1/256) sotto il quale non è possibile scendere (tralasciando la successiva divisione).

[cdimauro]

Ti riferisci a random.random()?

[ingframin]

Originariamente inviato da oNaSsIs

Scusate ma perché usate

ord(os.urandom(1))

per generare numeri casuali quando esiste l'apposita funzione random? In questo modo c'è un lower bound (1/256) sotto il quale non è possibile scendere (tralasciando la successiva divisione).

Perché os.urandom genera bytes random usando una apposita funzione del sistema operativo, il risultato che ottieni e di qualità crittografica.
random.random invece genera una sequenza di numeri pseudorandom.

Non è vero che il limite è 256.

from os import urandom
from struct import unpack

rand16bit = unpack('@H',urandom(2))[0]

Ed eccoti un bel numero random 16 bit unsigned. Se lo vuoi signed, devi usare h piccola invece di H grande.
Oppure:

rand01_32bit = unpack('@I',urandom(4))[0]/2**32

Un bel numero random compreso tra 0 e 1.
Reference:
https://docs.python.org/3.4/library/struct.html

(se usate struct per convertire dati da file binari grandi, attenti che è un bel collo di bottiglia e con pypy è più lento che con CPython... esperienza personale! )

EDIT:
Un mio collega mi ha fatto rilevare che esiste un metodo int.from_bytes(bytearray, bytorder="big" o "little")
magari è più intuitivo da usare invece di struct.unpack, però funziona solo con interi unsigned, niente float o double.

[oNaSsIs]

Interessante, non conoscevo questa possibilità.
Grazie, alla prossima!