DEV Community: bretthancox

Python list comprehensions - help with syntax

bretthancox — Tue, 14 Dec 2021 17:14:35 +0000

I struggled with list comprehensions in Python. The syntax seemed so alien and strange. What ended up helping me out most was understanding the logic behind them.

Imagine a for loop like this:

example_list = []

for x in range(10):
    example_list.append(x)

# Result: example_list == [0,1,2,3,4,5,6,7,8,9]

This loop is better written as a list comprehension. The list comprehension will retain readability and require less code.

How to do that? Start with the thing you want in the list: the values of x

example_list = [x]

for x in range(10):
    example_list.append(_)

# x has been moved from the for loop up into the list. This is step 1 - this code will not run until we complete the subsequent steps.

Now we have the end result in the list (x) we need to tell the list where the x comes from. In this case it is the values generated by iterating over range(10). We can transplant that line into the list comprehension:

example_list = [x for x in range(10)]

___ _ __ _________:
    example_list.append(_)

# Now we move the "for" logic up into the list comprehension. This is step 2 - the logic is in the list comprehension and the remains of the for loop need to be cleaned out.

Then, clear out the unnecessary content:

example_list = [x for x in range(10)]

# Result: example_list == [0,1,2,3,4,5,6,7,8,9]

I like to think of this as a sentence:

Add the value of x to this list for every integer value of x in the range 0 to 10.

List comprehensions follow a pattern. The pattern can be more complicated than our simple example, as follows:

[<the result to add to the list>  <the iterable or logic that generates the result>  <the conditions under which the result is added>]

The conditions are things like if statements. For example, the following if statement updates our for loop to produce only even numbers:

example_list = []

for x in range(10):
    if x%2 == 0:
        example_list.append(x)

# Result: example_list == [0,2,4,6,8]

If we skip to the point where the result and the for loop are in the list comprehension, we can see that the if statement is the remaining piece of our loop that needs to be transplanted:

example_list = [x for x in range(10)]

___ _ __ _________:
    if x%2 == 0:
        example_list.append(_)

Following the earlier pattern, we transplant the if statement to the end of the list comprehension:

example_list = [x for x in range(10) if x%2 == 0]

___ _ __ _________:
    __ ___ __ _:
        example_list.append(_)

Then tidy up the rest:

example_list = [x for x in range(10) if x%2 == 0]

# Result: example_list == [0,2,4,6,8]

With this information, you can build up to more complicated list comprehensions. For example, the result can be its own operation. The following code takes an existing list and sums the value of the current index and the subsequent 2 values. It also uses an if statement to prevent an out of bounds error.

source = [2,4,5,7,91,10,12,45,32,52,67]

sum_list = [sum(source[index:index+3]) for index in range(len(source)) if index+3 <= len(source)]
           #<------ THE RESULT ------>#<-------- THE ITERABLE ------->#<---- THE CONDITION ----->#

## Ouput = [11, 16, 103, 108, 113, 67, 89, 129, 151]

## Result == sum(source[index:index+3])
## Sum the values found at index n, n+1, and n+2. E.g. for index 
## 0, the individual operation would be sum([2,4,5]) for a value 
## of 11.

## Iterable = for index in range(len(source))
## Use the length of the source list to provide an iterable that
## yields values for use as the index. The index is the output of 
## this iterable which is used in the result.

## Condition = if index+3 <= len(source)
## Only use index if there are enough values left in the list to 
## sum. The last three-number grouping is sum([32,52,67]). Without 
## the if statement, the code would try to retrieve a value after 
## 67 on the next value of index and hit an out of bounds error.

Using the sentence approach, I would write this as:

Sum the values found at index n, n+1, and n+2 in the source list, where the value of n is between 0 and the length of the source list, as long as the source list is long enough to provide a value at n, n+1, and n+2.

I'm sure there is some aspect of my code that is non-pythonic, but I also hope this was helpful to someone struggling with list comprehensions. If you've made it through the basics of python, you have the information necessary to understand list comprehensions.

As my final note, there is very little as satisfying in writing python as when you build a complex list comprehension and it works first try.

Particle and the end of mesh

bretthancox — Wed, 29 Jan 2020 14:57:26 +0000

The situation

Particle is an IoT company specializing in a combination of hardware and cloud services. The great benefit of Particle is that you get a streamlined over-the-air update/programming setup, online management, and a lot of convenience features around exposing functions and variables to your own web requests.

With a customer update and forum post, Particle just announced the end of support for their two year old mesh technology. Built on top of the Nordic nRF52840 and OpenThread, the technology allowed for gateway devices (named Argon and Boron, Wi-Fi and Cellular) to provide a connection to the outside world while node devices (Xenon) would connect to each other and, when needing an internet connection, call out through the gateway.

The announcement makes clear that the xenon line will no longer be supported and the gateway devices will function as connected, but standalone, boards.

The announcement.

My take

Any company with multiple products faces this situation eventually: what do you do when one or more of your products is no longer profitable, whether it is not generating enough revenue or costs to build/design/support are too high? If you end the product line, you have to determine the risk of doing so.
For products such as Windows, a published support plan mitigates risk for customers. If I were to install Windows 8 today, I can easily look at the Microsoft support plan and see when it will no longer be supported. I cannot claim I was not informed.
For any product that wants to be used by commercial entities, you need predictability, reliability, and unambiguous support. Google is notorious for undermining these factors in all but its core product suite. Google Stadia? We promise we're really keen on games. Trust us! Google Inbox? Sorry, but we got bored (I'm sure it's not the reason, but I'm bitter about that one).
It's not a good look. Google gets away with it because it can rely on the fact that it's the biggest player in most markets.

Which brings us back to Particle.
In my opinion, the death of mesh and the Xenon is the signal to any sensible potential or current customer of Particle that you should not trust them with your revenue. Particle likes to tout the use of its boards in industry; what happens to anyone using the Xenon line in a product? You have a year to find an alternative. In Product timelines, that's gun-to-the-head territory.

Particle recommends using either CircuitPython or the OpenThreads SDK as an alternative, but neither of those options allow the Xenon to connect to a gateway. Without a gateway, there's no access to Particle Cloud. Without the Particle Cloud...well, why am I dealing with Particle at all?
None of this means Particle will end any of their other products, but the problem I see is that you can't guarantee that.

In one move, in my opinion, Particle just signaled that it is for hobbyists and proof-of-concepts only. If you need a real-world solution, roll your own. It will take more time, it will cost more money up-front, but it's yours. If you rely on anyone else, you trade convenience for uncertainty. If you take that bet, you have a better tolerance for risk than me.

Advent of Code 2019 - Day 5 (in Rust!)

bretthancox — Sun, 05 Jan 2020 20:24:30 +0000

Introduction

The thought of revisiting my Clojure version of the Intcode "computer" horrified me. I will be continuing with the Advent of Code, but personal time is limited, so I'll be taking my sweet time. Since I am not competing on time, and my prior implementation was painful to revise, I wanted to write it again.

Time to break out Rust and only rely on the Rust book (with help from the wider internets for some things like user input).

Day 5.1

Rehashing my description from the Clojure version:
Part 1 of Day 5 requires that the Intcode computer from Day 2 be updated to accommodate some new features:

The Opcode from Day 2 now comprises 5 digits. This is true even if only one digit is provided - you must infer the rest to be 0.
The Opcodes from Day 2 continue to apply, but with some additions that break from the [instruction, parameter1, parameter2, parameter3] setup:
1. Opcode 3 means take a value from human input (or simulate it) and write it to the address provided in the parameter x, where (as we will see in a moment) x is either the address to write it, or a pointer to the address to write it: [3, x]
2. Opcode 4 means read the value from an address and print it to the screen. It simulates "diagnostic codes" being printed out. This is like the reverse of Opcode 3.
The Opcode will provide parameter "modes". The modes are binary. For each Opcode, there are between 1 and 3 parameters, thus there are between 1 and 3 modes. In Day 2 the values in the parameters are always pointers to somewhere else in the Intcode. If a parameter mode is 0, that behavior is unchanged. If the mode is 1, use the literal content of the parameter.
1. For Opcode of 1 or 2, you either sum or multiply the literal content of par 1 and par 2
2. For Opcode of 3 or 4 (or any other write to/read from operation), a 0 means read/write to the location defined in the parameter (i.e. a pointer), while a 1 means read/write to the parameter itself. Specifically:
  1. [4, 4, 99, 2, 3] results in printing 3
  2. [104, 4, 99, 2, 3] results in printing 4
The Opcode will be provided in reverse. Example: 101103 - in this case we can break it into ABCDE:
1. A is the mode for parameter 3
2. B is the mode for parameter 2
3. C is the mode for parameter 1
4. DE is the Opcode, now provided as two digits
The new two-digit Opcode is really a single digit Opcode with an unnecessary prefix, so in 01, only the 1 has value.

Now, the Rust

So, Rust requires some prep. What types will I need to make?
For me, I needed two custom types:

The Intcode type, containing the Intcode as supplied and maintaining it through edits, the opcode pointer that tells the "computer" where the current opcode is located, and a boolean that tells the while loop we'll be using whether we found a stop opcode or not.
An ExtendedOpcode type that contains the components of the new, longer opcodes.

#[derive(Debug, Clone)]
pub struct Intcode {
    intcode: Vec<isize>,
    opcode_pointer: usize,
    continue_loop: bool,
}

#[derive(Debug, Clone)]
pub struct ExtendedOpcode {
    opcode: Opcode,
    mode_1: Modes,
    mode_2: Modes,
    mode_3: Modes,
}

Now, what the heck are the Opcode and Modes types?
Those are a pair of enums I used to make my code more readable. Matching integers is entirely possible, but the two enums provide some much more human-friendly labelling:

#[derive(Debug, Clone, PartialEq)]
enum Opcode {
    Stop,
    Add,
    Multiply,
    Input,
    Output,
    JumpIfTrue,
    JumpIfFalse,
    LessThan,
    Equals,
    OtherValue,
}


#[derive(Debug, Clone, PartialEq)]
enum Modes {
    Position,
    Immediate,
}

The remaining setup before we start writing the actual functions that perform the "computer" work are:

Implement PartialEq for the new ExtendedOpcode type (not used in the code itself, but needed for testing. assert! needs PartialEq for any types it is comparing).
A new function for the Intcode type.
A new function for the ExtendedOpcode type.

impl PartialEq for ExtendedOpcode {
    fn eq(&self, comparator: &Self) -> bool {
        self.opcode == comparator.opcode
        &&
        self.mode_1 == comparator.mode_1
        &&
        self.mode_2 == comparator.mode_2
        &&
        self.mode_3 == comparator.mode_3
    }
}

impl ExtendedOpcode {
    fn new(opcode: Opcode) -> Self {
        Self {
            opcode: opcode,
            mode_1: Modes::Position,
            mode_2: Modes::Position,
            mode_3: Modes::Position,
        }
    }
}


impl Intcode {
    fn new(intcode_vec: Vec<isize>) -> Self {
        Self {
            intcode: intcode_vec,
            opcode_pointer: 0,
            continue_loop: true,
        }
    }
}

In this next section you will find the "computer" logic. Here's the breakdown:

work_on_intcode is the "command and control" function, maintaining a while loop until a 99 opcode is found (which sets the self.continue_loop to false, exiting the loop). It calls the get_opcode_method function and uses the output of that function to decide which subsequent action to take.
get_opcode_method extracts the long-form opcode, and calls the split_opcodes function which splits the opcode into pieces, reverses the order, and converts back to integers. Then, adjusting the approach based on the length of the opcode, a new ExtendedOpcode is created and the actual opcode value is put into a match to apply the correct Opcode enum type.
1. The splitting of the long-form opcode means a 99 appears as [9, 9], so to protect me against future 9-prefixed opcodes, I put a sub-match to check that the second value is also a 9, ensuring I have found a 99 opcode.
Now, with the opcode known, I have the day 5.1 functions in place (all functions are named, but they are placeholders for now):
1. add_and_place first determines the values to work with, depending on whether the mode for each is Position or Immediate, then adds the two integers and writes them to the location of the third integer. It moves the opcode_pointer forward 4 places.
2. multiply_and_place is the same as the add function, but it multiplies.
3. take_input makes use of the text_io crate. Add #[macro_use] extern crate text_io; to the main.rs or lib.rs file for your project and then use let user_input: isize = read!(); or similar. The macro will attempt to coerce the type. The rest of the function, similar to the previous two, determines where it is writing to and puts the user input in that location. It increments the opcode_pointer by two as there are only two values associated.
4. print_output effectively does the opposite of three; it reads from a location defined by the opcode modes, and then prints to screen. It then moves the opcode_pointer 2 places.

impl Intcode {
    fn split_opcodes(&self, opcode_full: isize) -> Vec<isize> {
        let unsplit_opcode = opcode_full.to_string();
        let split_opcode = unsplit_opcode.trim().split_terminator("").skip(1).collect::<Vec<&str>>(); //split_terminator("").skip(1) splits the string, but prevents the resulting vector having "" at start and end
        //println!("{:?}", split_opcode);
        let rev_split_opcode = split_opcode.iter().rev().map(|o| o.parse::<isize>().unwrap()).collect::<Vec<isize>>();

        rev_split_opcode
    }


