Open Side Menu Go to the Top
Register
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

11-25-2014 , 06:43 PM
Quote:
Originally Posted by jmakin
the problem, as it was given to me, gives 2 points of the opposite sides of a rectangle. yes you should assume they are parallel to the x and y axis unless it otherwise specifies.

i just checked if any of the 2nd rectangle's corners end up inside the area bounded by the first rectangle's corners.
Returning the intersection of the rectangles is less trivial than it appears at first glance. There are different cases depending on whether 4, 2 or 1 of the corners of the second rectangle lie within the first (3 is not possible).

I'd just deal with those cases individually, not sure if there's a more elegant way to do it.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-25-2014 , 10:39 PM
Code:
class Rectangle

  attr_accessor :p1, :p2

  def initialize(p1,p2)
    @p1 = p1
    @p2 = p2
  end

  def overlap_rectangle(rect)
    xs = {
      my1: p1[0],
      my2: p2[0],
      other1: rect.p1[0],
      other2: rect.p2[0]
    }
    ys = {
      my1: p1[1],
      my2: p2[1],
      other1: rect.p1[1],
      other2: rect.p2[1]
    }

    x_interval = interval(xs)
    y_interval = interval(ys)
    p1 = [x_interval[0], y_interval[0]]
    p2 = [x_interval[1], y_interval[1]]
    Rectangle.new(p1,p2)
  end

  def interval(points)
    sorted_keys = sorted_keys_by_value(points)
    interval = [0,0]
    if no_overlap(sorted_keys, points)
      interval = [0,0]
    elsif share_edges(points)
      interval = min_max(points)
    else
      sorted_keys.each_cons(3) do |keys|
        if keys[1].to_s[0...-1] != keys[2].to_s[0...-1]
          interval = [points[keys[1]], points[keys[0]]]#[hi,low] 
        end
      end 
    end
    interval 
  end

  def sorted_keys_by_value(points)
    sorted_keys = [] 
    points.values.sort.uniq.reverse.each do |val|
      #simple points.key(val) fails when keys share a value so do this
      points.select{|k,v| v == val}.each do |k,v|
        sorted_keys << k
      end
    end
    sorted_keys
  end

  def min_max(points)
    [points.values.min, points.values.max]
  end

  def share_edges(points)
    points.values.uniq.length == 2 
  end

  def no_overlap(sorted_points,points)
    whos = sorted_points.map {|p| p.to_s[0...-1]}
    (whos[0] == whos[1]) && (whos[2] == whos[3]) \
    && points.values.uniq.length > 2
  end

end
Code:
require 'minitest/autorun'
require_relative 'rectangle'

class RectangleTest < MiniTest::Unit::TestCase

  def test_1
    a = Rectangle.new([2,3],[5,8])
    b = Rectangle.new([4,4],[9,9])
    n = a.overlap_rectangle(b)
    assert_equal [4,4], n.p1
    assert_equal [5,8], n.p2
  end

  def test_2
    a = Rectangle.new([0,0],[9,9])
    b = Rectangle.new([2,3],[4,7])
    n = a.overlap_rectangle(b)
    assert_equal [2,3], n.p1
    assert_equal [4,7], n.p2
  end

  def test_3
    a = Rectangle.new([0,0],[9,9])
    b = Rectangle.new([2,3],[9,9])
    n = a.overlap_rectangle(b)
    assert_equal [2,3], n.p1
    assert_equal [9,9], n.p2
  end
  def test_4
    a = Rectangle.new([1,3],[9,9])
    b = Rectangle.new([0,0],[9,9])
    n = a.overlap_rectangle(b)
    assert_equal [1,3], n.p1
    assert_equal [9,9], n.p2
  end
  def test_5
    a = Rectangle.new([1,3],[9,9])
    b = Rectangle.new([-2,-8],[5,8])
    n = a.overlap_rectangle(b)
    assert_equal [1,3], n.p1
    assert_equal [5,8], n.p2
  end
  def test_6
    a = Rectangle.new([1,3],[9,9])
    b = Rectangle.new([-1,5],[7,7])
    n = a.overlap_rectangle(b)
    assert_equal [1,5], n.p1
    assert_equal [7,7], n.p2
  end

  def test_7
    a = Rectangle.new([1,3],[4,4])
    b = Rectangle.new([5,5],[7,7])
    n = a.overlap_rectangle(b)
    assert_equal [0,0], n.p1
    assert_equal [0,0], n.p2
  end
  def test_jj
    a = Rectangle.new([1,3],[4,4])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [2,3], n.p1
    assert_equal [4,4], n.p2
  end
  def test_same
    a = Rectangle.new([2,2],[4,4])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [2,2], n.p1
    assert_equal [4,4], n.p2
  end

  def test_almost_same
    a = Rectangle.new([3,2],[4,4])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [4,4], n.p2
    assert_equal [3,2], n.p1
  end
  def test_almost_same2
    a = Rectangle.new([2,3],[4,4])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [4,4], n.p2
    assert_equal [2,3], n.p1
  end
  def test_almost_same3
    a = Rectangle.new([2,2],[4,3])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [2,2], n.p1
    assert_equal [4,3], n.p2
  end
  def test_almost_same4
    a = Rectangle.new([2,2],[3,4])
    b = Rectangle.new([2,2],[4,4])
    n = a.overlap_rectangle(b)
    assert_equal [2,2], n.p1
    assert_equal [3,4], n.p2
  end
