De Devschuur Coffee Corner

[Verwijderd]

YopY schreef op donderdag 21 januari 2010 @ 16:52:
[...]


En je denkt dat ik dat begrijp?

Ik weet niet hoe serieus je dit bedoeld, maar de kunst is gewoon jezelf niet laten verblinden door tekentjes.
Zoals ik al eerder heb gezegd, zo'n Sigma of Pi is bijvoorbeeld niets anders dan de wiskundige notatie van een for-loop
Deel het probleem op in kleine probleempjes (komt je misschien bekend voor van een stukje toegepaste wiskunde waar je je mee bezighoudt => informatica & programmeren).
Invullen van variabelen schept vaak ook een hoop duidelijkheid en maakt dingen makkelijker te onthouden (althans voor mij werkt het).
Zomaar een voorbeeldje:

10² = 100
10 = ²√(100)
2 = ¹⁰log 100

4³ = 64
4 = ³√(64)
3 = ⁴log 64

In mijn belevingswereld kun je zo heel gemakkelijk regeltjes onthouden. Ik vind het makkelijker om zo tot de algemene regels te komen/ze te onthouden:

ⁿ√b = a
^alog b = n
aⁿ = b

Verder is wiskunde echt een oefenvak. Ik geloof best dat er mensen beter of slechter (zoals ik) in zijn, maar ik weet zeker dat iedereen met een beetje drive écht wel wiskunde kan leren.

[ Voor 6% gewijzigd door Verwijderd op 21-01-2010 18:13 ]

[Haan]

