There is a celebrated book called "Powers of Ten" that offers up snapshots of what the universe looks like as you decrease or increase your magnification by successive powers of ten.

The cognitive scientist, Allan Newell, applied the "Powers of Ten" concept to the time dimension and observed that human action can be explained by biological, cognitive, rational and social constructs that generally operate at different time scales (Pirolli, p 19).

A Math_Geometry package can be organized in many different ways. Once common way to organize such a library would be along 2D versus 3D lines (i.e., Math_Geometry_2D, Math_Geometry_3D). Another way to organize such a library would be in terms of the format in which geometric objects are represented. A line, for example, can be represented in parametric, implicit, or explicit formats which entails a different list of constuctor arguments/types and algorithms for computing common line properties (e.g., getDistanceToPoint(), getFoot(), isCollinear(), etc...). A format-based Geometry package might have classes/packages called Math_Line_Parametric, Math_Line_Explicit, and Math_Line_Implicit. The main argument for a format-based Geometry package is that some line properties are easier to compute when represented in certain ways. A collection of format-based classes would invoke each others methods to compute a line property using the most straightforward method.

These are preliminary observations about the possible requirements for a php-based Math_Geometry package. The purpose of the discussion is to suggest that the 2D versus 3D aspect of geometry is not necessarily the primary dimension to use in organizing a Math_Geometry package. We should also consider representational issues and remember that different formats are better adapted to solving different types of problems and perhaps a format-based organizational structure should be the primary organizational dimension for a Math_Geometry package. An ideal Math_Geometry package might also be a compromise between these organizational principles (e.g., vector-based arguments to parametric line methods would compute 2D verus 3D properties depending on the length of the supplied arrays).

If you follow the @see link in the code above you will encounter java methods for computing other attributes of a polygon (e.g., the centroid, the perimeter).

Exercises

1. Create a Math_Polygon class that allows you to easily compute several attributes of a polygon given its x and y coordinates.

2. Would the computePolygonArea() function be useful for computing the integral of some function (i.e., the area under the curve)? How might it be applied and how accurate would it be relative to other methods for approximating the integral?

3. A group of polygons which are connected together by shared vertices is referred to as a mesh. Would you be able to compute the volume of a solid from its mesh representation (i.e., computeMeshVolume)?

Spatial software often works in a unit square coordinate system that maps the results to a target box coordinate sytem (i.e., unit2box) where they are viewed. Conversely, we may click on an object within a target box and convert the click coordinates to the underlying unit square coordinates (i.e., box2unit) to figure out which object was clicked.

The unit2box and box2unit functions below compute these mappings and work for a 2D or 3D coordinate system.

I created a class to house some methods for working with polar coordinates. The class is called Transform_Polar because I have run into the need for a collection of transform methods before (i.e, Transform_Regression) and the collection of these transforms might eventually become a useful Math_Transform package.

To interpret the output of these methods you need to think in radians as the output of the php atan function, for example, is in radians which means $theta is in radians.

2. Develop a spherical2cartesian.php script and include it in the
convert.php script to provide two-way transformations.

3. Instead of outputing the rho, phi, and theta coordinates as text
values, express them as angles and lines superimposed upon
a 3D sphere. SVG would be tool to consider using for your graphing experiments.