Compute Manhattan distance from origin given a set of left-right-step directionsTruncating an integer from...

Four ships at the ocean with the same distance

Is it possible for a character at any level to cast all 44 Cantrips in one week without Magic Items?

Is it okay to use open source code to do an interview task?

Findminimum of Integral

Intern not wearing safety equipment; how could I have handled this differently?

How do I separate enchants from items?

Would denouncing cheaters from an exam make me less likely to receive penalties?

Why won't the U.S. sign a peace treaty with North Korea?

What is the relationship between external and internal composition in a cartesian closed category?

run bash scripts in folder all at the same time

What does the multimeter dial do internally?

Is there a method for differentiating informative comments from commented out code?

This LM317 diagram doesn't make any sense to me

Chilling water in copper vessel

What was the profession 芸者 (female entertainer) called in Russia?

What are the consequences for a developed nation to not accept any refugees?

Publishing papers seem natural to many, while I find it really hard to think novel stuff to pursue till publication. How to cope up with this?

I'm feeling like my character doesn't fit the campaign

Decrease spacing between a bullet point and its subbullet point

Is it possible to complete a PhD in CS in 3 years?

Gory anime with pink haired girl escaping an asylum

Blocks from @ jafe

Is there a formal/better word than "skyrocket" for the given context?

How should I ask for a "pint" in countries that use metric?



Compute Manhattan distance from origin given a set of left-right-step directions


Truncating an integer from left to right and right to left2016 Advent of Code Day 1, Part 1 and Part 2Compute power set of a given set in PythonNavigating over a square spiral






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







5












$begingroup$


I am solving the problems for Advent of Code 2016 to learn Rust programming. The prompt for the first problem can be summarized:



I start at position 0,0 on a regular grid. I am given a set of directions to get to a location. I can only travel in "steps" on this grid, and I am only given directions in the form (e.g.):



R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4


Where the first character is the direction to turn right or left and the following number is the number of steps to take. I need to compute the Manhattan distance between my starting point and the ending point.



The instructions are saved in a text file called "2016-1.txt".



use std::fs;

struct Pos {
facing: char,
x: i32,
y: i32,
}

fn split_dir(dir_str: &str) -> Vec<&str> {
dir_str.split(", ").collect()
}

fn update_facing(rel_dir: &char, face_char: &char) -> char {
if *rel_dir == 'L' {
match face_char {
'N' => 'W',
'S' => 'E',
'E' => 'N',
'W' => 'S',
_ => 'I', // Is there a better way to handle the catch-all?
}
} else {
match face_char {
'N' => 'E',
'S' => 'W',
'E' => 'S',
'W' => 'N',
_ => 'I',
}
}
}

fn update_x(pos_x: i32, face_char: char, move_num: i32) -> i32 {
match face_char {
'E' => pos_x + move_num,
'W' => pos_x - move_num,
_ => pos_x
}
}

fn update_y(pos_y: i32, face_char: char, move_num: &i32) -> i32 {
match face_char {
'N' => pos_y + move_num,
'S' => pos_y - move_num,
_ => pos_y
}
}

fn get_manhattan_dist(pos_x: i32, pos_y: i32, origin_x: i32, origin_y: i32) -> i32 {
(pos_x - origin_x).abs() + (pos_y - origin_y).abs()
}

fn main() {
let s = fs::read_to_string("2016-1.txt")
.expect("Failed to read file.");

let split: Vec<&str> = split_dir(&s);

let mut pos: Pos = Pos {x: 0, y: 0, facing: 'N'};

for inst in split {
// Update direction
let rel_dir = inst.chars().nth(0).unwrap(); // Get first character of the instruction
pos.facing = update_facing(&rel_dir, &pos.facing);

// Update position
let move_num = &inst[1..].parse::<i32>().unwrap();
pos.x = update_x(pos.x, pos.facing, *move_num);
pos.y = update_y(pos.y, pos.facing, &move_num);
}

let dist = get_manhattan_dist(pos.x, pos.y, 0, 0);
println!("{}", dist);
}


I am particularly interested in error handling. Particularly in the update_facing function. This is my first Rust program, so all advice is warranted as well.










share|improve this question











