Advent of Code 2017

[vliegnerd]

Twieka schreef op vrijdag 1 december 2017 @ 20:07:
Geloof niet dat Day1 veel korter kan ..

spoiler:

ord(i) - ord('0') kan in ieder geval korter: int(i)
EDIT: en a[:1] kan korter: a[0]
EDIT2: en else 0 kan ook weg :-)

Ik kom op:

a = open("input\input01.txt").read().strip()
print(sum([int(i) for i,j in zip(a,a[1:]+a[0]) if i == j]))

Als het echt kort moet kan strip vervangen worden door [:-1] en kan een van de twee print() calls weg, maar dat is echt code-golf aan het worden.

Mijn code golf toegevoegd aan: https://github.com/tomkoo...b/master/aoc2017/day01.py

[ Voor 52% gewijzigd door vliegnerd op 01-12-2017 21:54 ]

[Camulos]

Was een lekkere opwarmer

[Down]

Ik zat er al een poosje naar uit te kijken. Ik heb hier de afgelopen twee edities ook heel veel lol mee gehad. Ik vind het hele concept leuk in elkaar zitten en knap dat het allemaal door één persoon bedacht en gebouwd is .

Een aantal van mijn collega's doen er ook aan mee en we bespreken regelmatig onze oplossingen met elkaar (soms ook onder het genot van een pizzaatje door de baas gefinancierd).

Ik doe mee met C#, lekker veel Linq abuse en geen zorgen om code quality. Inmiddels heb ik dag 1 er op zitten. Deel twee vond ik wel leuk.

Daanoz schreef op vrijdag 1 december 2017 @ 13:13:
Voor degene die willen optimaliseren in het 2de deel:

spoiler:

In het 2de deel hoef je in theorie maar de halve string te onderzoeken om tot het antwoord te komen
Scheelt bij mij 33% (220ms) executie tijd

Dat had ik me ook bedacht.

spoiler:

Deed me een beetje denken aan hoe je checkt of een string een palindroom is

.

[Xesxen]

Zo, en ook maar mijn code eens online gegooid. Ditmaal in PHP, de volgende zien we nog wel

https://github.com/xesxen.../master/Days/1/Solver.php

[Swedish Clown]

De eerste dag is inmiddels voorbij en er zijn voldoende voorbeelden te vinden op Github en aangezien er maar weinig in Erlang zullen programmeren, bij deze dag 1 in Erlang

U ziet een one/0 welke dag 1a en 1b sequentieel draait. Niet de meest efficiënte code maar draait in 641ms (gemiddelde over 100 runs).

Tevens ter lering en vermaak een parallel/0 functie toegevoegd welke dag 1a en 1b in parallel draait in hun eigen process en het resultaat vervolgens afwacht. 442ms gemiddeld over 100 runs.

Erlang: Dag 1

-module(day1).

-export([ one/0
        , parallel/0
        ]).

-define(REX_OPTS, [{capture, first, list}, global]).

one() ->
  L = input(),
  {_, A} = captcha(L, 1),
  {_, B} = captcha(L, length(L) div 2),
  {{day1, A}, {day2, B}}.

parallel() ->
  L = input(),
  A = fun() -> captcha(L, 1) end,
  B = fun() -> captcha(L, length(L) div 2) end,
  Self = self(),
  Pid1 = spawn_link(fun() -> Self ! {self(), {day1, A()}} end),
  Pid2 = spawn_link(fun() -> Self ! {self(), {day2, B()}} end),
  [ receive {Pid, R} -> R end || Pid <- [Pid1, Pid2] ].

input() ->
  {ok, Bin} = file:read_file(code:priv_dir(advent_of_code) ++ "/day1.txt"),
  {match, L} = re:run(binary_to_list(Bin), "([0-9])", ?REX_OPTS),
  L.

captcha(List, Nth) ->
  LL = List ++ List,
  lists:foldl(fun(L, {N, Sum}) ->
                  case L =:= lists:nth(N + Nth, LL) of
                    true -> {N + 1, Sum + list_to_integer(lists:flatten(L))};
                    false -> {N + 1, Sum}
                  end
              end, {1, 0}, List).

[ Voor 14% gewijzigd door Swedish Clown op 02-12-2017 02:32 ]

[kenneth]

Ik heb dag 2 opgelost maar ben niet helemaal tevreden over de oplossing. Het voelt alsof deze functie wat eleganter kan. Iemand?

[ Voor 8% gewijzigd door kenneth op 02-12-2017 09:28 ]

[Daanoz]

Mijn oplossing is vergelijkbaar, niet het mooiste inderdaad. Zeker vergeleken met deel 1 wat een mooie one-liner is.

[-ko-]

Ik doe ook weer mee. Wederom in Python. First make it work, daarna kijk ik of ik nog tijd heb om het mooi en snel te maken... ;-) Puzzels oplossen > mooie code dit jaar. Ik hoop alles dit jaar op te lossen, vorig jaar na een paar dagen gestopt...

https://github.com/BasLangenberg/AdventOfCode2017

[Quadro!]

kenneth schreef op zaterdag 2 december 2017 @ 09:08:
Ik heb dag 2 opgelost maar ben niet helemaal tevreden over de oplossing. Het voelt alsof deze functie wat eleganter kan. Iemand?

Bij het tweede deel gebruik ik recursie om uit iedere rij het deelbare paar te vissen (code). Niet per se eleganter, maar wel net wat anders.

[ Voor 25% gewijzigd door Quadro! op 10-12-2017 20:31 ]

[kenneth]

Quadro! schreef op zaterdag 2 december 2017 @ 09:28:
Bij het tweede deel gebruik ik recursie om uit iedere rij het deelbare paar te vissen (code). Niet per se eleganter, maar wel net wat anders.

Ah, ook een goeie.

Ik doe het nu met een sequence expression. Ik vind hem wel mooi zo.

Ik ga pepernoten en marsepein kopen

[veldsla]

Daanoz schreef op zaterdag 2 december 2017 @ 09:13:
Mijn oplossing is vergelijkbaar, niet het mooiste inderdaad. Zeker vergeleken met deel 1 wat een mooie one-liner is.

En wat gebeurt bij jou als de juiste deling in deel 2 op 1 uitkomt?
Dit geldt ook voor @-ko- zie ik.
En voor nog een aantal, ik ging toch even twijfelen, maar zie echt nergens staan dat de getallen uniek zijn en ook niet dat het resultaat van de deling > 1 moet zijn.

Python:

 def evenly(x, y):
    if x == y: return 0