    fn get_opcode_method(&self) -> ExtendedOpcode {
        let opcode_full = self.intcode[self.opcode_pointer];
        let opcode_split = self.split_opcodes(opcode_full);
        //println!("{:?}", opcode_split);
        let mut extended_opcode: ExtendedOpcode = ExtendedOpcode::new(Opcode::OtherValue);

        if opcode_split.len() > 2 && opcode_split[2] == 1 {
            extended_opcode.mode_1 = Modes::Immediate;   
        }

        if opcode_split.len() > 3 && opcode_split[3] == 1 {
            extended_opcode.mode_2 = Modes::Immediate;
        }

        if opcode_split.len() > 4 && opcode_split[4] == 1 {
            extended_opcode.mode_3 = Modes::Immediate;
        }

        match opcode_split[0] {
            9 => match opcode_split[1] {
                9 => extended_opcode.opcode = Opcode::Stop,
                _ => extended_opcode.opcode = Opcode::OtherValue,
            }
            1 => extended_opcode.opcode = Opcode::Add,
            2 => extended_opcode.opcode = Opcode::Multiply,
            3 => extended_opcode.opcode = Opcode::Input,
            4 => extended_opcode.opcode = Opcode::Output,
            5 => extended_opcode.opcode = Opcode::JumpIfTrue,
            6 => extended_opcode.opcode = Opcode::JumpIfFalse,
            7 => extended_opcode.opcode = Opcode::LessThan,
            8 => extended_opcode.opcode = Opcode::Equals,
            _ => extended_opcode.opcode = Opcode::OtherValue,
        }
        //println!("{:?}", self.intcode);
        extended_opcode
    }


    fn add_and_place(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        let write_to = match extended_opcode.mode_3 {
            Modes::Position => self.intcode[ self.opcode_pointer + 3 ] as usize,
            Modes::Immediate => self.opcode_pointer + 3 as usize,
        };

        self.intcode[write_to] = value_1 + value_2;
        self.opcode_pointer += 4;
    }


    fn multiply_and_place(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        let write_to = match extended_opcode.mode_3 {
            Modes::Position => self.intcode[ self.opcode_pointer + 3 ] as usize,
            Modes::Immediate => self.opcode_pointer + 3 as usize,
        };

        self.intcode[write_to] = value_1 * value_2;
        self.opcode_pointer += 4;
    }


    fn take_input(&mut self, extended_opcode: ExtendedOpcode) {
        let user_input: isize = read!();

        let write_to = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.opcode_pointer + 1 ] as usize,
            Modes::Immediate => self.opcode_pointer + 1 as usize,
        };
        self.intcode[write_to] = user_input;
        self.opcode_pointer += 2;
    }

    fn print_output(&mut self, extended_opcode: ExtendedOpcode) {
        let read_from = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.opcode_pointer + 1 ] as usize,
            Modes::Immediate => self.opcode_pointer + 1 as usize,
        };
        let val_to_output = self.intcode[read_from];
        println!("Diagnostic code: {:?}", val_to_output);
        self.opcode_pointer += 2;
    }

    fn jump_if_true(&self, _extended_opcode: ExtendedOpcode) {
        println!("I do nothing, yet.");
    }

    fn jump_if_false(&self, _extended_opcode: ExtendedOpcode) {
        println!("I do nothing, yet.");
    }

    fn less_than(&self, _extended_opcode: ExtendedOpcode) {
        println!("I do nothing, yet.");
    }

    fn equals(&self, _extended_opcode: ExtendedOpcode) {
        println!("I do nothing, yet.");
    }

    fn work_on_intcode(&mut self) -> Result<(), &str> {
        while self.continue_loop {

            let extended_opcode = self.get_opcode_method();

            match extended_opcode.opcode {
                Opcode::Stop => { 
                    println!("Finished.");
                    self.continue_loop = false;
                },
                Opcode::Add => self.add_and_place(extended_opcode),
                Opcode::Multiply => self.multiply_and_place(extended_opcode),
                Opcode::Input => self.take_input(extended_opcode),
                Opcode::Output => self.print_output(extended_opcode),
                Opcode::JumpIfTrue => self.jump_if_true(extended_opcode),
                Opcode::JumpIfFalse => self.jump_if_false(extended_opcode),
                Opcode::LessThan => self.less_than(extended_opcode),
                Opcode::Equals => self.equals(extended_opcode),
                Opcode::OtherValue => return Err("A value outside Opcode range was found."),
                _ => return Err("No idea where this came from..."),
            }
        }

        Ok(())
    }

}

With all of this in place, running it is pretty simple. My convenience file_open function just pulls in the contents of a file as a string and returns a Result containing (hopefully) the string, hence the unwrap to extract it.

The splitting of the string is a little long because it must be split, the result collected into a vector, that vector then iterated over to parse each &str into an integer of type isize. The parse returns a result, so it is unwrapped and the integers are then collected into another vector.

pub fn day_five() {
    let file_input = file_open();
    let input_string = file_input.unwrap();
    let int_vec = input_string.split(",").collect::<Vec<&str>>().iter().map(|o| o.parse::<isize>().unwrap()).collect::<Vec<isize>>();
    let mut intcode_obj = Intcode::new(int_vec);

    let opcode_results = intcode_obj.work_on_intcode();
}

Day 5.2

Adding the functions was simple due to the way I set up my types. Just add the functions and it just works - almost.
The opcode_pointer in jump_if_true and jump_if_false has to be coerced to a usize value because it is being used to access the vector by index. Rust does not allow negative index access, so an isize type would be problematic. A simple as usize makes the change.

fn jump_if_true(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        if value_1 != 0 {
            self.opcode_pointer = value_2 as usize;
        } else {
            self.opcode_pointer += 3;
        }
    }

    fn jump_if_false(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        if value_1 == 0 {
            self.opcode_pointer = value_2 as usize;
        } else {
            self.opcode_pointer += 3;
        }
    }

    fn less_than(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        let write_to = match extended_opcode.mode_3 {
            Modes::Position => self.intcode[ self.opcode_pointer + 3 ] as usize,
            Modes::Immediate => self.opcode_pointer + 3 as usize,
        };

        if value_1 < value_2 {
            self.intcode[write_to] = 1;
        } else {
            self.intcode[write_to] = 0;
        }

        self.opcode_pointer += 4;
    }

    fn equals(&mut self, extended_opcode: ExtendedOpcode) {
        let value_1 = match extended_opcode.mode_1 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 1 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 1 ],
        };

        let value_2 = match extended_opcode.mode_2 {
            Modes::Position => self.intcode[ self.intcode[ self.opcode_pointer + 2 ] as usize ],
            Modes::Immediate => self.intcode[ self.opcode_pointer + 2 ],
        };

        let write_to = match extended_opcode.mode_3 {
            Modes::Position => self.intcode[ self.opcode_pointer + 3 ] as usize,
            Modes::Immediate => self.opcode_pointer + 3 as usize,
        };

        if value_1 == value_2 {
            self.intcode[write_to] = 1;
        } else {
            self.intcode[write_to] = 0;
        }

        self.opcode_pointer += 4;
    }

Advent of Code 2019 - Day 6

bretthancox — Wed, 18 Dec 2019 16:21:57 +0000

Introduction

As part of my ongoing effort to learn Rust, I thought it would be interesting to not just revisit problems I've solved in Clojure (see Day 1 in Rust), but also try to solve problems I haven't figured out.

I think the Intcode computer will live on in Clojure as I have no great desire to revisit it in Rust, but Day 6 is standalone (for now), so I dived right in.

Day 6.1

Types sure are a thing, huh...?
Rust takes some getting used to once you get into more complicated challenges. The type system is relatively intuitive, but puzzling your way through return values is another matter altogether. I struggled with Options returned from HashMaps for a while, making this more complicated than it needed to be, but I guess that's the point of doing something in a language you're learning.

Starting point, a completely unnecessary (as it turned out) custom type. Really, it's a vector masquerading as something more complicated:

pub struct Day6Inputs<'a> {
    day6_input: Vec<&'a str>,
}

I'm still not comfortable with lifetimes in Rust, but the way I use this type means that the compiler recommended it's lifetime ('a) be explicitly defined. So I did as I was told - a lesson for any Rust newbie! Compiler knows best.

Next I allocate the input to the type:

let day6 = Day6Inputs {day6_input: vec!["Z9G)Q7N","D1W)7G9", ***MORE THINGS***, "QRW)9MD","LVF)MGV","RFM)NDH"]};

Then we get into the first meaningful action. I iterate over the day 6 input, mapping a split to each item, spliting the string at ) and storing the resulting pair of strings (or &str) in a vector. Those vectors are then added to another vector.

let capture: Vec<Vec<&str>> = day6.day6_input.iter().map(|x: &&str| x.split(")").collect::<Vec<_>>()).collect::<Vec<Vec<_>>>();

//&&str is because I am passing a reference to a &str into the closure:
// |x: &&str| x.split(")")

//Inside the closure, collect the split string into  a vector (e.g. "Z9G)Q7N" -> ["Z9G", "Q7N"]) using .collect::<Vec<_>>

//Finally collect the resulting vectors of points into another vector, which must be explicitly shown as being a vector of vectors: .collect::<Vec<Vec<_>>>()

Next I want to make a HashMap that shows each point with its immediate children:

{"COM": ["A", "B"], "A": ["C"] etc.}

So I start with the declaration, then I iterate over my vector of vectors. For each sub-vector, the first &str will be the parent, while the second &str will be the child.

let mut connections: HashMap<&str, Vec<&str>> = HashMap::new();

    for combination in capture {
        if connections.contains_key(combination[0]) {
/*This next "let" gets me the value if there is an 
entry with a key that matches the first `&str`.*/
            let value_vec = connections.entry(&combination[0]).or_insert(vec!["Nothing"]);
/*Then it checks if that value (a vector) already contains any 
of the connections. This prevents duplicate entries.*/
            if value_vec.iter().any(|v| v == &combination[1]) {
                println!{"Already in vector"};
            } else {
                value_vec.push(&combination[1]);
            }            
        } else {
            connections.insert(&combination[0], vec![&combination[1]]);
        }
/*This section checks if the child point is present as a key and, if not, 
adds it as a key and an empty vector as the value.
This is necessary as the points with no children would not otherwise 
be recorded in the HashMap.*/
        if !connections.contains_key(combination[1]) {
            connections.insert(&combination[1], Vec::new());
        }
    }

Now, with my HashMap populated, I need to determine the orbits for each point. This is done by counting the children of each child point from whichever starting point is chosen. COM - A - B - C has 6 orbits: 3 for COM, 2 for A, 1 for B, and 0 for C.
I do this with a recursive function:

fn chase_the_longest_path<'b>(connections: &'b HashMap<&str, Vec<&str>>, key_to_use: &'b str) -> usize {
/*Get the value vector out of the HashMap for the key_to_use*/
    let starting_point: Vec<&str> = connections.get(key_to_use).unwrap().to_vec();

/*Declare and assign a counter that begins with the number of orbits for
key_to_use*/
    let mut persistent_counter: usize = starting_point.len();
/*Then, for each point in the value vector associated with key_to_use,
recursively find all child orbits and increment the persistent_counter
with the return value from those recursive functions*/
    for value in starting_point {
        let temp_counter = chase_the_longest_path(connections, value);
        persistent_counter = persistent_counter + temp_counter;
    }
/*Return the counter, either to the earlier instance of this function, 
or to the call in the main function*/
    persistent_counter
}

This recursive function only operates on the chain for one key value, so we need another loop that iterates over the HashMap keys to run the function for each key. We also need a counter to sum the return values for each key, producing our total orbits:

let mut counter: usize = 0;

for (key, _val) in connections.iter() {
    counter += chase_the_longest_path(&connections, key);
}

println!("Total orbits: {}", counter);

And the right answer is returned. This file includes my Day 1 code, yet still takes only 1.027 seconds to run. Clojure is fun to write, but you can't beat that speed.

Update

RECORD SCRATCH

OK. Breathe.

What I did above absolutely does NOT work for part 2. While soothing my brain with well-written rust, I happened upon the following article:

No more tears no more knots arena allocated trees in rust

It turns out that Ben, the author, used the approach in his article to perform his version of Day 6. His GitHub is attached to his dev.to, for anyone curious.

So, huge caveat to my update, I leaned on Ben's code. If it looks like I reused code, I probably did. I decided to try and write it myself and then, if I hit issues, I used Ben's code to see the right way of doing it.
I will still write from my own perspective as it helps me to write, but I do not want to pretend or in any way suggest that this is 100% my own work.

TL;DR - this is a mix of my work and borrowed best practice from Ben Lovy

Day 6.1 - Redux

First, create a new type to hold the data for each heavenly body and its associated relationships. Parent is the body it orbits; descendants are the bodies that directly orbit it.

#[derive(Debug, Clone)]
pub struct Node {
    /* Each planet/asteroid/other heavenly body is a Node
    consisting of its own position in the tree of nodes (index),
    it's literal name (string_value), its immediate parent (which can
    be None or exactly 1, hence the Option), and its descendants 
    (which can be >1, hence the vector).*/
    index: usize,
    string_value: String,
    parent: Option<usize>,
    descendants: Vec<usize>,
}

Then, in order to compare the name to other Nodes, PartialEq is needed on this type:

impl PartialEq for Node {
    /*Without implementing PartialEq, could not compare
    names between different nodes*/
    fn eq(&self, comparator: &Self) -> bool {
        self.string_value == comparator.string_value
    }
}

And I then implemented a new function on the type to make creating Nodes easier:

impl Node {
    fn new(index: usize, name: &str) -> Self {
        /*Implemented on Node type, so Self is a Node.
        Creates a new Node and returns it for assignment*/
        Self {
            index,
            string_value: String::from(name),
            parent: None,
            descendants: vec![],
        }
    }
}

Next, Ben recommends a type that holds the vector of Nodes (or whatever you have named yours). Since it's a tree, I named it ChristmasTree:

#[derive(Debug, Clone, Default)]
pub struct ChristmasTree {
    /*Thematically-named type for storing the Nodes. 
    bodies means "heavenly bodies".*/
    bodies: Vec<Node>,
}

Then come the functions. I've commented them up pretty extensively, so they should be clear.
Part 1:

impl ChristmasTree {
        fn update_node_relationships(&mut self) {
        /*Use the input_file_handler file_open function to open the day6 inputs,
        unwrap the Result to gain access to the string of the file.
        Split the string at newlines to get the separate "PRNT)CHLD" strings
        and then for each string, trim it and pass it to use_the_split_string*/
        let file_input = file_open();
        let input_string = file_input.unwrap();
        input_string.split("\n").for_each(|o| self.use_the_split_string(o.trim()));
    }

    fn use_the_split_string(&mut self, parent_and_child: &str) {
        /*Split each string passed to the function (e.g. "PRNT)CHLD")
        into a vector of ["PRNT", "CHLD"].
        For the parent and child, use put_nodes_in_trees to return the 
        index for the parent and child Nodes.*/
        let splits = parent_and_child.split(")").collect::<Vec<&str>>();
        let parent_index = self.put_nodes_in_tree(splits[0]);
        let child_index = self.put_nodes_in_tree(splits[1]);
        /*With the parent and child Node locations now known:
            1) For the child Node, retrieve the parent. As a Node can have only
            one parent, any Some(_) result means we are trying to add a second 
            parent and something has gone wrong.
                a) If the result is None, write the parent index to the child Node
                as Some(parent_index)
            2) For the parent Node, any number of children are valid, so push the
            child Node index to the descendant vector*/
        match self.bodies[child_index].parent {
            Some(_) => panic!("Trying to write to existing parent field"),
            None => self.bodies[child_index].parent = Some(parent_index),
        }
        self.bodies[parent_index].descendants.push(child_index);
    }

    fn put_nodes_in_tree(&mut self, name: &str) -> usize {
        /*Check if any Nodes in the tree have the name of the
        current object. If true, return the Node location.
        If false, create a new Node and push it to the tree with
        and index == length of the tree vector before it's added.
        Return the new Node index.*/
        for node in &self.bodies {
            if node.string_value == name {
                return node.index;
            }
        }
        let index_to_set = self.bodies.len();
        self.bodies.push(Node::new(index_to_set, name));
        index_to_set
    }

    fn count_chain_to_root(&self, node_index: usize) -> usize {
        //I count back along the parent line for any given node, until I hit root
        match self.bodies[node_index].parent {
            Some(n) => 1 + self.count_chain_to_root(n),
            None => 0,
        }
    }

    fn sum_all_chains_to_root(&self) -> usize {
        /*I iterate over the tree vector, reducing the chain from node to root
        for every node in the vector. I return the sum*/
        self.bodies.iter().fold(0, |acc, n| {
            let node_chain_length = self.count_chain_to_root(n.index);
            acc + node_chain_length
        })
    }
}


pub fn six_two() {

    let mut tree = ChristmasTree::default();
    tree.update_node_relationships();

    let orbits = tree.sum_all_chains_to_root();
    println!("{}", orbits);
}

I'll cover the file handler later. It is a separate file that provides a utility file opener, returning the string version of the entire input.

Day 6.2

Part 2 builds on the ChristmasTree type, adding some additional functions that work out the logic.
I implemented my approach by picking one path as the fast path and one as the slow. I work backward along the fast path in full for every step along the slow path. If the two paths are ever on the same Node, then that is the common Node.

I use the common Node in place of the root Node used in part 1, and calculate the chain of orbits. Basically, I count from "YOU" to the common Node, then from "SAN" to the common Node. Add the two path lengths and subtract 2. My code counts "YOU" and "SAN" as Nodes, but the challenge tells us not to count them, so subtract 1 for each.

impl ChristmasTree {

    ***SNIP***

    fn find_index_for_known_string(&self, value: &str) -> Option<usize> {
        /*For a given string, return an Option containing the index, or None if not found*/
        for node in &self.bodies {
            if node.string_value == value.to_string() {
                return Some(node.index)
            }
        }
        None
    }


    fn chain_between_two_points(&self, point_one: &str, point_two: &str) -> usize {
        /*I do gather the indices for two points and collect the final distance between them.
        I also subtract 2 from the answer returned so that the orbit of each point is not counted,
        per AOC directions*/
        let point_one_index = match self.find_index_for_known_string(point_one) {
            Some(x) => x,
            None => panic!("Didn't find {} in the tree!", point_one),
        };
        let point_two_index = match self.find_index_for_known_string(point_two) {
            Some(x) => x,
            None => panic!("Didn't find {} in the tree!", point_two),
        };

        let count = self.move_slow_node(point_one_index, point_two_index, point_one_index, point_two_index) - 2;
        count
    }


    fn move_slow_node(&self, slow_node: usize, fast_node: usize, no_touch_slow: usize, no_touch_fast: usize) -> usize {
        /*I move the slow node up its parent chain every time the fast node completes a full recur to root
        If the fast node returns Some, it has found a point where both chains meet. The sum of both chains is then
        initiated and the result returned*/
        match self.move_fast_node(slow_node, fast_node) {
            Some(n) => self.sum_all_chains_to_node(n, no_touch_slow, no_touch_fast),
            None => self.move_slow_node(self.bodies[slow_node].parent.unwrap(), fast_node, no_touch_slow, no_touch_fast),
        }
    }


    fn move_fast_node(&self, slow_node: usize, fast_node: usize) -> Option<usize> {
        /*If the slow and fast node match, return an Option containing the matching index.
        Recur through the fast node, propogating an Option back up the recur for return.*/
        if self.bodies[slow_node].index == self.bodies[fast_node].index {
            return Some(slow_node); //The Node to return is irrelevant; they match if you're here
        } else {
             if self.bodies[fast_node].parent.is_some() {
                let par = self.bodies[fast_node].parent.unwrap();
                match self.move_fast_node(slow_node, par) {
                    Some(x) => return Some(x),
                    None => return None,
                } 
            } else {
                    None
                }
            }
        }


    fn sum_all_chains_to_node(&self, node_target: usize, node_index_one: usize, node_index_two: usize) -> usize {
        /*I iterate over the tree vector, reducing the chain from node to target node
        for every node in the custom vector. I return the sum*/
        let san_to_you: Vec<usize> = vec![node_index_one, node_index_two];
        println!("{:?} {:?} {:?}", self.bodies[node_index_one], self.bodies[node_index_two], san_to_you);
        san_to_you.iter().fold(0, |acc, &n| {
            let node_chain_length = self.count_chain_to_node(n, node_target);
            acc + node_chain_length
            })
        }   


    fn count_chain_to_node(&self, node_index: usize, node_target: usize) -> usize {
        //I count back along the parent line for any given node, until I hit the target node
        if node_index == node_target {
            return 0
        };
        match self.bodies[node_index].parent {
            Some(n) => 1 + self.count_chain_to_node(n, node_target),
            None => 0,
        }
    }
}


pub fn six_two() {

    let mut tree = ChristmasTree::default();
    tree.update_node_relationships();

    ***SNIP***

    let chain_from_me_to_santa = tree.chain_between_two_points(&"YOU", &"SAN");
    println!("{}", chain_from_me_to_santa);
}

Testing

Here I did my own thing. I hadn't followed some of Ben's patterns for creating the types, so my tests have to do more legwork than his. An area for learning.

I wrote my own simple tree for one test just so I could try out a different data set and I was glad I did. It exposed some pretty awful summing errors that the shorter tree didn't.

For anyone used to Clojure testing, rust testing feels very familiar. Take Ben's lead on this one: pretty assertions make a HUGE difference in readability when the test fails.

#[cfg(test)]
mod test {
    use super::*;
    use pretty_assertions::assert_eq;//{assert_eq, assert_ne};

    #[test]
    fn test_example_from_aoc() {
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nB)C\nC)D\nD)E\nE)F\nB)G\nG)H\nD)I\nE)J\nJ)K\nK)L");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let orbits = test_tree.sum_orbits();
        assert_eq!(orbits, 42);
    }

    #[test]
    fn test_count_descendants() {
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nB)C\nC)D\nD)E\nE)F\nB)G\nG)H\nD)I\nE)J\nJ)K\nK)L");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let direct_children = test_tree.bodies.iter().fold(0, |acc, node| acc + test_tree._count_descendants(node.index));
        assert_eq!(direct_children, 11);
    }

    #[test]
    fn test_two_points() {
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nB)C\nC)D\nD)E\nE)F\nB)G\nG)H\nD)I\nE)J\nJ)K\nK)L\nK)YOU\nI)SAN");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let chain_between = test_tree.chain_between_two_points(&"YOU", &"SAN");
        println!("{}", chain_between);
        assert_eq!(chain_between, 4);
    }

    #[test]
    fn test_two_points_new_you() {
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nK)YOU\nB)C\nC)D\nD)E\nE)F\nB)G\nG)H\nD)I\nE)J\nJ)K\nK)L\nI)SAN");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let chain_between = test_tree.chain_between_two_points(&"YOU", &"SAN");
        println!("{}", chain_between);
        assert_eq!(chain_between, 4);
    }

    #[test]
    fn test_two_points_rewritten_input() {
        println!("===\ntest_two_points_rewritten_input()\n===");
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nB)G\nG)H\nB)C\nC)D\nD)E\nE)F\nE)J\nJ)K\nK)L\nD)I\nI)SAN\nK)YOU");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let chain_between = test_tree.chain_between_two_points(&"YOU", &"SAN");
        println!("{}", chain_between);
        assert_eq!(chain_between, 4);
    }

    #[test]
    fn test_two_points_self_built_data() {
        let mut test_tree = ChristmasTree::default();
        let test_input = String::from("COM)B\nB)C\nC)D\nD)E\nE)SAN\nB)F\nF)G\nF)H\nH)I\nI)J\nI)K\nK)YOU\nJ)L");
        test_input.split("\n").for_each(|o| test_tree.use_the_split_string(o.trim()));
        let chain_between = test_tree.chain_between_two_points(&"YOU", &"SAN");
        println!("{}", chain_between);
        assert_eq!(chain_between, 7);
    }
}

Advent of Code 2019 - Day 1 (an aside, in Rust!)

bretthancox — Fri, 13 Dec 2019 20:31:39 +0000

Introduction

Since I'm dabbling with Rust, I wanted to see if I could do some of the Advent of Code using it. I'm nowhere near as proficient in Rust as I am in Clojure, so I don't expect to do some of the later challenges, but Day 1 is relatively friendly.

Day 1.1

I did one very simple approach and one that used functions implemented on a custom type. The latter is overkill for this, but it scales well when inputs are used multiple times. Implementing functions on the type reduces boilerplate later.

Anyway, here's the simple:

fn main() {
    let day1: Vec<u32> = vec![88093, 102524, ***SHORTEN*** 54128, 111698, 84299];
    let total_fuel_reqs: u32 = day1.into_iter()
                                   .map(|x| ((x / 3) as u32) - 2)
                                   .sum();
    println!("{:?}", total_fuel_reqs);
}

And here's the over-complicated version:

pub struct Day1Inputs{
    day1_input: Vec<u32>
}

impl Day1Inputs {
    fn day1_1(self) -> u32 {
        let total_fuel_reqs: u32 = self.day1_input
                                       .into_iter()
                                       .map(|x| ((x / 3) as u32) - 2)
                                       .sum();
        total_fuel_reqs
        }
    }

fn main() {
    let day1 = Day1Inputs {day1_input: vec![88093, 102524, ***SHORTEN*** 54128, 111698, 84299]};
    let fuel_req = day1.day1_1();
    (println!("Day 1: {:?}", fuel_req));
}

Day 1.2

I stuck with the implementation approach for this part. Recursion is a little less easy in Rust than Clojure (mainly because Clojure lets you stick a recur at the end of your loop and does everything else for you). As such, I built a recursion into day1_2.
One copy event to create a local version of the object mass that can be reduced with each loop as the new fuel mass is returned: fuel_req
One variable to catch the aggregating mass for the individual object and its fuel: total_fuel_mass_for_object
One variable to catch the aggregating mass for all objects: total_fuel_mass

An extra function was needed to hold the fuel calculation this time: day1_2_fuel_calc.
You'll notice that this function can't be called with self as it doesn't use self as an argument. This means it must be accessed via the double-colon approach: Day1Inputs::day1_2_fuel_calc

All previous u32 values were switched to i32 as the recursive fuel calculation can produce negative integers causing the code to panic if it is dealing with u32.

Then I create a new instance of the type since Vec can't implement Copy, preventing me from passing it to the day1_2 code after using it in day1_1.

pub struct Day1Inputs{
    day1_input: Vec<i32>
}

impl Day1Inputs {
   fn day1_1(self) -> i32 {
        let total_fuel_reqs: i32 = self.day1_input.iter().map(|x| ((x / 3) as i32) - 2).sum();
        total_fuel_reqs
        }

    fn day1_2_fuel_calc(mass: i32) -> i32 {
        let new_mass = ((mass / 3) as i32) -2;
        new_mass
    }

