Oggi pomeriggio per diverso tempo era impossibile comprare con ricarica superflash (disponibilità 0) e adesso dà disponibilità 0 su entrambi.
Si puo' sapere più o meno quanto spesso ci sono questi "down"?
Perchè per chi promuove BitBoat (come il sottoscritto) non è il massimo. Non c'è la possibilità di aprire a qualche venditore in più che non holdi troppo quando il prezzo sta salendo?
Grazie.
Ciao, ho fatto la tua stessa domanda a bertani che mi ha risposto in questo thread https://bitcointalk.org/index.php?topic=430372.msg10778639#msg10778639, in sostanza ci sono dei problemi con la carta superflash e la compravendita di bitcoin. |
|
|
|
La disponibilita' e' spesso zero in quanto intesa san paolo si sta muovendo per sospendere le carte utilizzate per la compravendita di bitcoin, di conseguenza i venditori non se la sentono di rischiare, visto anche che nell'ultimo periodo i volumi con Postepay sono stati superiori di quelli su Superflash. Stiamo lavorando per riuscire ad abbassare il prezzo con Postepay, dovremmo avere novita' gia' nei prossimi giorni!
Grazie dell'informazione, non sapevo del rischio di sospensione della superflash! Spero non blocchino anche la mia (anche se faccio solo pochi acquisti di btc all'anno mediante questa carta). |
|
|
|
Sono i venditori a scegliere se/quando/quanto vendere sulla piattaforma. Non é raro che di notte o il weekend i venditori abbiano disponibilità bassa/nulla (perché hanno terminato la loro disponibilità giornaliera di bitcoin, per esempio..).
Ciao, è da almeno un paio di giorni che ho notato che non c'è disponibilità di btc pagando mediante superflash, al momento l'unico modo di acquistare bitcoin è tramite postepay a un prezzo di 307 euro a btc ( mentre il prezzo di mercato è 270 euro), quindi non proprio basso. Ma non c'è modo di garantire una disponibilità minima ( magari dando qualche incentivo ai venditori? ) Non fa una buona impressione trovare così spesso disponibilità 0. |
|
|
|
Ho utilizzato un po' per curiosità un po' perchè può servire per il futuro questo sito di pagamento automatico, e ho acquistato quindi 0,10 BTC. Non posso che parlarne benissimo, prezzo eccellente, al momento del mio acquisto era 285,57 euro a btc, mentre Coinbit 297,85 euro (inoltre sotto il pagamento con superflash era riportato: collegamento al server il corso ...) BitBoat 297,33 euro (disponibilità con superflash era a 0) e soprattutto immediata ricezione dei bitcoin. Avendo effettuato tutta la procedura online (ho pagato mediante la mia superflash via sito web della banca) sono soddisfattissimo!  Complimenti veramente a GIANNAT. |
|
|
|
Devo dire che a lanciarlo si ha come la sensazione di "minare" .... Qualche esempio di esecuzione: $ echo "0.00000001"|./pigreco_while
Valore stimato di pi greco = 3.141592660980685458582684077555
Valore NOTO di pi greco = 3.141592653589793115997963468544
tiri = 34119; centri=26797; seed = 1426291102; errore=7.39089e-09
$ echo "0.00000001"|./pigreco_while
Valore stimato di pi greco = 3.141592653082085906390830132295
Valore NOTO di pi greco = 3.141592653589793115997963468544
tiri = 430439; centri=338066; seed = 1426291107; errore=5.07707e-10
Ciao picchio e buon pi greco day a tutti! Stamattina 3 / 14 / 15 alle 9:26:53 secondi sono state "festeggiate" le prime 9 cifre decimali del pi greco! Succede 1 volta ogni 100 anni Per quanta riguarda il tuo programmino ho trovato interessante l'idea che hai avuto; mi spiego meglio, tu vuoi vedere dopo quanto tempo si arriva entro un certo limite di errore, effettivamente da come l'ha impostato tu questo ricorda molto da vicino il concetto di difficoltà dei bitcoin. Ovviamente se dovessimo usare veramente il programma per vedere quanto il metodo Monte Carlo funziona nella stima di pi greco (la velocitá di convergenza dell'algoritmo al risultato) non avrebbe molto senso fare così, poiché affermare di riuscire a fare un errore dell'ordine di e-09 / e-10 solo con poche decine di migliaia di punti sarebbe un po' come ricavare dal fatto che un certo blocco é minato in 30 secondi una stima per eccesso della propria velocità di risoluzione del problema. La grossa differenza tra il mining e la stima di pi greco é che con il pi greco tu sai che piú calcoli fai, migliore diventa l'approssimazione (almeno fino a un certo punto), mentre con il mining si é costretti a parlare di probabilitá di trovare una soluzione. Io per arrivare a una stima "stabile" delle prime 6 cifre di pi greco ho dovuto generare centinaia di miliardi di punti, se per caso dopo 10000 punti ottengo le prime 5 cifre corrette e al 10001 punto la stima risulta corretta solo fino alla 4^ cifra, l'algoritmo allora non ha localizzato la soluzione, l'ha semplicemente solo "indovinata". Sarebbe possibile, almeno a livello teorico, fare il mining sostituendo il problema di ottenere la famosa stringa con un tot di 0 iniziali con quello di approssimare pi greco fino alla x-esima cifra decimale ?  Con il pi greco bisognerebbe trovare l'accoppiata seed / numero di punti generati per dimostrare di avere trovato la soluzione richiesta, ma forse tutti dovrebbero usare una stessa funzione random? Sarebbe piú facile "barare" e fornire una soluzione al problema che non richieda molti calcoli? EDIT: mi é venuto in mente che come minimo bisogna trovare però almeno un modo per collegare il calcolo del pi greco alle transazioni contenute nel blocco da validare ... |
|
|
|
Ho concluso l'ennesima transazione senza problemi con ghibly79! Venditore "quasi" perfetto, diventerà perfetto il giorno che si fiderà a inviarmi i btc senza aspettare la ricezione del bonifico  L'acquisto giornaliero da Ghibly Grazie anche perchè sei uno dei pochi che mi lascia sempre il feedback, non come altri che "sì sì te lo lascio subito adesso, ci mancherebbe, figurati, sto gia' loggando, ho il dito sul tasto" poi spariscono  Dovro' farti piu' sconto in futuro (up) Dal momento che anch'io ti lascio sempre il feedback (e in più anche il trust), mi aspetto lo sconto per la prossima volta Ciao. |
|
|
|
Scambio doge con btc, piccola transazione avvenuta senza problemi. |
|
|
|
E fare una griglia di punti al posto del casuale, ti risparmieresti la generazione di numeri casuali che per milioni di punti temo crei alla fine sempre gli stessi. Svolgeresti tantissimi calcoli ripetuti e forse inutili.
A mio avviso il metodo ha molto senso se lo fai con figure irregolari e per una stima di massima, se vuoi affinare la stima a qualche decimale credo non sia il massimo accanirsi ma senza queste prese di posizione forse saremmo ancora al tempo della pietra :-)
Sono d'accordo, non é sicuramente il metodo più efficace né quello che converge più rapidamente, ma ormai mi ha preso e voglio vedere se almeno é possibile arrivare a un errore di non più di una parte su un miliardo. Tieni conto che se si potessero generare effettivamente dei numeri reali e quindi dei veri punti 0-dimensionali ( e non dei numeri su una macchina con una precisione finita che quindi corrispondono a dei rettangolini, un po' come l'impronta di una freccia fisica su un bersaglio) non potrebbe succedere certo di generare milioni di punti uguali La parte che mi intriga di più é proprio quella della generazione pseudocasuale dei numeri, che é tutt'altro che scontata quando si tenta di parallelizzare la procedura (ad esempio, quattro sequenze di numeri casuali generati da 4 thread paralleli mantengono le stesse proprietá statistiche di un'unica sequenza di numeri casuali? Non é scontato, bisogna vedere come é implementata la funzione random che si utilizza). D'altronde in un forum dedicato al bitcoin un po' di curiosità per le sequenze stocastiche e le loro proprietà ci sta bene. |
|
|
|
Python è un linguaggio molto versatile e può essere considerato sia interpretato che compilato allo stesso tempo, visto che in esecuzione genera automaticamente il bytecode come qualsiasi altro compilato. Riguardo il parallelo basta aggiungere una manciata di codice e sei apposto. FaSan EDIT : ho fatto un piccolo test su una macchina virtuale, ed ho ottenuto il risultato PI con 1miliardo di punti in 8 minuti, sfruttando una singola cpu (virtualizzata). Dopo cena ho un pò più di tempo e ci applico il multithread, vediamo come và Con la mia cpu Core2 Duo P8700 e programma compilato con free pascal riesco a fare 1 miliardo di punti in poco più di 1 minuto, pensando di portare il programma su altri pc più potenti e con più core la strada migliore mi sembra proprio il multithread. Grazie a tutti per l'aiuto! EDIT: se qualcuno vuole provare il mio programmino è questo https://dl.dropboxusercontent.com/u/134071847/Stimapigreco2.exe, è per Windows, basta cliccarci su, inserire il numero di punti (provate 10000000000) dovrebbe impiegarci meno di 10 minuti. Non ci sono virus! |
|
|
|
E fare una griglia di punti al posto del casuale, ti risparmieresti la generazione di numeri casuali che per milioni di punti temo crei alla fine sempre gli stessi. Svolgeresti tantissimi calcoli ripetuti e forse inutili.
Vuoi mettere la sensazione di lanciare tante freccette contro un bersaglio, contare quante entrano e quante no nel cerchio, e da questa pseudocasualitá simulata ricavare la stima di pigreco?  |
|
|
|
Anch'io in poche righe mi sono scritto un programma che funziona, ma cercavo qualcosa di molto efficiente ( voglio generare migliaia di miliardi di punti) quindi mi serve un programma 1) compilato e non interpretato 2) che sfrutti in parallelo tutti i core della cpu |
|
|
|
(...) Detto in altre parole, prova a far girare il tuo programma con la condizione x*x+y*y=1.0, e dopo 1 miliardo di tentativi guarda quanto vale num_centri... [OT] Qui' ci sono approfondimenti sulle terne pitagoriche interessanti... puoi proporre agli alunni il quesito e rientra anche tutto il discorso della radice di un intero ... ovviamente essendo da 0 a 1 bisogna passare dai numeri Q ma il concetto è quello delle terne pitagoriche ... Ad esempio 0.6^2+0.8^2=1 ... [/OT] Tante belle idee, grazie! |
|
|
|
|
Acquisto da Ghibly, tutto perfetto! Venditore consigliato!
|
|
|
|
Valore esatto Pi greco dopo 1.000.000.000 di cui interi 785.378.829 viene 3.141515316 Questo su un Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz. Diciamo che con 4 thread sono veloce come il tuo singolo circa però, se ad ora vuoi provarlo a farlo comunque girare, avendo tu 8 core, magari qualcosa di meglio di pascal ottieni, ma rimane molto "lento". Allora: a casa ho un portatile con un Intel Core 2 Duo 8700 2.53 Ghz (ha 6 anni), a scuola spero di avere qualcosa di meglio (anche se ovviamente a casa ho più tempo per fare esperimenti). Dai tuoi tempi le prestazioni mi sembrano davvero scarse  , sarà merito anche del compilatore free pascal che dicono siano uno dei migliori quanto a efficienza del codice prodotto. PS.
Dal tuo codice:
if (x*x+y*y<1.0) then num_centri:=num_centri+1;
Ma non dovrebbe esser minore-uguale? Infatti, per dire, il punto (1,0) quindi uno dei vertici, fa come risultato dell'espressione proprio 1 quindi non soddisferebbe la funzione if, ma in realtà fa parte del cerchio essendo sulla circonferenza, no?
Sì, ma non cambierebbe nulla. La probabilità di generare un punto che sta "esattamente" su una circonferenza (quindi sul "contorno" del cerchio) è 0, nel senso che se stai lavorando con misure di superficie (come nel mio caso, aree di cerchi e aree di quadrati), la misura unidimensionale di una circonferenza ha una misura nulla rispetto alle altre. Detto in altre parole, prova a far girare il tuo programma con la condizione x*x+y*y=1.0, e dopo 1 miliardo di tentativi guarda quanto vale num_centri... |
|
|
|
Bella l'idea della pi greco song, te la rubo! ci sono varie interpretazioni ma non ho mai provato effettivamente a suonarla ... a naso tenderei a trasformare il numero in base opportuna per le note musicali prima di suonarlo, se mai ci spostiamo di 3d e ne parliamo, non mi dispiacerebbe fare 4 chiacchiere su pi song .. Ah, io per "pi song" intendevo semplicemente che chiederò agli studenti di provare a comporre loro qualcosa ispirandosi al pi greco, io non mi intendo molto di musica e quindi sulla conversione numeri-note non sarei di grande aiuto. Pitagora l'ha fatto con i poligoni iscritti e circoscritti, forse si potrebbe avvolgere uno spago sui cilindri n volte e si misura la lunghezza dello spago o del filo da pesca se non si allunga troppo o del filo di rame (quello dei trasformatori) ... o ...
Abbiamo pensato anche a quello, ma è davvero sfuggente questa misura "curvilinea"! L'approssimazione migliore la dovremmo trovare facendo oscillare un pendolo molto lungo e invertendo la formula del periodo di oscillazione (il tempo si misura molto più facilmente) http://www.cplusplus.com/reference/cstdlib/rand/... Return Value An integer value between 0 and RAND_MAX. Dove: Maximum value returned by rand This macro expands to an integral constant expression whose value is the maximum value returned by the rand function. This value is library-dependent, but is guaranteed to be at least 32767 on any standard library implementation. Quindi mi sa che alla fine son pochi numeri, vanno fatte delle inizializzazioni e se qualcuno esperto volesse intervenire potrei approfondire volentieri (per imparare!), so che ci sono delle librerie e delle discussioni in merito, se vuoi giocare allora va bene ma se parli di avere parecchie cifre di pi greco allora credo ci voglia un ragionamento serio su tale aspetto altrimenti meglio lasciar perdere (NB: la mia e' una sensazione non una certezza). Questo metodo non converge molto rapidamente, quindi non mi aspetto certo di determinare le prime 30 cifre decimali del pi greco (tra l'altro interverrebbero prima probabilmente anche aspetti di arrotondamento da studiarsi con l'analisi numerica). Il mio obiettivo era 8-10 cifre (un errore di una parte su 10 miliardi non sarebbe affatto male!!), e generando fino a 500 miliardi di punti ho verificato che la stima continua a migliorare fino alla 5^ cifra decimale, quindi al momento mi concentro per aumentare la velocità di elaborazione, dopodichè lascerò girare il programma per un paio di giorni (se non mi si frigge la cpu ) e solo allora potrò verificare se effettivamente il tutto funziona (secondo me per il tipo di precisione che cerco dovrebbe bastare). Sarebbe anche interessante verificare quale sia il limite oltre al quale questa successione di approssimazioni (dati i problemi da te citati sulla funzione random e quelli connessi all'analisi numerica) smetta di convergere a pi greco. |
|
|
|
Bella l'idea della pi greco song, te la rubo! Anche se un po' OT, il mio collega di fisica sta cercando di ideare un esperimento fisico in cui si misura una circonferenza, il suo diametro, e facendo il rapporto si dovrebbe ottenere una stima di pi greco. E' difficilissimo anche ottenere solo 3,14! (causa errori sulle misure) Ovviamente la parte difficile è misurare con precisione una circonferenza (che è curva ), mentre con il calibro si riesce ad avere un'incertezza piccolissima sul diametro. Facendo rotolare molte volte un cilindro lungo un percorso speriamo di minimizzare l'incertezza sull'errore di misura della circonferenza. Per quanto riguarda la generazione di numeri pseudo-casuali, ovviamente l'implementazione di quella funzione è cruciale per una buona stima finale del pi greco. Ad esempio avevo sentito dire che la funzione rand() di excel da questo punto di vista è scarsa (riporto semplicemente delle voci). Ma io mi fido che la funzione "random" del pascal ( o la funzione analoga in c ) sia implementata a dovere, non è possibile controllare tutto! Forse il grado di accuratezza della stima di pi greco potrebbe essere un modo indiretto per stabilire la bontà o meno di una funzione di generazione pseudo-casuale di numeri. Come collegare questo discorso alla generazione delle chiavi pubbliche ( perchè non quelle private? ) dei bitcoin sinceramente non saprei. |
|
|
|
Non avevo capito il grado di complessità su cui volevo andare per quello te lo avevo fatto in PHP al volo.
Per quel che riguarda la velocità il PHP a sto punto non fa al caso tuo, rimane comunque troppo "lento".
Sicuramente per quello che devi fare le GPU sono perfette sfruttando le loro memorie interne e facendo tornare al programma principale direttamente il count.
Perfetto, allora qualcosa ci capisco Tranquillo che non voglio nulla, come detto erano 20 righe di codice... Se no non te lo postavo in chiaro! XD
Molto gentile, certo che è da 1 anno e mezzo che sono nel mondo bitcoin e non sono ancora riuscito ad acquistare/pagare nulla con i bitcoin ! Per quel che riguarda le GPU invece non cambia il programma a seconda delle GPU ma del tipo di librerie che usi.
In particolare sulle GPU nVidia si programma in c usando CUDA, mentre sulle ati usando opencl.
Ma quindi mi confermi che i programmi che girano su nvidia non girano su ati e viceversa? Posso provare nel week end a metterti giù un paio di righe su CUDA ma solo se poi tu hai questa tecnologia. Inoltre nel caso ti darei il sorgente c ma non ti saprei indicare come compilarlo su windows.
Ho a disposizione una nVidia Geforce GT 730, e quindi da questa pagina http://www.nvidia.it/object/geforce-gt-730-it.html#pdpContent=2 deduco che dovrei avere 96 core (o 384, non ho capito quale sia il mio modello) Non lo farei per il compenso ma per divertimento e interesse personale nel programmare con CUDA ma se ci riesco (e non è scontato, non ho molto tempo in questo periodo) poi sul come portarlo su windows sarebbe opera tua!
Io ero partito per fare questo lavoro per la scuola per il pi greco day, poi mi sono appassionato ben più del necessario (per i miei studenti dubito farà molta differenza se riuscirò a determinare una o due cifre decimali esatte in più  ) Ho scelto questo metodo per determinare pi greco perchè mi sembra molto semplice (noi matematici diremmo "elegante"), comprensibile e alla portata di tutti, anche se sono stati sviluppati altri metodi (ad esempio delle serie) che convergono a pi greco molto più rapidamente. Ma l'eleganza (e la possibilità per gli studenti di capire che cosa sta succedendo) vuole la sua parte... Infine mi sono reso conto che l'algoritmo si prestava molto bene per essere parallelizzato, ma le mie competenze informatiche sono quelle che sono... Grazie ancora! |
|
|
|
|
Un paio di osservazioni:
con il mio programmino, per poter ottenere 3,14152, cioè le prime 5 cifre decimali esatte, ho dovuto generare circa 500 miliardi di punti (circa 10 ore di lavoro-macchina)
Secondo i più esperti, parallelizzare il programma e farlo girare su una gpu invece che su una cpu incrementerebbe di molto la velocità? Immagino che in quel caso di sicuro aumenterebbe di molto anche la complessità del programma e si perderebbe inoltre in portabilità (schede video di marca diversa --> diverse implementazioni del programma), giusto?
|
|
|
|
Grazie per le risposte! Ho dato per scontato che mi contattaste prima di mettervi al lavoro, vi avrei dato qualche indicazione più precisa. Mi serve : - il multithread per una questione di ottimizzazione (sul mio portatile il mio programmino fa circa 1 miliardo di iterazioni al secondo) - il tecnico di informatica della scuola in cui lavoro mi ha detto che i processori nella mia scuola sono quad-core, ciascuno con due thread, quindi potenzialmente posso fare un x 8 di incremento di velocità - è importante che il programma gestisca variabile intere e reali molto grandi (devo poter generare anche mille miliardi di punti senza i limiti derivanti da variabili di tipo int o real) - per davvo: penso che per lo scopo che mi prefiggo php non sia adatto perchè interpretato e quindi più lento (correggimi se sbaglio) - per golikcoin: mi serve non solo l'eseguibile ma anche il sorgente per poter poi fare eventualmente anche delle modifiche e con l'occasione imparare poi a capire come funziona il multithread, (NB: il Pascal è il linguaggio che conosco e di cui ho già installato compilatore e ambiente di sviluppo, se mi proponi qualcos'altro tipo C ecc. se mi dai una mano a capire quali software su windows installare per poterlo compilare ) Quindi riassumendo: - ringrazio davvo (inviami un tuo indirizzo e ti invio un piccolo riconoscimento per il lavoro svolto) - chiedo a golikcoin : che linguaggio hai usato? il tuo programma contempla l'uso di variabili molto grandi? Mandami pure l'exe e poi ci mettiamo d'accordo sul compenso. Grazie. PS: il programma mi serve per sabato 14 marzo (mese 3, giorno 14, anno 15 --> 3,1415) giorno del "pi greco day" ! EDIT: per golikcoin: dall'immagine del tuo programma l'algoritmo viene fatto girare 10 volte; a me servirebbe che l'algoritmo girasse anche 1 sola volta, ma che stampasse a video ogni x punti generati la stima parziale di pi greco (per poter così visualizzare il fatto che con il crescere dei punti generati migliora la stima); quindi se ad esempio voglio generare 10 miliardi di punti con una stampa a video della stima ogni miliardo di punti , il programma dovrebbe: - dividere il primo miliardo di punti da generare in 4 (ad esempio) thread da 250 milioni di punti ciascuno - alla fine del primo ciclo aggiornare la variabile comune a tutti i thread: num_centri - stampare la stima parziale di pi greco dopo il primo miliardo di punti - quindi ridividere il secondo miliardo di punti in 4 thread, .... - così fino al 10^ miliardo di punti Ecco il mio programmino:  |
|
|
|
Cerco un programmatore disposto a modificare (o sarebbe meglio dire a riscrivere ) un mio piccolissimo programmino (< 100 righe di codice!). Ovviamente pago in btc. Il programmino in questione non c'entra nulla con il mondo bitcoin, è una semplice implementazione del metodo Monte Carlo per la stima del valore di pi greco. L'idea è molto semplice, il programma genera dei "punti" casuali nel primo quadrante del piano cartesiano (una coppia di variabili pseudo-casuali comprese tra 0 e 1). Tutti questi punti quindi cadono necessariamente in un quadrato immaginario di vertici (0,0),(1,0),(1,1),(0,1). Poi il programma calcola quanti di questi punti cadono anche nel settore circolare (x^2 + y^2 <= 1,x>=0, y>=0). Se genero molti punti, il rapporto tra il numero di punti che cadono nel quarto di cerchio e quelli totali che cadono nel quadrato è all'incirca uguale al rapporto tra le aree delle due figure, cioè pigreco / 4. Qui di seguito l'algoritmo di base del programma (è in Pascal): for i:=1 to num_punti do
begin
x:= random ;
y:= random ;
if (x*x+y*y<1.0) then num_centri:=num_centri+1;
end;
num_centri_reale:=num_centri;
num_punti_reale:=num_punti;
stima_pi_greco:=4.0*num_centri_reale/num_punti_reale;
writeln('');
writeln('Stima di Pi greco dopo ',i,' punti: ', stima_pi_greco:1:9);
pi_greco:=3.1415926535;
writeln('Valore esatto Pi greco: ', pi_greco:1:9);
Il programma di per sè funziona, volevo farne però una versione "multithread"*; non mi intendo affatto di questa tecnica di programmazione e per questo chiedo l'aiuto di qualcuno che se ne intenda. (*Ho dato un'occhiata a questo http://wiki.freepascal.org/Multithreaded_Application_Tutorial e ho capito che non ho il tempo/voglia di studiarmi da solo la cosa). Grazie. |
|
|
|
|
Show Posts