$endgroup$












  • $begingroup$
    am particularly interested in error handling — what do you want to happen on errors?
    $endgroup$
    – Shepmaster
    7 hours ago


















5












$begingroup$


I am solving the problems for Advent of Code 2016 to learn Rust programming. The prompt for the first problem can be summarized:



I start at position 0,0 on a regular grid. I am given a set of directions to get to a location. I can only travel in "steps" on this grid, and I am only given directions in the form (e.g.):



R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4


Where the first character is the direction to turn right or left and the following number is the number of steps to take. I need to compute the Manhattan distance between my starting point and the ending point.



The instructions are saved in a text file called "2016-1.txt".



use std::fs;

struct Pos {
facing: char,
x: i32,
y: i32,
}

fn split_dir(dir_str: &str) -> Vec<&str> {
dir_str.split(", ").collect()
}

fn update_facing(rel_dir: &char, face_char: &char) -> char {
if *rel_dir == 'L' {
match face_char {
'N' => 'W',
'S' => 'E',
'E' => 'N',
'W' => 'S',
_ => 'I', // Is there a better way to handle the catch-all?
}
} else {
match face_char {
'N' => 'E',
'S' => 'W',
'E' => 'S',
'W' => 'N',
_ => 'I',
}
}
}

fn update_x(pos_x: i32, face_char: char, move_num: i32) -> i32 {
match face_char {
'E' => pos_x + move_num,
'W' => pos_x - move_num,
_ => pos_x
}
}

fn update_y(pos_y: i32, face_char: char, move_num: &i32) -> i32 {
match face_char {
'N' => pos_y + move_num,
'S' => pos_y - move_num,
_ => pos_y
}
}

fn get_manhattan_dist(pos_x: i32, pos_y: i32, origin_x: i32, origin_y: i32) -> i32 {
(pos_x - origin_x).abs() + (pos_y - origin_y).abs()
}

fn main() {
let s = fs::read_to_string("2016-1.txt")
.expect("Failed to read file.");

let split: Vec<&str> = split_dir(&s);

let mut pos: Pos = Pos {x: 0, y: 0, facing: 'N'};

for inst in split {
// Update direction
let rel_dir = inst.chars().nth(0).unwrap(); // Get first character of the instruction
pos.facing = update_facing(&rel_dir, &pos.facing);

// Update position
let move_num = &inst[1..].parse::<i32>().unwrap();
pos.x = update_x(pos.x, pos.facing, *move_num);
pos.y = update_y(pos.y, pos.facing, &move_num);
}

let dist = get_manhattan_dist(pos.x, pos.y, 0, 0);
println!("{}", dist);
}


I am particularly interested in error handling. Particularly in the update_facing function. This is my first Rust program, so all advice is warranted as well.










share|improve this question











$endgroup$












  • $begingroup$
    am particularly interested in error handling — what do you want to happen on errors?
    $endgroup$
    – Shepmaster
    7 hours ago














5












5








5





$begingroup$


I am solving the problems for Advent of Code 2016 to learn Rust programming. The prompt for the first problem can be summarized:



I start at position 0,0 on a regular grid. I am given a set of directions to get to a location. I can only travel in "steps" on this grid, and I am only given directions in the form (e.g.):



R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4


Where the first character is the direction to turn right or left and the following number is the number of steps to take. I need to compute the Manhattan distance between my starting point and the ending point.



The instructions are saved in a text file called "2016-1.txt".



use std::fs;

struct Pos {
facing: char,
x: i32,
y: i32,
}

fn split_dir(dir_str: &str) -> Vec<&str> {
dir_str.split(", ").collect()
}

fn update_facing(rel_dir: &char, face_char: &char) -> char {
if *rel_dir == 'L' {
match face_char {
'N' => 'W',
'S' => 'E',
'E' => 'N',
'W' => 'S',
_ => 'I', // Is there a better way to handle the catch-all?
}
} else {
match face_char {
'N' => 'E',
'S' => 'W',
'E' => 'S',
'W' => 'N',
_ => 'I',
}
}
}

fn update_x(pos_x: i32, face_char: char, move_num: i32) -> i32 {
match face_char {
'E' => pos_x + move_num,
'W' => pos_x - move_num,
_ => pos_x
}
}