Er wel over nadenken en dan toch ervoor kiezen om het te negeren?

[ Voor 36% gewijzigd door veldsla op 02-12-2017 12:12 ]

[zwiep]

Ik heb door de geboorte van mijn 2e zoontje wat vertraging opgelopen en heb mij dan ook niet verder kunnen voorbereiden. Ben begonnen met Java omdat ik hiermee al een klein beetje bekend ben.

[wmkuipers]

Toch weer makkelijk voor javascript gekozen, dit keer sla ik een animatie/visualisatie over:
Deel 1:

spoiler:

for (i=0; i<input.length; i++){
min = Number.MAX_VALUE;
max = -min;
for (j=0; j<input[i].length; j++){
min = (input[i][j] < min ? input[i][j] : min)
max = (input[i][j] > max ? input[i][j] : max)
}
checksum += max - min;

}
console.log(checksum)

Deel 2:

spoiler:

checksum = 0;
for (i=0; i<input.length; i++)
for (j=0; j<input[i].length; j++)
for (k=0 ; k<input[i].length; k++)
if (j != k && (input[i][j] % input[i][k] == 0 ) )
checksum += input[i][j]/input[i][k]
console.log(checksum)

[Verwijderd]

Damn...dat late opstaan gaat me punten kosten!

[Kraay89]

zwiep schreef op zaterdag 2 december 2017 @ 11:29:
Ik heb door de geboorte van mijn 2e zoontje wat vertraging opgelopen en heb mij dan ook niet verder kunnen voorbereiden.

Altijd vervelend, dat soort interrupties...

Gefeliciteerd kerel!

Dag 2 was ook wel eenvoudig!

[P.O. Box]

spoiler:

Ik heb bij deel 2 eerst de array met waarden gesorteerd. Daarna het laatste element er af gepopt en die vergeleken met de rest van de array. Indien de waarde het getal uit de rest van de array groter is dan de helft van de gepopte waarde, break ik de lus en pop ik het volgende getal van de array af. And so on.

[Lye]

Toch wel even zitten twijfelen hoe deel 2 van vandaag mooi op te lossen was, while loops en dergelijke vervuilden mijn code behoorlijk. Uiteindelijk heb ik er voor gekozen

spoiler:

om elke rij dalend te sorteren en vervolgens combinaties te berekenen. De functie die ik gebruik om combinaties te berekenen levert een Sequence/stream/lazy list op, waarna ik dus voor elke berekende combinatie direct kan kijken of deze voldoet. Hiermee worden dus niet alle combinaties berekend. Code

Het is niet de meest efficiënte manier, wel de mooiste (naar mijn mening).

[ Voor 31% gewijzigd door Lye op 02-12-2017 14:49 ]

[Hydra]

Mijn oplossing voor dag 2 (Kotlin)

[Daanoz]

veldsla schreef op zaterdag 2 december 2017 @ 11:19:
[...]

En wat gebeurt bij jou als de juiste deling in deel 2 op 1 uitkomt?

Hmm, mijn eerste iteratie van de oplossing hield ik daar wel rekening mee. De korte versie inderdaad niet, antwoord komt toevallig wel goed uit, dus dat scheelt weer.

[vliegnerd]

kenneth schreef op zaterdag 2 december 2017 @ 09:08:
Ik heb dag 2 opgelost maar ben niet helemaal tevreden over de oplossing. Het voelt alsof deze functie wat eleganter kan. Iemand?

Precies hetzelfde gevoel: Mijn functie (python) is ongeveer hetzelfde, of misschien nog minder elegant. Ben benieuwd of er iemand een echt slimme truc heeft.

[Radiant]

spoiler:

Grappig, als je de kalender refresht krijg je steeds een ander circuitje

[Edwin88]

Dag 2 best netjes kunnen neerzetten in een paar regeltjes: https://github.com/EdwinM...ob/master/src/02/index.ts


Worden de opdrachten steeds moeilijker of blijven het dit soort rekensommetjes?

[Bee.nl]

Edwin88 schreef op zaterdag 2 december 2017 @ 19:14:
Worden de opdrachten steeds moeilijker of blijven het dit soort rekensommetjes?

De moeilijkheidsgraad neemt steeds iets toe. De puzzels zijn op een gegeven moment ook niet meer te bruteforcen, waardoor je echt gedwongen wordt om een efficiënt algoritme te verzinnen. Zo zijn heel veel mensen vorig jaar stuk gelopen op puzzel 11. De puzzels zijn echter altijd zo geschreven door de maker dat er een slimme manier bestaat om binnen korte tijd het antwoord te genereren.

[Bolukan]

Ah puzzel 11! Ik ben uiteindelijk maar gaan nadenken en heb het met potlood en papier opgelost. Maar geen enkele puzzel is te moeilijk. Ze zijn niet vergelijkbaar met Project Euler.

Vanmorgen 63 punten gescoord. Om 06.01:34 het eerste antwoord gepost, voor de tweede antwoord nam ik te veel tijd. Afgelopen 2 dagen waren binnen ca 6 minuten beide opgaven door 100 mensen opgelost. Vorig jaar had ik punten gescoord op dag 20 en 22. Misschien waren die wat moelijker, zodat ik kans maakte als langzame programmeur?

[Daanoz]

Zo die was wel weer een stapje omhoog...

spoiler:

Deel 1 zonder bruteforce maar met berekenen gevonden. Maar deel 2 heb ik toch echt uiteindelijk de spiral moeten genereren in code om achter het antwoord te komen.... Jammer, kon geen patroon in de getallen vinden, ben erg benieuwd of iemand die wel kan vinden?

[kenneth]

spoiler:

Ben nog bij deel 1, moest weg voor ik hem kon afmaken maar ik was al zover dat de getallen naar rechtsonder opeenlopende kwadraten zijn: 3², 5², 7², 9², enz. Weet niet of dat helpt bij deel 2?

[Hydra]

Ugh. Day 3 part 1 opgelost netjes zonder echt geheugen te gebruiken. Kan je met deel 2 eigenlijk gewoon opnieuw beginnen

[Verwijderd]

Deel 1 even met pen en papier uitgerekend. Met twee gaat dat wat lastiger dus pc maar opgestart.

[Bolukan]

Deel 1 met de hand en deel 2 toch wat in elkaar geflanst: in de 4e spiraal was het raak, dus het is achteraf gezien met de hand te doen geweest.

[Hydra]

Dag 3 in Kotlin

