Newsgroup: it.hobby.enigmi
Titolo: [MAT] Fattoriali e potenze

Proviamo a cambiare un po' il genere.
 
Dimostrare che un fattoriale non può mai essere pari ad una potenza maggiore o uguale a 2.
 
In formule:
 
dimostrare che la N!=X^Y
 
non ha soluzioni per Y>1
 
Ciao
GaS


Beh, in effetti c'e almeno una soluzione:
 
0! = 1  (per definizione) ed ovviamente 1^Y =1 per qualsiasi Y, quindi
 
0! = 1^2    e cosi' via....
 
-- 
 
Ciao,
      Gorgo
 

Il giorno martedì 28 ottobre 2014 15:09:14 UTC+1, Gorgo ha scritto:

Lo sapevo che mi perdevo un pezzo nella condizione: in effetti bisogna imporre anche N>1
 
Scusate
 
ciao
GaS
 


Scusa, mi viene un'osservazione OT:
Per alcuni N, N!+1 e' un quadrato perfetto.
La cosa ha un che di cabalistico:
 
4!+1 = 5^2
5!+1 = 11*11 
7!+1 = 71^2
 
Ignoro se oltre a 4,5,7 ci siano altri termini di questa
sequenza da OEIS. :-)
 
Ciao
Livio
 
 

 Lo sapevo che mi perdevo un pezzo nella condizione: in effetti bisogna imporre anche N>1
 
 
e ovviamente con N, X ed Y numeri interi... :-)
 

 non ha soluzioni per Y>1
 
Nel numero X^Y ogni fattore primo compare con esponente multiplo di Y e
quindi strettamente maggiore di 1.
 
Consideriamo ora il piů grande numero primo p minore di N: esso compare
nella fattorizzazione di N! con esponente 1, perché fra p e 2p č sempre
compreso un altro numero primo (postulato di Bertrand).
 
Quindi i due numeri non possono essere uguali.
 
M.
 
-- 
Per rispondermi via e-mail togli l'ovvio.

 Quindi i due numeri non possono essere uguali.
 
Ovviamente dimostrazione impeccabile :-)
 
Ciao ciao
 

 sequenza da OEIS. :-)
 
Rilancio:
2!+2=2^2
3!+3=3^2
5!+5=5^3
 
Tutto questo è un caso?
Noi di Cazzengier crediamo di no...
 
 
Tornando seriamente alla domanda di Livio, la ricerca sui numeri bassi non da ovviamente soluzioni, LZ le avrebbe già trovate ma nel dubbio le ho testate anche io fino a 17.
 
Detto
 
N!+1=X^2
 
ho quindi provato a concentrarmi su numeri "alti" (qualsiasi cosa voglia dire): ovviamente per N>15 N! finisce con una sequenza di 0 e quindi X^2=xxx0...01
 
Questo significa che X deve finire per 1 o per 9 e quindi abbiamo già ridotto la ricerca al 20% dei possibili candidati (poi certo che il 20% di infinito sempre infinito è... :-)
 
Per quanto riguarda i numeri che finiscono con 1 tutti i numero X=ab..y00..01 sono teoricamente candidati.
 
Per i numeri che finiscono per 9 invece le cose non sono così "semplici", per adesso ho individuato le seguenti "classi" di numeri:
 
A)
49
499
4999
49...9
 
B)
99
999
9999
99...9
 
 
Oltre alle due classi infinite A e B ho un possibile candidato che "potrebbe" finire con ....681249 ma non sono sicuro che possa portare veramente a qualcosa...
 
Ciao
GaS


Va a finire che trovare il quarto termine della sequenza intera 
N!+1=X^2 o dimostrare che non esiste e' un problema carino. 
 
In bruteforce, con la calcolatrice di Windows si puo' verificare
fino a N=29 e non esiste. Poi bisogna implementare il calcolo
a interi molto grandi. Gia' 100! ha 158 cifre e 1000! ne ha 2568.
Con un po' di pazienza sono riuscito a farmi dire dalla stessa
calcolatrice che 100.000! ne ha 456.574. 
 
