Si tu penses à RSA pour le cryptage, tu vas être déçu de la lenteur de l'application (à cause du modulo principalement mais aussi de la multiplication)...
On peut grandement accélérer la recherche du chiffre du quotient en faisant une division qui donne une approximation qu'on doit corriger maximum 2 fois (par chiffre).

A 4 ça déborde de l'écran,alors à 20!
Même sur un fichier,10 devrait suffire.
Pole.

Oui mais ce code renvoit TOUT les nb premiers <n. Pas si n est premier.
On peut facilement trouver un nombre premier de 1000 chiffres, mais on est loin de savoir combien il y a de nb premiers jusqu'à 10^1000(record : 4*10^22) et encore plus de les connaître tous (record : 10^16).

phi(n) renvoie le nombre de nombre inférieur à n premier avec n.
Un nombre est premier avec un autre si leur PGCD est 1.
pi(n) renvoie bien le nb de nb premier inférieur à n.

Il faut attendre assez longtemps pour le calcul. J'ai modifié le code pour qu'il affiche tout les 100 lignes. De cette manière, on peut suivre l'éxécution du programme.

Il manque la classe Utilitaire. Est-ce mon java 1.2.2 qui n'a pas cette classe?

J'ai oublié pour la fonction de pochhammer :
on peut aussi s'en passer
une variable mis à 0.5 et à chaque boucle on multiplie par 0.5+k

Je verrais bien le début comme ça :
private double arcsin(double z) {
         int k,i;
         int N = 30; // This number determines the precision, higher it is, higher the precision is.
         double res,tmp1,tmp2,tmp3,facto;
        
         res = 0;
         if (Math.abs(z)<=0.5) {
// = sum(k=0 a n) de (produit de j=0 a k-1 de (0.5+j))*z exp 2k+1) div (k! * k+1)
          tmp2=z;tmp3=1;facto=1;
             for (k=0;k<N;k++) {
                 tmp3 *= 0.5+k;  // tmp3=prod(0.5,k)
                 tmp1 =tmp3*tmp2;
                 tmp1 /= (2*k+1);
                 tmp1 /= facto;
                 tmp2 *= z*z; // c'est le 2*k+1 de la boucle
                 if (k!=0) facto *=k;    // facto=fact(k)            
                 res += tmp1;
             }
         } else if (z>0.5) {

Voilà. Pour la suite change le "tmp2 *= z*z;" en "tmp2 *= z;".
(Je n'ai pas compilé le code, donc il peut y avoir des erreurs)

Juste pour l'optimisation (si tu veux avoir quelques milliers de décimales) :
tmp1 /= fact(k);
tu peux mettre une variable que tu multiplie à chaque fois dans la boucle.
for (i=0;i<k;i++)
     tmp2 *= ((z+1)/2);
même chose

Mais ces améliorations ne servent à rien si tu te sers que de 7 où 16 décimales.
Par contre, pour les BigDecimal, ça peut servir. (Il y a peut être une fonction arcsin dans la bibliothèque de BigDecimal, mais bon)

Ce qui me dégoute, c'est cette page : http://www.enseignement.polytechnique.fr/profs/informatique/Luc.Maranget/IF/qs/main002.html
J'arrive en 10s à factoriser T20 : 5 fois plus lent.
J'arrive en 12s à factoriser T30 : 3 fois plus lent.
J'arrive en 3min30 à factoriser F7 : 7 fois plus lent.
J'arrive en 4min40 à factoriser T40 : 9 fois plus lent.
J'arrive en 11min à factoriser T45 : 5 fois plus lent.
Et je ne vois pas comment optimiser encore plus.

Oui mais je n'ai jamais vu l'intérêt de cette méthode. Ca rapporte à la même procedure, faire un objet BigInteger dedans revient à le mettre en paramètre. Donc inutile de le faire. Autant ne pas se compliquer la vie.