fn update_y(pos_y: i32, face_char: char, move_num: &i32) -> i32 {
match face_char {
'N' => pos_y + move_num,
'S' => pos_y - move_num,
_ => pos_y
}
}

fn get_manhattan_dist(pos_x: i32, pos_y: i32, origin_x: i32, origin_y: i32) -> i32 {
(pos_x - origin_x).abs() + (pos_y - origin_y).abs()
}

fn main() {
let s = fs::read_to_string("2016-1.txt")
.expect("Failed to read file.");

let split: Vec<&str> = split_dir(&s);

let mut pos: Pos = Pos {x: 0, y: 0, facing: 'N'};

for inst in split {
// Update direction
let rel_dir = inst.chars().nth(0).unwrap(); // Get first character of the instruction
pos.facing = update_facing(&rel_dir, &pos.facing);

// Update position
let move_num = &inst[1..].parse::<i32>().unwrap();
pos.x = update_x(pos.x, pos.facing, *move_num);
pos.y = update_y(pos.y, pos.facing, &move_num);
}

let dist = get_manhattan_dist(pos.x, pos.y, 0, 0);
println!("{}", dist);
}


I am particularly interested in error handling. Particularly in the update_facing function. This is my first Rust program, so all advice is warranted as well.










share|improve this question











$endgroup$




I am solving the problems for Advent of Code 2016 to learn Rust programming. The prompt for the first problem can be summarized:



I start at position 0,0 on a regular grid. I am given a set of directions to get to a location. I can only travel in "steps" on this grid, and I am only given directions in the form (e.g.):



R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4


Where the first character is the direction to turn right or left and the following number is the number of steps to take. I need to compute the Manhattan distance between my starting point and the ending point.



The instructions are saved in a text file called "2016-1.txt".



use std::fs;

struct Pos {
facing: char,
x: i32,
y: i32,
}

fn split_dir(dir_str: &str) -> Vec<&str> {
dir_str.split(", ").collect()
}

fn update_facing(rel_dir: &char, face_char: &char) -> char {
if *rel_dir == 'L' {
match face_char {
'N' => 'W',
'S' => 'E',
'E' => 'N',
'W' => 'S',
_ => 'I', // Is there a better way to handle the catch-all?
}
} else {
match face_char {
'N' => 'E',
'S' => 'W',
'E' => 'S',
'W' => 'N',
_ => 'I',
}
}
}

fn update_x(pos_x: i32, face_char: char, move_num: i32) -> i32 {
match face_char {
'E' => pos_x + move_num,
'W' => pos_x - move_num,
_ => pos_x
}
}

fn update_y(pos_y: i32, face_char: char, move_num: &i32) -> i32 {
match face_char {
'N' => pos_y + move_num,
'S' => pos_y - move_num,
_ => pos_y
}
}

fn get_manhattan_dist(pos_x: i32, pos_y: i32, origin_x: i32, origin_y: i32) -> i32 {
(pos_x - origin_x).abs() + (pos_y - origin_y).abs()
}

fn main() {
let s = fs::read_to_string("2016-1.txt")
.expect("Failed to read file.");

let split: Vec<&str> = split_dir(&s);

let mut pos: Pos = Pos {x: 0, y: 0, facing: 'N'};

for inst in split {
// Update direction
let rel_dir = inst.chars().nth(0).unwrap(); // Get first character of the instruction
pos.facing = update_facing(&rel_dir, &pos.facing);

// Update position
let move_num = &inst[1..].parse::<i32>().unwrap();
pos.x = update_x(pos.x, pos.facing, *move_num);
pos.y = update_y(pos.y, pos.facing, &move_num);
}

let dist = get_manhattan_dist(pos.x, pos.y, 0, 0);
println!("{}", dist);
}


I am particularly interested in error handling. Particularly in the update_facing function. This is my first Rust program, so all advice is warranted as well.







programming-challenge rust taxicab-geometry






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 6 hours ago









200_success

134k21 gold badges171 silver badges440 bronze badges




134k21 gold badges171 silver badges440 bronze badges










asked 9 hours ago









Bryce FrankBryce Frank

1473 bronze badges




