Primtal igen igen

Så har du opgivet det mål? Ved sådanne ting kan du jo netop kompensere for lagerplads ved at brugere flere udregninger. Netop sien tager jo meget plads, hvor du med en decideret primtalstest for ethvert ulige tal >= 3 ville kunne køre den. Du kan naturligvis også kombinere og fjerne måske alle multipla af 3 og 5 (eller hvad nu), og tjekke resten med en primtalstest.

Hvis du laver sådanne forsøg, ville det være interessant at få lidt resultater samt forsøgsspecifikationer at se :-).

Der er forskellige måder at gøre tingene på, og jeg kender de fleste. Mit største problem lige nu er at finde ud af i hvilken form primtalslisten fylder mindst.

i form af et bitset fylder den 512 MB og derfor er det naturligvis nærliggende at tro at fx. en vector indeholdende alle primtalende vil fylde mindre.

Man kender aldrig de fleste, for det kan man kun udtale sig om, hvis man kender alle måderne :-P.

Ja, eller en hob, binært søgetræ eller hvad nu.

Jeg har lave nogle mindre forbedringer der gør at koden:
1. Ser lidt bedre ud.
2. Listen kan nu udvides ved at stacke bitsetene, har ikke lige regnet ud hvordan, men det kommer nok.

#include <bitset>
#include <vector>
class Prime {
        std::vector<std::bitset<0x10000> > Pv;
    public:
        Prime() {
            std::bitset<0x10000> Pb(3);
            Pb.flip();
            for(unsigned long n = 2; n < 0x100;) {
                for(unsigned long i = 2*n; i < 0x10000; Pb.reset(i), i += n) {}
                for(n++; Pb[n] != 1; n++) {}
            }
            Pv.push_back(Pb);
        }
};

Du kan muligvis også vinde noget ved at erklære variablen i et andet sted således denne erklæring ikke sker for alle n.

Forsøger GCC ikke automatisk at optimere til det? Ellers er det vel bare at smække en -O2 eller -O3 på GCC. Hvis han vel og mærke bruger GCC

Du kan muligvis også vinde noget ved at erklære variablen i et andet sted således denne erklæring ikke sker for alle n.

Intil videre så tror jeg bare at jeg lader det være op til compileren, men god iagtagelse.

Hvad angår de forskellige compilere, så aner jeg faktisk ikke hvad jeg kører med.
Jeg bruger bloodshed dev-c++.

Jeg er ikke inde i GCC optimeringsrutiner - og hvis jeg skulle være det, kunne jeg ikke lave andet; så stort er det :-). Og optimeringer er ret komplekse - og afhænger også af målarkitekturen (optimeringer kan eksempelvis ødelægge kode af, så det ikke kan køre ordentligt på målarkitekturen). Men pointen er, at til sådan nogle småting her, skal man bare smække optimering på så længe det virker, men jeg er nu stadig tilhænger af, at man også selv optimerer koden, hvor man kan :-).

jeg er helt enig. Jeg er stor modstander af "sloppy code", men lige med det her tester jeg bare en metode. Ville det iøvrigt ikke kunne løses ved at lave den static?

Jeps, i første omgang skal det virke, og så kan man forfine efterfølgende.

Så vidt jeg ved, kan du ikke erklære kontrolvariablen for static i en loop-erklæring (scopet for den kontrolvariabel er jo netop kun dette loop). Men jo, jeg ville erklære den i scope 1 (eller hvad nu man kalder det - altså i starten af funktionen/proceduren). Om den skal være static eller ej, kommer an på om funktionen kaldes flere gange - ellers er det ligegyldigt om den er static eller ej. Og konceptuelt har statiske variabler (i forbindelse med metoder) mest nytte ved små funktioner, der kaldes mange gange, og ikke rigtig nogle ved lange (tidsmæssigt) funktioner, der kaldes få gange.