Helaas geen tijd om te refactoren (vanwege sinterklaas); heb voor deel 2 een totaal andere richting gebruikt dan in deel 1.

[Sjeik]

Ik doe ook mee! Het enige wat ik een beetje kan is Excel. Maar ben trots te zeggen dat ik tot nu toe alle puzzels heb opgelost
Wel heel leuk om daar mee bezig te zijn
Iemand belangstelling in het excelbestand?

[dcm360]

Hm, deel 1 ziet er inderdaad berekenbaar uit nu ik het zo lees. Welja, gewoon de hele spiraal volgen in een tail-recursive function werkt ook wel. Voor deel twee nog overwogen om daar wat moois voor te gaan schrijven, maar uiteindelijk een mutable hashmap in de oplossing van deel 1 gebeund en dat doet het ook.

edit: hm, dat laatste was dan wel erg lelijk. In wat ik nu online heb staan heb ik de mutable hashmap toch maar weggepoetst met een immutable hashmap die meegaat met de recursieve functie.

[ Voor 30% gewijzigd door dcm360 op 03-12-2017 16:02 ]

[vliegnerd]

Ha! Dag 3 is leuk.

Deel A is inderdaad gewoon te berekenen (snelst met pen en papier), maar ben benieuwd of er een slim algoritme is voor deel B is.

Ik heb zoals zovelen ook maar gewoon een array gevuld. De meeste code had ik nog liggen van vorig jaar, dus zoveel werk was het ook niet.

Gezien het chronisch tijdgebrek van deze dagen, alleen een interactieve versie. Dat wil zeggen ee jupyter notebook (python) waarmee ik de oplossingen heb gevonden.

[ZieglerNichols]

Deel 1 ook zonder code opgelost en voor deel 2 met brute force code de spiraal gemaakt totdat het juiste element gevonden was. Was minder ver dan ik had gedacht!

Aan de stats is wel te zien dat dag 3 iets lastiger is dan de eerste 2.

[ Voor 27% gewijzigd door ZieglerNichols op 03-12-2017 17:10 ]

[Verwijderd]

Ik doe ook mee!
mijn github-repo: https://github.com/DutchG...-of-Code/tree/master/Rust

Taal: Rust

[Marcj]

Ik was toch een beetje vastgelopen in Erlang en heb gewoon te weinig tijd om er verder in te duiken. Dag 1 en 2 in ieder geval opgelost in Haskell: https://github.com/marcdejonge/advent2017/tree/master/src

[Camulos]

Dag 3 was in ieder geval een stuk uitdagender
Net als anderen heb ik deel 1 zonder spiraal kunnen doen... maar in deel 2 was er geen ontkomen aan.

C# oplossing dag 3

[Lye]

Ik ben de halve dag bezig geweest om mijn algoritme om een index op de spiraal om te zetten in coördinaten te bouwen. Ik had een algoritme die bijna klopte, voor de eerste opdracht werkte het bij toeval, en berekend de Manhattan distance in O(1).

De tweede opdracht is gewoon opzoeken in deze lijst, maar dat is natuurlijk niet leuk. Het algoritme voor de tweede opdracht was geen probleem, onder de voorwaarde dat het index-naar-coordinaten-algoritme goed werkt. Ik kreeg een bug hierin niet geplet, totdat ik deze post tegen kwam. Die maakte alles mooi en prachtig.
Uiteindelijk heb ik het ook iteratief opgelost aangezien er nog geen wiskundige oplossing in O(1) lijkt te zijn. De leesbaarheid had nog iets beter gekund, maar ben op zich wel tevreden met de huidige oplossing (Kotlin).

[Quadro!]

Moet zeggen dat ik gisteren wel een paar keer heb overwogen om te switchen naar een andere (imperatieve) taal, maar uiteindelijk is het toch gelukt in Haskell. Geen tijd gehad om slimme truucjes o.i.d. te proberen, dus gewoon die spiralen iteratief gegenereerd. Gezien de algorithmische complexiteit hiervan kan ik me wel voorstellen dat dit bij grotere waarden voor n vrij snel voor problemen zou zorgen.

Vandaag was weer erg makkelijk, getuige ook de snelste tijd op het overall leaderboard (1:10 vs 4:02 gisteren).

[Hydra]

Grappig. Dag 4 was weer extreem simpel.

[Verwijderd]

Argggh, voor sommige problemen zijn python en php toch een stuk sneller ontwikkelen dan C!

[vliegnerd]

Verwijderd schreef op maandag 4 december 2017 @ 08:18:
Argggh, voor sommige problemen zijn python en php toch een stuk sneller ontwikkelen dan C!

Duh! Waarom zouden die talen ontwikkeld zijn?

[Verwijderd]

vliegnerd schreef op maandag 4 december 2017 @ 08:28:
[...]


Duh! Waarom zouden die talen ontwikkeld zijn?

Om AoC problemen op te lossen

[ZieglerNichols]

Ik zat veel te moeilijk te doen over tweede deel van dag 4

spoiler: Dag 4

Was al begonnen met een script dat alle permutaties van de substrings maakte en die met elkaar vergeleek, tot ik opeens doorhad dat je ze natuurlijk alleen maar hoeft te ordenen (sort) en dan 1 keer vergelijken....

[DRaakje]

Erg makkelijk vandaag, daarom maar in een single linq statement gedaan. Met comments zodat mensen snappen wat er gebeurt. Kijk ook eens op reddit als je het opgelost, dan kan je kijken naar andere strategieën die mensen hebben gebruikt, erg leerzaam.

https://pastebin.com/vt67Jd6Z

spoiler:

var lines = Properties.Resources.TextFile1.Split('\n'); //Split the input to single lines

int resultA = lines.Select(x => x.Trim().Split(' ')) //split to seperate words
.Where(x => x.Count() == x.Distinct().Count()) //Compare start count with distinct count (removes duplicates)
.Count(); //count the result is the andwer

int resultB = lines.Select(x => x.Trim().Split(' ') //split to seperate words
.Select(z=> string.Join("-", //joins the result of below
z.GroupBy(y=> y) //get the freq count of each used letter
.OrderBy(y=> y.Key) //sort so all the letters anagrams look the same
.Select(y=> $"{y.Key}{y.Count()}"))) //make a string a5 => a5-b4-etc
).Where(x => x.Count() == x.Distinct().Count()).Count(); //same as partA

[ Voor 15% gewijzigd door DRaakje op 04-12-2017 10:07 ]

[Marcj]

Dag 4 was inderdaad wel heel simpel:

spoiler:

module Day4(run) where

import Data.List
import Data.List.Split

