Algoritmi - Comparazione Numeri primi

Detta così sembra che modifichi il codice e poi lanci l'exe senza riicompilare... ma non è così vero?

Ricompilo

comunque domani mattina, appena posso provo pierotofy

In questo modo fai uno spreco massiccio di memoria.

Innanzitutto qui:

stop = ((UInt64)Math.Sqrt(num));

non usare l'operatore di casting, che rallenta il programma, ma usa la classe Convert, metodo ToInt64 in questo modo:

stop = Convert.ToInt64(Math.Sqrt(num));

In secondo luogo memorizzare i numeri in una lista ti è utile solo se crei un metodo che restituisce l'insieme di numeri primi, e non se hai intenzione di scriverli immediatamente a video. Infine è molto più semplice prendere un numero dispari e verificare che non sia multiplo di tutti i numeri da 3 a n-1. Io personalmente continuo ad usare questo:

public static List<int> NumeriPrimi(long nMax) {
    List<int> res = new List<int>(2, 3, 5, 7, 11, 13, 17);
    for (long i = 19; i <= nMax; i += 2) {
        bool primo = true;
        for (long o = 3; o < i; o++) {
            if (i % o == 0) {
                primo = false;
            }
        }
        if (primo) {
            res.Add(i);
        }
    }
    return res;
}
                

Così ho cercato di ottimizzarlo al massimo ma sicuramente ci sono soluzioni migliori. Buona fortuna!!

Uh?

In quale maniera l'operatore di casting rallenterebbe il programma rispetto all'invocazione di un metodo di conversione?

@nessuno:
Il tuo sistema può essere usato solo se hai una lista finita di numeri, io non voglio che questo abbia un limite.
Il programma com cui ho comparato, comunque, ha lo stesso funzionamento del mio.


@tuttodiMC
Non sapevo che l'operatore di casting rallentasse così rispetto al convert. Grazie
Per quanto riguarda la memorizzazione la uso perché così posso usare i numeri che ho trovato per controllare quelli successivi;
evitando così di usare i numeri non primi come possibili divisori.
Forse però se la memorizzazione toglie molto tempo conviene controllarli tutti indifferentemente...

Il limite lo hai naturalmente in ogni codice (il tuo, il mio ... non importa) ed è determinato dal tipo di dato usato.



Eh? In che senso? Hai solamente contato il numero di linee? Boh ...

Il limite è il tipo di dato e la memoria a disposizione, quindi perché aggiungerne un altro?

"Il programma com cui ho comparato, comunque, ha lo stesso funzionamento del mio."

Mi spiace se non mi sono spiegato bene. Intendevo dire che entrambi i programmi partono
da un numero e stampano a video i numeri primi che trovano (e contemporaneamente li scrivono su file).
Sono quindi 2 programmi equivalenti.

Forse non mi spiego bene ... è lo *stesso limite* di cui stiamo parlando ... se assegni a n il valore massimo del tipo di dato che utilizzi, hai lo stesso limite nei due codici ...



No ... due programmi *non sono equivalenti* solo per il risultato che conseguono.
Esistono programmi con migliaia di linee e che vengono eseguiti in tempi biblici e programmi molto corti che vengono eseguiti molto più velocemente. Solo a parità di linee di codice e di tempo potrai parlare di "programmi equivalenti".

Il concetto è semplice ... perché "riscopri l'acqua calda"? Gli algoritmi (e anche i codici che li implementano) per l'individuazione dei numeri primi sono arcinoti e c'è stata tanta gente che ci ha sbattuto la testa. Che senso ha scrivere "altro codice" che peggiora quelli esistenti?