1473 bronze badges












  • $begingroup$
    am particularly interested in error handling — what do you want to happen on errors?
    $endgroup$
    – Shepmaster
    7 hours ago


















  • $begingroup$
    am particularly interested in error handling — what do you want to happen on errors?
    $endgroup$
    – Shepmaster
    7 hours ago
















$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
7 hours ago




$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
7 hours ago










1 Answer
1






active

oldest

votes


















3












$begingroup$

Your code looks more complicated than necessary for this task.



The first thing I noticed was the directions N, E, S, W. There is no need to explicitly name them. It is simpler to just define a direction as a 2-dimensional tuple:



struct Direction {
dx: i32,
dy: i32
}


That's the essence of a direction. As the next step, I remembered that rotating such a direction by 90 degrees is quite simple. It just involves swapping the coordinates and reversing one of them. To get these right, I manually checked all the combinations after writing this code:



impl Direction {
fn left(&self) -> Direction { Direction { dx: self.dy, dy: -self.dx } }
fn right(&self) -> Direction { Direction { dx: -self.dy, dy: self.dx } }
}


By these simple definitions, I avoided dealing with N, E, S, W at all.



When I tested the program using the example you provided, my IDE added a trailing newline to the file, as is usual for text files. Then the program crashed because it could not parse an empty string. Therefore I changed split_dir(&s) into split_dir(s.trim()), and it worked.



To understand the main program, I separated it into the part that deals with input and output, and the processing part in between. To do this, I defined this function:



fn manhattan_distance(s: &str) -> i32 {
...
}


I inlined the split_dir, update_x, update_y and get_manhattan_dist functions, and in the end my code became:



use std::fs;

struct Pos {
x: i32,
y: i32,
dir: Direction,
}

struct Direction {
dx: i32,
dy: i32,
}

impl Direction {
fn left(&self) -> Direction {
Direction {
dx: self.dy,
dy: -self.dx,
}
}

fn right(&self) -> Direction {
Direction {
dx: -self.dy,
dy: self.dx,
}
}
}

fn manhattan_distance(s: &str) -> i32 {
let steps = s.trim().split(", ");

let mut pos = Pos {
x: 0,
y: 0,
dir: Direction { dx: 0, dy: -1 },
};

for step in steps {
let (turn, dist) = step.split_at(1);

// Update direction
pos.dir = match turn {
"L" => pos.dir.left(),
"R" => pos.dir.right(),
_ => panic!("invalid turn {} in step {}", turn, step),
};

// Update position
let dist = dist.parse::<i32>().unwrap();
pos.x += pos.dir.dx * dist;
pos.y += pos.dir.dy * dist;
}

pos.x.abs() + pos.y.abs()
}

fn main() {
let s = fs::read_to_string("2016-1.txt").expect("Failed to read file.");

println!("{}", manhattan_distance(&s));
}


What's left now are some automatic tests. The function manhattan_distance is well-prepared for that since it has no side-effects, does not need any input or output, gets its parameter as a simple string and just returns its result.



And here are some example tests. You should add some more to explore other interesting cases, like crossing the x or y axis. The current tests might also pass if you omit the calls to abs.



#[cfg(test)]
mod tests {
use crate::manhattan_distance;

#[test]
fn manhattan_distance_example() {
assert_eq!(11, manhattan_distance("R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4"))
}

#[test]
fn manhattan_distance_empty() {
assert_eq!(0, manhattan_distance(" tn"))
}

#[test]
fn manhattan_distance_simple() {
assert_eq!(13, manhattan_distance("R8, L5"))
}

#[test]
fn manhattan_distance_rectangle() {
assert_eq!(0, manhattan_distance("R8, L5, L8, L5"))
}
}


Your code is a good working base, it was just longer than necessary. I also changed most of the variable names to be a little more precise and easier to grasp for a casual reader of the code. For example, since the task talks about "steps", it's only natural to name the corresponding variables in the code also "steps" and "step".



Since this is my first real program in Rust as well, I don't know what the really idiomatic Rust code looks like, I hope I could improve the code nevertheless.



To check whether I made any typical beginner's mistakes, I ran cargo-clippy, and I didn't get any complaints.






share|improve this answer