run = do passwords <- readPasswords
return (part1 passwords, part2 passwords)

readPasswords :: IO [[String]]
readPasswords = map (splitOn " ") <$> splitOn "\n" <$> readFile "data/day4.txt"

part1 passwords = sum $ map (fromEnum . checkPassword) passwords

part2 passwords = sum $ map (fromEnum . checkPassword) $ map (map sort) passwords

checkPassword :: [String] -> Bool
checkPassword (pass:passes) = (not (pass `elem` passes)) && checkPassword passes
checkPassword [] = True

Haskell werkt best mooi voor dit soort problemen, vooral dat deel 2 ongeveer 30 seconden na deel 1 was opgelost

[kenneth]

Was al gekelderd in de leaderboard omdat ik de puzzel van gisteren niet op tijd af kon krijgen, loop ik vandaag gewoon echt te prutsen

Ik had de oplossing heel snel en redelijk vroeg. Maar het werkte toch niet. Echt zo'n geval dat je denkt: in deze code zit écht geen fout. Toch? TOCH!?

Meestal zit er dan toch een lullige fout in. Maar vandaag niet. Vandaag had ik door copypasta-gepruts extra newlines in de input.txt, waardoor hij twee correcte passphrases te veel gaf

Goed, redelijk netjes opgelost. Het is deze editie vooralsnog de hele Seq-module misbruiken, hopelijk word ik de komende dagen gedwongen om echt nieuwe technieken en algoritmes te leren. Een functionele implementatie van BFS of iets dergelijks ...

Vanavond eerst maar dag 3 nog eens bekijken.

Marcj schreef op maandag 4 december 2017 @ 09:53:
Haskell werkt best mooi voor dit soort problemen, vooral dat deel 2 ongeveer 30 seconden na deel 1 was opgelost

Had ik ook Door, net als bij dag 2, een andere functie te injecteren het tweede probleem op te lossen doet me FP steeds meer waarderen. Het komt allemaal erg vloeiend en natuurlijk over.

[ Voor 19% gewijzigd door kenneth op 04-12-2017 10:12 ]

[Ryada]

Helaas ben ik een beetje laat van de partij maar heb net dag 1 afgerond.

Heb naar mijn mening het een beetje hacky gedaan door een Try/Catch als codeflow te gebruiken als je aan het eind van de lijst komt maar ben best tevreden met de snelheid waar ik de challenge heb gecomplete.
Zal vanavond eens kijken of ik hem een stuk minder slecht kan maken
Zit ook best wat duplicatie in maarja ik wou hem even snel maken ipv het goed te doen de eerste keer

[Verwijderd]

Pff...ik dacht echt even dat ik helemaal gek aan het worden was met deel 2 - bleek ik daar de incorrecte passphrases te tellen. /facepalm

[dcm360]

Hier zat inderdaad niet echt een uitdaging in. Als basis maar de code van dag 2 gepakt en daar wat kleine aanpassingen aan gemaakt.

[Peelee]

kenneth schreef op maandag 4 december 2017 @ 10:10:
Was al gekelderd in de leaderboard omdat ik de puzzel van gisteren niet op tijd af kon krijgen, loop ik vandaag gewoon echt te prutsen

Weet iemand eigenlijk hoe de scoring precies werkt? Ik vond het niet zo snel terug op de site.
De vroege vogels lijken me alvast meer punten te krijgen, en er lijkt een afstraffing voor foute oplossingen te zijn, maar meer heb ik nog niet gevonden

kenneth schreef op maandag 4 december 2017 @ 10:10:
Had ik ook Door, net als bij dag 2, een andere functie te injecteren het tweede probleem op te lossen doet me FP steeds meer waarderen. Het komt allemaal erg vloeiend en natuurlijk over.

Functie compositie werkt inderdaad super voor dit soort problemen

[Daedalus]

Dag 1 en 2 waren opwarmertjes, dacht met dag 3 gaat het echt beginnen, en toen kwam dag 4 't Was dat er nog een extra newline in m'n input zat die ik was vergeten af te halen, anders had ik 'm nog sneller opgelost.

Peelee schreef op maandag 4 december 2017 @ 13:00:
[...]

Weet iemand eigenlijk hoe de scoring precies werkt? Ik vond het niet zo snel terug op de site.
De vroege vogels lijken me alvast meer punten te krijgen, en er lijkt een afstraffing voor foute oplossingen te zijn, maar meer heb ik nog niet gevonden

V.z.i.w. zijn er geen strafpunten voor foute oplossingen. Volgens de beschrijving hier krijgt de eerste met een oplossing 100 punten, de volgende 99 enz. tot de 100ste met 1 punt en de rest krijgt 0 punten. Het gaat dus puur op tijd.

[dcm360]

In die zin worden foute oplossingen ook wel een beetje afgestraft, want het kost op dat moment gewoon tijd om de bug uit het programma te halen, en in die tijd kan iemand anders wel een correcte oplossing inleveren.

[Peelee]

Owja, nu zie ik dat de score uit het private leaderboard niet die van het algemene leaderboard is.
Dat verklaart waarom ik toch nog punten heb, terwijl ik telkens pas vrij laat op de dag aan de opdrachten kan werken

[Ryada]

Net lekker dag 2 lopen maken, en de eerste was nog best te doen maar die 2de van die dag was een uitdaging, maar dat kwam vooral omdat ik heel erg graag niet nested loops wou gebruiken.
Probeerde het dit keer maar goed te doen ipv snel dan hoef ik geen slechte code te comiten naar mijn repo, en ben super tevreden met het eind resultaat. Op naar dag 3.

[Brandts]

Leuk! Dit is de eerste keer dat ik hiervan hoor. Ik ga ook meedoen om mijn kennis op het gebied van LabVIEW weer wat op te frissen. Zie hier mijn "code" van de eerste dag:

spoiler:

edit: spoiler tags toegevoegd, ondanks er relatief weinig zijn die de code kunnen lezen

[ Voor 14% gewijzigd door Brandts op 04-12-2017 14:35 ]

[Hydra]

"Een plaatje zeg meer dan duizend woorden" maar ik snap er geen snars van

[Lye]

Vandaag was inderdaad een eitje zeg. Gaf mij mooi de kans om eens een beetje in het rond te hakken met lambda's en extension functions. Natuurlijk mag een beetje misbruik maken van Sets ook niet ontbreken. Code.

[ Voor 26% gewijzigd door Lye op 04-12-2017 17:36 ]

[Brandts]

