Newsgroup: it.discussioni.misteri
Titolo: siamo fottuti!

[~/superpollo]$ echo "2^2012" | bc | grep "666"
38606663148805556877255952409681585954671161292647520039399263695074\
[~/superpollo]$
 
;-)
 
bye
 
-- 
La Tunze non e' una ipotesi campata in aria.
La Tunze e' una Realta' Evidente.
Socratis.

 bye
 
Nemmeno troppo, questo:
 
echo "2^2001" | bc | grep "666"
 
solo 2003, 2009,2010,2011 fanno eccezione e poi tutti fino al 2019. 
Attenzione al 2021, però.
 
 

Tetis ha scritto:

e il 2285? che te ne pare? :-O
 
[~/superpollo]$ echo "2^2285" | bc | grep -c "666"
4
[~/superpollo]$
 
O_o bye


 e il 2285? che te ne pare? :-O
 
Ehh, capperi. 5 occorrenze. Hai provato andando indietro nel passato?


 Ehh, capperi. 5 occorrenze. Hai provato andando indietro nel passato?
 
4 a dire il vero...
 
nel passato e nel futuro, dall'anno 1 all'anno 5000
 
 
[~/superpollo]$ head beast
1: 0
2: 0
3: 0
4: 0
5: 0
6: 0
7: 0
8: 0
9: 0
10: 0
[~/superpollo]$ tail beast
4991: 1
4992: 0
4993: 2
4994: 0
4995: 3
4996: 0
4997: 2
4998: 0
4999: 1
5000: 0
[~/superpollo]$ for N in 1 2 3 4 5 6 ; do cat beast | grep -c "$N$" ; done
1490
511
169
21
9
2
[~/superpollo]$
 
 
and the winner is...
 
 
[~/superpollo]$ cat beast | grep "6$"
4254: 6
4927: 6
[~/superpollo]$
 
 
O_o bye
 
-- 
La Tunze, in realta' non fa altro che svincolare 1
dal suo essere neutro.
Questo tipo di Tunze ante-litteram era usata dai Maya

 4 a dire il vero...
 
hai ragione , eran 5... ignorate il post precedente.


 [~/superpollo]$
 
 
cio� hai cercato le occorrenze della stringa 666?
 
ma dove le hai cercate?
 
non conosco bene il comando grep..
 
Grazie ciao 
 
 

 4 a dire il vero...
 
5, confermo, sulla terza riga ce ne sono due ti. grep trova 4 righe 
perchè cerca per righe le occorrenze senza preoccuparsi delle 
ripetizioni, avresti inoltre un problema con i risultati spezzati su 
due righe. Se però fai come faccio io:
 
echo 2^^^^2285 | bc  > res
vim res
?666
trovi tutte le occorrenze ma non risolvi ancora il problema 
dell'eventualità di triplette spezzate  su righe diverse. Per quello 
occorre eliminare i ritorni carrello usando sed.
 
echo 2^^^^2285 | bc | sed s/\\//g | tr '\n' 'k'|sed /k//g
vim res
?666
 
naturalmente per avere un contatore di occorrenze puoi scrivere uno 
script più elaborato:
 
echo 2^^^^2285 | bc | sed s/\\//g | tr '\n' 'z'|sed /z//g | sed 
/666/portici\n/g | grep 666 | wc -l
 
che dopo avere eliminato i caratteri \ ed avere trasformato i ritorni 
carrello in z e dopo avere eliminato le lettere z sostituisca le 
occorrenze di 666 con portici seguito da un ritorno carrello. Adesso 
applicando e mandandolo a wc -l trovi le occorrenze corrette: a me 
risulta 5 in questo modo.
 
La sintassi dopo echo è così perché echo in dos mette le virgolette e 
sopprime un carattere ^ ogni 2. il pipe su bc ne sopprime un altro e 
quindi in questo modo il bc riceve esattamente 2^2285.
 