    fn day1_2(self) -> i32 {
        let mut total_fuel_mass: i32 = 0;
        for mass in self.day1_input {
            let mut total_fuel_mass_for_object: i32 = 0;
            let mut fuel_req = mass;
            loop {
                fuel_req = Day1Inputs::day1_2_fuel_calc(fuel_req);
                if fuel_req <= 0 {
                    break;
                }
                total_fuel_mass_for_object = total_fuel_mass_for_object + fuel_req;
            }
            total_fuel_mass = total_fuel_mass + total_fuel_mass_for_object;
        }
        total_fuel_mass
    }
}


fn main() {
    let day1_1 = Day1Inputs {day1_input: vec![88093, 102524, ***SHORTEN*** 54128, 111698, 84299]};
    let fuel_req = day1_1.day1_1();
    (println!("Day 1.1: {:?}", fuel_req));

    let day1_2 = Day1Inputs {day1_input: vec![88093, 102524, ***SHORTEN*** 54128, 111698, 84299]};
    let total_fuel_req = day1_2.day1_2();
    (println!("Day 1.2: {:?}", total_fuel_req));
}

Update

I noticed that my repeating the creation of inputs was necessary because I wasn't being smart about ownership. I needed to derive the Clone trait for my new type and then clone it:

// Derive the Clone trait for the new type
#[derive(Clone)]
pub struct Day1Inputs{
    day1_input: Vec<i32>
}

impl Day1Inputs {
   fn day1_1(self) -> i32 {
        let total_fuel_reqs: i32 = self.day1_input.iter().map(|x| ((x / 3) as i32) - 2).sum();
        total_fuel_reqs
        }

    fn day1_2_fuel_calc(mass: i32) -> i32 {
        let new_mass = ((mass / 3) as i32) -2;
        new_mass
    }

    fn day1_2(self) -> i32 {
        let mut total_fuel_mass: i32 = 0;
        for mass in self.day1_input {
            let mut total_fuel_mass_for_object: i32 = 0;
            let mut fuel_req = mass;
            loop {
                fuel_req = Day1Inputs::day1_2_fuel_calc(fuel_req);
                if fuel_req <= 0 {
                    break;
                }
                total_fuel_mass_for_object = total_fuel_mass_for_object + fuel_req;
            }
            total_fuel_mass = total_fuel_mass + total_fuel_mass_for_object;
        }
        total_fuel_mass
    }
}


fn main() {
    let day1 = Day1Inputs {day1_input: vec![88093, 102524, ***SHORTEN*** 54128, 111698, 84299]};
// Add a clone() to this line, moving a clone, not the original
    let fuel_req = day1.clone().day1_1();
    (println!("Day 1.1: {:?}", fuel_req));

// Allowing this line to move the original day1 without errors
    let total_fuel_req = day1.day1_2();
    (println!("Day 1.2: {:?}", total_fuel_req));
}

Advent of Code 2019 - Day 5

bretthancox — Fri, 13 Dec 2019 15:39:47 +0000

Introduction

Wow...day 5 really confused the heck out of me. Implementation was no more complicated than any other day, but the explanation was tough to follow.

That being said, once I did understand it, this was a fun problem. It's hard to show Day 5.1 and Day 5.2 separately as the "Intcode computer" was updated during both days. I can speak to the different implementations, but the normal split between the two is harder to show.

EDIT: To be fair to Jon Bristow, there is a lot going on in this day of the advent. I have no doubt that whatever method was used to convey the instructions, someone would have struggled to understand. I was just that person today.

Day 5.1

Part 1 of Day 5 requires that the Intcode computer from Day 2 be updated to accommodate some new features:

The Opcode from Day 2 now comprises 5 digits. This is true even if only one digit is provided - you must infer the rest to be 0.
The Opcodes from Day 2 continue to apply, but with some additions that break from the [instruction, parameter1, parameter2, parameter3] setup:
1. Opcode 3 means take a value from human input (or simulate it) and write it to the address provided in the parameter x, where (as we will see in a moment) x is either the address to write it, or a pointer to the address to write it: [3, x]
2. Opcode 4 means read the value from an address and print it to the screen. It simulates "diagnostic codes" being printed out. This is like the reverse of Opcode 3.
The Opcode will provide parameter "modes". The modes are binary. For each Opcode, there are between 1 and 3 parameters, thus there are between 1 and 3 modes. In Day 2 the values in the parameters are always pointers to somewhere else in the Intcode. If a parameter mode is 0, that behavior is unchanged. If the mode is 1, use the literal content of the parameter.
1. For Opcode of 1 or 2, you either sum or multiply the literal content of par 1 and par 2
2. For Opcode of 3 or 4 (or any other write to/read from operation), a 0 means read/write to the location defined in the parameter (i.e. a pointer), while a 1 means read/write to the parameter itself. Specifically:
  1. [4, 4, 99, 2, 3] results in printing 3
  2. [104, 4, 99, 2, 3] results in printing 4
The Opcode will be provided in reverse. Example: 101103 - in this case we can break it into ABCDE:
1. A is the mode for parameter 3
2. B is the mode for parameter 2
3. C is the mode for parameter 1
4. DE is the Opcode, now provided as two digits
The new two-digit Opcode is really a single digit Opcode with an unnecessary prefix, so in 01, only the 1 has value.

Phew! I'll just use this tinsel to wipe my brow.

With that laid out, I started with my mental step 1: determining the Opcode and the associated modes. This function takes in the new, (possibly) longer Opcode, reverses it, splits it, and outputs a map comprising the Opcode and each individual mode. The map is created with the default modes in place, ensuring it always contains all modes. If the Opcode doesn't actually have three parameters, subsequent code simply ignores the modes it doesn't need, so having three modes in every map regardless of Opcode is not a problem.
I prevent null pointer errors by counting the length of the full Opcode and building the map based on the information actually provided in the Opcode.

(defn opcode_reverse_and_dissect
  "I take the new, longer opcode and reverse it, then dissect it into the meaningful components"
  [opcode]
  (let [opcode_details {:opcode nil :par1_mode 0 :par2_mode 0 :par3_mode 0}
        opcode_length (count (str opcode))
        opcode (apply str (reverse (str opcode)))]
    (if (= opcode "99")
      {:opcode 99}
      (case opcode_length
        1 (assoc opcode_details 
                 :opcode (Integer/parseInt (str (nth opcode 0))))
        2 (assoc opcode_details 
                 :opcode (Integer/parseInt (str (nth opcode 0))))
        3 (assoc opcode_details 
                 :opcode (Integer/parseInt (str (nth opcode 0)))
                 :par1_mode (Integer/parseInt (str (nth opcode 2))))
        4 (assoc opcode_details 
                 :opcode (Integer/parseInt (str (nth opcode 0)))
                 :par1_mode (Integer/parseInt (str (nth opcode 2)))
                 :par2_mode (Integer/parseInt (str (nth opcode 3))))
        5 (assoc opcode_details 
                 :opcode (Integer/parseInt (str (nth opcode 0)))
                 :par1_mode (Integer/parseInt (str (nth opcode 2)))
                 :par2_mode (Integer/parseInt (str (nth opcode 3)))
                 :par3_mode (Integer/parseInt (str (nth opcode 4))))))))

So then the new Intcode computer is needed. I take the Day 2 version and update it.
For Opcode 1 and 2, the new modes made the code more complicated to house within this primary function, so I broke it into a new, very literally-named function.
The new logic for Opcode 3 and 4 basically checks the mode and either writes to or reads from the location defined by posb (i.e. the first parameter). Not complicated enough to need breaking out.
One note, the code (Integer/parseInt (do (print "Input code: ") (flush) (read-line))))) helps prompt the user for their input and then clears the output stream before accepting the read-line from the user and turning it into an integer. There is no error-checking, so those elves better not enter non-numeric characters!


(defn revised_one_and_two_behavior
  "I check the modes in the full Opcode and adjust the values of par1 and par2 appropriately"
  [intcode posb posc posd opcode_details operator]
  (let [par1 (if (= (:par1_mode opcode_details) 0) 
               (get intcode (get intcode posb))
               (get intcode posb))
        par2 (if (= (:par2_mode opcode_details) 0)
               (get intcode (get intcode posc))
               (get intcode posc))
        par3 (if (= (:par3_mode opcode_details) 0)
               (get intcode posd)
               posd)]
    (assoc intcode par3 
           (day2_operator 
            par1 
            par2
            operator))))


(defn day5_opcode
  "I check the opcode and perform, or cause to be performed, the appropriate actions"
  [intcode]
  (loop [posa 0
         posb 1
         posc 2
         posd 3
         intcode intcode]
    (let [opcode (get intcode posa)
          opcode_details (opcode_reverse_and_dissect opcode)]
      (cond
        (= (:opcode opcode_details) 99) intcode
        (= (:opcode opcode_details) 1) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (revised_one_and_two_behavior intcode posb posc posd opcode_details +))
        (= (:opcode opcode_details) 2) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (revised_one_and_two_behavior intcode posb posc posd opcode_details *))
        (= (:opcode opcode_details) 3) (recur (+ posa 2) (+ posb 2) (+ posc 2) (+ posd 2)
                                              (assoc intcode 
                                                     (if (= (:par1_mode opcode_details) 0)
                                                       (get intcode posb)
                                                       posb)
                                                     (Integer/parseInt (do (print "Input code: ") (flush) (read-line)))))
        (= (:opcode opcode_details) 4) (do
                                         (println "Diagnostic code:" (if (= (:par1_mode opcode_details) 0)
                                                                       (get intcode (get intcode posb))
                                                                       (get intcode posb)))
                                         (recur (+ posa 2) (+ posb 2) (+ posc 2) (+ posd 2) intcode))

        ;; Hiding part 2 for now...

        :else (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4) intcode)))))

Day 5 depends on user input to vary the output. The Day 5.2 code is the same as Day 5.1. Each part can be completed by entering a different user input value with the same inputs. Specifially, enter "1" for part 1 and "5" for part 2. Hence my -main function for Day 5 only has a single line with no println. That's because the Intcode computer does the required printing:

(defn -main
  "I call the functions for the Advent of Code on the basis of which day(s) are added as arguments to the command line call"
  [& days]
  (loop [days days
         day (first days)]
    (if (empty? days)
      nil
      (do
        (cond 

        ;; *** Snip ***

              (= day "5") (day5_opcode day5_intcode)

              :else (println "Day not completed yet"))
        (recur (rest days) (first (rest days)))))))

Day 5.2

So Day 5.1 passes with the above code. Now we go to Day 5.2. New Opcode instructions arrive, now with three numbers. This brings us to a situation where sequences can be 1, 2, 3, or 4 elements in length:

Opcode of 5 means that if parameter 1 is non-zero, skip to a new location defined by parameter 2, otherwise move to the next set in the sequence
Opcode of 6 is the same as 5, but checking for zero, not non-zero
Opcode of 7 writes a 1 or a 0 to the location defined in parameter 3 if parameter 1 is less than parameter 2
Opcode of 8 writes a 1 or a 0 to the location defined in parameter 3 if parameter 1 is equal to parameter 2
For all of the above, modes still apply, switching the behavior from looking at the parameter value as a pointer, to literally looking at the parameter value. Examples:
1. [5, 2, 4, 99, 12 .....] would see that parameter 1 is non-zero. It would read parameter 2 as a pointer. Pointer is 4, so the value of index 4 is 12. Thus the code would skip to the next sequence starting at index 12 (not shown).
2. [1105, 2, 4, 99, 12 .....] would see that parameter 1 is non-zero. It would read parameter 2 literally. The value is 4. Thus the code would skip to the next sequence starting at index 4.

Since this logic was complicated, I broke each new Opcode logic into a function. Again, very literal naming.
The Intcode Computer is also updated to include the new checks and behavior:

(defn opcode_5
  "I check for non-zero at par1 and move return the starting integer for the next Opcode/parameter set depending on finding"
  [intcode posa posb posc opcode_details]
   (let [par1 (if (= (:par1_mode opcode_details) 0) 
                (get intcode (get intcode posb))
                (get intcode posb))
         par2 (if (= (:par2_mode opcode_details) 0)
                (get intcode (get intcode posc))
                (get intcode posc))]
     (if (zero? par1)
       (+ posa 3)
       par2)))


(defn opcode_6
  "I check for zero at par1 and move return the starting integer for the next Opcode/parameter set depending on finding"
  [intcode posa posb posc opcode_details]
  (let [par1 (if (= (:par1_mode opcode_details) 0)
               (get intcode (get intcode posb))
               (get intcode posb))
        par2 (if (= (:par2_mode opcode_details) 0)
               (get intcode (get intcode posc))
               (get intcode posc))]
    (if (zero? par1)
      par2
      (+ posa 3))))


(defn opcode_7
  "I compare par1 and par2 to see if par1 < par2. If true, write 1 to par3/par3 pointer, otherwise write 0"
  [intcode posa posb posc posd opcode_details]
  (let [par1 (if (= (:par1_mode opcode_details) 0)
               (get intcode (get intcode posb))
               (get intcode posb))
        par2 (if (= (:par2_mode opcode_details) 0)
               (get intcode (get intcode posc))
               (get intcode posc))
        par3 (if (= (:par3_mode opcode_details) 0)
               (get intcode posd)
               posd)]
    (if (< par1 par2)
      (assoc intcode par3 1)
      (assoc intcode par3 0))))