Hydra schreef op maandag 4 december 2017 @ 14:03:
"Een plaatje zeg meer dan duizend woorden" maar ik snap er geen snars van

Ik ben het helemaal met je eens. Ik vind LabVIEW code vele malen makkelijke om te "lezen" dan geschreven code. Maar in tegenstelling tot andere talen moet je wel specifieke kennis hebben om uberhaupt iets van de code te kunnen lezen Bij deze het resultaat van de code van dag 2:

spoiler:

[Hydra]

De leaderboards hebben trouwens ook een JSON response!

[tha_crazy]

Druk druk druk hier, loop wat achter
Wel even de tijd gehad om dag 2 deel 1 even uit mijn hoofd te doen

Dat is weer eens wat anders als er een stukje software voor bouwen

[DNL_TIM]

Ik kende Advent of Code ook nog niet, er zitten pittige puzzels tussen. Die van vandaag was echter veel te makkelijk. Ik ben zo te zien een van de weinigen die nog in php aan het rotzooien is

[Edwin88]

Dag 3 heb ik net eindelijk af kunnen maken (had gister weinig tijd). Heb er wel te lang over gedaan naar mijn gevoel.

Ben wel benieuwd of iemand naar mijn code zou willen kijken voor wat feedback; altijd goed om code te kunnen laten zien. Inmiddels duik ik ook in andermans oplossingen:
https://github.com/EdwinM...ob/master/src/03/index.ts

En ook nu naar dag 4! Hopelijk morgenochtend wel weer tijd voor dag 5..

Update: Dag 4 was wel weer een stuk simpeler inderdaad. Wel leuk vraagstuk.

[ Voor 8% gewijzigd door Edwin88 op 04-12-2017 22:03 ]

[Swedish Clown]

Dag 4 in Erlang Leuk dagje om lekker code golf te spelen

Erlang: Dag 4

-module(day4).

-export([ run/0 ]).

run() ->
  L = input(),
  { {day4a, length(v(fun(P) -> P end, L))}
  , {day4b, length(v(fun(P) -> lists:map(fun lists:sort/1, P) end, L))}}.

v(SF, L) when is_function(SF) -> lists:filter(fun(P) -> v(SF(P), false) end, L);
v([], V) when V =:= false -> true;
v(_, true) -> false;
v([H|T], _) -> v(T, lists:member(H,T)).

input() ->
  {ok, Bin} = file:read_file(code:priv_dir(advent_of_code) ++ "/day4.txt"),
  [string:tokens(S, " ") || S <- string:tokens(binary_to_list(Bin), "\n")].

[ Voor 20% gewijzigd door Swedish Clown op 05-12-2017 02:03 ]

[Bolukan]

Dag 5. Voor mensen die nog een screensaver in Excel zoeken:

spoiler:

[code=vba]
Public Sub FindMaze()
Dim row As Long
Dim myvalue As Long
Dim myRange As Range
Dim teller As Long

Set myRange = ThisWorkbook.Worksheets(1).Range("C1:C1097")
row = 1
While row < 1098
myvalue = myRange.Cells(row, 1).Value
If myvalue >= 3 Then
myRange.Cells(row, 1) = myvalue - 1
Else
myRange.Cells(row, 1) = myvalue + 1
End If
row = row + myvalue
teller = teller + 1
If teller Mod 1000 = 0 Then
Debug.Print teller
DoEvents
End If
Wend

Debug.Print "Escaped"
Debug.Print teller

End Sub
[/code]

[Hydra]

Dag 5 in Kotlin

Toen ik na 3 keer eindelijk de instructies goed gelezen had, was 't makkelijk

@Bolukan da's alleen de oplossing voor deel 2 toch?

[ Voor 11% gewijzigd door Hydra op 05-12-2017 08:08 ]

[ZieglerNichols]

De transitie van deel 1 naar deel 2 was vandaag erg makkelijk. Er zat minder dan 1 minuut tussen het insturen van mijn twee antwoorden, inclusief de 9 seconden rekentijd voor deel 2.

[ Voor 4% gewijzigd door ZieglerNichols op 05-12-2017 08:21 ]

[Verwijderd]

Eerste versie in C deed over probleem 1 en 2 samen ongeveer 150 ms inclusief file i/o, na wat refactoring rond de 75ms. Die winst was ik dan wel al kwijt aan extra programmeertijd. Was vergeten een kopie van een array te maken om deel 2 uit te rekenen.

[ Voor 17% gewijzigd door Verwijderd op 05-12-2017 08:32 ]

[Lye]

ZieglerNichols schreef op dinsdag 5 december 2017 @ 08:21:
De transitie van deel 1 naar deel 2 was vandaag erg makkelijk. Er zat minder dan 1 minuut tussen het insturen van mijn twee antwoorden, inclusief de 9 seconden rekentijd voor deel 2.

9 seconden, wablief?! Ik vind het al naar dat mijn oplossing er 130ms over doet... Welke taal gebruik je, als ik vragen mag?

Vandaag tail recursion gebruikt, ik probeer zoveel mogelijk functionaliteit van Kotlin te mis/gebruiken, terwijl ik stiekem ook erg het FP idioom wil aanhangen. Helaas vroeg vandaag toch eigenlijk echt wel om mutable data structuren.

[ Voor 22% gewijzigd door Lye op 05-12-2017 08:36 ]

[ZieglerNichols]

Lye schreef op dinsdag 5 december 2017 @ 08:32:
9 seconden, wablief?! Ik vind het al naar dat mijn oplossing er 130ms over doet... Welke taal gebruik je, als ik vragen mag?

De 9 seconde is in MATLAB, wat niet bepaald bekend staat om zijn executie snelheid

Gelukkig is code kloppen in MATLAB wel heel snel en efficient, dus voor dit soort challenges weegt het voordeel van snel code genereren voor mij op tegen de langzame execution tijd. Dat blijkt ook wel omdat ik nog nummer 1 sta in de Tweakers private leaderboard

[Lye]

Ah kijk, ik begon al te twijfelen aan mijn leesskills dat ik zal gooien op een gebrek aan koffie.

[kenneth]

Lye schreef op dinsdag 5 december 2017 @ 08:32:
Helaas vroeg vandaag toch eigenlijk echt wel om mutable data structuren.

Dat leek me op de eerste blik ook dus ik heb stiekem iets in C# geklopt om de oplossing maar te hebben. De rest van de dag nadenken over een immutable oplossing maar ik zie hem vooralsnog niet. Zou dan ook een beetje immutability omwille van de immutability worden maar daar zijn dit soort contests voor, toch?