Ti chiederai perchè ho sostituito 666 con portici. Beh, perchè 666, se 
non le contate male, sono le volte a crociera (curve quartiche 
intersezioni di due cilindri) dei portici che coprono la scalinata che 
a Bologna conduce da Via Saragoza incrocio con via Meloncello e via De 
Coubertin al Santuario di San Luca.

Riprova un poco perché a me risulta che in 4927 ci siano 7 occorrenze. 
Mentre in 4254 hai avuto fortuna e sono effettivamente 6.
 
 

 /666/portici\n/g | grep 666 | wc -l
 
type naturalmente l'ultimo è grep portici:
 
echo 2^^^^2285 | bc | sed s/\\//g | tr '\n' 'z'|sed /z//g | sed
 /666/portici\n/g | grep portici | wc -l
 
 

Tetis ha scritto:

tetis, l'ulimo polimata :-)


 echo 2^^^^2285 | bc | sed s/\\//g | tr '\n' 'k'|sed /k//g
 
 
Piu' semplicemente puoi usare la variabile di ambiente
BC_LINE_LENGTH
 
es.
export BC_LINE_LENGTH=2000000000
echo 2^2285 | bc | sed "{s/666/portici\n/g}" | grep -c portici
 
Giorgio

 > ;-)
 
Guarda che il numero in questione non e' il 666 ma il 616
(contrariamente all'opinione comune).

 O_o bye
 
In conclusione, tenendo conto delle correzioni all'output fatte come 
suggerisce Giorgio in ambiente linux, oppure con il seguente script in 
Windows + Unix_cmd trovo:
 
for /l %i in (1,1,5000) do echo 2^^^^%i|bc|sed s/\\//g|tr '\n' 'z'|sed 
s/z//g|sed s/666/portici\n/g|grep -c portici >> portici
 
gawk '{ print FNR ". " $0;}' portici > portici_numbered
 
for /l %i in (1,1,10) do grep -c ". "%i portici_numbered
 
1:1482
2:525
3:192
4:38
5:11
6:4
7:1
 
ed infine:
 
grep  ". 7" portici_numbered
 
4927. 7
 
4927 = 13 x 379
 
nessuna delle potenze dei due fattori contiene il 666 :-)
 
La lunghezza di riga usata di default da bc spezza il numero in modo da 
falsare il risultato in diversi casi:
 
844,1075,1539,1541,1722,1758,1760,1762,1837,1839,2015,2118,2120,2138,2157,2186 
(in questo caso le occorrenze sono due entrambe compaiono 
spezzate),2274,2276,2278,2324,2326,2330, e via via sempre più spesso 
man mano che cresce la lunghezza delle potenze binarie considerate.
 