Snake schreef op donderdag 21 januari 2010 @ 16:23:
Ik moet in het kader van een nieuwe opdracht gaan werken met Visual Studio 2005, VB.NET (delen in C#) en SourceSafe.

Am I fucked?

[EdwinG]

YopY schreef op donderdag 21 januari 2010 @ 15:47:

Over geschiedenis gesproken, Euler 5.

"..."

Men ontdekt priemgetallen - in bovenstaande loop hoef je 4, 6, 8, 9, 10, 12, 14, 15, 16 en 18 niet te controleren, omdat die al deelbaar zijn door lagere getallen (2, 3, etc).

Dat gaat precies niet goed werken. Dat een getal deelbaar is door 3 betekent niet dat het ook deelbaar is door 9. Andersom wel.
De beste manier om hier de oplossing te vinden is om de cijfers 1 t/m 20 te ontbinden in factoren, daar de dubbelen* uit te schrappen, en die vervolgens met elkaar te vermenigvuldigen.

* Dubbel als in 'komt voor in meerdere cijfers', niet 'komt meerdere keren voor in 1 cijfer'

Overigens: euler 5 link

[ Voor 17% gewijzigd door EdwinG op 21-01-2010 19:11 . Reden: Opmerking over 'break' weggehaald, niet goed gekeken ]

[.oisyn]

EdwinG schreef op donderdag 21 januari 2010 @ 19:08:
De beste manier om hier de oplossing te vinden is om de cijfers 1 t/m 20 te ontbinden in factoren, daar de dubbelen* uit te schrappen, en die vervolgens met elkaar te vermenigvuldigen.

Dat ontbinden in factoren is een beetje onhandig. Je kunt beter gewoon met de priemgetallen beginnen, en elk priemgetal net zo lang met zichzelf vermenigvuldigen tot het groter wordt dan 20, en dan het product nemen van al die getallen. En dan zie je ook meteen het antwoord al, want bij 5 is 5*5 al teveel, dus het antwoord is 2⁴ * 3² * 5 * 7 * 11 * 13 * 17 * 19.

In plaats van blijven vermenigvuldigen zou je ook floor(_xlog 20) kunnen nemen. En goh, dan lijkt het wel erg veel op dat stukje code dat YopY postte

.edit: mijn Kol Q l8or 2 oplossing:

code:

isprime(x) := x>1 & (x==2 | apply(i:2..ceil(sqrt(x)),r:1,r&(x%i!=0)))
smallestmultiple(x) := apply(i:2..x,r:1,r*if(isprime(i),i**floor(log(x)/log(i)),1))
smallestmultiple(20)
> 232792560

[ Voor 21% gewijzigd door .oisyn op 21-01-2010 21:19 ]

[Soultaker]

Wat het makkelijkste of het beste is, is natuurlijk zeer discutabel bij dit soort simpele problemen.

Ik zou zelf zeggen dat 't eenvoudiger is om de gevraagde berekening direct uit te voeren.

Haskell:

foldr1 lcm [1..20]

Als je in een taal werkt waarin je geen lowest common multiple functie hebt, kun je die ook nog eenvoudig definiëren, bijvoorbeeld:

Haskell:

gcd a 0 = a
gcd a b = gcd b (mod a b)
lcm a b = div (a*b) (gcd a b)

Dit werkt in principe in iedere taal, maar pas op dat de berekening van lowest common multiple op deze manier kan overflowen als een 32-bits integer gebruikt wordt voor de tussenresultaten.

Overigens kan het probleem in APL opgelost worden in slechts vijf karakters: ∧/⍳20 Niet echt een kunst, maar wel grappig dat 't kan.

[RayNbow]

Soultaker schreef op donderdag 21 januari 2010 @ 22:33:
Wat het makkelijkste of het beste is, is natuurlijk zeer discutabel bij dit soort simpele problemen.

Ik zou zelf zeggen dat 't eenvoudiger is om de gevraagde berekening direct uit te voeren.

Haskell:

foldr1 lcm [1..20]

Waarom geen left fold?

(of nog beter: een stricte left fold)

[Soultaker]

No reason. Left fold werkt net zo goed. Efficiëntie was niet van groot belang voor twintig getallen, natuurlijk.

Heeft Haskell überhaupt strictness typing? Ik dacht van niet, maar ik ken Haskell eigenlijk niet zo goed. Sowieso is een left fold natuurlijk al efficiënter vanwege de tail recursion.

[RayNbow]

Haskell heeft geen strictness typing, maar je hebt wel o.a. de seq primitive:

Haskell:

seq _|_ b = _|_
seq a   b = b     -- if a /= _|_

(_|_ = ASCII versie van ⊥, i.e. bottom)

De Data.List module bevat stricte left folds die gebruik maken van seq:

Haskell:

foldl1' :: (a -> a -> a) -> [a] -> a
foldl1' f (x:xs) =  foldl' f x xs

foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' f a []     = a
foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs

[Haan]

* Haan begint een beetje af te haken bij de laatste pagina's

[mithras]

Tja, die wiskunde is allemaal wel te snappen, maar dat programeren... Kol Q l8or 2, Haskell? God, dat doe je niet toch voor je lol?

* mithras rent

[Vincentio]

mithras schreef op vrijdag 22 januari 2010 @ 09:49:
Tja, die wiskunde is allemaal wel te snappen, maar dat programeren... Kol Q l8or 2, Haskell? God, dat doe je niet toch voor je lol?

* mithras rent

Haskell is nu eenmaal verplicht bij technische informatica op de TU Delft.

[Amras]

Vincentio schreef op vrijdag 22 januari 2010 @ 10:08:
[...]
Haskell is nu eenmaal verplicht bij technische informatica op de TU Delft.

Heb het gevolgd en volbracht, maar het is nu wel aardig weggezakt. Als ik zo'n stukje Haskell voorbij zie komen dan kan ik nog wel beredeneren wat het ongeveer doet, maar zelf even iets bakken dat wordt lastig. Moet zeggen dat de lambda calculus practicumopdracht behoorlijk pittig was, al weet ik niet of die nu nog gegeven wordt.

[Haan]

Net trouwens tegen een leuke javascript 'feature' aangelopen. Ik haalde via xmlHttpRequest een lijst met persoonsgegevens op en liep met een for loopje door de nodes (for (var i = 0; i < persons.length; i++) etc. ) niet zo heel spannend. Alleen bleek na de eerste iteratie waarde van i opeens 15 te zijn in plaats van de verwachte waarde 1

Blijk ik een functie aan te roepen waarin door een set attributen gelopen wordt, met deze loop: for (i = 0; i< attributes.length; i++)

Heb ik dus per ongeluk een globale variable 'i' gedefinieerd die de lokale 'i' overschrijft

[RayNbow]

Amras schreef op vrijdag 22 januari 2010 @ 10:10:
Moet zeggen dat de lambda calculus practicumopdracht behoorlijk pittig was, al weet ik niet of die nu nog gegeven wordt.

Ik kan zelf geen LC practicumopdracht herinneren van het vak IN2320 Programmeertalen (versie 2004/2005). Er waren wel een aantal colleges over semantiek en LC, waarvan je de stof moest kennen voor het tentamen.

Nu wordt de lambda calculus niet meer gegeven in Delft. Het oude vak IN2320 is aangepast en heet nu IN1605_III (gegeven in het 4e kwartaal).

mithras schreef op vrijdag 22 januari 2010 @ 09:49:
[...]Haskell? God, dat doe je niet toch voor je lol?

Tuurlijk wel

[ Voor 13% gewijzigd door RayNbow op 22-01-2010 10:49 ]

[Amras]

RayNbow schreef op vrijdag 22 januari 2010 @ 10:47:
[...]

Ik kan zelf geen LC practicumopdracht herinneren van het vak IN2320 Programmeertalen (versie 2004/2005). Er waren wel een aantal colleges over semantiek en LC, waarvan je de stof moest kennen voor het tentamen.

Nu wordt de lambda calculus niet meer gegeven in Delft. Het oude vak IN2320 is aangepast en heet nu IN1605_III (gegeven in het 4e kwartaal).

Die opdracht heb ik wel gehad bij dat vak, maar ik denk dat ik het één of twee jaar eerder heb gevolgd dan jij.

[YopY]

Verwijderd schreef op donderdag 21 januari 2010 @ 17:11:
asm?

pff, ASM is makkelijk, is gewoon een soort ZZT-OOP, . Of Befunge in 1 dimensie. Overigens is Befunge niet eens zo gek lastig (ook al was dat wel de bedoeling van de schrijver), heb gister de wiki pagina eens goed gelezen.

En ik ben heel snel geintimideerd door wiskundige notatie, . Te lui om het goed te bekijken / proberen te begrijpen, houden we het maar op. Ik zal de adviezen later eens goed bekijken / lezen (daar ik nu 'aan het werk' ben). Of misschien printen en in de trein bekijken.

[user109731]

Ik vind Haskell best leuk en mooi, maar vooral voor wiskundige algoritmes. Misschien een vooroordeel, maar zodra je een real-world iets wil maken krijg je met monads te maken en daar wordt de code imho niet mooier van. Ik snap wel hoe ze werken en waarom ze bestaan, maar misschien moet ik het gewoon vaker gebruiken en ga ik het dan waarderen...

Dit heb ik nog meer bij Prolog. Hele leuke manier van werken, maar wil je echte IO gaan doen dan krijg je te maken met allerlei obscure predicaten die ook nog eens per implementatie verschillen. En sommige predicaten beginnen te tellen bij 0 en anderen bij 1. Het idee is goed, maar de standaard predicaten lijken soms wat vreemd ontworpen. Weet iemand toevallig een Prolog-dialect die deze problemen niet heeft?

[Dr.Bob]

Hmmm ik kom er niet uit, weet iemand wat de volgende functie doet en waarom?

code:

function f(i)
{
    if(i == 0)
        return true;
    return !(f(i-1));
}

[ Voor 14% gewijzigd door Dr.Bob op 23-01-2010 10:37 ]

[TJHeuvel]

Waar het dan op lijkt is dat hij even getallen checked, op een nogal omslachtige manier.

code:

function f(i)
{
    if(i == 0)
        return true;
    return !(f(i-1));
}

[ Voor 13% gewijzigd door TJHeuvel op 22-01-2010 14:40 ]

[pedorus]

Niet compileren omdat If met een hoofdletter staat? Anders traag testen of iets even is, evt met overflow.

Had iets beters verwacht.

[Bob]

testen of het getal even is gok ik?
huiswerk?

[Dr.Bob]

Nee, zeker geen huiswerk. Collega hier zit een beetje de wiseguy uit te hangen met dit soort maffe shizzle, maar ik heb geen flauw idee wat het is. Dus wil hem met een slim antwoord van jullie om de oren slaan :-)

[Amras]

Dr.Bob schreef op vrijdag 22 januari 2010 @ 14:43:
Nee, zeker geen huiswerk. Collega hier zit een beetje de wiseguy uit te hangen met dit soort maffe shizzle, maar ik heb geen flauw idee wat het is. Dus wil hem met een slim antwoord van jullie om de oren slaan :-)