(defn opcode_8
  "I compare par1 and par2 to see if par1 == par2. If true, write 1 to par3/par3 pointer, otherwise write 0"
  [intcode posa posb posc posd opcode_details]
  (let [par1 (if (= (:par1_mode opcode_details) 0)
               (get intcode (get intcode posb))
               (get intcode posb))
        par2 (if (= (:par2_mode opcode_details) 0)
               (get intcode (get intcode posc))
               (get intcode posc))
        par3 (if (= (:par3_mode opcode_details) 0)
               (get intcode posd)
               posd)]
    (if (= par1 par2)
      (assoc intcode par3 1)
      (assoc intcode par3 0))))


(defn day5_opcode
  "I check the opcode and perform the appropriate replacements of items based on the primary rules. Opcode = index 0; Noun = index 1; Verb = index 2; Insert_at = index 3"
  [intcode]
  (loop [posa 0
         posb 1
         posc 2
         posd 3
         intcode intcode]
    (let [opcode (get intcode posa)
          opcode_details (opcode_reverse_and_dissect opcode)]
      (cond
        (= (:opcode opcode_details) 99) intcode
        (= (:opcode opcode_details) 1) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (revised_one_and_two_behavior intcode posb posc posd opcode_details +))
        (= (:opcode opcode_details) 2) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (revised_one_and_two_behavior intcode posb posc posd opcode_details *))
        (= (:opcode opcode_details) 3) (recur (+ posa 2) (+ posb 2) (+ posc 2) (+ posd 2)
                                              (assoc intcode 
                                                     (if (= (:par1_mode opcode_details) 0)
                                                       (get intcode posb)
                                                       posb)
                                                     (Integer/parseInt (do (print "Input code: ") (flush) (read-line)))))
        (= (:opcode opcode_details) 4) (do
                                         (println "Diagnostic code:" (if (= (:par1_mode opcode_details) 0)
                                                                       (get intcode (get intcode posb))
                                                                       (get intcode posb)))
                                         (recur (+ posa 2) (+ posb 2) (+ posc 2) (+ posd 2) intcode))
        (= (:opcode opcode_details) 5) (let [new_posa (opcode_5 intcode posa posb posc opcode_details)]
                                         (recur new_posa (+ new_posa 1) (+ new_posa 2) (+ new_posa 3) intcode))
        (= (:opcode opcode_details) 6) (let [new_posa (opcode_6 intcode posa posb posc opcode_details)]
                                         (recur new_posa (+ new_posa 1) (+ new_posa 2) (+ new_posa 3) intcode))
        (= (:opcode opcode_details) 7) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (opcode_7 intcode posa posb posc posd opcode_details))  ;; intcode posa posb posc posd opcode_details
        (= (:opcode opcode_details) 8) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                                              (opcode_8 intcode posa posb posc posd opcode_details))
        :else (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4) intcode)))))

Finally, -main is exactly the same. Just enter "5" instead of "1" and the result is produced.

Testing

Since I struggled with the logic I didn't know how to write tests until I was done. At that point I didn't see the value, so today is a bad day for testing...

Advent of Code 2019 - Day 4

bretthancox — Wed, 11 Dec 2019 22:47:20 +0000

Introduction

Day 3 was a big spike in complexity for me. Not sure why - maybe it was meant to be harder, maybe my brain doesn't deal well with the type of problem it was. Fortunately, Day 4 made far more sense to me. I was able to break it down into much more logical steps, thus making my functions far better structured and the flow far cleaner.

Day 4.1

The challenge: given a range of six digit "passwords", count the number of "passwords" that, checking each number from left to right, (1) only equal the preceding number or increment it, and (2) have at least one pair of neighboring numbers that are equal.
An example that meets both definitions is 122345

My logic for this part of Day 4 was to start with the checks I needed to perform:

Does each individual number within the sequence equal or exceed its predecessor?
Is there at least one pair of equal, neighboring numbers within the input?

So, that's two functions!

(defn check_equal_incrementing_order
  "I check if the numbers are equal or increase across the number being tested"
  [vector_of_ints]
  (loop [vector_of_ints vector_of_ints
         final_state true]
    (if (or (= 1 (count vector_of_ints)) (false? final_state))
      final_state
      (recur 
       (rest vector_of_ints) 
       (if 
        (> (first vector_of_ints) (second vector_of_ints))
         false
         true)))))


(defn check_at_least_one_equal_pair
  "I check if at least one neighboring pair of numbers are equal"
  [vector_of_ints]
  (loop [vector_of_ints vector_of_ints
         final_state false]
    (if (or (= 1 (count vector_of_ints)) (true? final_state))
      final_state
      (recur 
       (rest vector_of_ints) 
       (if 
        (= (first vector_of_ints) (second vector_of_ints))
         true
         false)))))

Next was the handling of the input. Specifically, splitting the initial number into individual integers. From my experience, strings are easier to split than integers, so my steps are:

Convert the integer to a string
Split that string into a vector of individual characters
Parse the vector of split strings into a vector of integers

Add one function to push the data through those steps and we have the following:

(defn convert_int_to_string
  "I convert an integer to a string"
  [integer]
  (str integer))