end
I think this works. Feel free to critique, I've been posting pure **** to exercism.io lately and realizing how much I actually suck at this.

This was also a lot harder than I thought it'd be btw. I wouldn't feel too bad about flubbing this and it's the exact type of problem you can improve on with practice/exposure to similar problems.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-25-2014 , 10:48 PM
Code:
# convenience ctor
def r(x1,y1,x2,y2) Rect.new Point.new(x1,y1), Point.new(x2,y2); end

Point = Struct.new(:x, :y)

Rect = Struct.new(:p1, :p2) do

  def intersection(r2)
    # just checking the disjoint case here
    xs = x_points + r2.x_points
    ys = y_points + r2.y_points
    return nil if disjoint(xs) || disjoint(ys)

    # these three lines are really the whole implementation
    xs = xs.sort
    ys = ys.sort
    r(xs[1], ys[1],xs[2], ys[2])
  end

  def x_points() [p1.x, p2.x].sort; end

  def y_points() [p1.y, p2.y].sort; end

  def disjoint(_s) _s == _s.sort; end

end

###############################
# TESTS BELOW
# (pure ruby cause lol require)
###############################

r1 = r(0,0,  6,4) 
r2 = r(4,2,  13,8)
expected_intersection = r(4,2,  6,4)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(3,1,  8,3)
expected_intersection = r(3,1,  6,3)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(1,1,   3,3)
expected_intersection = r(1,1,   3,3)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(6,0,  7,3)
expected_intersection = nil
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

Last edited by gaming_mouse; 11-25-2014 at 10:54 PM.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-25-2014 , 10:48 PM
To beat this rectangle problem to death.
Quote:
rec·tan·gle
ˈrekˌtaNGɡəl/
noun
a plane figure with four straight sides and four right angles, especially one with unequal adjacent sides, in contrast to a square.
Even assuming sides are parallel to the respective axes which of course is necessary, there are clearly inputs of opposite corner vertices that are errors and in my view it is good practice to detect them and reflect that to the function callers. The point i was trying to make was that in software development it is a common occurrence for developers to make assumptions about the task at hand that are in error in some way or another. Even seemingly trivial programming tasks can end up being more involved than what it might appear at first glance.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-25-2014 , 11:20 PM
Quote:
Originally Posted by gaming_mouse
[code]
# these three lines are really the whole implementation
xs = xs.sort
ys = ys.sort
r(xs[1], ys[1],xs[2], ys[2])
haha, its interesting looking back at this now.

I seem to always foresee a problem with approach A so try approach B. Then when B fails I add checks that would have solved A's original problem but mentally I'm attached to approach B. I then go down a weird path and end up with an ugly solution. In this case I tried to solve for the disjoint case by comparing keys of the hash with the point values. Then I gave in and added the disjoint check and got the tests passing lol.

Maybe theres a reason I don't do this professionally
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 05:26 AM
Ah yeah, gaming_mouse's solution is pretty cute.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 10:49 AM
Asked my brother re rectangle problem, he does a lot of work on 2D geometric stuff like this. One line solution for axis aligned:

Code:
Rect.prototype.intersects_rect = function (rc)
{
  return !(rc.right < this.left || rc.bottom < this.top || rc.left > this.right || rc.top > this.bottom);
};
Honestly if I was asked this in an interview, I'd probably panic and not do a good job of it lol but hey ho, in a relaxed environment I could work it out (getting flashbacks to secondary school geometry here lol)

Polygon collision is a lot trickier

Last edited by Gullanian; 11-26-2014 at 11:00 AM.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 11:30 AM
Gull, you have to return the intersection rectangle as well.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 12:05 PM
doh, I'll show myself out lol. Wouldn't rate my chances of answering that on the spot in an interview but there we go!
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 12:08 PM
Quote:
Originally Posted by gaming_mouse
Code:
# convenience ctor
def r(x1,y1,x2,y2) Rect.new Point.new(x1,y1), Point.new(x2,y2); end

Point = Struct.new(:x, :y)