Haha, dus je gaat even patsen met de kennis van de mensen hier.

Verwijs je hem dan wel door naar dit topic?

[Bob]

Wiseguy met zo'n code? Meest debiele code die ik ooit heb gezien om te testen of iets even is. Da's nu toch echt wel het enige dat die method doet? Buiten idd stack overflow geven voor een int van een degelijke grootte.

[Reptile209]

Die kan je uit je hoofd nog wel volgen:
f(0) => true
f(1) => !f(0) => false
f(2) => !f(1) => !f(0) => true
f(3) => !f(2) => !f(1) => !f(0) =>false
see the pattern?

[Dr.Bob]

Haha, dus je gaat even patsen met de kennis van de mensen hier.

Als het even kan wel ja
Zolang het uitdagend genoeg is voor iemand hier die zo zijn grenzeloze kennis en inzicht kan demonstreren, zeg ik: win-win situatie

[Matis]

Het is een veredelde even-oneven flipflop tot 0, zoals Reptile209 al aangeeft.

[ Voor 8% gewijzigd door Matis op 22-01-2010 14:52 ]

[Amras]

Dr.Bob schreef op vrijdag 22 januari 2010 @ 14:51:
[...]
Als het even kan wel ja
Zolang het uitdagend genoeg is voor iemand hier die zo zijn grenzeloze kennis en inzicht kan demonstreren, zeg ik: win-win situatie

Niet lullig bedoeld hoor, maar met een beetje inzet moet je zelf toch wel kunnen zien wat de code doet. Stop er simpelweg wat waarden in (zoals hierboven gebeurt) en kijk wat er uitkomt. Je doet een beetje alsof dit stukje code rocket science is.

[Haan]

Toch maar even aan die collega vragen wat er mis is met

code:

function f (i)
{
    return i % 2 == 0;
}

[Matis]

Haan schreef op vrijdag 22 januari 2010 @ 14:59:
Toch maar even aan die collega vragen wat er mis is met

code:

function f (i)
{
    return i % 2 == 0;
}

Maar die is niet recursief

[user109731]

En resulteert (dus) niet in infinite recursion bij i < 0

[pedorus]

Vraag anders deze terug:

C#:

static int Foo(int i)
{
    i = i - ((i >> 1) & 0x11111111 * 5);
    i = (i & 0x11111111 * 3) + ((i >> 2) & 0x11111111 * 3);
    return ((i + (i >> 4) & 0x1010101 * 0xF) * 0x1010101) >> 24;
}

[Verwijderd]

Dr.Bob schreef op vrijdag 22 januari 2010 @ 14:36:
Hmmm ik kom er niet uit, weet iemand wat de volgende functie doet en waarom?

code:

bool  Foo (int i)
{
If (i == 0) return true;
return !(Foo(i-1));
}

Gewoon een papiertje pakken (analoge monitor), een pen erbij (analoog input-device) en wat waarden ingeven.
Begin bij 1 (arbitrair, je mag ook bij 1.000.000 beginnen ).

[.oisyn]

JanDM schreef op vrijdag 22 januari 2010 @ 15:03:
En resulteert (dus) niet in infinite recursion bij i < 0

Dat deed die andere ook niet. Sterker nog, het resultaat is exact identiek, ook bij negatieve getallen.

De functie waar pedorus mee komt telt gewoon het aantal bits die op 1 staan

[ Voor 13% gewijzigd door .oisyn op 22-01-2010 15:25 ]

[YopY]

pedorus schreef op vrijdag 22 januari 2010 @ 15:14:
Vraag anders deze terug:

C#:

static int Foo(int i)
{
    i = i - ((i >> 1) & 0x11111111 * 5);
    i = (i & 0x11111111 * 3) + ((i >> 2) & 0x11111111 * 3);
    return ((i + (i >> 4) & 0x1010101 * 0xF) * 0x1010101) >> 24;
}

Offtopic, maar ik Googlede dat stukje code en het bleek dat Google deze pagina (4 minuten geleden) al geindexeerd had, .

(en Bing nog niet)

Overigens, euh. Die functie doet iets met bits en zo. Waarschijnlijk doet die iets heel eenvoudigs .

[ Voor 11% gewijzigd door YopY op 22-01-2010 15:26 ]

[abeker]

Aantal bitjes dat aan staat tellen, gok ik

[Soultaker]

pedorus schreef op vrijdag 22 januari 2010 @ 15:14:
Vraag anders deze terug:

Goh, die postte je hier ook al.

YopY schreef op vrijdag 22 januari 2010 @ 15:24:
Offtopic, maar ik Googlede dat stukje code en het bleek dat Google deze pagina (4 minuten geleden) al geindexeerd had, .

Ja, dat is me ook opgevallen. Ik denk dat Google populaire websites en/of sites die vaak updaten, ook vaak indexeert. Wel cool dat de index ook min of meer realtime geüpdatet wordt.

[CodeCaster]

.oisyn schreef op vrijdag 22 januari 2010 @ 15:24:
[...]

Dat deed die andere ook niet. Sterker nog, het resultaat is exact identiek, ook bij negatieve getallen.

Oh? Blijft f(x) bij x <0 niet eeuwig f(x-1) doen?

[.oisyn]

En integers zijn oneindig groot zodat je er altijd 1 vanaf kunt trekken en dus geen underflow hebt en daardoor nooit uiteindelijk weer bij 0 uitkomt?

't Kan natuurlijk, er werd geen taal genoemd bij de originele post, maar aan de code te zien is het C++, C# of Java, en die gedragen zich doorgaans allemaal identiek (bij C++ is het ongespecificeerd maar in de praktijk doet het op zo'n beetje alle implementaties en platforms hetzelfde).

[ Voor 67% gewijzigd door .oisyn op 22-01-2010 15:40 ]

[Haan]

Maar heb je voor die tijd niet allang een stackoverflow gehad?

[Verwijderd]

nee

spuit 11

[ Voor 17% gewijzigd door Verwijderd op 22-01-2010 15:40 ]

[CodeCaster]

Haan schreef op vrijdag 22 januari 2010 @ 15:39:
Maar heb je voor die tijd niet allang een stackoverflow gehad?

In C# in ieder geval wel.

Hij flipt na -2147483648 gewoon naar 2147483647, en 12253 iteraties verder krijg je een mooie StackOverflowException