(defn make_vec_of_strings
  "I convert a string into a vector of individual characters"
  [string]
  (str/split string #""))


(defn make_substrings_into_ints
  "I convert the substrings into integers"
  [vec_of_strings]
  (into [] (map #(Integer/parseInt %) vec_of_strings)))


(defn produce_vector_of_ints
  "I push the initial number through the conversion steps"
  [number]
  (->> number
       (convert_int_to_string)
       (make_vec_of_strings)
       (make_substrings_into_ints)))

The final step for determining if an input number is a valid password is to check that both of the earlier checks are true. So here's a function that determines that:

(defn check_both_checks_are_true
  "I perform the two checks and confirm that both return true"
  [vector_of_ints]
  (if (and (check_at_least_one_equal_pair vector_of_ints) (check_equal_incrementing_order vector_of_ints))
    true
    false))

Last but not least, the command and control that takes in the start and stop values and runs each through the sequence. If check_both_checks_are_true returns true, increment the counter. At the end, the counter is the value to submit to pass Day 4.1:

(defn day4_1_command_and_control
  [start end]
  (loop [start start
         end end
         counter 0]
    (if (> start end)
      counter
      (if (true? (check_both_checks_are_true (produce_vector_of_ints start)))
        (recur 
         (inc start)
         end
         (inc counter))
        (recur
         (inc start)
         end
         counter)))))

(defn -main
  "I call the functions for the Advent of Code on the basis of which day(s) are added as arguments to the command line call"
  [& days]
  (loop [days days
         day (first days)]
    (if (empty? days)
      nil
      (do (cond

        ***snip***

              (= day "4") (do
                            (println "Day 4.1 - Number of combinations:" (day4_1_command_and_control day4_start day4_end)))
              :else (println "Day not completed yet"))
        (recur (rest days) (first (rest days))))))
        )

Day 4.2

This part made me scratch my head for a moment. How to check if there are three or more neighboring numbers that are equal and then only discount the "password" if it doesn't also contain true matching pair of numbers?
A "password" that fails while meeting the criteria of part 1: 122234
A "password" that passes the new criteria: 122233
The latter password also has a 33 pair, so the 222 trio doesn't invalidate it.

My logic was to realize that the trio check was all I needed. I could find a matching pair, then check to see if the pair was isolated or part of a larger sequence.
Basically, in the working example above (122233) you would first find [2 2]. You then check the preceding numbers and the subsequent numbers and see if you find a trio that match. For [2 2], the preceding number gives you a trio of [1 2 2]. That is fine. For the subsequent number you get [2 2 2]. That is a fail.
Ignore the fact that you would find another [2 2] pair and move to the next pair in 122233. You get [3 3]. You can only look back as that is the end of the vector, giving you [2 3 3]. That is fine, meaning this "password" can be counted.

I wrote two functions to do this check:

(defn check_if_trio_equal
  "I take a trio of ints and check if they are equal or not, returning true if they are."
  [trio_of_ints]
  (let [[a b c] trio_of_ints]
    (if (= a b c)
      true
      false)))

(defn check_if_more_than_two_identical_values_neighboring
  "I check if at least one neighboring pair of numbers are equal without being part of larger group, returning true if there is one isolated pair"
  [vector_of_ints]
  (loop [posa 0]
    (if (= (count vector_of_ints) (+ posa 1))
      false
      (let [pair_to_check [(nth vector_of_ints posa) 
                           (nth vector_of_ints (+ 1 posa))]
            first_trio (if 
                        (<= (count vector_of_ints) (+ posa 2)) ;; Checks if index of posa+2 would be out of range...
                         [1 2 3] ;;...and if so, uses a generic vector that won't fail the check
                         [(nth vector_of_ints posa) (nth vector_of_ints (+ posa 1)) (nth vector_of_ints (+ posa 2))])
            second_trio (if 
                         (= posa 0) 
                          first_trio ;; If the backward looking vector would start at index -1, just run with the first vector
                          [(nth vector_of_ints (- posa 1)) (nth vector_of_ints posa) (nth vector_of_ints (+ posa 1))])]
        (if (and 
             (= (first pair_to_check) (second pair_to_check)) ;; The identified pair match...
             (false? (check_if_trio_equal first_trio)) ;; ..and the first trio does not match...
             (false? (check_if_trio_equal second_trio))) ;; ...and the second trio does not match. This means it is a true pair.
          true
          (recur (inc posa)))))))

The second function gets complicated because I need to prevent my trio selection being outside the index range for the vector_of_ints. I catch situations that would result in index errors by using a static [1 2 3] true trio vector for first_trio and reusing first_trio for second_trio when that trio would be out of range.
If an isolated pair is found, the rest of the "password" is irrelevant, so it returns true. Otherwise it keeps going until it finds true, or it reaches the index limit and returns false.

Then I have the aggregator function, same as in part 1, that compiles the three checks, as it is now, and returns true or false:

(defn check_three_checks_are_true
  "I perform the three checks and confirm that both return true"
  [vector_of_ints]
  (if (and
       (check_at_least_one_equal_pair vector_of_ints)
       (check_equal_incrementing_order vector_of_ints)
       (check_if_more_than_two_identical_values_neighboring vector_of_ints))
    true
    false))

Last, but not least, the command control for part 2 and calling it. Command and control is no different to part 1, except it calls the three check function instead of the two check:

(defn day4_2_command_and_control
  [start end]
  (loop [start start
         end end
         counter 0]
    (if (> start end)
      counter
      (if (true? (check_three_checks_are_true (produce_vector_of_ints start)))
        (recur
         (inc start)
         end
         (inc counter))
        (recur
         (inc start)
         end
         counter)))))


(defn -main
  "I call the functions for the Advent of Code on the basis of which day(s) are added as arguments to the command line call"
  [& days]
  (loop [days days
         day (first days)]
    (if (empty? days)
      nil
      (do
        (cond 

        ***snip***

              (= day "4") (do
                            (println "Day 4.1 - Number of combinations:" (day4_1_command_and_control day4_start day4_end))
                            (println "Day 4.2 - No more than two identical neighboring values:" (day4_2_command_and_control day4_start day4_end)))
              :else (println "Day not completed yet"))
        (recur (rest days) (first (rest days))))))
        )

Testing

Since I determined my function logic first, I was able to write much better tests for Day 4. Part 1 is especially well covered.
I realized afterward that I had used primarily five digit numbers, but the logic of the challenge doesn't actually depend on six digits, so any number long enough to display the characteristics being tested would suffice.

(ns advent.core-test
  (:require [clojure.test :refer :all]
            [advent.core :refer :all]))


(deftest day4_order_equal_inc
  (testing "Confirming that the check for equal or incrementing order returns the correct result"
    (is (true? (check_equal_incrementing_order [1 2 2 4 5])))
    (is (false? (check_equal_incrementing_order [1 2 2 1 5])))))

(deftest day4_check_one_pair_equal
  (testing "Confirming that checking for one equal pair produces the correct result"
    (is (true? (check_at_least_one_equal_pair [1 2 2 4 5])))
    (is (false? (check_at_least_one_equal_pair [1 2 3 4 5])))))

(deftest day4_check_int_to_string
  (testing "Does the int get appropriately converted"
    (is (= (convert_int_to_string 12245) "12245"))
    (is (= (convert_int_to_string 12345) "12345"))))

(deftest day4_split_string
  (testing "Does the string get split correctly"
    (is (= (make_vec_of_strings "12245") ["1" "2" "2" "4" "5"]))))

(deftest day4_produce_ints
  (testing "Do the substrings get converted to integers"
    (is (= (make_substrings_into_ints ["1" "2" "2" "4" "5"]) [1 2 2 4 5]))))

(deftest day4_ensure_both_checks_are_true
  (testing "Confirm that when both checks are true, the result is true"
    (is (true? (check_both_checks_are_true [1 2 2 4 5])))
    (is (false? (check_both_checks_are_true [1 2 3 4 5])))
    (is (false? (check_both_checks_are_true [1 2 2 3 2])))))

(deftest day4_end_to_end_int_to_vecint
  (testing "Confirm that the end to end process of building the vec of ints works"
    (is (= (produce_vector_of_ints 12245) [1 2 2 4 5]))))

(deftest day4_1_test
  (testing "Confirm the results are correct"
    (is (= (day4_1_command_and_control 122342 122348) 5))
    (is (= (day4_1_command_and_control 112224 112233) 7))))


(deftest day4_2_logic_check
  (testing "Checking the logic of picking a password with only two neighboring values"
    (is (true? (check_if_more_than_two_identical_values_neighboring [1 2 2 4 5])))
    (is (false? (check_if_more_than_two_identical_values_neighboring [1 2 2 2 5])))))

(deftest day4_2_test
  (testing "Confirm the results are correct"
    (is (= (day4_2_command_and_control 122342 122348) 5))
    (is (= (day4_2_command_and_control 112224 112233) 7))))

Advent of Code 2019 - Day 3, Part 2

bretthancox — Tue, 10 Dec 2019 22:06:58 +0000

Introduction

I don't know if the problems are getting harder, or my brain just struggled with the structure of this one, but it feels like I have double the functions necessary to achieve the goal.

Nevertheless, Day 3 is finished! This second part highlighted some brittleness in my approach to part 1. My approach for the individual sub-lines (producing [x-start x-end y] or [y-start y-end x]) meant that I couldn't work with the outputs of later functions in the chain. I had to go back to the coordinate-producing function.
Given more time, this feels like a refactoring candidate, but time waits for no Santa!

Day 3.2

Challenge is to work out the intersection point closest to origin as determined by the sum of the distance it occurs from origin when following each of the two input lines. Instead of working out relative position on the grid (Manhattan distance), now it's about following the directions for the lines and counting the steps taken for each, summing the two distances.

After doing some reading, I found that if you know the coordinates of a single point (i.e. an intersection point), you can use the cross product formula to check if that point is on the same plane: Cross product on Wikipedia

Essentially, if the cross product for a sub-line and an intersection point is 0, then the point exists on that line.

Sub-line:    a-----------------------b

Coordinates: a (xa, ya)   b (xb, yb)   i (xi, yi)   Where i is the intersection point

Cross product: |((yi - ya)(xb - xa)) - ((xi - xa)(yb - ya))|

What does that do for us?
If you have an input line with the following coordinates [[0 0] [9 0] [9 3] [5 3]] and an intersection point of [9 2], then to determine distance you're not measuring the length of the entire line. The line to measure instead ends at the intersection point: [[0 0] [9 0] [9 2]]
The distance in this simple, one line example is thus 9 + 2 = 11
Cross product tells us between which two points the intersection occurs. If cross product is 0, the point of intersection is on that sub-line.

With that in mind I started with a cross product function:

(defn crossproduct
  "I determine if an intersection point is on the line defined by point1 and point2"
  [point1 point2 testpoint]
  (let [part1 (- (second testpoint) (second point1))
        part2 (- (first point2) (first point1))
        part3 (- (first testpoint) (first point1))
        part4 (- (second point2) (second point1))
        crossprd (- (* part1 part2) (* part3 part4))]
    (if (= crossprd 0)
      true
      false)))

Next, a function that takes in a single intersect point and the coordinate set for a single line, producing a shorter coordinate set that terminates in the point of intersection. Using crossproduct, if the point of intersection occurs on a sub-line, use the intersect coordinate as the end of that particular sub-line, thus going from [xa xb] or [ya yb] to [xa xi] or [ya yi]

(defn day3_2_crossproduct_output
  [intersection line_coordinates]
  (loop [line_coordinates line_coordinates
         line_start (first line_coordinates)
         line_end (second line_coordinates)
         coordinates_to_intersect [line_start]
         is_intersected (crossproduct line_start line_end intersection)]
    (if (true? is_intersected)
      (conj coordinates_to_intersect intersection)
      (recur 
       (rest line_coordinates) 
       line_end
       (second (rest line_coordinates)) 
       (conj coordinates_to_intersect line_end)
       (crossproduct line_end (second (rest line_coordinates)) intersection)))))

Then, before the command and control function, I know that the distance is the combined distance from input line 1 and input line 2, so a summing function will be needed:

(defn sum_the_distance 
  [coords_to_intersect]
(loop [coords_to_intersect coords_to_intersect
       point1 (first coords_to_intersect)
       point2 (second coords_to_intersect)
       total 0]
  (if (= (count coords_to_intersect) 1)
    total
    (recur 
     (rest coords_to_intersect)
     point2
     (second (rest coords_to_intersect))
     (+ total (reduce + (map #(Math/abs %) (map - point2 point1))))))))

The input is the coordinates generated by crossproduct_output - i.e. a coordinate set terminating in a point of intersection.
The last line looks complicated, but is just doing the following:

Subtract both values in point1 from point2. Using map allows a function to apply to all contents of collections, so this step would work like so: [8 5] - [4 2] == [4 3]. This is not possible with a simple -
Next, map that result to Math/abs ensuring all values are positive. Even negative coordinate changes add to the distance traveled.
Reduce the resulting positive pair using + to produce the length of the sub-line. Using the earlier example (reduce + [4 3]) == 7
Add that to the total distance for the next loop.

Finally, the command and control. This function takes in the input lines, produces the coordinates for each, finds the points of intersection, and builds a vector of distances.
On each loop, the function takes the next point of intersection and the coordinates of the two input lines, and uses the functions discussed above to produce a total distance for each input line. Lastly, it adds the total distance for each line, producing the combined distance, before adding that value to the distances vector.
Once all points of intersection have been iterated over, the return value is the first value of the sorted vector of distances. The default sort behavior on integers is to sort them in ascending order, making the first value the smallest:

(defn day3_2_loop_intersects
  [line1 line2]
  (let [line1_coords (day3_1_coordinate_builder line1)
        line2_coords (day3_1_coordinate_builder line2)
        intersections (day3_1_all_intersections_for_both_lines line1 line2)
        distances []]
    (loop [intersections intersections
           line1_intersection_coords (day3_2_crossproduct_output (first intersections) line1_coords)
           line2_intersection_coords (day3_2_crossproduct_output (first intersections) line2_coords)
           distances distances]
      (println (count intersections) (count distances))
      (if (= 1 (count intersections))
        (first (sort distances))
        (recur 
         (rest intersections)
         (day3_2_crossproduct_output (first (rest intersections)) line1_coords)
         (day3_2_crossproduct_output (first (rest intersections)) line2_coords)
         (conj distances (+ (sum_the_distance line1_intersection_coords) (sum_the_distance line2_intersection_coords))))))))

(defn -main
  "I call the functions for the Advent of Code on the basis of which day(s) are added as arguments to the command line call"
  [& days]
  (loop [days days
         day (first days)]
    (if (empty? days)
      nil
      (do
        (cond (= day "1") (do
                            (println "Day 1.1 - Module masses only:" (day1_1 day1_masses))
                            (println "Day 1.2 - Fuel for the fuel:" (reduce + (map day1_2 day1_masses))))
              (= day "2") (do 
                            (println "Day 2.1 - Intcode output: " (day2_1 (day2_prep day2_intcode 12 2)))
                            (println "Day 2.2 - Noun/verb:" (day2_2_result (day2_2_nounverb day2_intcode 99 19690720))))
              (= day "3") (do 
                            (println "Day 3.1 - Manhattan distance:" (day3_1_manhattan_distance day3_line1 day3_line2))
                            (println "Day 3.2 - Shortest route to intersect:" (day3_2_loop_intersects day3_line1 day3_line2)))
              :else (println "Day not completed yet"))
        (recur (rest days) (first (rest days))))))
        )

And with a quick lein run 3 I have my day 3 results, earning two more gold stars!

Testing

Testing was simpler in part 2, mainly because I found a less convoluted way to achieve the goal than in part 1. Only note for next round of testing is to use def to define the inputs, rather than writing (into [] (map #(name %...*snip* every time I needed an input. Readability would be a lot better.

(deftest day3_2_crossproduct_test
  (testing "Finding the set of coordinates that terminate in an intersection"
  (is (= (day3_2_crossproduct_output 
          (second 
           (day3_1_all_intersections_for_both_lines 
            (into [] (map #(name %) '[R8,U5,L5,D3]))
            (into [] (map #(name %) '[U7,R6,D4,L4]))))
          (day3_1_coordinate_builder (into [] (map #(name %) '[R8,U5,L5,D3]))))
         [[0 0] [8 0] [8 5] [6 5]]
         ))))

(deftest sum_the_distance_test
  (testing "Summing the distance"
    (is (= (sum_the_distance [[0 0] [8 0] [8 5] [6 5]]) 15))
    (is (= (sum_the_distance [[0 0] [0 7] [6 7] [6 5]]) 15))))

(deftest day3_2_loop_intersects_test
  (testing "day3_2_loop_intersects"
    (is (= (day3_2_loop_intersects
            (into [] (map #(name %) '[R75,D30,R83,U83,L12,D49,R71,U7,L72]))
            (into [] (map #(name %) '[U62,R66,U55,R34,D71,R55,D58,R83])))
           610)
        (= (day3_2_loop_intersects
            (into [] (map #(name %) '[R98,U47,R26,D63,R33,U87,L62,D20,R33,U53,R51]))
            (into [] (map #(name %) '[U98,R91,D20,R16,D67,R40,U7,R15,U6,R7])))
           410))))

Advent of Code 2019 - Day 3, Part 1

bretthancox — Mon, 09 Dec 2019 20:55:02 +0000

Introduction

Day 3 (posting on day 9...better get ready for day 4 on day 19...) exposed the amount of time since I did math in a meaningful way. My solution is painful, probably because I don't know some fundamental mathematical approach to the problem, but it is what it is. Behold, day 3!

Advent of Code

Day 3.1

Day 3 requires that some directions and distances be taken in and processed to produce points of intersection. The input defines two lines that will have 1 or more intersection points. The lines comprise only vertical or horizontal changes in direction.

I handle the input as strings in Clojure. To avoid having to wrap every single part of the input in double-quotes, I wrote the input as follows:

(def day3_line1 (into [] (map #(name %) '[R1001,D890,R317,U322,L481,D597, ;;*snip*

By doing this, I can use the text as provided in the problem and Clojure handles putting the symbols (as it interprets them) into a new vector as strings.
The single apostrophe in front of the symbol vector tells Clojure not to evaluate the content of the vector, just use it. Allowing Clojure to evaluate it will give you some nice long Java errors.

With the input defined, the "logic" needs to be built. Given my approach, I struggle to write "logic" without quoting it.

(ns advent.core
  (:gen-class)
  (:require [advent.inputs :refer :all]
            [clojure.string :as str]))

(defn day3_1_coordinate_vec_builder_x
  "I construct the coordinates for horizontal lines"
  [operator coordinates next_str]
  (vector (operator (get coordinates 0) ;; X
                    (Integer/parseInt (subs next_str 1)))
          (get coordinates 1))) ;; Y

(defn day3_1_coordinate_vec_builder_y
  "I construct the coordinates for vertical lines"
  [operator coordinates next_str]
  (vector (get coordinates 0) ;; X
          (operator (get coordinates 1)  ;; Y
                    (Integer/parseInt (subs next_str 1)))))

(defn day3_1_coordinate_builder
  "I turn the direction set for each line into coordinates that represent each point the line changes direction"
  [strings]
  (loop [next_str (first strings)
         rest_strings (rest strings)
         coordinates [0 0]
         vec_of_coords [coordinates]]
    (if (= (+ 1 (count strings)) (count vec_of_coords))
      vec_of_coords
      (cond (str/starts-with? next_str "U") (recur (first rest_strings)
                                                   (rest rest_strings)
                                                   (day3_1_coordinate_vec_builder_y + coordinates next_str)
                                                   (conj vec_of_coords (day3_1_coordinate_vec_builder_y + coordinates next_str)))
            (str/starts-with? next_str "D") (recur (first rest_strings)
                                                   (rest rest_strings)
                                                   (day3_1_coordinate_vec_builder_y - coordinates next_str)
                                                   (conj vec_of_coords (day3_1_coordinate_vec_builder_y - coordinates next_str)))
            (str/starts-with? next_str "R") (recur (first rest_strings)
                                                   (rest rest_strings)
                                                   (day3_1_coordinate_vec_builder_x + coordinates next_str)
                                                   (conj vec_of_coords (day3_1_coordinate_vec_builder_x + coordinates next_str)))
            (str/starts-with? next_str "L") (recur (first rest_strings)
                                                   (rest rest_strings)
                                                   (day3_1_coordinate_vec_builder_x - coordinates next_str)
                                                   (conj vec_of_coords (day3_1_coordinate_vec_builder_x - coordinates next_str)))))))

To avoid writing extra :refer entries for every new input, I switched to :refer :all, thus pulling all inputs in at once.

day3_1_coordinate_builder uses the vector of instructions to build a coordinate set for each line passed to it. U or D indicate a change in the y value of the coordinate and are sent to day3_1_coordinate_vec_builder_y, while R or L indicates a change in x and are sent to day3_1_coordinate_vec_builder_x. The operator changes based on whether the axis being changed is increasing or decreasing. A D decreases y, while a U increases it.
The output is a vector of vectors. The inner vectors are the [x y] coordinates for each direction change, including origin [0 0].

Next, I use a command and control for the majority of the intersection-identifying process:

(defn day3_1_all_intersections_for_both_lines
  "I am basically command and control. I walk through each function, passing the result to the next.
Finally merge the intersection points into one vector."
  [line_1 line_2]
  (let [line_1_coordinates (day3_1_coordinate_builder line_1)
        line_2_coordinates (day3_1_coordinate_builder line_2)
        line_1_horizontals (day3_1_get_horizontals line_1_coordinates)
        line_1_verticals (day3_1_get_verticals line_1_coordinates)
        line_2_horizontals (day3_1_get_horizontals line_2_coordinates)
        line_2_verticals (day3_1_get_verticals line_2_coordinates)
        l1v_intersect_l2h (day3_1_find_intersection_points line_1_verticals line_2_horizontals)
        l2v_intersect_l1h (day3_1_find_intersection_points line_2_verticals line_1_horizontals)]
    (loop [intersect_main l1v_intersect_l2h
           intersect_source l2v_intersect_l1h]
      (if (empty? intersect_source)
        intersect_main
        (recur (into intersect_main intersect_source) (rest intersect_source))))))

This function is basically taking in a number of other function outputs. Since most of my functions work on only half of the data set, this function was necessary to consolidate the results.
The reason for half each time is because I broke each line into sub-lines: horizontal and vertical. This allowed for comparison of line 1 horizontal sub-lines to the line 2 vertical sub-lines and vice versa. Since intersection could only occur between vertical and horizontal sub-lines, this seemed simple.

First, for each line, I extract the key values for each sub-line. Looking at horizontal sub-lines, the y doesn't change for the entire length, so each sub-line is defined by three values x-start, x-end, and y.
Thus each of these functions returns a vector of sub-vectors. Each sub-vector defines a sub-line as: [start end constant].

(defn day3_1_get_horizontals
  "I extract the horizontal lines from the coordinate vector. It then produces a three number set for each: [x1 x2 y].
x1 is the start of the line. x2 is the end of the line. y is the constant y-plane. "
  [coordinates]
  (loop [start (first coordinates)
         rest_coords (rest coordinates)
         horizontals []]
    (if (<= (count rest_coords) 0)
      horizontals
      (if 
       (not= 
        (- (first start) (first (first rest_coords))) 0)
        (recur (first rest_coords) (rest rest_coords) (conj horizontals [(first start) (first (first rest_coords)) (second start)]))
        (recur (first rest_coords) (rest rest_coords) horizontals)
        ))))


(defn day3_1_get_verticals
  "I extract the vertical lines from the coordinate vector. It then produces a three number set for each: [y1 y2 x].
y1 is the start of the line. y2 is the end of the line. x is the constant x-plane. "
  [coordinates]
  (loop [start (first coordinates)
         rest_coords (rest coordinates)
         verticals []]
    (if (<= (count rest_coords) 0)
      verticals
      (if
       (not=
        (- (second start) (second (first rest_coords))) 0)
        (recur (first rest_coords) (rest rest_coords) (conj verticals [(second start) (second (first rest_coords)) (first start)]))
        (recur (first rest_coords) (rest rest_coords) verticals)))))

Then, for the two lines, use all vertical sub-lines and check if they intersect with the horizontal sub-lines:

(defn day3_1_find_intersection_points
  "For each of the initial lines, I compare the horizontal sub-lines from line A to the vertical sub-lines from line B.
Run again with vertical sub-lines from line A and horizontal sub-lines from line B to get all intersects."
  [vert_lines horiz_lines]
  (loop [vert_loop vert_lines
         horiz_loop horiz_lines ;; bind to a different name so that...
         intersections []]
    (if (empty? vert_loop)
      intersections
      (if (empty? horiz_loop) ;; ...we can reuse the original vector as passed to the function even if we empty out the copy
        (recur (rest vert_loop) horiz_lines intersections) 
        (let [vert_coords (first vert_loop)
              horiz_coords (first horiz_loop)
              vert_x_axis (nth vert_coords 2)
              horiz_y_axis (nth horiz_coords 2)
              ;; A little cheat. The end of a line can have a smaller number than the start
              ;; and catching this situation with code is painful. So I guarantee that the smallest
              ;; x or y value is x1 or y1 and the largest is x2 or y2, simplifying subsequent math.
              ;; Since the direction of the line is irrelevant to determining intersects, this is not a problem.
              vert_y1 (if (> (nth vert_coords 0) (nth vert_coords 1)) (nth vert_coords 1) (nth vert_coords 0))
              vert_y2 (if (> (nth vert_coords 0) (nth vert_coords 1)) (nth vert_coords 0) (nth vert_coords 1))
              horiz_x1 (if (> (nth horiz_coords 0) (nth horiz_coords 1)) (nth horiz_coords 1) (nth horiz_coords 0))
              horiz_x2 (if (> (nth horiz_coords 0) (nth horiz_coords 1)) (nth horiz_coords 0) (nth horiz_coords 1))]
          (if 
           (and
            (and (> horiz_y_axis vert_y1) (< horiz_y_axis vert_y2)) ;; If horizontal y axis is within the y range of the vertical line being assessed
            (and (> vert_x_axis horiz_x1) (< vert_x_axis horiz_x2))) ;; and vertical x axis is within the x range of the horizontal line being assessed
            (recur vert_loop (rest horiz_loop) (conj intersections [vert_x_axis horiz_y_axis])) ;; then the lines intersect and we add it to the vector of intersections.
            (recur vert_loop (rest horiz_loop) intersections))))))) ;; Otherwise, don't update the intersections and move on.

The key to this is that an intersect means that the x value for a vertical sub-line is within the x range of a horizontal and the y axis for that horizontal sub-line is within the y range of the vertical. If that isn't true, they don't intersect.
To make things somewhat simpler, I also disregard the direction of any sub-line as it doesn't change the intersect. This approach means my > and < checks at the end don't need to be conditional as I'll always be comparing against the largest and smallest values, in that order.

Then back to the day3_1_all_intersections_for_both_lines function, as shown earlier, to do the main command and control and pull the intersection set together for the complete lines.

Lastly, the actual Manhattan distance calculation and invoking it.
Manhattan distance is defined as |(x-origin - x-intersect) + (y-origin - y-intersect)|. Using that calculation, I iterate over the points of intersection and store or replace the smallest resulting value until, at the end, it is returned.

(defn day3_1_manhattan_distance
  "I take the vector of intersection points and calculate the Manhattan distance. I then compare
that distance to the last recorded distance and, if smaller, store that distance instead. I return the smallest distance."
  [line_1 line_2]
  (loop [intersection_points (day3_1_all_intersections_for_both_lines line_1 line_2)
         intersect (first intersection_points)
         smallest_distance (+ (Math/abs (- 0 (first intersect))) (Math/abs (- 0 (second intersect))))]
    (if (empty? intersection_points)
      smallest_distance
      (recur (rest intersection_points) 
             (first intersection_points) 
             (if (< smallest_distance 
                    (+ (Math/abs (- 0 (first intersect))) (Math/abs (- 0 (second intersect)))))
               smallest_distance
               (+ (Math/abs (- 0 (first intersect))) (Math/abs (- 0 (second intersect)))))))))

(defn -main
  (println "Day 3.1 - Manhattan distance:" (day3_1_manhattan_distance day3_line1 day3_line2)))

Testing

I definitely do not do test-driven development. I tried for Day 3.2, but these are my tests for Day 3.1.
I didn't plan on writing this many, but my code was so troublesome that it needed a lot more attention than I had planned.

(deftest day3_1_coord_builder
  (testing "Day 3.1 Building coordinates"
    (is (= (day3_1_coordinate_builder ["R8","U5","L5","D3"]) [[0 0] [8 0] [8 5] [3 5] [3 2]]))
    (is (= (day3_1_coordinate_builder ["U7","R6","D4","L4"]) [[0 0] [0 7] [6 7] [6 3] [2 3]]))
    (is (= (day3_1_coordinate_builder ["U7","R6","D4","L4","L5","D4"]) [[0 0] [0 7] [6 7] [6 3] [2 3] [-3 3] [-3 -1]]))
    ))

(deftest day3_1_horizontal_lines
  (testing "Day 3.1 Horizontal line definitions [Xstart Xend Y]"
    (is (= (day3_1_get_horizontals [[0 0] [8 0] [8 5] [3 5] [3 2]]) [[0 8 0] [8 3 5]]))
    (is (= (day3_1_get_horizontals [[0 0] [0 7] [6 7] [6 3] [2 3]]) [[0 6 7] [6 2 3]]))
    (is (= (day3_1_get_horizontals [[0 0] [0 7] [6 7] [6 3] [2 3] [-3 3] [-3 -1]]) [[0 6 7] [6 2 3] [2 -3 3]]))
    ))

(deftest day3_1_vertical_lines
  (testing "Day 3.1 Vertical line definitions [Ystart Yend X]"
    (is (= (day3_1_get_verticals [[0 0] [8 0] [8 5] [3 5] [3 2]]) [[0 5 8] [5 2 3]]))
    (is (= (day3_1_get_verticals [[0 0] [0 7] [6 7] [6 3] [2 3]]) [[0 7 0] [7 3 6]]))
    (is (= (day3_1_get_verticals [[0 0] [0 7] [6 7] [6 3] [2 3] [-3 3] [-3 -1]]) [[0 7 0] [7 3 6] [3 -1 -3]]))))

(deftest day3_1_intersections
  (testing "Day 3.1 find the intersection coordinates"
    (is (= (day3_1_find_intersection_points [[0 7 0] [7 3 6]] [[0 8 0] [8 3 5]]) [[6 5]]))
    (is (= (day3_1_find_intersection_points [[0 5 8] [5 2 3]] [[0 6 7] [6 2 3]]) [[3 3]]))
    ))

(deftest day3_1_manhattan_test
  (testing "Day 3.1 Manhattan distance"
    (is (= (day3_1_manhattan_distance 
            (into [] (map #(name %) '[R75,D30,R83,U83,L12,D49,R71,U7,L72])) 
            (into [] (map #(name %) '[U62,R66,U55,R34,D71,R55,D58,R83])))
           159))
    (is (= (day3_1_manhattan_distance 
            (into [] (map #(name %) '[R8,U5,L5,D3])) 
            (into [] (map #(name %) '[U7,R6,D4,L4])))
           6))
    ))

Extra

I was getting a little fed up with constantly running all preceding days when running day 3. As such, I updated my main function to take command line arguments and run the days specified by the user:

(defn -main
  "I call the functions for the Advent of Code on the basis of which day(s) are added as arguments to the command line call"
  [& days]
  (loop [days days
         day (first days)]
    (if (empty? days)
      nil
      (do
        (cond (= day "1") (do
                            (println "Day 1.1 - Module masses only:" (day1_1 day1_masses))
                            (println "Day 1.2 - Fuel for the fuel:" (reduce + (map day1_2 day1_masses))))
              (= day "2") (do 
                            (println "Day 2.1 - Intcode output: " (day2_1 (day2_prep day2_intcode 12 2)))
                            (println "Day 2.2 - Noun/verb:" (day2_2_result (day2_2_nounverb day2_intcode 99 19690720))))
              (= day "3") (do 
                            (println "Day 3.1 - Manhattan distance:" (day3_1_manhattan_distance day3_line1 day3_line2))
                            (println "Day 3.2:" (day3_2_loop_intersects day3_line1 day3_line2)))
              :else (println "Day not completed yet"))
        (recur (rest days) (first (rest days)))))))

Now, typing lein run 1 3 will result in only the code for Day 1 and Day 3 running.

Advent of Code 2019 - Day 2

bretthancox — Thu, 05 Dec 2019 18:24:21 +0000

Introduction

Day 2 (posting on day 5...sigh...) was an increase in complexity over day 1. Parsing "Intcode" to generate an instruction set for Santa's rocket. Sounds legit to me!

Advent of Code

Day 2.1

The Intcode provides instructions on how to further edit the Intcode to generate a final version of the code. For this part, the goal is to complete the instruction set and submit the value of the 0-indexed item in the code set after it has been processed.

(ns advent.core
  (:gen-class)
  (:require [advent.inputs :refer [day2_intcode]]))

Once again, I moved the inputs into my advent.inputs file

If anyone is curious, it looks like this:

(ns advent.inputs
  (:gen-class))

(def day2_intcode [1 0 0 3 1 1 2 3 1 3 4 3 1 5 0 3 2 1 9 19 1 19 5 23 2 6 23 27 1 6 27 31 2 31 9 35 1 35 6 39 1 10 39 43 2 9 43 47 1 5 47 51 2 51 6 55 1 5 55 59 2 13 59 63 1 63 5 67 2 67 13 71 1 71 9 75 1 75 6 79 2 79 6 83 1 83 5 87 2 87 9 91 2 9 91 95 1 5 95 99 2 99 13 103 1 103 5 107 1 2 107 111 1 111 5 0 99 2 14 0 0
])

Then, the Intcode repeatedly requires adding or multiplying two values. To make my code more readable I moved these concepts into separate functions. Not necessary, but sometimes parentheses hell is worth avoiding!

(defn day2_add
  "Extracts repeated additions from other code"
  [int1 int2]
  (+ int1 int2))

(defn day2_multiply
  "Extracts repeated multiplications from other code"
  [int1 int2]
  (* int1 int2))

EDIT: Reading this again, I noticed I could have written a day2_operator function instead. Functions are first class citizens, so instead of writing two functions to do essentially the same thing with a different operator, I could have done the following:

(defn day2_operator
  "Extracts repeated operations from other code"
    [int1 int2 operator]
    (operator int1 int2))

(day2_operator 5 5 +) ;; Result: 10
(day2_operator 5 5 *) ;; Result: 25

C'est la vie. END EDIT

Then comes day 2.1 in action. The key is to work in groups of 4: [opcode noun verb insert_at].
Opcode defines whether to add, multiply, or end the program.
Noun and verb are (seemingly) just names for the integers at index 1 and 2.
Insert_at defines where the result of the add/multiply is placed in the Intcode.

For Clojure, this is loop territory. I explicitly define the four indices I need, then on each successful loop I add 4 to each. That moves each value to the next sequence of 4 integers.
I maintain the Intcode throughout, updating it for each loop.
I extract the Opcode each time through and use it to determine what action to take, with a result of 99 returning the revised Intcode.

(defn day2_1
  "Checks the opcode and performs the appropriate replacements of items based on the primary rules. Opcode = index 0; Noun = index 1; Verb = index 2; Insert_at = index 3"
  [intcode]
  (loop [posa 0
         posb 1 
         posc 2 
         posd 3         
         intcode intcode]
    (let [opcode (get intcode posa)]
      (if (= opcode 99)
        intcode
        (if (= opcode 1)
          (recur
           (+ posa 4)
           (+ posb 4)
           (+ posc 4)
           (+ posd 4)
           ;; This horrible line does the following: 
             ;; for index 1 and 2, get the value at index 1 and 2, then use those values as indices to get the values for calculation
             ;; then, get the target_index value at index 3, take the calculation result, and write the calculation result to the target_index
           (assoc intcode (get intcode posd) (day2_add (get intcode (get intcode posb)) (get intcode (get intcode posc)))) 
           )
          (if (= opcode 2)
            (recur
             (+ posa 4)
             (+ posb 4)
             (+ posc 4)
             (+ posd 4)
             (assoc intcode (get intcode posd) (day2_multiply (get intcode (get intcode posb)) (get intcode (get intcode posc))))
             )
            (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4) intcode
                   )))))))

NOTE: Thinking about it as I write this, a cond could have worked here. Oh well.

The problem then throws one final curveball: substitute the values at index 1 and 2 of the Intcode before running, a process that apparently produces a 1202 program alarm in the story. A quick day2_prep function accepting the Intcode with no alarm and that's done.
Running this from main, I print the result and get that nice star.


(defn day2_prep
  "Performs the preparation task of replacing the 'noun' and 'verb' (aka index 1 and index 2) with new values"
  [no_alarm noun verb]
  (assoc (assoc no_alarm 1 noun) 2 verb))

(defn -main
  "I call the functions for the Advent of Code"
  []
  (println "Day 2.1 - Intcode output: " (day2_1 (day2_prep day2_intcode 12 2))))

Day 2.2

As with day 1, time to complicate the previous problem.
This time, it's working out what combination of Intcode produces a specified answer at index 0. Time to brute force this!

nounverb accepts the Intcode and the specified max value either the noun or verb can be (99 for the challenge). It then just iterates the verb until it reaches 99. At 99, it resets the verb to 0 and increments the noun by 1.
Repeat until the result (calculated using the same code as in Day 2.1) matches the desired outcome. Having the outcome hardcoded is bad practice, but for this limited scope I'll take the risk. My test cases are set up to succeed at finding this value if the rest of the code runs correctly.
The end result is a vector of the noun and verb that produce the result.

The result function does the final calculation as defined in the problem.

(defn day2_2_nounverb
  "I find the noun and verb that produce the desired outcome of 19690720 at index 0 and return them as a vector"
  [intcode max] 
  (let [number_of_items (if (< (count intcode) max) max (count intcode))]
    (loop [noun 0 verb 0]
      (let [result (day2_1 (day2_prep intcode noun verb))]
        (if (= (get result 0) 19690720)
          [(get result 1) (get result 2)]
          (recur 
           (if (= verb (- number_of_items 1)) 
             (inc noun) 
             noun)
           (if (= verb (- number_of_items 1)) 
             0 
             (inc verb)))
          )))))


(defn day2_2_result
  "I use the noun and verb vector to perform the calculation that produces the final answer for day 2.2"
  [nounverb]
  (+ (* 100 (get nounverb 0)) (get nounverb 1)))

Testing

I didn't really need test cases for Day 1, but Day 2 had me chasing my tail at one point and I was breaking previously working code. To help me out, I wrote test cases.

Where results are not intuitive, I manually produced the answer and then used it in the test.

I continue this into Day 3 as it is a nice check that I haven't broken logic. This is especially true as you go from part 1 to part 2 of a day, when you might be tempted to edit existing functions

(ns advent.core-test
  (:require [clojure.test :refer :all]
            [advent.core :refer :all]))

(deftest day2_1_computer_test
  (testing "Day 2.1"
    (is (= (day2_1 [10 0 0 99]) [2 0 0 0 99]))
    (is (= (day2_1 [2 3 0 3 99]) [2 3 0 6 99]))
    (is (= (day2_1 [2 4 4 5 99 0]) [2 4 4 5 99 9801]))
    (is (= (day2_1 [1 1 1 4 99 5 6 0 99]) [30 1 1 4 2 5 6 0 99]))
    ))

(deftest day2_1_alarm_prep_test
  (testing "Day 2.1 alarm prep"
    (is (= (day2_prep [1 0 0 0 99] 12 2) [1 12 2 0 99]))
    (is (= (day2_prep [1 1 1 4 99 5 6 0 99] 12 2) [1 12 2 4 99 5 6 0 99]))
    ))

(deftest day2_2_test
  (testing "Day 2.1 noun and verb finder"
    (is (= (day2_2_nounverb [1 5 6 0 99 19690719 1] 99) [0 5]))
    (is (= (day2_2_result (day2_2_nounverb [1 5 6 0 99 19690719 1] 99)) 5))
    ))

So there we go. Day 2 in the bag. Day 3 still to finish...only two days late.

UPDATE

I did refactor the day2_1 function to use cond. Not much shorter, but much clearer about what the code is doing:

(defn day2_1
"I check the opcode and perform the appropriate replacements of items based on the primary rules. Opcode = index 0; Noun = index 1; Verb = index 2; Insert_at = index 3"
  [intcode]
  (loop [posa 0
         posb 1 
         posc 2 
         posd 3         
         intcode intcode]
    (let [opcode (get intcode posa)]
      (cond
        (= opcode 99) intcode
        (= opcode 1) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                            (assoc intcode (get intcode posd) (day2_operator 
                                                               (get intcode (get intcode posb)) 
                                                               (get intcode (get intcode posc)) 
                                                               +)))
        (= opcode 2) (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4)
                            (assoc intcode (get intcode posd) (day2_operator 
                                                               (get intcode (get intcode posb)) 
                                                               (get intcode (get intcode posc)) 
                                                               *)))
        :else (recur (+ posa 4) (+ posb 4) (+ posc 4) (+ posd 4) intcode)))))

I also noticed some strange, late night decisions in my day2_2_nounverb function, so I took a stab at fixing it up. I dropped the slightly weird number_of_items and instead opted to use the max value being passed in. This simplifies things a little. I also added an argument, desired_value, to replace the hardcoded value in the original:

(defn day2_2_nounverb
  "I find the noun and verb that produce the desired outcome of 19690720 at index 0 and return them as a vector"
  [intcode max desired_result] 
    (loop [noun 0 verb 0]
      (let [result (day2_1 (day2_prep intcode noun verb))]
        (if (= (get result 0) desired_result)
          [(get result 1) (get result 2)]
          (recur 
           (if (= verb (- max 1)) 
             (inc noun) ;Noun only iterates every full cycle of verb, otherwise it loops without change
             noun)
           (if (= verb (- max 1)) 
             0 ;If a full verb cycle has occurred, reset to 0, otherwise increment
             (inc verb)))
          ))))

Advent of Code 2019 - Day 1

bretthancox — Tue, 03 Dec 2019 20:07:50 +0000

Introduction

My Clojure skills are rarely used, but it is a fun language for thinking outside the box. I'll jump at a chance to apply it. So I jumped at Advent of Code 2019!

Advent of Code

Day 1.1

The first test was nice and simple for Clojure. Iterating over collections and then summing the result is a breeze.
As I suspected the calculation for the amount of fuel would need to be reused, I broke it into its own function. I was glad I did.

This is the code that produces the correct answer to Day 1.1. I moved the inputs into their own inputs.clj file to avoid cluttering my code. day1_masses is the input provided by Advent of Code. I packaged it into a vector for index access.

(ns advent.core
  (:gen-class)
  (:require [advent.inputs :refer [day1_masses]]))

(defn day1_fuel_calc
  "I do the fuel calculation as defined for day 1"
  [mass]
  (- (int (Math/floor (/ mass 3))) 2))

(defn day1_1
  "I take the mass vector and produce a single fuel requirement"
  [mass_vec]
  (reduce + (map day1_fuel_calc mass_vec)))

(defn -main
  "I call the functions for the Advent of Code"
  []
  (println "Day 1.1 - Module masses only:" (day1_1 day1_masses)))

Day 1.2

Once again, the second part of the day utilized some nice Clojure features. In this case, loop/recur. I used the day1_2 function with map to produce a collection of individual fuel calculations. The additional fuel is calculated per individual mass, not total mass, so having the map/reduce in the day1_2 function would have been too complicated. For cleanliness, I should really have another function perform the map/reduce and call that function from main, but it's not overly messy.

The following code produces the correct result.

(ns advent.core
  (:gen-class)
  (:require [advent.inputs :refer [day1_masses]]))


(defn day1_fuel_calc
  "I do the fuel calculation as defined for day 1"
  [mass]
  (- (int (Math/floor (/ mass 3))) 2))


(defn day1_2
  "I take the individual masses for each item, work out the fuel requirement for each item, and then recursively calculate the fuel requirement for the fuel"
  [mass]
  (loop [fuel_needed (day1_fuel_calc mass)
         total_fuel 0]
    (if (< fuel_needed 0)
      total_fuel
      (recur (day1_fuel_calc fuel_needed) (+ total_fuel fuel_needed)))))


(defn -main
  "I call the functions for the Advent of Code"
  []
  (println "Day 1.2 - Fuel for the fuel:" (reduce + (map day1_2 day1_masses))))

Clojure and go blocks: How to stop your program from exiting

bretthancox — Fri, 12 Jul 2019 17:16:35 +0000

This is my first post and probably on a topic done to death, but it's a topic I tripped over when first using the core.async features of Clojure.

Clojure's core.async uses go blocks. Wrap something in a go block and it will happen asynchronously. Simple, right?
What tends to happen when you first try is you write something like this to see if you get the principle:

(defn counter [start end]
  (loop [count start]
    (if (> count end)
      1
      (do
        (println count)
        (recur (inc count))))))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (go (counter 0 100)))

Aaaand nothing happens. Maybe you're lucky and it counts to "1", but then the program exits. Why didn't it finish?

Well, it did. When you put something inside a go block, you tell Clojure you want it to occur in another thread. The program pushes the actions inside the go block to another thread and then returns to the current thread immediately.
That last part is critical. The main thread contains nothing after the go block. So the program is done and exits. There is nothing left to do. The only way the above example would count to 100 is if the main thread had enough work to do that the other thread could complete.

So, how do you make sure this simple example completes?
First, it is important to understand that any go block makes a channel. I won't go into detail on channels, but anyone learning the core.async library has probably seen something like this:

(def my_channel_name (chan))

There are other ways to define a channel, but generally you would use chan, whether in a def statement or in a let or other binding.

A go block is also a channel. From the clojuredocs, go "...Returns a channel which will receive the result of the body when completed..."

Whatever you put inside the go block, its return value is placed on a channel that is the go block itself. In my example, when the if statement is true, the go block will exit with a value of 1. It doesn't really matter what that value is as I am not using it, but the presence of the channel and something being placed on it are the key to making sure your program concludes after the go block is finished.

Core.async has multiple methods for taking values from a channel, but we will be using <!! in this example. This is one of two similar looking functions in core.async with similar purposes. The other is <!.

<! can only be used inside a go block. It is a non-blocking take for the main thread. Non-blocking just means the program doesn't wait for it to take anything from the associated channel.

<!! is a blocking take and can be used outside a go block. If there is nothing for it to take (i.e. nothing on the channel it is taking from) then it blocks the thread in which it appears.

So, before we update our example, let's recap:

Go blocks take place on other threads than our main thread.
The main thread finishes because it has no more work to perform.
A go block acts like a channel that will provide the return value of anything that takes place inside it.
<!! blocks a thread until it can take a value from a channel.

So, we can make a very simple change to our example:

(defn counter [start end]
  (loop [count start]
    (if (> count end)
      1
      (do
        (println count)
        (recur (inc count))))))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  ;;(go (counter 0 100))) ;;not used
  (<!! (go (counter 0 100))))  ;;new code

And now the program prints 0 to 100.
The addition of the <!! blocks the main thread from completing until it can take a value from a channel. In this case, the channel is our go block and the counter function inside doesn't return a value until it finishes counting from start to end.

Another option is to use a channel to tell the main thread when work is finished in other threads.
When a channel is explicitly closed using close! it returns nil as its last value. Since nil is a false value, the following code can check for the closing of a designated "last action" channel by monitoring for a false return value:

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
(let [close_on_last_action_chan (chan)]

  (go-loop [counter 1]
    (if (> counter 1000)
      (close! close_on_last_action_chan)
      (recur (inc counter))))

  (while (<!! close_on_last_action_chan))))

Just make sure you use this channel only to monitor for conclusion of the program. Putting other 'false' values on this channel could end the program prematurely.

Conclusion

These are contrived examples. There is absolutely no value in doing simple incr loops in a go block. What it demonstrates is the need to "capture" the main thread if it might conclude before async events complete.

I hope that this was helpful to someone. I have little doubt there are better ways to do what I've described above, but if nothing else this approach helped me with some of the issues I experienced understanding the core.async library.

Thanks for reading!