Rect = Struct.new(:p1, :p2) do

  def intersection(r2)
    # just checking the disjoint case here
    xs = x_points + r2.x_points
    ys = y_points + r2.y_points
    return nil if disjoint(xs) || disjoint(ys)

    # these three lines are really the whole implementation
    xs = xs.sort
    ys = ys.sort
    r(xs[1], ys[1],xs[2], ys[2])
  end

  def x_points() [p1.x, p2.x].sort; end

  def y_points() [p1.y, p2.y].sort; end

  def disjoint(_s) _s == _s.sort; end

end

###############################
# TESTS BELOW
# (pure ruby cause lol require)
###############################

r1 = r(0,0,  6,4) 
r2 = r(4,2,  13,8)
expected_intersection = r(4,2,  6,4)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(3,1,  8,3)
expected_intersection = r(3,1,  6,3)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(1,1,   3,3)
expected_intersection = r(1,1,   3,3)
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(0,0,  6,4) 
r2 = r(6,0,  7,3)
expected_intersection = nil
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"

r1 = r(6,0,  7,3) 
r2 = r(0,0,  6,4)
expected_intersection = nil
puts expected_intersection == r1.intersection(r2) ? "Pass" : "Fail"
Added one more test.
(run in browser)
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 12:13 PM
This is a pretty easy interview question if you follow the strategy of:

1. Always draw the problem out.
2. See if you can simplify the problem (like by sorting so you can assume rectangle 1 is always left of rectangle 2)
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 12:46 PM
Quote:
Originally Posted by Benholio
Added one more test.
(run in browser)
doh, but easily fixed: http://rubyfiddle.com/riddles/0cdda/2

doesn't change the main algorithm at all
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 12:54 PM
Quote:
Originally Posted by jjshabado
This is a pretty easy interview question if you follow the strategy of:

1. Always draw the problem out.
2. See if you can simplify the problem (like by sorting so you can assume rectangle 1 is always left of rectangle 2)
yeah it could be a good interview question. and it's easy to make it a lot less trivial, eg, by adding multiple rectangles and finding all intersections, finding places where 3 or more intersect, etc
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 01:05 PM
Quote:
Originally Posted by gaming_mouse
yeah it could be a good interview question. and it's easy to make it a lot less trivial, eg, by adding multiple rectangles and finding all intersections, finding places where 3 or more intersect, etc
You guys think it's a "good" interview question though? If you want a mathy candidate, you need much harder questions. If you don't care about mathematical skills, it's verbose and irrelevant - plenty of decent coder types will look unduly bad answering this question, if they haven't dealt much with cartesian coordinates before. Answers are also going to be tedious to verify. You want questions that spread candidates out on a spectrum (quick full answer > slow full answer without help > slow full answer with some help > partial answer > no progress) and I don't see how even a harder variant of this question does this.

I'd rather give straight math proofs and more fundamental CS questions.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 01:15 PM
Quote:
Originally Posted by candybar
You guys think it's a "good" interview question though? If you want a mathy candidate, you need much harder questions. If you don't care about mathematical skills, it's verbose and irrelevant - plenty of decent coder types will look unduly bad answering this question, if they haven't dealt much with cartesian coordinates before. Answers are also going to be tedious to verify. You want questions that spread candidates out on a spectrum (quick full answer > slow full answer without help > slow full answer with some help > partial answer > no progress) and I don't see how even a harder variant of this question does this.

I'd rather give straight math proofs and more fundamental CS questions.
i'm looking at a little differently. i don't see it as overly mathy since the math is really 8th grade level. i'm looking for problems where the details get out of the way, and the problem becomes just a springboard to see how someone codes. i almost never give really "hard" logic problems. i guess in that way i disagree with you about the cartesian coordinates being an irrelevant detail that could trip you up. i agree it's a kind of "book keeping" or "notation" detail, but it's so simple that it should be easy to get right, and i'd expect anyone good to be able to get it right. getting that stuff right is a skill that's important to writing maintainable code imo.

so i'd give the direction to clean the code up as much possible and give me an example of what you consider clean, production quality code. i'd explicitly tell them it's not a race to beat the clock, but an opportunity to convey what "good" code means to them.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 01:16 PM
I didn't say it was a good interview question, I said it was an easy one.