Il rapporto Numero_cifre/N sembra crescere dolcemente.
 
N        Nc/N     Nc/N/log(N)
10       0.7      0.7
100      1.58     0.79
1000     2.57     0.86
10000    3.57     0.89
100000   4.57     0.91
 
... e quel .57 mi fa venire i brividi.  :-)
Vuoi vedere che 1.000.000! ha ca 5.57e6 cifre?
E che Nc/n/log(N) tende a 1 per N->oo ?
 
Ciao
 

 E che Nc/n/log(N) tende a 1 per N->oo ?
 
P.S. Sai che le alterna le cpu? non l'avrei mai detto, forse e' per non
farle friggere ed e' cosa che riguarda il sistema operativo cioe' Linux.
 
-- 
Tanti saluti
 

> E che Nc/n/log(N) tende a 1 per N->oo ?
 
-- 
Tanti saluti
 

 Il numero degli zeri finali lo sai gia'?
 
Sono quasi 3676 righe di 68 zeri finali l'una.
 
-- 
Tanti saluti
 

 Sono quasi 3676 righe di 68 zeri finali l'una.
 
L'ultima, dalla quale in poi son tutti zeri, e' questa:
 
56176505841254400000000000000000000000000000000000000000000000000000\
 
-- 
Tanti saluti
 


--------------------------------------
Bravo! Io, col mio Basic, ci avrei messo una vita e forse piu'. :-)
 
Si' mi interesserebbe avere conferma del numero delle cifre.
Rifacendo i conti di Nc/N dove Nc e' il numero delle cifre di N!:
 
N         Nc/N
10        0.7
100       1.58
1000      2.568
10000     3.5659
100000    4.56574
 
Ora se i tuoi 5.729.406 caratteri sono formattati a righe di 68 car+CR/LF
le cifre potrebbero essere 68/70*5729406=5565709 per cui
 
N         Nc/N
1000000   5.565709
 
con un'impressionante convergenza dei decimali di Nc/N che mi piacerebbe capire.

 piacerebbe capire.
 
Be' non credo che l'approssimazione di Sterling:
n! =~ sqrt(* pi n) (n/e)^n
puo' servirti, perche' la conosci gia' certamente.
 