[ Voor 23% gewijzigd door CodeCaster op 22-01-2010 15:47 ]

[.oisyn]

Haan schreef op vrijdag 22 januari 2010 @ 15:39:
Maar heb je voor die tijd niet allang een stackoverflow gehad?

Waarom zou een compiler per se recursieve code moeten genereren? 't Is tail recursion, dat kun je gewoon met een jump oplossen omdat je state niet hoeft te bewaren (niet dat hier überhaupt een noemenswaardige state is trouwens).

[Haan]

In C# krijg je in ieder geval al een stack overflow als i ~ 12000 is

[pedorus]

Haan schreef op vrijdag 22 januari 2010 @ 15:51:
In C# krijg je in ieder geval al een stack overflow als i ~ 12000 is

Probeer ook eens ctrl-F5, maar dat verschuift alleen de lat.

Een andere functie:

C#:

        static int f(int i)
        {
            var r = Math.Sqrt(5);
            var p = 0.5 + r / 2;
            return (int)(0.5 + Math.Pow(p, i) / r);
        }

[ Voor 26% gewijzigd door pedorus op 22-01-2010 16:04 . Reden: toch terug naar origineel, was te googlebaar ]

[.oisyn]

CodeCaster schreef op vrijdag 22 januari 2010 @ 15:40:
[...]

In C# in ieder geval wel.

Hij flipt na -2147483648 gewoon naar 2147483647, en 12253 iteraties verder krijg je een mooie StackOverflowException

Waarmee je je eigen opmerking ontkracht : hij blijft niet eeuwig doorlopen

@pedorus: fibonacci, alleen klopt ie volgens mij niet.
.edit: ah, na uitvoeren blijkbaar toch wel

@Soultaker hieronder: good point.

[ Voor 15% gewijzigd door .oisyn op 22-01-2010 16:18 ]

[Soultaker]

.oisyn schreef op vrijdag 22 januari 2010 @ 15:42:
Waarom zou een compiler per se recursieve code moeten genereren? 't Is tail recursion, dat kun je gewoon met een jump oplossen omdat je state niet hoeft te bewaren.

Deze functie is niet tail recursive, omdat het resultaat van foo(n - 1) nog omgekeerd moet worden.

[Bob]

Soultaker schreef op vrijdag 22 januari 2010 @ 16:02:
[...]

Deze functie is niet tail recursive, omdat het resultaat van foo(n - 1) nog omgekeerd moet worden.

Daarvoor heb je hier toch geen hele stack nodig? Een bit + counter is zelfs genoeg de hele tijd omkeren tot je bij nul bent, kan gerust met tail recursie volgens mij

[YopY]

.oisyn schreef op vrijdag 22 januari 2010 @ 15:24:
De functie waar pedorus mee komt telt gewoon het aantal bits die op 1 staan

Leesvoer, zijn nog een aantal (overigens allen leesbaardere) alternatieven: http://gurmeetsingh.wordp...st-bit-counting-routines/. Vond die pagina wel grappig.

[Soultaker]

Bob schreef op vrijdag 22 januari 2010 @ 16:10:
Daarvoor heb je hier toch geen hele stack nodig? Een bit + counter is zelfs genoeg de hele tijd omkeren tot je bij nul bent, kan gerust met tail recursie volgens mij

Natuurlijk kan je 'm herschrijven zodat 'ie wél tail recursive is, maar dat was het punt niet. Als we toch gaan herschrijven zou ik voor Haan's suggestie kiezen. Dat verandert echter niets aan het punt dat de gegeven functie niet tail recursive is.

[ Voor 29% gewijzigd door Soultaker op 22-01-2010 16:14 ]

[pedorus]

.oisyn schreef op vrijdag 22 januari 2010 @ 15:57:
@pedorus: fibonacci, alleen klopt ie volgens mij niet.
.edit: ah, na uitvoeren blijkbaar toch wel

Ik dacht al, waar zit de fout. Testen van 0-46 tegen

C#:

        static int f2(int i)
        {
            return i > 1 ? f2(i - 1) + f2(i - 2) : i;
        }

Levert op dat recursie niet erg weggeoptimaliseerd wordt (bij ctrl-f5), maar dat het wel overal klopt.

[.oisyn]

Ik zat meer te denken aan het feit dat de "officiele" versie

phiⁿ - (1 - phi)ⁿ
---------------------
        √5

is, oftewel, er zijn uiteindelijk 2 machtsverheffingen, maar jouw code doet:

phiⁿ
------ + 0.5
 √5

[RayNbow]

JanDM schreef op vrijdag 22 januari 2010 @ 12:04:
Misschien een vooroordeel, maar zodra je een real-world iets wil maken krijg je met monads te maken en daar wordt de code imho niet mooier van.

Hoezo wordt de code niet mooier op? Of je nou dit typt:

Python:

def example():
    print "What's your name?"
    x = raw_input()
    print "Hello " + x
    return

Of 1 van de volgende alternatieven:

Haskell:

example :: IO ()
example
 = do _ <- putStrLn "What's your name?"
      x <- getLine
      _ <- putStrLn ("Hello " ++ x)
      return ()

Haskell:

-- We hoeven geen naam te geven aan het resultaat van putStrLn:
example'
 = do putStrLn "What's your name?"
      x <- getLine
      putStrLn ("Hello " ++ x)
      return ()

Haskell:

-- En aangezien het resultaat van putStrLn altijd () is,
-- kunnen we `return ()` weglaten:
example''
 = do putStrLn "What's your name?"
      x <- getLine
      putStrLn ("Hello " ++ x)

NB 1: x in de Haskell code is de naam van het resultaat van getLine, niet een mutable memory location zoals in Python.
NB 2: return () in Haskell doet niets met de control flow zoals in Python, maar maakt hier een IO actie aan met als resultaat (). Het resultaat van een do-block is altijd het resultaat van de laatste actie.


 

Ik snap wel hoe ze werken en waarom ze bestaan, maar misschien moet ik het gewoon vaker gebruiken en ga ik het dan waarderen...

Monads bestaan iig omdat wiskundige bestaat en je ziet ze overal wel terug.

Voorbeeld van een monad: de verzameling.
[list=1]
• Gegeven een willekeurige a, kan ik de verzameling {a} maken;
• Gegeven een verzameling van a'tjes en gegeven een functie die a'tjes afbeeldt op b'tjes, kan ik een verzameling b'tjes maken;
• Gegeven een verzameling van verzameling van a'tjes, kan ik een verzameling van a'tjes maken.

