6 ms·

The main difficulty of part 2 is that there are edge cases that are not covered by the examples. I have appended the example list with some edge cases, so use t

by Foivos 3y ago

The main difficulty of part 2 is that there are edge cases that are not covered by the examples. I have appended the example list with some edge cases, so use this list instead: two1nine eightwothree abcone2threexyz xtwone3four 4nineeightseven2 zoneight234 7pqrstsixteen eighthree sevenine oneight xtwone3four three7one7 eightwothree oooneeone eight7eight

codr7 3y ago
I don't get the amount of effort people out into the replacement-strategy, I did perfectly fine without it and the code is about as complex as the examples I've seen. https://github.com/codr7/swift-interpreter/blob/main/part10/aoc/code2.lisp https://github.com/codr7/swift-interpreter/blob/main/part10/...
- Levitz 3y ago
  >replacement-strategy Oh so THAT is what is causing people problems.
- brynbryn 3y ago
  Ahh, people are trying to do a replacement before finding tokens. I wondered why so many people were saying this was difficult. My head went straight to token parsing, which given the limited set of tokens made it trivial. Thought I was missing something
  - skydhash 3y ago
    I think people with understanding of compilers always want to model their code as DSL, and that makes it easier to go for backwards scanning.
- deleted 3y ago
  [deleted]
- messe 3y ago
  Yeah, all the talk of replacement seems like people masively overthinking or abstracting a day one problem. My C++ solution was a simple search using the <algorithm> header. It's a little less neatly abstracted out as yours, and could be cleaned up a fair bit, as I wasn't bothered to deduplicate the code after getting it working (and I will if this turns out to be useful tomorrow), but the essence is the same: https://gist.github.com/joedavis/3d6f2b87bae4809ef8a062caff756119 https://gist.github.com/joedavis/3d6f2b87bae4809ef8a062caff7... C++'s .rbegin() / .rend() reverse iterators made the search fairly trivial.
  - matsemann 3y ago
    I disagree on it being "overthinking". I just did replacement without really thinking. Saw that it failed on the "eightwo" case since "two" got replaced first, so just replaced "two" with "two2two" instead, then passed it through solver for part1. To me that's simpler and more naive than correctly writing a search or backwards-forwards regex :) My solution in Kotlin https://github.com/kolonialno/adventofcode/commit/686cbebb07e86ac981cd12bf3b6e42828d985958 https://github.com/kolonialno/adventofcode/commit/686cbebb07...

by Foivos 3y ago

codr7 3y ago

I don't get the amount of effort people out into the replacement-strategy, I did perfectly fine without it and the code is about as complex as the examples I've seen. https://github.com/codr7/swift-interpreter/blob/main/part10/aoc/code2.lisp https://github.com/codr7/swift-interpreter/blob/main/part10/...

Levitz 3y ago
>replacement-strategy Oh so THAT is what is causing people problems.
brynbryn 3y ago
Ahh, people are trying to do a replacement before finding tokens. I wondered why so many people were saying this was difficult. My head went straight to token parsing, which given the limited set of tokens made it trivial. Thought I was missing something
- skydhash 3y ago
  I think people with understanding of compilers always want to model their code as DSL, and that makes it easier to go for backwards scanning.
deleted 3y ago
[deleted]
messe 3y ago
Yeah, all the talk of replacement seems like people masively overthinking or abstracting a day one problem. My C++ solution was a simple search using the <algorithm> header. It's a little less neatly abstracted out as yours, and could be cleaned up a fair bit, as I wasn't bothered to deduplicate the code after getting it working (and I will if this turns out to be useful tomorrow), but the essence is the same: https://gist.github.com/joedavis/3d6f2b87bae4809ef8a062caff756119 https://gist.github.com/joedavis/3d6f2b87bae4809ef8a062caff7... C++'s .rbegin() / .rend() reverse iterators made the search fairly trivial.
- matsemann 3y ago
  I disagree on it being "overthinking". I just did replacement without really thinking. Saw that it failed on the "eightwo" case since "two" got replaced first, so just replaced "two" with "two2two" instead, then passed it through solver for part1. To me that's simpler and more naive than correctly writing a search or backwards-forwards regex :) My solution in Kotlin https://github.com/kolonialno/adventofcode/commit/686cbebb07e86ac981cd12bf3b6e42828d985958 https://github.com/kolonialno/adventofcode/commit/686cbebb07...