How do you usually implement right triangles in programming

Question

When I want to implement axis aligned 2d rectangles I always go with {x, y, w, h}, because that is the natural approach to it. With 3d axis aligned rectangles you need {x, y, z, w, h, d(depth)}. For a 2d triangle I need {x1, y1, x2, y2, x3, y3}. But what do I need for axis aligned right triangles. How would you store them?

I can imagine going with the same data as a rectangle and then a number 0 to 3 indicating which point is opposite to the hypotenuse. I can also imagine going with {x, y, w, h}, where w and h is allowed to be negative (opposite to the normal rects).

Which is the common approach to implementing right triangles?

EDIT:

Well I finally decided to go with {x, y, w, h, r}, where w, h >= 0 and r is the radians. So at first I can concentrate r = {0, pi/2, pi, 3pi/2} and if I wanna go crazy later on, I can do just that without breaking my interface.

Answer 1

There is no "common approach", because this is not a requirement occuring so frequently that it needs a special standard. So pick a solution which suits your needs like the one you suggested:

{x, y, w, h}, where w and h is allowed to be negative

That is actually the first idea which came into my mind when I saw your question, so why don't you give it a try?

Note if you implement this as an abstract data type or class Triangle, these four values are only needed as an internal storage representation, and there is no need for your classes's API to expose its internals. For example, the API can provide methods for querying the coordinates of the 3 corners in a uniform manner, without letting the user of that API see that one corner is stored internally "differently" than the other two. So if you later come to the point where you think the internal representation was chosen suboptimal, you can easily change it later without the need to change the code which uses the API.

So do not overthink the internal representation, better invest some time into the design of your API.

Answer 2

A triangle usually is implemented by storing 3 coordinates for the 3 corners. Any triangle, that is, regardless whether it's 2D or 3D, right, acute, equilateral, obtuse, or has whatever property you could think of.

Usually, there is no real need to special case axis aligned right triangles, because they don't have that many special properties compared to other triangles (other than being able to interpret it as half of an axis aligned rectangle, but why don't you use a rectangle in that case?).

Contrarily, there are some problems if you only allow axis aligned right triangles:

• gaps between axis aligned right triangles can not always be filled with other axis aligned right triangles.
• if you want to save bytes by reducing the data stored, you introduce some conventions that aren't always obvious and might lead to bugs later (look at your "clever" idea of storing negative width or height: you might easily introduce a bug that calculates negative area values!)

If you think your use case is special enough to profit from a different internal implementation, you could go for one. In that case, be sure to document what conventions you introduce (and as always, try to keep the API from leaking implementation details, especially in case you need to switch said implementation later)

Answer 3

For axis-aligned rectangles, I usually just go with {x1,y1,x2,y2} defining (either) one of its diagonals. Note that this uniquely defines an axis-aligned rectangle. And thus also defines two (axis-aligned) right triangles, with diagonal~hypoteneuse. To uniquely define just one, apply something like the "right-hand screw rule", i.e., hand open, palm up, point your right-hand thumb in the direction from {x1,y1} to {x2,y2}, and then your fingers point towards the right-angle.