[Edwin88]

Verwijderd schreef op dinsdag 5 december 2017 @ 08:30:
Eerste versie in C deed over probleem 1 en 2 samen ongeveer 150 ms inclusief file i/o, na wat refactoring rond de 75ms. Die winst was ik dan wel al kwijt aan extra programmeertijd. Was vergeten een kopie van een array te maken om deel 2 uit te rekenen.

Ik denk dat ongeveer de helft van iedereen die mee doet dit probleem bij de eerste testrun tegenkwam (indien je in een taal schrijft die dit toestaat)

[Hydra]

ZieglerNichols schreef op dinsdag 5 december 2017 @ 08:38:
Dat blijkt ook wel omdat ik nog nummer 1 sta in de Tweakers private leaderboard

Dat heeft vooral het e.e.a. te maken met hoe laat je opstaat

Edwin88 schreef op dinsdag 5 december 2017 @ 08:56:
Ik denk dat ongeveer de helft van iedereen die mee doet dit probleem bij de eerste testrun tegenkwam (indien je in een taal schrijft die dit toestaat)

Kotlin ftw: immutable by default

Lye schreef op dinsdag 5 december 2017 @ 08:32:
Vandaag tail recursion gebruikt, ik probeer zoveel mogelijk functionaliteit van Kotlin te mis/gebruiken, terwijl ik stiekem ook erg het FP idioom wil aanhangen. Helaas vroeg vandaag toch eigenlijk echt wel om mutable data structuren.

Cool! Daar moet ik ook eens wat dieper induiken. Bedankt dat je me eraan herinnert dat Kotlin dat snapt.

[ Voor 70% gewijzigd door Hydra op 05-12-2017 09:07 ]

[vliegnerd]

Lye schreef op dinsdag 5 december 2017 @ 08:32:
[...]

9 seconden, wablief?! Ik vind het al naar dat mijn oplossing er 130ms over doet... Welke taal gebruik je, als ik vragen mag?

Mijn python3 versie doet er veel meer dan 9 seconden over. Niet getimed, maar het zou zo maar 1 minuut kunnen zijn.



Het is natuurlijk wel leuk om het sneller te maken, maar niet efficient. De tijd vanaf het lezen van de vraag tot het invullen van het antwoord wordt er niet korter van. Ben wel benieuwd naar betere algoritmes.

[Edwin88]

vliegnerd schreef op dinsdag 5 december 2017 @ 09:25:
[...]

Mijn python3 versie doet er veel meer dan 9 seconden over. Niet getimed, maar het zou zo maar 1 minuut kunnen zijn.
...

Een typescript/node omgeving doet er net niet 1 second over... Hoe kan Python zo langzaam zijn? Gebruik je een raar algoritme?

Mijn tweede deel:

spoiler:

function breakoutDifferent(jumpArr: number[]) {
let index = 0;
let steps = 0;

do {
steps++;
index += (jumpArr[index] >= 3) ? jumpArr[index]-- : jumpArr[index]++;
} while(jumpArr.length > index || index < 0);

return steps;
}

[DRaakje]

275 ms voor part 1 en 2.

Wel erg makkelijk
https://pastebin.com/HqcpyJFA

[Verwijderd]

[...]

Kotlin ftw: immutable by default

Het heeft er meer mee te maken dat een array default by value wordt meegegeven bij een functie-aanroep. Dat is nou net een taalconstructie die C bij arrays niet kent. Moet dat maar accepteren, of anders alles als const, of toch in php gaan oplossen natuurlijk.

[ Voor 16% gewijzigd door Verwijderd op 05-12-2017 09:57 ]

[Lye]

Verwijderd schreef op dinsdag 5 december 2017 @ 09:56:
[...]


Het heeft er meer mee te maken dat een array default by value wordt meegegeven bij een functie-aanroep. Dat is nou net een taalconstructie die C bij arrays niet kent.

In Kotlin wordt een array ook by reference meegegeven. Het zijn echter datastructuren als lists, sets en maps die by default immutable zijn. Je moet expliciet aangeven dat een collectie mutable is, anders maak je gewoon een kopie van de structuur wanneer je dingen toevoegt. Op voorwaarde dat je de goede operators gebruikt. Een list heeft bijvoorbeeld geen "add" method, maar wel een "plus" operator die een kopie maakt met het toe te voegen element.

Overigens zijn er wel ideeën om by value passing toe te voegen voor alle data types.

[ Voor 5% gewijzigd door Lye op 05-12-2017 10:00 ]

[dcm360]

Braaf tail recursion en immutable data structures gebruikt: deel 2 deed er 4 minuten over (kwestie van aanzetten en even gaan douchen).
Als ik hetzelfde ding met een gewone array uitvoer gaat het overigens binnen een seconde...

Code komt vanavond nog wel online, nu geen tijd voor om dat net genoeg te maken

[ Voor 16% gewijzigd door dcm360 op 05-12-2017 10:01 ]

[Ryada]

Ben je met Day3 part 2 bezig, denk je het antwoord te hebben, is het antwoord fout. Maar het zou het correcte antwoord voor iemand anders zijn. Of ik ben gewoon goed of er klopt iets niet xD

[Verwijderd]

Lye schreef op dinsdag 5 december 2017 @ 09:59:
[...]


In Kotlin wordt een array ook by reference meegegeven. Het zijn echter datastructuren als lists, sets en maps die by default immutable zijn. Je moet expliciet aangeven dat een collectie mutable is, anders maak je gewoon een kopie van de structuur wanneer je dingen toevoegt. Op voorwaarde dat je de goede operators gebruikt. Een list heeft bijvoorbeeld geen "add" method, maar wel een "plus" operator die een kopie maakt met het toe te voegen element.

Overigens zijn er wel ideeën om by value passing toe te voegen voor alle data types.

Kotlin ken ik verder niet, dus moet misschien iets nauwkeuriger zijn: in php worden arrays by value doorgegeven. Het is wel grappig: als ik met de mindset van C naar php kijk, of andersom, snap ik nauwelijks nog wat er gebeurt. Moet echt even intern paradigmshiften (kop koffie of zo).

[Lye]

Verwijderd schreef op dinsdag 5 december 2017 @ 10:06:
[...]


Kotlin ken ik verder niet, dus moet misschien iets nauwkeuriger zijn: in php worden arrays by value doorgegeven. Het is wel grappig: als ik met de mindset van C naar php kijk, of andersom, snap ik nauwelijks nog wat er gebeurt. Moet echt even intern paradigmshiften (kop koffie of zo).