Oftewel, de typeconstructor Set met de volgende drie functies vormt een monad:^**

code:

unit :: a -> Set a
map  :: (a -> b) -> Set a -> Set b
join :: Set (Set a) -> Set a

(** Er zijn ook een paar regels waar deze drie functies aan moeten voldoen, maar die laat ik voorlopig buiten beschouwing)


Tegenwoordig kun je trouwens ook al in .NET monad comprehension queries schrijven. Stel dat de hypothetische class IO bestond, dan zou je het volgende kunnen schrijven:

C#:

var example = from _ in IO.Print("What's your name?")
              from x in IO.GetLine
              from _ in IO.Print("Hello " + x)
              select 0;
int x = example.run();

[.oisyn]

.oisyn schreef op vrijdag 22 januari 2010 @ 16:23:
Ik zat meer te denken aan het feit dat de "officiele" versie

phiⁿ - (1 - phi)ⁿ
---------------------
        √5

is, oftewel, er zijn uiteindelijk 2 machtsverheffingen, maar jouw code doet:

phiⁿ
------ + 0.5
 √5

Ah, ik zie het al, die tweede versie geeft steeds een te grote waarde, maar de error (0.5 - (1 - phi)ⁿ/√5) is altijd kleiner dan 1 en convergeert naar 0.5 (want (1 - phi)ⁿ convergeert naar 0), waardoor het door de cast naar int alsnog goed gaat.

[ Voor 7% gewijzigd door .oisyn op 22-01-2010 17:03 ]

[pedorus]

Die 0.5 is inderdaad voor de afronding. De formule staat op http://mathworld.wolfram.com/FibonacciNumber.html
Ik snap eigenlijk niet waarom Wikipedia die formule (nog) niet geeft, ik kijk er vast overheen.

Net even getest trouwens, en zelfs deze functie geeft een stackoverflow bij hoge i:

C#:

        static int fi(int i)
        {
            return i == 0 ? 0 : fi(i - 1);
        }

[user109731]

.oisyn schreef op vrijdag 22 januari 2010 @ 15:24:
[...]

Dat deed die andere ook niet. Sterker nog, het resultaat is exact identiek, ook bij negatieve getallen.

Ik twijfelde nog of ik er iets over moest zeggen Desalniettemin, zoals gezegd zit er een verschil in mogelijke stack overflow.

RayNbow schreef op vrijdag 22 januari 2010 @ 16:30:
[...]
Hoezo wordt de code niet mooier op?

Ik heb ooit een kleine interpreter geschreven in Haskell (Parsec was wel mooi, ook monads), met een interpreter monad. Dat werkte wel maar in het begin was het aardig tobben. Nu ik echter jouw reactie zo lees klinkt het allemaal weer heel logisch. Misschien binnenkort maar weer eens mee spelen, of dit boek doornemen

[RayNbow]

JanDM schreef op vrijdag 22 januari 2010 @ 17:26:
Misschien binnenkort maar weer eens mee spelen, of dit boek doornemen

Ah, dat boek waar mijn naam in de papieren versie in voorkomt...

 

RayNbow schreef op vrijdag 22 januari 2010 @ 16:30:
(** Er zijn ook een paar regels waar deze drie functies aan moeten voldoen, maar die laat ik voorlopig buiten beschouwing)

Goed, ik verveelde me en heb ASCII diagrammen gemaakt van de monadwetten.

join . map join = join . join

                        join
          M (M (M a)) -------> M (M a)
              |                   |
     map join |                   | join
              |                   |
              v                   v
            M (M a) -----------> M a
                        join

join . map unit = join . unit = id

                      unit
             M a -------------> M (M a)
              |\                  |
     map unit | \______________   | join
              |        id      \  |
              v                 \ v
           M (M a) ------------> M a
                      join

unit . f = map f . unit

                      unit
              a ---------------> M a
              |                   |
            f |                   | map f
              |                   |
              v                   v
              b ---------------> M b
                      unit

join . map (map f) = map f . join

                      join
            M (M a) -----------> M a
              |                   |
 map (map f)  |                   | map f
              |                   |
              v                   v
            M (M b) -----------> M b
                      join

[afraca]

Euler probleem 7, 10.001ste priemgetal vinden.Nu de schaamte, execution time van m'n php script: 154.8879430294 seconden.......

Maar goed, zoals eerder vermeld, nooit ook maar iets van programmeren geleerd, behalve "php" (mét die aanhalingstekens) bij informatica op havo, wat een grap.... Puur voor de fun dus

Deze methode schijnt overigens voor priemgetallen tot een miljoen zwaar goed te werken, maar heb ik overigens niet gebruikt in m'n scriptje. (Overigens wist ein freund in python er 300 seconden over te doen, met Sieve methode 1.4 seconden )

[Verwijderd]

Al dat gepraat over euler... Hoogste tijd om daar mee bezig te gaan, zeker nu ik de komende weekenden toch voornamelijk thuis zit. Het zijn prachtige oefeningen!

Oh, wat heerlijk, de Top Gear aflevering dat ze de auto's bekladden met 'Men Love Rules', 'Nascar Sucks' enzo is op TV. Echt zo geniaal, ze cruisen lekker door Ala-fucking-bama haha zo mooi hoe die mensen reageren hahahahahaha

[ Voor 41% gewijzigd door Verwijderd op 22-01-2010 21:28 ]

[RayNbow]

afraca schreef op vrijdag 22 januari 2010 @ 20:57:
Deze methode schijnt overigens voor priemgetallen tot een miljoen zwaar goed te werken, maar heb ik overigens niet gebruikt in m'n scriptje. (Overigens wist ein freund in python er 300 seconden over te doen, met Sieve methode 1.4 seconden )

Probleem met de zeef van Eratosthenes is dat je een bovengrens moet kiezen en bij Euler #7 weet je die niet. Okay, je kan een bovengrens gokken, zeven en dan kijken of je genoeg priemgetallen bij elkaar gesprokkeld hebt.

Maar Euler #7 is nog simpel genoeg dat je gewoon een lijstje tot-nu-toe gevonden priemgetallen kunt bijhouden die je tevens gebruikt om te testen of een bepaald getal priem is (door het getal te delen door elk tot nu toe gevonden priemgetal).