C'è un ulteriore errore sistematico in quest'analisi che consiste nella 
possibilità che nel numero compaiano sequenze del tipo 6666 o più 
lunghe. Secondo che si decida di contarle come un unico 666 o come una 
doppia occorrenza si ottengono risultati differenti. Il caso 4927 
rientra proprio in questa categoria in quanto occorre una volta 6666. 
Quindi le occorrenze del 666 risultano 7 se 6666 conta 1 volta oppure 8 
se conta 2 oppure 6 se non conta affatto. Il 6666 ricorre inoltre due 
volte nei numeri: 1862,1885,1887,1889, (sequenza particolarmente 
curiosa proporrei di andare a vedere cosa succedeva in quegli anni 
tutti nai primi anni della storia dell'Italia unita :-) )) e poi ancora 
ricorrerà due volte in 
2698,2816,3173,3175,3177,3213,3787,3873,3979,4039,4041,1056,4058,4105,4132,4134,4654,4870,4886
 
La sequenza 66666 ricorre in: 
220,838,840,869,1887,1889,2269,2271,2273,2275,2812,2866,2868,2870,2872,2874,2952,2954,2956,2958 
(altro cluster molto notevole 
quest'ultimo),3122,3124,3171,3173,3175,3189,3577,3648,3650,3729,3965,3976,4134,4584,4686,4868,4929.
 
La sequenza 666666 (che naturalmente porta ad un conteggio doppio del 
666 con il metodo che ho usato) compare in 
2269,2271,2868,2870,2954,2956
 
Sequenze di 7 volte 6 non compaiono mai in questo intervallo fino al 
5000.
 
Nello stesso intervallo di sequenze più lunghe non ne compaiono. Questi 
risultati possono essere molto naturalmente usati per correggere i 
conteggi secondo le regole che si decidano.
 
 

 lunghe.
 
ah: il famoso "banana phenomenon" (berlusconi non c'entra):
 
http://www.inwap.com/pdp10/hbaker/hakmem/algorithms.html#item176
 


 bye
 
Interessante anche l'item 28: ho usato bc ed un programma on line che 
si trova qui:
 
http://www.numberempire.com/numberfactorizer.php
 
 
per fattorizzare il 125° numero di Mersenne in poco meno di 5 secondi, 
il tempo di fare il copia incolla da bc alla barra di fattorizzazione e 
fare return, ma ci si impiega certamente meno, il risultato è:
 
2^125-1= 42535295865117307932921825928971026431 =
=31*601*1801*269089806001*4710883168879506001
 
in pieno accordo con il risultato del 1975, ottenuto in 371 secondi.
 
 
31 * 601 * 1801 * 269,089,806,001 * 4,710,883,168,879,506,001.
 
Stessa sorte per 2^137-1:
 
Number 174224571863520493293247799005065324265471
Factorization: 32,032,215,596,496,435,569*5,439,042,183,600,204,290,159
 
fattorizzato la prima volta il 9 luglio 1971 in cinquanta ore.
 
Comunque:
 
2^127-1 è primo:
Number 170,141,183,460,469,231,731,687,303,715,884,105,727
Factorization: 170,141,183,460,469,231,731,687,303,715,884,105,727
 
Il che però era noto già nel 10 Gennaio del 1876, come aveva scoperto 
Lucas.
 
Fattorizzare il primo di Mersenne immediatamente successivo, che ha 
richiesto quasi altri 120 anni per essere trovato, non si può con il 
programmino on-line di quel link, lo fattorizzo forse facilmente in 
python, dovresti senz'altro averne una implementazione nella tua 
distribuzione linux, un codice è questo:
 
http://blog.dhananjaynene.com/2009/01/2009-is-not-a-prime-number-a-python-program-to-compute-factors/
 
 
comunque in remoto, usando Sage riesco a verificare in qualche minuto 
che 2^2203-1, bestiola da più di 660 cifre,  sedicesimo numero di 
Mersenne è primo. La cosa mi ha alquanto sbalordito tenendo conto che 
la fattorizzazione di una chiave RSA il 12 dicembre del 2009 aveva 
richiesto uno sforzo coordinato di due anni da parte di diversi 
laboratori di calcolo.
 
Per il 18° 2^3217-1 ho cominciato circa alla 15.53 mentre scrivevo 
questa mail ed alle 16.00 l'esito è stato che i fattori di 2^3217-1 
sono:
 
259117086013202627776246767922441530941818887553125427303974923161874019
266586362086201209516800483406550695241733194177441689509238807017410377
709597512042313066624082916353517952311186154862265604547691127595848775
610568757931191017711408826252153849035830401185072116424747461823031471
398340229288074545677907941037288235820705892351068433882986888616658650
280927692080339605869308790500409503709875902119018371991620994002568935
113136548829739112656797303241986517250116412703509705427773477972349821
676443446668383119322540099648994051790241624056519054483690809616061625
743042361721863339415852426431208737266591962061753535748892894599629195
183082621860853400937932839420261866586142503251450773096274235376822938
649407127700846077124211823080804139298087057504713825264571448379371125
032081826126566649084251699453951887789613650248405739378594599444335231
188280123660406262468609212150349937584782292237144339628858485938215738
821232393687046160677362909315071
 
cioè il numero stesso.
 
Sarebbe carino scrivere un comando di fattorizzazione efficiente per 
bc?