Dat ligt natuurlijk meer aan PHP dan aan C, de meeste andere "grote" talen doen arrays ook fatsoenlijk by reference.

[Hydra]

Verwijderd schreef op dinsdag 5 december 2017 @ 09:56:
Het heeft er meer mee te maken dat een array default by value wordt meegegeven bij een functie-aanroep. Dat is nou net een taalconstructie die C bij arrays niet kent. Moet dat maar accepteren, of anders alles als const, of toch in php gaan oplossen natuurlijk.

Het punt is dat Kotlin aanstuurt op immutability als default. Juist om dat soort fouten te voorkomen. Kotlin 'kent' ook prima mutable data structuren maar die moet je expliciet gebruiken.

[Verwijderd]

Lye schreef op dinsdag 5 december 2017 @ 10:22:
[...]


Dat ligt natuurlijk meer aan PHP dan aan C, de meeste andere "grote" talen doen arrays ook fatsoenlijk by reference.

Het is wel een discussie wat precies fatsoenlijk is. Vanuit het gezichtspunt van C is de gebruikte methode de beste (en eigenlijk de enige: array is pointer). Aan de andere kant, voor een taal als php die in een nogal "rommelige" webomgeving wordt gebruikt, is de by value methode wel makkelijk. Minder kans op onbedoelde neveneffecten als iemand een array wijzigt in een of andere functie.

[Verwijderd]

Hydra schreef op dinsdag 5 december 2017 @ 10:33:
[...]


Het punt is dat Kotlin aanstuurt op immutability als default. Juist om dat soort fouten te voorkomen. Kotlin 'kent' ook prima mutable data structuren maar die moet je expliciet gebruiken.

Dank je voor deze uitleg.

Ik denk ook dat immutability by default op zich het beste is. Wijzigen van datastructuren buiten de scope van je eigen functie / class / whatever betekent toch ergens dat je buiten je eigen verantwoordelijkheidsgebied bezig bent.

[Lye]

Verwijderd schreef op dinsdag 5 december 2017 @ 10:34:
[...]


Het is wel een discussie wat precies fatsoenlijk is. Vanuit het gezichtspunt van C is de gebruikte methode de beste (en eigenlijk de enige: array is pointer). Aan de andere kant, voor een taal als php die in een nogal "rommelige" webomgeving wordt gebruikt, is de by value methode wel makkelijk. Minder kans op onbedoelde neveneffecten als iemand een array wijzigt in een of andere functie.

In theorie wel ja, zij het dat objecten vervolgens wel weer by reference zijn.. Ik moest ook daadwerkelijk opzoeken hoe het in PHP ook alweer zat. Het blijft inconsistent

[Hopscotch]

Helemaal leuk is dat in php de array by reference doorgegeven wordt totdat deze gemanipuleerd wordt. Dan wordt er een kopie gemaakt.

[Verwijderd]

Lye schreef op dinsdag 5 december 2017 @ 10:39:
[...]


In theorie wel ja, zij het dat objecten vervolgens wel weer by reference zijn.. Ik moest ook daadwerkelijk opzoeken hoe het in PHP ook alweer zat. Het blijft inconsistent

Daarom denk ik dat in php -> wordt gebruikt bij objecten. Een reminder dat het een pointer is. Komend vanuit C++ komt dat heel natuurlijk over. Merk dat ik daar nooit zo over heb nagedacht. Het zat er zo bij me ingeramd dat het me volledig logisch overkwam dat het dus by reference is, en dat dat eigenlijk wat raar is voor de taal. Alhoewel ik ook wel snap dat een deepcopy van een object bij elke aanroep wat ingewikkeld zou worden.

[Lye]

Verwijderd schreef op dinsdag 5 december 2017 @ 10:53:
[...]


Daarom denk ik dat in php -> wordt gebruikt bij objecten. Een reminder dat het een pointer is. Komend vanuit C++ komt dat heel natuurlijk over. Merk dat ik daar nooit zo over heb nagedacht. Het zat er zo bij me ingeramd dat het me volledig logisch overkwam dat het dus by reference is, en dat dat eigenlijk wat raar is voor de taal. Alhoewel ik ook wel snap dat een deepcopy van een object bij elke aanroep wat ingewikkeld zou worden.

-> wordt gebruikt omdat . al gebruikt wordt voor string concatenation. Dat het ook in C wordt gebruikt voor structs en pointers is een leuke bijkomstigheid, echter niet zo bedoeld.

[Kraay89]

Ik heb dag 3 deel 1 af en dag 4 en 5 nu ook.

Dag 3 kost me erg veel moeite. Ik ben tijden bezig geweest om een slim algoritme te vinden maar daar liet mijn index-fu me keer op keer in de steek. Uiteindelijk maar ge-bruteforced door kwadrantjes van de spiral te genereren voor elke ronde en dan wat snelle vergelijkingen uit te dokteren.
Deel 2 gaat ook een bruteforce worden lijkt me, maar ik ben er nog niet over uit hoe.

Dag 4 was goed te doen, liep alleen bij deel 2 te kutten met nested loops, waardoor ik scheef aan het tellen was.

Dag 5 was relatief makkelijk. Ik heb het eerst geprobeerd met een recursieve functie, maar daar bleef ik tegen de max recursion depth aanlopen. Na het kiezen voor een meer straightforward implementatie en het vinden van de antwoorden snap ik wel waarom . Deel 1 is klaar in ~1 seconde en deel 2 ergens tussen de 5 en 10 seconden in python.

[ Voor 27% gewijzigd door Kraay89 op 05-12-2017 11:35 ]

[ThaStealth]

Dag 5 Deel 1 had ik binnen paar minuten af, deel 2 heb ik wel 10 minuten naar mijn code gestaard en 5x geprobeerd waardoor ik tegen de anti brute force filteringen aanliep . Uiteindelijk gebruikte ik de (gemanipuleerde) input van probleem 1 als input voor probleem 2 waardoor de uitkomst veeeel lager was.

Rookie foutje en niet geraliseerd dat arrays by ref en niet by val worden doorgegeven in C#....

Kraay89 schreef op dinsdag 5 december 2017 @ 11:26:

Dag 5 was relatief makkelijk. Ik heb het eerst geprobeerd met een recursieve functie, maar daar bleef ik tegen de max recursion depth aanlopen. Na het kiezen voor een meer straightforward implementatie en het vinden van de antwoorden snap ik wel waarom . Deel 1 is klaar in ~1 seconde en deel 2 ergens tussen de 5 en 10 seconden in python.