In Python krijg je dan zoiets:

Python:

def enumFromThen(start,next):
    step = next - start
    while True:
        yield start
        start += step

primes = [2]

for n in enumFromThen(3,5):
    if len(primes) == 10001:
        break
    else:
        for p in primes:
            if n % p == 0:
                break
        else:
            primes.append(n)

print primes[-1]

 

In Haskell kun je trouwens bij dit probleem mooi wederzijdse recursie gebruiken:

Haskell:

primes = 2 : filter (single.primeFactors) [3,5..]
  where single [x] = True
        single _   = False

primeFactors n | n > 0 = go n primes
  where go n (p:ps)
           | p*p > n    =  [n | n /= 1]
           | r == 0     =  p : go q (p:ps)
           | otherwise  =  go n ps
           where (q,r)  =  quotRem n p

main = print (primes !! 10000)  -- NB: zero-based indexing

[Verwijderd]

/me gaat vanavond zijn virtuele GR probleem 14 laten bruteforcen

hopelijk is hij morgen klaar...

edit: singlethreaded... draaien er nu 2

[ Voor 10% gewijzigd door Verwijderd op 22-01-2010 23:41 ]

[.oisyn]

Pff, brute forcen? Als je een beetje langer nadenkt kun je deze in O(n) doen . Even proberen.

[pedorus]

Een uiterst naieve aanpak in c# kost hier toch wel 1-2 seconden

spoiler:

static int el(uint i) { return i == 1 ? 1 : (i % 2 == 0 ? el(i / 2): el(3 * i + 1)) + 1; }
static void Main(string[] args)
{ Console.WriteLine(Enumerable.Range(1,1000000).OrderBy(a=>-el((uint) a)).First()); }

[Verwijderd]

.oisyn schreef op zaterdag 23 januari 2010 @ 00:22:
Pff, brute forcen? Als je een beetje langer nadenkt kun je deze in O(n) doen . Even proberen.

weet, je begint bij 1, en dan zoek je een patroon... maar daar heb ik geen zin in
waarschijnlijk kan je gewoon hetvolgende doen: (oke, dat gaat niet werken, maar zoiets...)

code:

foo(int bar)
bar = bar * 2
return = (bar -1) / 3

en dan net zolang aanroepen totdat bar >1000000 is...

echter, je pc een nacht aan laten staan is veel leuker

mn batterij rekenmachines is nu voor 9% klaar

[ Voor 4% gewijzigd door Verwijderd op 23-01-2010 00:34 ]

[.oisyn]

pedorus schreef op zaterdag 23 januari 2010 @ 00:24:
Een uiterst naieve aanpak in c# kost hier toch wel 1-2 seconden

spoiler:

static int el(uint i) { return i == 1 ? 1 : (i % 2 == 0 ? el(i / 2): el(3 * i + 1)) + 1; }
static void Main(string[] args)
{ Console.WriteLine(Enumerable.Range(1,1000000).OrderBy(a=>-el((uint) a)).First()); }

idd zeg, m'n naïeve C++ implementatie doet er 0.4s over. Waarom dat bij darkstone zo lang duurt mag Joost weten.

[RobIII]

.oisyn schreef op zaterdag 23 januari 2010 @ 01:05:
[...]


idd zeg, m'n naïeve C++ implementatie doet er 0.4s over. Waarom dat bij darkstone zo lang duurt mag Joost weten.

Hij heeft het over een "virtuele GR". Dat lijkt me een Virtuele Grafische Rekenmachine ofzo? En als die 1 van de oudereste modellen virtualiseert/emuleert dan kon 't wel eens even gaan duren

[Verwijderd]

Ik zit eens naar watr oude Euler oplossingen te kijken en eens wat implementaties te herschrijven.
1 is nu:

C#:

int solution = Enumerable.Range(1, 999).Where(n => n % 5 == 0 || n % 3 == 0).Sum();