$endgroup$
















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "196"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f223639%2fcompute-manhattan-distance-from-origin-given-a-set-of-left-right-step-directions%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3












    $begingroup$

    Your code looks more complicated than necessary for this task.



    The first thing I noticed was the directions N, E, S, W. There is no need to explicitly name them. It is simpler to just define a direction as a 2-dimensional tuple:



    struct Direction {
    dx: i32,
    dy: i32
    }


    That's the essence of a direction. As the next step, I remembered that rotating such a direction by 90 degrees is quite simple. It just involves swapping the coordinates and reversing one of them. To get these right, I manually checked all the combinations after writing this code:



    impl Direction {
    fn left(&self) -> Direction { Direction { dx: self.dy, dy: -self.dx } }
    fn right(&self) -> Direction { Direction { dx: -self.dy, dy: self.dx } }
    }


    By these simple definitions, I avoided dealing with N, E, S, W at all.



    When I tested the program using the example you provided, my IDE added a trailing newline to the file, as is usual for text files. Then the program crashed because it could not parse an empty string. Therefore I changed split_dir(&s) into split_dir(s.trim()), and it worked.



    To understand the main program, I separated it into the part that deals with input and output, and the processing part in between. To do this, I defined this function:



    fn manhattan_distance(s: &str) -> i32 {
    ...
    }


    I inlined the split_dir, update_x, update_y and get_manhattan_dist functions, and in the end my code became:



    use std::fs;

    struct Pos {
    x: i32,
    y: i32,
    dir: Direction,
    }

    struct Direction {
    dx: i32,
    dy: i32,
    }

    impl Direction {
    fn left(&self) -> Direction {
    Direction {
    dx: self.dy,
    dy: -self.dx,
    }
    }

    fn right(&self) -> Direction {
    Direction {
    dx: -self.dy,
    dy: self.dx,
    }
    }
    }

    fn manhattan_distance(s: &str) -> i32 {
    let steps = s.trim().split(", ");

    let mut pos = Pos {
    x: 0,
    y: 0,
    dir: Direction { dx: 0, dy: -1 },
    };

    for step in steps {
    let (turn, dist) = step.split_at(1);

    // Update direction
    pos.dir = match turn {
    "L" => pos.dir.left(),
    "R" => pos.dir.right(),
    _ => panic!("invalid turn {} in step {}", turn, step),
    };

    // Update position
    let dist = dist.parse::<i32>().unwrap();
    pos.x += pos.dir.dx * dist;
    pos.y += pos.dir.dy * dist;
    }

    pos.x.abs() + pos.y.abs()
    }

    fn main() {
    let s = fs::read_to_string("2016-1.txt").expect("Failed to read file.");

    println!("{}", manhattan_distance(&s));
    }


    What's left now are some automatic tests. The function manhattan_distance is well-prepared for that since it has no side-effects, does not need any input or output, gets its parameter as a simple string and just returns its result.



    And here are some example tests. You should add some more to explore other interesting cases, like crossing the x or y axis. The current tests might also pass if you omit the calls to abs.



    #[cfg(test)]
    mod tests {
    use crate::manhattan_distance;

    #[test]
    fn manhattan_distance_example() {
    assert_eq!(11, manhattan_distance("R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4"))
    }

    #[test]
    fn manhattan_distance_empty() {
    assert_eq!(0, manhattan_distance(" tn"))
    }

    #[test]
    fn manhattan_distance_simple() {
    assert_eq!(13, manhattan_distance("R8, L5"))
    }

    #[test]
    fn manhattan_distance_rectangle() {
    assert_eq!(0, manhattan_distance("R8, L5, L8, L5"))
    }
    }


    Your code is a good working base, it was just longer than necessary. I also changed most of the variable names to be a little more precise and easier to grasp for a casual reader of the code. For example, since the task talks about "steps", it's only natural to name the corresponding variables in the code also "steps" and "step".



    Since this is my first real program in Rust as well, I don't know what the really idiomatic Rust code looks like, I hope I could improve the code nevertheless.



    To check whether I made any typical beginner's mistakes, I ran cargo-clippy, and I didn't get any complaints.






    share|improve this answer











    $endgroup$


















      3












      $begingroup$

      Your code looks more complicated than necessary for this task.



      The first thing I noticed was the directions N, E, S, W. There is no need to explicitly name them. It is simpler to just define a direction as a 2-dimensional tuple:



      struct Direction {
      dx: i32,
      dy: i32
      }


      That's the essence of a direction. As the next step, I remembered that rotating such a direction by 90 degrees is quite simple. It just involves swapping the coordinates and reversing one of them. To get these right, I manually checked all the combinations after writing this code:



      impl Direction {
      fn left(&self) -> Direction { Direction { dx: self.dy, dy: -self.dx } }
      fn right(&self) -> Direction { Direction { dx: -self.dy, dy: self.dx } }
      }


      By these simple definitions, I avoided dealing with N, E, S, W at all.



      When I tested the program using the example you provided, my IDE added a trailing newline to the file, as is usual for text files. Then the program crashed because it could not parse an empty string. Therefore I changed split_dir(&s) into split_dir(s.trim()), and it worked.



      To understand the main program, I separated it into the part that deals with input and output, and the processing part in between. To do this, I defined this function:



      fn manhattan_distance(s: &str) -> i32 {
      ...
      }


      I inlined the split_dir, update_x, update_y and get_manhattan_dist functions, and in the end my code became:



      use std::fs;

      struct Pos {
      x: i32,
      y: i32,
      dir: Direction,
      }

      struct Direction {
      dx: i32,
      dy: i32,
      }

      impl Direction {
      fn left(&self) -> Direction {
      Direction {
      dx: self.dy,
      dy: -self.dx,
      }
      }

      fn right(&self) -> Direction {
      Direction {
      dx: -self.dy,
      dy: self.dx,
      }
      }
      }

      fn manhattan_distance(s: &str) -> i32 {
      let steps = s.trim().split(", ");

      let mut pos = Pos {
      x: 0,
      y: 0,
      dir: Direction { dx: 0, dy: -1 },
      };

      for step in steps {
      let (turn, dist) = step.split_at(1);

      // Update direction
      pos.dir = match turn {
      "L" => pos.dir.left(),
      "R" => pos.dir.right(),
      _ => panic!("invalid turn {} in step {}", turn, step),
      };

      // Update position
      let dist = dist.parse::<i32>().unwrap();
      pos.x += pos.dir.dx * dist;
      pos.y += pos.dir.dy * dist;
      }

      pos.x.abs() + pos.y.abs()
      }

      fn main() {
      let s = fs::read_to_string("2016-1.txt").expect("Failed to read file.");

      println!("{}", manhattan_distance(&s));
      }


      What's left now are some automatic tests. The function manhattan_distance is well-prepared for that since it has no side-effects, does not need any input or output, gets its parameter as a simple string and just returns its result.



      And here are some example tests. You should add some more to explore other interesting cases, like crossing the x or y axis. The current tests might also pass if you omit the calls to abs.



      #[cfg(test)]
      mod tests {
      use crate::manhattan_distance;

      #[test]
      fn manhattan_distance_example() {
      assert_eq!(11, manhattan_distance("R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4"))
      }

      #[test]
      fn manhattan_distance_empty() {
      assert_eq!(0, manhattan_distance(" tn"))
      }

      #[test]
      fn manhattan_distance_simple() {
      assert_eq!(13, manhattan_distance("R8, L5"))
      }

      #[test]
      fn manhattan_distance_rectangle() {
      assert_eq!(0, manhattan_distance("R8, L5, L8, L5"))
      }
      }


      Your code is a good working base, it was just longer than necessary. I also changed most of the variable names to be a little more precise and easier to grasp for a casual reader of the code. For example, since the task talks about "steps", it's only natural to name the corresponding variables in the code also "steps" and "step".



      Since this is my first real program in Rust as well, I don't know what the really idiomatic Rust code looks like, I hope I could improve the code nevertheless.



      To check whether I made any typical beginner's mistakes, I ran cargo-clippy, and I didn't get any complaints.






      share|improve this answer











      $endgroup$
















        3












        3








        3





        $begingroup$

        Your code looks more complicated than necessary for this task.



        The first thing I noticed was the directions N, E, S, W. There is no need to explicitly name them. It is simpler to just define a direction as a 2-dimensional tuple:



        struct Direction {
        dx: i32,
        dy: i32
        }


        That's the essence of a direction. As the next step, I remembered that rotating such a direction by 90 degrees is quite simple. It just involves swapping the coordinates and reversing one of them. To get these right, I manually checked all the combinations after writing this code:



        impl Direction {
        fn left(&self) -> Direction { Direction { dx: self.dy, dy: -self.dx } }
        fn right(&self) -> Direction { Direction { dx: -self.dy, dy: self.dx } }
        }


        By these simple definitions, I avoided dealing with N, E, S, W at all.



        When I tested the program using the example you provided, my IDE added a trailing newline to the file, as is usual for text files. Then the program crashed because it could not parse an empty string. Therefore I changed split_dir(&s) into split_dir(s.trim()), and it worked.



        To understand the main program, I separated it into the part that deals with input and output, and the processing part in between. To do this, I defined this function:



        fn manhattan_distance(s: &str) -> i32 {
        ...
        }


        I inlined the split_dir, update_x, update_y and get_manhattan_dist functions, and in the end my code became:



        use std::fs;

        struct Pos {
        x: i32,
        y: i32,
        dir: Direction,
        }

        struct Direction {
        dx: i32,
        dy: i32,
        }

        impl Direction {
        fn left(&self) -> Direction {
        Direction {
        dx: self.dy,
        dy: -self.dx,
        }
        }

        fn right(&self) -> Direction {
        Direction {
        dx: -self.dy,
        dy: self.dx,
        }
        }
        }

        fn manhattan_distance(s: &str) -> i32 {
        let steps = s.trim().split(", ");

        let mut pos = Pos {
        x: 0,
        y: 0,
        dir: Direction { dx: 0, dy: -1 },
        };

        for step in steps {
        let (turn, dist) = step.split_at(1);

        // Update direction
        pos.dir = match turn {
        "L" => pos.dir.left(),
        "R" => pos.dir.right(),
        _ => panic!("invalid turn {} in step {}", turn, step),
        };

        // Update position
        let dist = dist.parse::<i32>().unwrap();
        pos.x += pos.dir.dx * dist;
        pos.y += pos.dir.dy * dist;
        }

        pos.x.abs() + pos.y.abs()
        }

        fn main() {
        let s = fs::read_to_string("2016-1.txt").expect("Failed to read file.");

        println!("{}", manhattan_distance(&s));
        }


        What's left now are some automatic tests. The function manhattan_distance is well-prepared for that since it has no side-effects, does not need any input or output, gets its parameter as a simple string and just returns its result.



        And here are some example tests. You should add some more to explore other interesting cases, like crossing the x or y axis. The current tests might also pass if you omit the calls to abs.



        #[cfg(test)]
        mod tests {
        use crate::manhattan_distance;

        #[test]
        fn manhattan_distance_example() {
        assert_eq!(11, manhattan_distance("R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4"))
        }

        #[test]
        fn manhattan_distance_empty() {
        assert_eq!(0, manhattan_distance(" tn"))
        }

        #[test]
        fn manhattan_distance_simple() {
        assert_eq!(13, manhattan_distance("R8, L5"))
        }

        #[test]
        fn manhattan_distance_rectangle() {
        assert_eq!(0, manhattan_distance("R8, L5, L8, L5"))
        }
        }


        Your code is a good working base, it was just longer than necessary. I also changed most of the variable names to be a little more precise and easier to grasp for a casual reader of the code. For example, since the task talks about "steps", it's only natural to name the corresponding variables in the code also "steps" and "step".



        Since this is my first real program in Rust as well, I don't know what the really idiomatic Rust code looks like, I hope I could improve the code nevertheless.



        To check whether I made any typical beginner's mistakes, I ran cargo-clippy, and I didn't get any complaints.






        share|improve this answer











        $endgroup$



        Your code looks more complicated than necessary for this task.



        The first thing I noticed was the directions N, E, S, W. There is no need to explicitly name them. It is simpler to just define a direction as a 2-dimensional tuple:



        struct Direction {
        dx: i32,
        dy: i32
        }


        That's the essence of a direction. As the next step, I remembered that rotating such a direction by 90 degrees is quite simple. It just involves swapping the coordinates and reversing one of them. To get these right, I manually checked all the combinations after writing this code:



        impl Direction {
        fn left(&self) -> Direction { Direction { dx: self.dy, dy: -self.dx } }
        fn right(&self) -> Direction { Direction { dx: -self.dy, dy: self.dx } }
        }


        By these simple definitions, I avoided dealing with N, E, S, W at all.



        When I tested the program using the example you provided, my IDE added a trailing newline to the file, as is usual for text files. Then the program crashed because it could not parse an empty string. Therefore I changed split_dir(&s) into split_dir(s.trim()), and it worked.



        To understand the main program, I separated it into the part that deals with input and output, and the processing part in between. To do this, I defined this function:



        fn manhattan_distance(s: &str) -> i32 {
        ...
        }


        I inlined the split_dir, update_x, update_y and get_manhattan_dist functions, and in the end my code became:



        use std::fs;

        struct Pos {
        x: i32,
        y: i32,
        dir: Direction,
        }

        struct Direction {
        dx: i32,
        dy: i32,
        }

        impl Direction {
        fn left(&self) -> Direction {
        Direction {
        dx: self.dy,
        dy: -self.dx,
        }
        }

        fn right(&self) -> Direction {
        Direction {
        dx: -self.dy,
        dy: self.dx,
        }
        }
        }

        fn manhattan_distance(s: &str) -> i32 {
        let steps = s.trim().split(", ");

        let mut pos = Pos {
        x: 0,
        y: 0,
        dir: Direction { dx: 0, dy: -1 },
        };

        for step in steps {
        let (turn, dist) = step.split_at(1);

        // Update direction
        pos.dir = match turn {
        "L" => pos.dir.left(),
        "R" => pos.dir.right(),
        _ => panic!("invalid turn {} in step {}", turn, step),
        };

        // Update position
        let dist = dist.parse::<i32>().unwrap();
        pos.x += pos.dir.dx * dist;
        pos.y += pos.dir.dy * dist;
        }

        pos.x.abs() + pos.y.abs()
        }

        fn main() {
        let s = fs::read_to_string("2016-1.txt").expect("Failed to read file.");

        println!("{}", manhattan_distance(&s));
        }


        What's left now are some automatic tests. The function manhattan_distance is well-prepared for that since it has no side-effects, does not need any input or output, gets its parameter as a simple string and just returns its result.



        And here are some example tests. You should add some more to explore other interesting cases, like crossing the x or y axis. The current tests might also pass if you omit the calls to abs.



        #[cfg(test)]
        mod tests {
        use crate::manhattan_distance;

        #[test]
        fn manhattan_distance_example() {
        assert_eq!(11, manhattan_distance("R5, L2, L1, R1, R3, R3, L3, R3, R4, L2, R4, L4, R4"))
        }

        #[test]
        fn manhattan_distance_empty() {
        assert_eq!(0, manhattan_distance(" tn"))
        }

        #[test]
        fn manhattan_distance_simple() {
        assert_eq!(13, manhattan_distance("R8, L5"))
        }

        #[test]
        fn manhattan_distance_rectangle() {
        assert_eq!(0, manhattan_distance("R8, L5, L8, L5"))
        }
        }


        Your code is a good working base, it was just longer than necessary. I also changed most of the variable names to be a little more precise and easier to grasp for a casual reader of the code. For example, since the task talks about "steps", it's only natural to name the corresponding variables in the code also "steps" and "step".



        Since this is my first real program in Rust as well, I don't know what the really idiomatic Rust code looks like, I hope I could improve the code nevertheless.



        To check whether I made any typical beginner's mistakes, I ran cargo-clippy, and I didn't get any complaints.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 6 hours ago

























        answered 7 hours ago









        Roland IlligRoland Illig

        14k1 gold badge23 silver badges55 bronze badges




        14k1 gold badge23 silver badges55 bronze badges






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Code Review Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f223639%2fcompute-manhattan-distance-from-origin-given-a-set-of-left-right-step-directions%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Ciclooctatetraenă Vezi și | Bibliografie | Meniu de navigare637866text4148569-500570979m