5-10 seconde is vrij traag volgens mij, bij mij zijn ze beide < 0.5 sec klaar. (wel in C#, maar Python zal echt niet onderdoen)

[ Voor 42% gewijzigd door ThaStealth op 05-12-2017 11:37 ]

[ZieglerNichols]

Ryada schreef op dinsdag 5 december 2017 @ 10:06:
Ben je met Day3 part 2 bezig, denk je het antwoord te hebben, is het antwoord fout. Maar het zou het correcte antwoord voor iemand anders zijn. Of ik ben gewoon goed of er klopt iets niet xD

Niet iedereen heeft dezelfde puzzel-input, dus je kan niet zomaar jouw antwoord met dat van iemand anders vergelijken. Wat voor de een goed is, kan voor de andere fout zijn.

[Ryada]

ZieglerNichols schreef op dinsdag 5 december 2017 @ 11:38:
[...]


Niet iedereen heeft dezelfde puzzel-input, dus je kan niet zomaar jouw antwoord met dat van iemand anders vergelijken. Wat voor de een goed is, kan voor de andere fout zijn.

Dat begrijp ik, maar ik gebruik 100% zeker mijn eigen input van de website. Heb het ondertussen 3x gechecked.

[kenneth]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:26:
Dag 5 was relatief makkelijk. Ik heb het eerst geprobeerd met een recursieve functie, maar daar bleef ik tegen de max recursion depth aanlopen. Na het kiezen voor een meer straightforward implementatie en het vinden van de antwoorden snap ik wel waarom . Deel 1 is klaar in ~1 seconde en deel 2 ergens tussen de 5 en 10 seconden in python.

Ondersteunt python geen tail call optimization? Ik ken python niet (goed) maar met alle functionele features zou ik dat nou wel verwachten. Of was je functie niet tail recursive?

---

Ik heb het nadenken over immutability maar opgegeven. Dat zou echt te ver gezocht zijn. Het is goed zo.

[Kraay89]

ThaStealth schreef op dinsdag 5 december 2017 @ 11:36:

[...]

5-10 seconde is vrij traag volgens mij, bij mij zijn ze beide < 0.5 sec klaar. (wel in C#, maar Python zal echt niet onderdoen)

Dat ben ik zeker met je eens, maar ik zou zo 1-2-3 even niet weten waar ik kan schaven. (Ik ben maar hobbyist)

spoiler:

Ik loop gewoon door de array heen aan de hand van de instructies, d.m.v. een while True loop. Ik vang de onvermijdelijke (en gewenste) IndexError af en breek dan de loop.

[Brandts]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:26:
Ik heb dag 3 deel 1 af en dag 4 en 5 nu ook.

Dag 3 kost me erg veel moeite. Ik ben tijden bezig geweest om een slim algoritme te vinden maar daar liet mijn index-fu me keer op keer in de steek. Uiteindelijk maar ge-bruteforced door kwadrantjes van de spiral te genereren voor elke ronde en dan wat snelle vergelijkingen uit te dokteren.
Deel 2 gaat ook een bruteforce worden lijkt me, maar ik ben er nog niet over uit hoe.

Ik ben nu bezig met dag 3. Deel 1 heb ik weten te reduceren tot 1 enkele wiskundige formule. Hiervoor hoef ik dus eigenlijk niets te programmeren met loops o.i.d.

Deel 2 kan ik zo even niets anders bedenken dan brute forcen. Helaas is de formule uit deel 1 hier nutteloos.

[Lye]

kenneth schreef op dinsdag 5 december 2017 @ 11:43:
[...]

Ondersteunt python geen tail call optimization? Ik ken python niet (goed) maar met alle functionele features zou ik dat nou wel verwachten. Of was je functie niet tail recursive?

Nope. Python ondersteunt geen tail recursion. Blijkbaar zijn terug te halen stacktraces belangrijker dan efficiëntie.

Ik heb het nadenken over immutability maar opgegeven. Dat zou echt te ver gezocht zijn. Het is goed zo.

Ik zie ook niet in hoe dit fatsoenlijk te doen is (Dus zonder een exponentieel trager programma).

ThaStealth schreef op dinsdag 5 december 2017 @ 11:36:
5-10 seconde is vrij traag volgens mij, bij mij zijn ze beide < 0.5 sec klaar. (wel in C#, maar Python zal echt niet onderdoen)

Ik heb zojuist ook een simpele Python versie gebouwd, die deed er ook 6 seconden over.. Ik ben er nog niet achter waar de bottleneck zit, maar het is wel verschrikkelijk traag.

[ Voor 27% gewijzigd door Lye op 05-12-2017 11:57 ]

[Merethil]

Lye schreef op dinsdag 5 december 2017 @ 11:47:
[...]

Nope. Python ondersteunt geen tail recursion. Blijkbaar zijn terug te halen stacktraces belangrijker dan efficiëntie.

[...]

Ik zie ook niet in hoe dit fatsoenlijk te doen is (Dus zonder een exponentieel trager programma).

[...]

Ik heb zojuist ook een simpele Python versie gebouwd, die deed er ook 6 seconden over.. Ik ben er nog niet achter waar de bottleneck zit, maar het is wel verschrikkelijk traag.

Ik doe 'm dit jaar ook in Python (normaal in Java) en bij mij draaide deel 2 van dag 5 ook in een seconde of 5-6... Het is een vrij simpel stukje code, kan er weinig aan bijschaven.

[Verwijderd]

Heb mijn C implementatie 1-1 vertaald naar php. Runtime gaat van 75ms naar 10s. Ofwel meer dan 100x zo langzaam... (tenzij je xdebug uitschakelt, dan zijn het er nog "maar" 2 )

spoiler: phpcode

$clock = 0;
$ip = 0;
$len = count($instructions);
while ($ip >= 0 && $ip < $len) {
    $ip += $instructions[$ip] >= 3 ? $instructions[$ip]-- : $instructions[$ip]++;
    $clock++;
}

En als je de caching van de lengte van het array niet uitvoert, wordt het een whopping 22 seconden.....

Ik vermoed dat een van de oorzaken is, dat de C executable voor het grootste deel in L1 (en/of) L2 cache van de processor draait, terwijl php en python implementaties daar niet zo goed in passen. Is maar een wilde gok.

Update: en uitschakelen van xdebug is ook wel dienstig. Looptijd is nu nog 2 seconden.

[ Voor 32% gewijzigd door Verwijderd op 05-12-2017 12:48 ]