Allora, il numero, chiamiamolo milionef come il file, ha:
Cifre totali: 5.565.709  (quindi l'hai calcolato esatto)
Zeri finali :   249.998
 
Questo conto delle cifre totali e' garantito, perche' semplicemente do
questo comando:
cat milionef | tr -d '\\ \n' | wc -c
 
Per gli zeri invece ho dovuto far qualcosa a manina, le righe finali
sono risultate cosi':
 
La 3677-ma dalla fine e' questa:
56176505841254400000000000000000000000000000000000000000000000000000\
con 53 zeri.
 
L'ultima, cioe' la 81.849-ma, quest'altra:
000000000000000000000000000000000000000000000
con 45 zeri.
 
In mezzo ci sono 3.675 righe formate ciascuna da 68 zeri, che sono
quindi 249.900 zeri.
 
Aggiungo, per curiosita', che risultano queste frequenze delle cifre:
 
0: 532338 (coi finali sono 782336)
1: 532223
2: 532921
3: 531100
4: 532174
5: 531421
6: 531351
7: 530558
8: 530361
9: 531264
 
-- 
Tanti saluti
 


----------------------------------------------
Calcolo in Basic interpretato in 2 secondi il numero di cifre di 10.000.000!
 
For j = 2 To 10000000
    L = L + Log(j)
Next j
L = L / Log(10)
Nc = Int(L + 1)
 
Infatti il numero delle cifre di N! e' l'arrotondamento per 
eccesso del logaritmo in base dieci di N! il quale logaritmo
e' la sommatoria di Log10(x) per x=2..N
 
Nc(10.000.000!)=65.657.060
 
Fino al miliardo in 3..4 minuti:
 
 N  -  Nc/N
 10 -  .7
 100 -  1.58
 1000 -  2.568
 10000 -  3.566
 100000 -  4.56574
 1000000 -  5.565709
 10000000 -  6.565706
 100000000 -  7.56570557
 1000000000 -  8.565705523
 

 Per alcuni N, N!+1 e' un quadrato perfetto.
 
Questo equivale a dire che N!/4 è il prodotto di due numeri consecutivi.
 
Siccome due numeri consecutivi sono primi fra loro, questo significa in
particolare che i fattori primi di N!/4 si suddividono fra i due numeri
in modo che un dato fattore compaia solo in uno di essi: tutti i 2 da
una parte, i 3 tutti insieme, ecc.
 
Sembra ovvio che non ci siano altri casi oltre a 4, 5, 7, però per il
momento non m'è riuscito di dimostrarlo.


  1000000000 -  8.565705523
 
Allora hai una macchina potentissima, oppure ho sbagliato io la scelta
del calcolo. Da me per trovare Nc di un milione ha impiegato 4 minuti e
28 secondi; per il miliardo ho dato ^C dopo una decina di minuti.
Da me la funzione che ho fatto e' uguale (sembra!) alla tua:
-------------
define logfat(n)
{
logfat=0;
for (j=1; j<=n; j++)
{
logfat = logfat + l(j);
}
return logfat/l(10);
}
------------
dove l() e' la funzione di Bc (dunque ottima) che da' il logaritmo in
base e (quello in base 10 non c'e'). Uguale -dicevo- tranne la storia
dell'intero, perche' in Bc la funzione, corrispondente alla tua Int(),
non mi riesce di trovarla. Comunque e' inessenziale.
 
Mi sa che se provi 1.000.000! ci metti solo un paio di ore al max, non
le mie quasi 10.
 
-- 
Tanti saluti
 


-----------------------
No, ho macchine arcaiche. Un PC del 2006 con Windows XP e
un ancor piu' vecchio Visual Basic 5.0.
Ma lavorando coi logaritmi uso la dimensione delle variabili
di default (doppia precisione?). Per N = 10 milioni deve fare
10 milioni di logaritmi  e 10 milioni di somme, e' ragionevole
che ci metta 2 secondi. (2 decimi di secondo per un milione,
200 secondi per un miliardo).
 
Calcolare il valore completo di 1.000.000! in Basic... non 
saprei neppure da che parte cominciare, salvo comporre variabili 
intere di 6 milioni di cifre con un array di interi e tempi di 
calcolo biblici.
 
 

 200 secondi per un miliardo).
 
Gia', ma vorrei sapere allora perche' da me ci mette tanto. Forse
perche' i log naturali sono piu' lenti, dovrei fare un programma in C
che faccia direttamente quelli decimali.
 
-- 
Tanti saluti
 

 che faccia direttamente quelli decimali.
 
Infatti, con due righe di codice in C, mi da':
 1.000.000.000  8.565706  in circa 40 secondi
10.000.000.000  9.565706  in circa  6 minuti.
 
In C magari si puo' anche velocizzare, io l'ho fatto cosi':
------------
#include <stdio.h>
#include <math.h>
 
double n, tot, j, n_cifre;
 
main()
{
printf("Introdurre n: ");
scanf("%lf", &n);
 
tot=0;
n_cifre=0;
 
for (j=2; j<=n; ++j)
{
tot = tot + log10(j);
}
 
n_cifre = tot/n;
 
printf("\ntot = %lf\n",tot);
printf("\nn_cifre     = %lf\n",n_cifre);
printf("\n");
return 0;
}
--------
 
-- 
Tanti saluti
 

 sequenza da OEIS. :-)
 
Dopo averci pensato un po' senza successo ho chiesto su ism: si tratta
del "problema di Brocard" e la congettura che non ci siano altre
soluzioni non è ancora stata dimostrata.
 
http://en.wikipedia.org/wiki/Brocard's_problem
 



Che bello! Grazie. Da' soddisfazione anche riscoprire qualche cosa! :-)