Best leuk speelgoed eigenlijk dat LINQ en aanverwante dingetjes, tijd om daar maar eens wat dieper in te duiken Zou het nog korter kunnen (in C#)?

[ Voor 4% gewijzigd door Verwijderd op 23-01-2010 10:27 ]

[user109731]

Verwijderd schreef op zaterdag 23 januari 2010 @ 00:32:
[...]

weet, je begint bij 1, en dan zoek je een patroon... maar daar heb ik geen zin in
waarschijnlijk kan je gewoon hetvolgende doen: (oke, dat gaat niet werken, maar zoiets...)

code:

foo(int bar)
bar = bar * 2
return = (bar -1) / 3

Je kunt Memoization gebruiken. Dat kan hier heel eenvoudig omdat het resultaat van de functie enkel afhankelijk is van z'n argumenten (ik neem aan dat je recursie gebruikt). Bijv. f(20) = 1 + f(10). f(10) is al eerder berekent, dus kun je die waarde gebruiken, etc.

Het kan trouwens ook niet-recursief, en met optimalisatie

[ Voor 6% gewijzigd door user109731 op 23-01-2010 10:40 ]

[Verwijderd]

RobIII schreef op zaterdag 23 januari 2010 @ 02:32:
[...]

Hij heeft het over een "virtuele GR". Dat lijkt me een Virtuele Grafische Rekenmachine ofzo? En als die 1 van de oudereste modellen virtualiseert/emuleert dan kon 't wel eens even gaan duren

hij heeft m nu gevonden .
gok dat ie rond 4 uur klaar was

Het kan trouwens ook niet-recursief, en met optimalisatie

recursie op dat ding is een heel, heel, heel erg slecht idee
hij heeft maar 400 bytes stack, en het callen van een programma (geen subroutines.....) kost 9 bytes

edit: iemand op het euler forum deed er 26 uur over met c/c++.

[ Voor 25% gewijzigd door Verwijderd op 23-01-2010 11:57 ]

[cfern]

Verwijderd schreef op zaterdag 23 januari 2010 @ 10:12:
Zou het nog korter kunnen (in C#)?

code:

int solution = Enumerable.Range(1,999).Sum(n=>n%3==0||n%5==0?n:0);

Let wel: deze versie is alleen korter als je de overbodige spaties weglaat. Als je de IDE de boel netjes laat opmaken zijn ze even lang.

[Matis]

Verwijderd schreef op zaterdag 23 januari 2010 @ 11:43:
edit: iemand op het euler forum deed er 26 uur over met c/c++.

Misschien op een 16MHz CPU ofzo

[Verwijderd]

de GR is 15 mhz

[SanderI]

Ook maar is een paar Euler problemen proberen op te lossen in C#.

Problem 5 had ik eerst op een erg naive manier opgelost. 2 loops en simpel checken of het huidige nummer deelbaar was door 1t/m20. Execution time : 15 - 20 sec ofzo

Mijn veeel snellere oplossing voor Problem 5 is uiteindelijk dit geworden:

C#:

Func<int, int, int> gcd = null;
gcd = (x,y) => y == 0 ? x : gcd(y, x % y);
long result = Enumerable.Range(1, 19).Aggregate((p, f) => p * (f / gcd(p, f)));

Ik leer weer een hoop van al die Euler praat

[pedorus]

cfern schreef op zaterdag 23 januari 2010 @ 11:43:

code:

int solution = Enumerable.Range(1,999).Sum(n=>n%3==0||n%5==0?n:0);

Hij kan nog iets korter (zonder direct het antwoord te geven)..

spoiler:

Je kan beredeneren dat dit ook kan (rest n%3 is altijd 0, 1 of 2, en 5 is oneven), maar ook met haakjes is dit korter:
int solution = Enumerable.Range(1, 999).Sum(n => n % 3 * n % 5 == 0 ? n : 0);

Verwijderd schreef op zaterdag 23 januari 2010 @ 12:41:
de GR is 15 mhz

Maar waarom zou een virtuele GR even traag moeten zijn?

[dcm360]

Ligt misschien aan de emulator. Wabbit kan je instellen op 'echte' snelheid en zo snel mogelijk. Echte snelheid is natuurlijk leuk als je spelletjes of animaties wil doen, maar rekenproblemen gaan iets vlotter op zo snel mogelijk. Maar dan moet je dat wel goed instellen

[Verwijderd]

ahh, een kenner

had even getest, en "max speed" draait ie op ongeveer 150 mhz, met 50% cpu (100% op 1 core)
echter, volgens mij maakt een i7 @ 10 mhz gehakt van dat ding...

sterker nog, dat ding is zo traag dat ie niet eens een prefetch buffer nodig heeft om voluit te draaien
het RAM is sneller dan de cpu zelf

[ Voor 28% gewijzigd door Verwijderd op 23-01-2010 14:32 ]

[Matis]

Verwijderd schreef op zaterdag 23 januari 2010 @ 14:27:
ahh, een kenner

had even getest, en "max speed" draait ie op ongeveer 150 mhz, met 50% cpu (100% op 1 core)
echter, volgens mij maakt een i7 @ 10 mhz gehakt van dat ding...

Dat is idd het gebrek aan werkgeheugen

[Verwijderd]

code:

#define EQU .equ
#include "ti83plusasm.inc"
.org $9D95-2
.DB t2ByteTok, tAsmCmp

#define max_number 1000000

    di
    LD  BC,max_number / 65536
    LD  DE,max_number % 65536
    LD  IX,0
mainloop:
    push    bc
    push    de
    LD  HL,0    ;iteratie counter
mainloop2
    ;checken of getal 1 is...
    xor a
    or  E
    dec a
    or  d
    or  c
    or  b
    jr  z,exit
    
    LD  A,E
    rr  A
    jr  nc,even
oneven: ;*3
    push    hl
    push    bc
    push    de
    sla e
    rl  d
    rl  c
    rl  b
    
    pop hl
    add hl,de
    ex  de,hl
    
    pop hl
    adc hl,bc
    LD  B,H
    LD  c,L
    
    ; push  de
    ; push  bc
    ; b_call(_disphl)
    ; pop   bc
    ; pop   de
;nu 1 optellen  
    
     xor    a
     scf
     adc A,E\ LD E,A\ LD A,0
     adc A,D\ LD D,A\ LD A,0
     adc A,C\ LD C,A\ LD A,0
     adc A,B\ LD B,A
    pop hl
    inc hl  ;counter ophogen
    
even:   srl B   ;delen door 2
    rr  C
    rr  D
    rr  E
    inc hl  ;counter ophogen
    jr  mainloop2
    
exit:   push    ix
    pop de
    or  a
    push    hl
    sbc hl,de
    pop hl
    jr  c,less
    push    hl
    pop ix
less:
    
    
    pop de
    pop bc
    
    dec de
    xor a
    or  d
    or  e
    jr  nz,mainloop
    
    LD  hl,(currow)
    ld  l,0
    LD  h,0
    LD  (currow),HL
    
    push    ix
    pop hl
    b_call(_dispHL)
    
    ei
    ret

ik het dat ding onderschat, de goede oude "black brick" doet hier minder dan een minuut over op standaard clocks! (6 mhz, that is, 15 mhz is overgeclockt.....)
gewoon bruteforce

[Verwijderd]

Hah, ik zit maar te zoeken waarom ik steeds een fout krijg... Ik initialiseer m'n counter steeds opnieuw binnen de loop

[CoolGamer]

Verwijderd schreef op zaterdag 23 januari 2010 @ 17:06:
Hah, ik zit maar te zoeken waarom ik steeds een fout krijg... Ik initialiseer m'n counter steeds opnieuw binnen de loop

Zulk soort problemen klinken bekend Heb er zelf af en toe ook wel eens last van dat ik niet zie wat er mis mee is en dan is het vaak zoiets simpels.

[Soultaker]

.oisyn schreef op zaterdag 23 januari 2010 @ 00:22:
Pff, brute forcen? Als je een beetje langer nadenkt kun je deze in O(n) doen .

Dat lijkt me sterk, tenzij je het Collatz conjecture weet te bewijzen.

[whoami]

cfern schreef op zaterdag 23 januari 2010 @ 11:43:
[...]

code:

int solution = Enumerable.Range(1,999).Sum(n=>n%3==0||n%5==0?n:0);

Let wel: deze versie is alleen korter als je de overbodige spaties weglaat. Als je de IDE de boel netjes laat opmaken zijn ze even lang.

Eh .... Je neemt dit zelf toch niet serieus hoop ik ? Het weglaten van whitespace is niet gelijk aan 'iets verkorten'.

[cfern]

Ik bedoelde eigenlijk dat het aantal non-whitespacekarakters kleiner is. In die zin is de oplossing korter.

[.oisyn]

Soultaker schreef op zondag 24 januari 2010 @ 16:44:
[...]

Dat lijkt me sterk, tenzij je het Collatz conjecture weet te bewijzen.

Die hoeft niet bewezen te worden, het blijkt al uit de opdracht dat voor elk getal onder de miljoen de stellig iig opgaat.

Verder is het natuurlijk ook niet echt O(n), maar het komt daar wel in de buurt, omdat je feitelijk langs elk getal komt. Het probleem is echter dat je niet weet hoe hoog hij eerst klimt voordat hij weer binnen je domein terecht komt.

[afraca]

PHP:

<?php
$Euler_Problem_ID = 8;
$description = "Find the greatest product of five consecutive digits in the 1000-digit number.";

$number = "7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450";

$array = array();
for ($i=0; $i <= 990 ; $i++) { 
    $array[] = array_sum(str_split(substr($number,0+$i,5)));
}

echo max($array);
?>

Code says it all. Ik krijg er een awesome array uit, en met de max functie haal ik er

spoiler:

42

als antwoord uit Niet goed

Ben ik nou helemaal achterlijk dat ik het niet zie? ...

(Wel gisteren euler probleem 2, van de fibonacci reeks gehaald. Voor rankk.org was er een vergelijkbare challenge, alleen hoefde je voor project euler niet verder te rekenen dan 4 miljoen, bij rankk.org mag je de 84ste term zoeken, en dan heb je wél de BC math library van php nodig, anders krijg je problemen met float worden van je getallen )

[Verwijderd]

@afraca: Lees de opdracht eens goed?

Find the greatest product...

[Soultaker]

.oisyn schreef op zondag 24 januari 2010 @ 17:22:
Die hoeft niet bewezen te worden, het blijkt al uit de opdracht dat voor elk getal onder de miljoen de stelling iig opgaat.

Daaruit volgt nog niet een bovengrens aan de tijdcomplexiteit van het algoritme dat jij waarschijnlijk in gedachten hebt, maar alleen dat dat algoritme termineert (wat in het algemeen nog niet bewezen is; dat is precies wat het Collatzvermoeden inhoudt).

Dus je hebt gelijk dat het niet vereist is om het Collatzvermoeden te bewijzen, maar de geclaimde O(n) lijkt me ook nog niet bewezen (of je hebt een prachtig algoritme en ditto bewijs verzonnen, maar ik ga er gemakshalve vanuit dat dat niet het geval is).

[ Voor 55% gewijzigd door Soultaker op 24-01-2010 23:10 ]

[afraca]

Verwijderd schreef op zondag 24 januari 2010 @ 23:02:
@afraca: Lees de opdracht eens goed?

[...]

Schijnt essentieel te zijn, lezen van een opdracht XD array_sum --> array_product, et voila, een goed antwoord morgen volgende euler probleempje, of even rondkijken op rankk.org (waar ook niet programmeer dingen staan).

[pedorus]

afraca schreef op zondag 24 januari 2010 @ 22:52:
42[/spoiler]
als antwoord uit Niet goed

Mm, dat ziet er anders wel degelijk uit als een goed antwoord. Nu enkel de juiste vraag er nog even bij vinden...

[ Voor 13% gewijzigd door pedorus op 25-01-2010 01:10 . Reden: komma's... ]

[.oisyn]

Pffff. Ik probeer Problem 275 op te lossen, maar m'n algo geeft het verkeerde antwoord bij de gevraagde 18, terwijl het bij 6, 10 en 15 wel klopt

.edit: en terwijl ik dit zeg bedenk ik me ineens een case die onder de 17 niet voor kan komen, en dat dat met mijn code niet goed gaat, dus dan heb ik iig weer een richting waarin ik kan zoeken . Vanavond maar weer eens naar kijken.

[ Voor 39% gewijzigd door .oisyn op 25-01-2010 15:04 ]

[Snake]

kan iemand mij vertellen waarvoor dat pijltje links op regel 3 dient? vind het zo klein om een topic voor aan te maken en Google helpt me (erewoord) echt niet verder

[Woy]

Bij mij komt die op de plekken waar mijn zoek-criteria gematched heeft (Find in files).

[ Voor 27% gewijzigd door Woy op 25-01-2010 15:47 ]

[IntoDevel]

Voor de nostalgische dev'er

http://www.michaelv.org/

[Haan]

IntoDevel schreef op maandag 25 januari 2010 @ 17:52:
Voor de nostalgische dev'er

http://www.michaelv.org/

Stoer!

[Soultaker]

Geweldige site! Sommige applicaties (Calculator, Mine Sweeper) gedragen zich net echt.

[CoolGamer]

Soultaker schreef op maandag 25 januari 2010 @ 23:22:
Geweldige site! Sommige applicaties (Calculator, Mine Sweeper) gedragen zich net echt.

Mine Sweeper niet helemaal. Je kan al bij je eerste zet op een mijn stuiten. (Of kon dat in 3.11. Was nog voor mijn tijd)

Maar dit is inderdaad heel erg vet gemaakt.

[.oisyn]

En de DOS prompt niet te vergeten

[Matis]

.oisyn schreef op maandag 25 januari 2010 @ 23:37:
En de DOS prompt niet te vergeten

Het shutdown commando werd helaas niet ondersteund

[Soultaker]

@TheCoolGamer: nu je het zegt! Dat had ik inderdaad ook een paar keer voordat ik een spelletje won, en onder Windows kan dat niet. Maar veel andere details (met het zonnetje dat veranderd als je de muisknop ingedrukt hebt enzo) kloppen wel. Helaas ontbreekt een high-score lijst ook.

Die DOS prompt kan btw zelfs full-screen met Alt-Enter

[ Voor 28% gewijzigd door Soultaker op 25-01-2010 23:55 ]

[.oisyn]

.oisyn schreef op maandag 25 januari 2010 @ 14:55:
Pffff. Ik probeer Problem 275 op te lossen, maar m'n algo geeft het verkeerde antwoord bij de gevraagde 18, terwijl het bij 6, 10 en 15 wel klopt

.edit: en terwijl ik dit zeg bedenk ik me ineens een case die onder de 17 niet voor kan komen, en dat dat met mijn code niet goed gaat, dus dan heb ik iig weer een richting waarin ik kan zoeken . Vanavond maar weer eens naar kijken.

Pfff, die fix heeft wel geholpen, maar het antwoord is nog steeds niet goed