Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Paul
    @Meakeel
    I liked today, it wasn't as bad as the int computer one the other year
    that nearly killed me
    Scarecrowe
    @Scarecrowe
    i liked the int computer one also :D
    Paul
    @Meakeel
    Right I need to head to bed, I'm knackered!
    alexwoods14
    @alexwoods14
    I have an error in my part 1 but only if i remove some print statements. I think I'm starting to lose my mind
    Paul
    @Meakeel
    Thats odd.
    alexwoods14
    @alexwoods14
    extremely. They are simple print statements as well. nothing fancy involved
    write(*,*) "lentype = 1, ", lenarg, "subpackets" is one of the culprits. including it gives 977 (correct), commenting it out gives 802
    even a blank write(*,*) gives the correct answer but its suddenly wrong when its removed.
    Jonathan George
    @jongeorge1
    That's very odd.
    alexwoods14
    @alexwoods14
    My biggest bodge so far, I've replaced them all with write(*,'()',advance="no") which makes them print nothing.
    code works but I don't like or trust it
    Different compiler works so it's not my code. gfortran gives me 977 and ifort gives me a wrong answer on the same code and input
    Jonathan George
    @jongeorge1
    !
    alexwoods14
    @alexwoods14
    This is surreal. It's now broken for both compilers yet my part 2 works completely fine with either.
    alexwoods14
    @alexwoods14
    As is often the case, it was my fault. I defined versum but never initialised it to 0. It was being assigned space in memory and just assumed that value when the first sum happened.
    image.png
    It's quick at least. 56 microseconds
    Total time for all 16 days:
    image.png
    Paul
    @Meakeel

    Thats pretty fast, I don't have the energy today to use gradient descent or similar, brute force all the way

    for (let i = 0; i < targetArea.x[1]; i++) {
    for (let j = 0; j < targetArea.y[1]; j++) {
    new Probe(i, j, targetArea).runProbe();
    }
    }

    alexwoods14
    @alexwoods14
    I gave up and brute forced it too. I was close with a decent one so I'll try and improve it another day if i have the effort for it
    I take that back. If I dont search such a massive area brute force only takes 45ms which I'm more than happy with
    The problem would have been better if the target size was larger such that it couldn't be so easily brute forced in my opinion
    alexwoods14
    @alexwoods14
    Rather interestingly, my bash script to run and time all them runs each one faster than If I run them individually. Similar to what @jongeorge1 has but unexpected due to the different memory management
    image.png
    Paul
    @Meakeel
    Ahh I actually had a problem with my brute force, I didn't make the area big enough
    I think I went -300 to +300 on both the x and y to get the right answer
    still pretty quick
    its a weekday one
    don't assume he will not make it harder
    a previous year there was like 10 days in a row that used the previous days code
    Jonathan George
    @jongeorge1
    The intcode VM :)
    I've not spent long on today's yet. I've knocked out half a potential solution to day 1. But probably the easy half 😂
    Still, if ever there was a day for parallelising the brute force approach... maybe I can give my CPU a workout today...
    image.png
    alexwoods14
    @alexwoods14

    I think I went -300 to +300 on both the x and y to get the right answer

    I changed my bounds to X vel 0 to maxX and Y as minY to -Miny.
    Runs in 0.5ms now

    I haven't yet had a reason to parallelise my code but one of the later days I will
    Jonathan George
    @jongeorge1
    Yeah, I think it's unlikely in practice. Historically, the only puzzles that have taken longer than a few 100ms have been the ones that required calculation of 10's of thousands of hashes. Anything else that took longer was normally because the challenge was in the optimisation.
    alexwoods14
    @alexwoods14
    I'm currently studying high performance computing so I'll parallelise one of them just for the sake of it. I'm not expecting it to give much performance benefit as its not that kind of problem as you say
    Jonathan George
    @jongeorge1
    Oh FFS. That is a lot of reading today.
    Iain M Norman
    @IainMNorman
    Having Covid gives me a pass :-)
    Jonathan George
    @jongeorge1
    Noooo
    You ok?
    alexwoods14
    @alexwoods14

    Oh FFS. That is a lot of reading today.

    Far too much

    Scarecrowe
    @Scarecrowe
    It is a mental head fuck today :D
    alexwoods14
    @alexwoods14
    I think I'm going to leave it a few days and catch up on my long train journey home on the 22nd. I had a quick read through and it seems tricky to understand
    Scarecrowe
    @Scarecrowe
    There is a lot to take in with parsing the data correctly
    Paul
    @Meakeel
    I'm so glad part 2 was easy today
    Scarecrowe
    @Scarecrowe
    day22-timings.PNG