Available Software

Maple

The following shows some examples of how to use maple to perform geometry operations and analysis:

including the package
> with(geometry):

defining a circle
> circle(c, x^2 + y^2 = 1):

defining a line and points and then testing if the points are on that line
> line(l, x + y = 1), point(A, a, 1/2), point(B, 3/5, b):
> IsOnLine(A, l), IsOnLine(B, l), IsOnLine({A,B}, l);
						false, true, false

defining a triangle and getting a bisector
> triangle(ABC, [point(A, 0, 0), point(B, 1, 1), point(C, 1, 0)]):
> bisector(bA, A, ABC), bisector(bB, B, ABC), bisector(bC, C, ABC):
> intersection(iAB, bA, bB), intersection(iAC, bA, bC), intersection(iBC, bB, bC):
> coordinates(iAB), coordinates(iAC), coordinates(iBC);
		[[0.7071067812, 0.2928932188], [0.7071067812, 0.2928932188], [0.7071067812, 0.2928932188]]

> s := sides(ABC):
> r := 2*area(ABC) / (s[1] + s[2] + s[3]):
> incircle(c1, ABC):
> circle(c2, [iAB, r]):
> simplify(coordinates(center(c1))), simplify(coordinates(center(c2)));

                             1/2                   1/2
                        1 + 2        1        1 + 2        1
                       [--------, --------], [--------, --------]
                             1/2       1/2         1/2       1/2
                        2 + 2     2 + 2       2 + 2     2 + 2

> simplify(radius(c1)), simplify(radius(c2));

                                      1         1
                                   --------, --------
                                        1/2       1/2
                                   2 + 2     2 + 2

There is much more available in the geometry package, but I have only shown a small sample to give one an idea. It took more time than preferable to actually figure out the syntax and how to work with the available functionality. Maple is generally fairly closed so I could not find any information on the actual implementation of these routines. All the same, the following list describes the available means of creating an object:

Point

Two numerical values

Line

Two points
Equation

Circle

Three points
Two points, assumed to form a diameter of the circle
The center, and the radius
The equation

Polygon (Regular)

The number of sides, center of the polygon, and the radius of the circumscribed circle

Triangle

Three points
Three lines
Three line segments
Two sides and their contained angle

Square

Two opposite corners
Two adjacent corners (returns a list of two squares)
A vertex and the center of the square

All entities appear to store many of the straight-forward attributes along with the equation (or coefficients for an equation). A very quick analysis of source can be found here

The following information comes from http://people.scs.fsu.edu/~burkardt/cpp_src/geometry/geometry.html. Note that there is no actual structures present in the code.

Point: Represented by double[2]
Lines: Represented using two points on the line
Circle: double for the radius and a point for the center
Triangle: Simply three points
Polygon: An integer N and double[] of size 2*N for the points

As one can see the representation is very simple, mostly due to the fact that it is coded in a C fashion.

Java Topology Services (JTS)

I looked through the source at http://www.jump-project.org/project.php?PID=JTS&SID=OVER. The software seems to be very GIS oriented, and hence it does not really apply to the more analytic approach that my project wants to take. I've bookmarked the site and put it in this document because it may be of some use in the future but for now I am going to put it to the side.

GMath

Sourceforge site found at http://sourceforge.net/projects/tmath/. It is not taking an analytic approach, and hence I can't take too much from this. The following does list the things that describe the entities:

Lines can use two points or a point and a directional vector
Circles have a center and a radius
Triangles have three points
Rectangles have upper-left and lower-right corner coordinates.

Resulting Decisions

Point

Simply a sequence of Number and/or Symbol instances

Line

Just two points would be stored at the instance level. If the equation is required for anything, it will be retrievable from a class method.
Slope-intercept form (y = mx + b) is not used because it cannot represent vertical lines (b = 0, for a(x - x0) + b(y - y0) = 0)

Rays and Segments

Both of these can extend Line itself (for maximum code reuse)
Rays would also be constructed with a point and a directional vector.
For segments, two points have to be given to construct the line, then assume these are the two endpoints.

Polygon

A list of points seems best to represent a general polygon. Special cases (eg, regular polygons) could be represented in other ways, but at the moment it is not completely clear if this will be beneficial. I think it would be best to stick with this and play with it to see how things turn out.
The only other option (for a general polygon) would be a list of segments, but these could be constructed on the fly if needed. If performance was an issue then these could also be stored along with the points.
Like Maple, a regular polygon could also be constructed from information regarding the circumscribing circle. As for representing a regular polygon this way, it would be a bad idea because the circumscribed circle doesn't give us much information regarding the polygon itself. Plus, a polygon generates a circumscribed circle rather than the other way around.

Circle

Store a (radius, center) pair for each instance. If the equation is required for anything, it will be retrievable from a class method.
The equation allows one to easily inquire information pertaining line intersection, point incidence/containment, and so forth. The (radius, center) pair allows for easy area and circumference information, along with allowing lines to be formed easily between the center of the circle and an arbitrary point.
We could pull the (radius, center) information from the equation itself, but memory is cheap these days so it will be much easier (and neater code-wise) to have this information readily available within the class. It will make the code much more intuitive compared to pulling radius/center information out of a stored equation.

All entities can be either numerical or symbolic, and all informational tasks will handle things in a general manner so it doesn't matter what one chooses.

All entities will have the ability to be constructed many different ways, mostly based on common representations. It will not be the concern of a user to understand the internals but rather just how they can construct it. If a user is familiar with a certain representation then, most likely, they can construct an entitity using that information

To start, there will be as much code reuse as possible. This may not result in the most optimal code, but the code should be "modular" enough so that introducing different calculation methods will be near effortless.

All entities will be immutable since if new objects are required, they can simply be constructed. Also, any transformation to a geometrical entity would return a new instance. This remains consistent with the current SymPy design, so it makes the most sense.

For now, the standard basis will be used for the Euclidean space [x = (1,0), y = (0,1)]. Later plans may involve allowing a different basis to be used for each entity, or at least at the global level.