Compute Manhattan distance from origin given a set of left-right-step directionsTruncating 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
Chilling water in copper vessel
Tesco's Burger Relish Best Before End date number
Writing an ace/aro character?
How can I use my cell phone's light as a reading light?
What was the significance of Spider-Man: Far From Home being an MCU Phase 3 film instead of a Phase 4 film?
How was the website able to tell my credit card was wrong before it processed it?
How do I talk to my wife about unrealistic expectations?
Wires do not connect in Circuitikz
Passwordless authentication - how and when to invalidate a login code
What term do you use for someone who acts impulsively?
Is homosexuality or bisexuality allowed for women?
I'm feeling like my character doesn't fit the campaign
Tikz people in diagram
Four ships at the ocean with the same distance
What are the effects of abstaining from eating a certain flavor?
Was it ever illegal to name a pig "Napoleon" in France?
What are the consequences for a developed nation to not accept any refugees?
Sense of humor in your sci-fi stories
Draw a diagram with rectangles
Moving millions of files to a different directory with specfic name patterns
Why does Trump want a citizenship question on the census?
Strong Password Detection in Python
My previous employer committed a severe violation of the law and is also being sued by me. How do I explain the situation to future employers?
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?
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;
$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.
programming-challenge rust taxicab-geometry
$endgroup$
add a comment |
$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.
programming-challenge rust taxicab-geometry
$endgroup$
$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
6 hours ago
add a comment |
$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.
programming-challenge rust taxicab-geometry
$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
programming-challenge rust taxicab-geometry
edited 5 hours ago
200_success
134k21 gold badges171 silver badges440 bronze badges
134k21 gold badges171 silver badges440 bronze badges
asked 8 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
6 hours ago
add a comment |
$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
6 hours ago
$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
6 hours ago
$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
6 hours ago
add a comment |
1 Answer
1
active
oldest
votes
$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.
$endgroup$
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
$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.
$endgroup$
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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.
edited 5 hours ago
answered 6 hours ago
Roland IlligRoland Illig
14k1 gold badge23 silver badges55 bronze badges
14k1 gold badge23 silver badges55 bronze badges
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
$begingroup$
am particularly interested in error handling — what do you want to happen on errors?
$endgroup$
– Shepmaster
6 hours ago