Den stora tråden för snabba nybörjarfrågor[Java]

Du kör en for-loop 6*10^11 gånger.

Om varje varv tar

En nanosekund så tar det 10 minuter

En microsekund så tar det 7 dagar

En millisekund så tar det 19 år

Grejen med project Euler problemen är att i stort sett alla har en uppenbar brute-froce-lösning a la den du postade. Men för stora tal (som indata till detta problem) så funkar de inte då de tar för lång tid.

Algoritmen LoveShy postade är väldigt snabb och funkar bra. Testa att göra några exempel för hand med mindre tal för att förstå hur den fungerar.

Jag kanske ska tillägga att jag inte skrivit den. Intressant hur den fungerar dock. För varje delare den hittar så delar den talet man testar med delaren och sedan testar mot det nya talet. Det gör att antal tester sjunker avsevärt och därmed ökar även hastigheten av testet.

Tack för svaren! Bör man undvika att göra brute-force-lösningar generellt?

Med ett program som bara ska köras en gång, beror det väl på hur mycket tid man vill lägga på programmeringen jämfört med körtiden. Kan jag skriva två enkla for-loopar och låta datorn stå och jobba under natten, gör jag hellre det än läser en timme på Wikipedia och kodar avancerade datastrukturer i två. Men jag har inte lärt mig något, och det kan ju ha varit tanken med projektet, inte resultatet.

Håller med JagHarIngaKompisar helt där.

Är det vettigt att lösa project euler uppgifter för att lära sig programmera på en bra nivå? Eller bör man satsa på något annat? Jag läser ett IT inriktat program så jag får ju en del därifrån också men jag känner att det är för lite att endast programmera på skolan. Tack på förhand

Jag har aldrig gjort något sådant överhuvudtaget. Det viktiga är istället att programmera, och fortsätta programmera, programmera nya saker, lära sig nya saker, implementera dessa i ett eget projekt, fortsätta programmera, lära mer, implementera, osv. Att du kan lösa en sak efter att ha spenderat två veckor på att optimera en for-loop.. inte värt mycket ifall du inte just ska arbeta med just det, och det kommer du inte att göra imorgon precis...

Så kort, hitta något roligt projekt som du kan göra, gärna något som kan byggas på under tiden du lär dig nya saker. Finns mängder av sidor som listar olika typer av projekt utefter vad man lär sig, vad man behöver kunna, osv.

Man lär sig i princip bara matematik av det. De första 10 problemen är väl intressanta och ungefär vad man ger någon på en anställningsintervju. Sen blir det primtal för hela slanten.

Hur man organiserar större program, testande av kod, m.m. kan du leta i stjärnorna efter. Men kul och lärorikt att läsa andras kod, i andra språk.

En del problem går t.o.m. att lösa med penna och papper, så ja, det är matematiskt inriktat. Sen dyker det såklart upp ett intressant problem då och då.

Håller med Gottisborgen här. Som vanlig utvecklare kommer du ytterst sällan (om ens någonsin) behöva fundera på något som liknar project Euler-problemen.

Däremot är de vettiga om du vill träna på din problemlösningsförmåga och fördjupa/repetera dina matematikkunskaper.

Tack för era svar! Jag läste till mig ett basicprojekt kan vara t.ex. en miniräknare. Så jag tänkte ge mig på det och fixa ett GUI till. Då kommer nästa fråga, hur vanligt är det att man jobbar med GUI som programmerare?

Tänk dig att du vill jobba med trä, vad finns det för typer av jobb när du vill jobba med trä? En helt del, eller hur? Bygga hus? Riva hus? Bygga nya möbler, renovera gamla? Tiotals, om inte hundratals olika typer av jobb...
Precis så är det o jobba som programmerare, det rymmer så ofantligt många olika typer av programmerare. Vill du inte jobba med GUI så finns det femtioelvatusen andra jobb som inte innefattar det.

Själv som konsult var mitt första jobb utan någon som helst gui, mitt andra var att refaktorera ett program och fixa om byggmiljön till att fungera med en nyare utvecklingsmiljö + kompilator, det tredje var att bygga ett gui över ett testramverk, sen en blandning av allt och mycket göra egna verktyg från scratch och minimalt med gui för att testare ska använda programmen. Är helt och hållet handikappad när det kommer till design o sådant, men det fungerar...

Att designa ett snyggt GUI, göra det användarvänligt, och programmera logiken bakom, är väl egentligen tre helt skilda konstformer.