Although I think its not bad as a relatively early question in an interview. The math is pretty trivial and so you can focus more on general problem solving and how someone can translate an algorithm into code.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 01:16 PM
Yeah, what GM said.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 01:20 PM
Quote:
Originally Posted by candybar
Answers are also going to be tedious to verify.
Also, I think this is just wrong. When I ask an interview question I'm watching and listening to the candidate answer it. I'm pretty confident I can read/understand code (especially with a problem I'm familiar with) faster than most people can write it (and I'm sure that's true for most interviewers).
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 02:25 PM
A classmate asked me about preparing for interviews and I gave him some pointers and then introduced him to FizzBuzz. Guess what programming problem he was given in the interview?
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 02:54 PM
Quote:
Originally Posted by jjshabado
Also, I think this is just wrong. When I ask an interview question I'm watching and listening to the candidate answer it. I'm pretty confident I can read/understand code (especially with a problem I'm familiar with) faster than most people can write it (and I'm sure that's true for most interviewers).
There are a ridiculous number of convoluted ways to solve this problem and a whole bunch of different ways of handling edge cases, not to mention the problem/solution can be generalized in a number of directions (rotated rectangles, n-dimensional space, polygons, Riemannian) that the average interview will be unprepared to evaluate. You don't want to give a 5th grade problem that with answers that will confound college students - you want to give 9th grade problems with a range of answers that can be evaluated by an 11th grader.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 03:08 PM
Quote:
Originally Posted by candybar
There are a ridiculous number of convoluted ways to solve this problem and a whole bunch of different ways of handling edge cases
indeed, and someone who choosing one of those convoluted ways (and not realizing there are simpler ones) is valuable information about them. i mean, it's not like the simpler solutions here are difficult "tricks" that it would be unfair to expect someone to find.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 03:08 PM
It's an interview question, and a very simple one at that. If you can't explain to me how your solution works, I don't want to work with you.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 03:09 PM
Damn, GM.

Edit: Looks like my super-mod powers of not being subjected to the 25 second window between posts only applies in in my forum. Lame.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 03:27 PM
Quote:
Originally Posted by gaming_mouse
i'm looking for problems where the details get out of the way, and the problem becomes just a springboard to see how someone codes.
If I'm not mistaken, this problem has a trivial 4-line solution - how does this help you see how someone codes? If you want to see lots of code, why not just a give a boring problem with a long boring answer?

Quote:
i guess in that way i disagree with you about the cartesian coordinates being an irrelevant detail that could trip you up. i agree it's a kind of "book keeping" or "notation" detail, but it's so simple that it should be easy to get right, and i'd expect anyone good to be able to get it right.
It's an irrelevant detail because variance in comfort with cartesian coordinates has very little to do with variance in programming ability. Tons of bad coders were good at math back in 8th grade and the problem is far too easy for them. You could have given this problem to me in 8th grade a few days after I first learned how to program and I would've given you a perfect answer instantly.

Quote:
i'd give the direction to clean the code up as much possible and give me an example of what you consider clean, production quality code. i'd explicitly tell them it's not a race to beat the clock, but an opportunity to convey what "good" code means to them.
"Clean, production quality" is an attribute of a code base and generally speaking not a quality that can be attributed to small code snippets. It's like calling individual cells of professional athletes athletic. Answers to puzzles aren't going to tell me whether someone is going to have the discipline to come back to a preliminary solution that "works" to fix minor bugs and optimize performance in small ways. They aren't going to tell me whether the candidate is going to fix inconsistent names that are scattered around a code base, add tests to legacy code, carefully isolate code written for a specific situation that's unlikely to apply generally, and otherwise work to improve a code base.

Puzzles are for judging ability and once you have the capacity to program at a high level, "clean production quality" is almost entirely about character. You can judge character during the interview, but it's definitely not by seeing whether code produced for a puzzle question looks production-quality - that's more of a sign of an inflexible mind than anything else.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
11-26-2014 , 03:42 PM
Quote:
Originally Posted by candybar
If I'm not mistaken, this problem has a trivial 4-line solution - how does this help you see how someone codes? If you want to see lots of code, why not just a give a boring problem with a long boring answer?
If someone comes up with the trivial 4-line solution, I think I've learned a lot about how they can code.

Quote:
Originally Posted by candybar
It's an irrelevant detail because variance in comfort with cartesian coordinates has very little to do with variance in programming ability. Tons of bad coders were good at math back in 8th grade and the problem is far too easy for them. You could have given this problem to me in 8th grade a few days after I first learned how to program and I would've given you a perfect answer instantly.
Great. Then you move on to the next question.

Quote:
Originally Posted by candybar
"Clean, production quality" is an attribute of a code base and generally speaking not a quality that can be attributed to small code snippets.
I agree with this. For me its much more about seeing how they approach a problem, come up with a solution, and translate that solution into working/sensible code. I start with simpler questions because it helps avoiding wasting time and it helps build a candidate's confidence rather than throwing them right at a hard problem.

I strongly disagree with the idea that this is a puzzle. Even if someone had no exposure to cartesian coordinates I'd expect them to be able to pick up the necessary information in the interview. Programmers have to pick up much more complicated topics on a regular basis.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote

      
m