severoon's Journal: Unnecessary Complications in Fundamental Abstractions

Imagine a bicycle. How many dimensions does it have? Surely, it's a 3D object, right? Ok, ok, 4D if you count time. That means it's comprised of particles that each have three degrees of freedom (orthogonal possible motions), x, y, and z.

But wait. Is that really true? A particle in Euclidean three-space only has three degrees of freedom? What if it's not symmetric about its center point (a bicycle-shaped fundamental particle, for instance)? This kind of particle has FIVE degrees of freedom, I'm counting. It has x, y, and z, but it also has two rotations, without which its exact position in 3D space cannot be specified. (Or am I wrong, is it three rotations? I played with a cube for a few seconds and convinced myself that only two are required to achieve any orientation--did I get this right?)

To be a bit more formal about it, let's construct the 3D bicycle-particle space, in which each and every point, the ordered set of numbers (x, y, z, theta, phi) represents the position of a bicycle-particle. The first three numbers in this ordered sequence specify the point in three-space that is equally far from every point making up the particle on the average. The second two represent the rotation about this point of the particle in the x-y plane, and then the x-z.

That's if we're talking about a fundamental particle that doesn't have any spatial symmetries (you're thinking if you split a bike down the middle, it's left side and right side are symmetrical--you're wrong though--the pedals are not, and the chain and gearwheels are necessarily only on one side, so a bike has no spatial symmetries).

This leads me to wonder...how do we know that, for example, quarks aren't like this? Why do we think of them as spheres, which are symmetrical in every direction, and then assign them all these weird properties like charm or strangeness or color? What if they're just like bikes, and these weird properties are nothing more than a degree of freedom in theta and phi (remember, quantum particles can't choose from a continuous spectrum in their degrees of freedom, they can only choose discrete states). What if color and strangeness and all of that is simply the discrete states of rotation in phi and theta? Why make this more abstract and complicated than it needs to be if one model is as good as the next?

I figure I must be wrong. I figure that someone, somewhere must have already thought of this and will have a good enough understanding to explain it to a layperson such as myself. I'm somewhat less confident they'll run across my journal entry here and actually do so.

Back to the bicycle (the big one, not a bicycle-shaped particle). If we assume it's made up of spherical particles that are exactly the same regardless of how they're oriented, then a macroscopic bicycle is indeed a 3D object (forget time already...jeez!). Every particle has three degrees of freedom, therefore the bike's position can be fully specified by a long set of three coordinates, one set for each atom, or electron, or quark, or whatever, in the bike.

Hang on a second, though...we know we're talking about a bicycle here. Let me ask: if we know it's a bike, then we know these sets of points we've listed must be confined to some kind of structure. Using the above technique, we can fully specify the position of ANYTHING in three-space. Which is great, if we're dealing with everything...but we're talking about bikes here, and we don't want sets of points that represent other things...only bikes are allowed in our space.

If that's true, then we know that we don't have to specify each and every point in the frame. We can specify one point relative to the bike (including rotations) instead of each and every particle making up the bike. That's a heck of a lot less writing...but it's inadequate. The previous way, with the long list of points, we could specify a bicycle in any position. Now we have some assumptions built in, over and above the fact that it's a bike. We have to assume that all bikes have their handlebars oriented relative to the frame in the same way. We can't have a bike with the handlebars turning to the left represented in our space. Similarly, we have to assume the pedals are in a particular position relative to the frame, the wheels too. Anything else that moves on a bike in some way independent of the frame.

Or...we could simply add more numbers to our ordered set. We specify the point that is on average equidistant from each particle making up the bike using x, y, z, theta, and phi. Then we specify the angle of the handlebars using psi1, the front wheel psi2, and the rear psi3. Similarly, any other variables we wish to introduce can be added to the ordered set so that any bike can be fully represented in our space such that no part of its position is left unspecified. Still a heck of a lot less writing than moles of ordered triples!

The number of elements making up this ordered tuple could be considered the dimensionality of the bike. We could record the position of the bike completely by recording each of these as independent variables against time, and there would be no information missing over the entire duration of the ride about the position of the bike, while we've freely allowed the rider to make do anything during the ride a bike can do. The bike is a so-called "free particle" in this space. It is only constrained by the fact that it is a bike, that the handlebars and fork interact with the frame in an assumed way, that the wheels interact with the fork and frame in an assumed way--these aspects are fixed because the sets of particles making up a wheel always relate to the rest of the structure in a way that makes the bike a bike. These constraints give the bike its structure, its "bikeness".

But in order to do away with tracking each particle of the bike independently, we've launched ourselves into a multi-dimensional space. Now the rotation of the handlebars, the front wheel, and the rear wheel are all orthogonal directions in addition to the position and orientation of the frame (5 more dimensions, the original x, y, z, theta, and phi). In exchange, we've fully specified, by defining this space, what it means to be a "bicycle"...which conglomerations of particles qualify as bikes and which do not. And more importantly, we've done so without using redundancy--each number in that ordered tuple is absolutely required so that no aspect of bikeness is left unspecified for any "point" (or bike) in the space.

I recently had the idea that coding is sort of like building spaces. Just as I describe the space containing all possible bicycles above, coding the interface of an object specifies an n-dimensional space. Actually, I think it might even define two spaces--the n-dimensional space of problems and the p-dimensional space of solutions...and more yet: a mapping between them.

Take a simple function in Java: double add(double x, double y) { return x + y; }. This method takes x and y, adds them together, and returns the result. The parameters form the problem space--x and y are free to vary independently, and form an ordered pair in that 2D space. The solution space is 1D, the value that is returned. add() is a simple case, it might be a class with several methods specified that creates a very complicated problem space. One thing that's neat about object-oriented programming is that it allows the programmer to let the class itself define an object which represents the point in the solution space, rather than having to return the result immediately like add() does, an object can accumulate state over many the many dimensions of that particular solution space.

This is just a fledgling idea in my mind, so I won't continue here at length, but suffice it to say that I already see problems. For example, in the add() function above...x and y do not quite describe the problem domain accurately if you assume they represent a 2D free particle...they don't; they represent a constrained particle. Imagine if x were the maximum value allowed in a double, and so was y. There is no mapping into the solution space becaues the returned double would overflow. In fact, if one of these variables is at a maximum allowed by double, then any positive, non-zero value in the other is not allowed, so the constraint is quite significant. We could reformulate the method so that x and y are floats, and therefore the solution space provides a mapping for every possible point in the problem domain, but this shrinks the size of the problem domain our function can address considerably beyond what need be. In many cases, it'd be better just to acknowledge that the 2D point in the problem domain must be constrained.

I feel that this idea is somehow valuable and can be developed into a sensible means of specifying APIs that are complete and consistent, yet provides a mapping over the maximum region of the problem space. Imagine representing a bicycle in code, for example. Interfaces might specify a frame and a handlebar-fork assembly, and a Bike object could mandate how these different interfaces interoperate to form a bicycle. This way of thinking could allow me to formulate interfaces much more concisely than I currently do, leaving much more extensibility.

One quick example...most mountain bikes nowadays have suspended front ends, meaning a shock system built into the fork. Clearly, this adds one more degree of freedom to a bicycle...you can't fully specify a bike's position if it has one of these forks without a number representing the compression of that front shock assembly. So, should the interface representing the fork specify this?

No. If that interface is used by the Bicycle object to coordinate how it plays with the frame, then it's totally irrelevant whether it is a suspension fork or not. The Bicycle object that mandates how these components work and play together couldn't care less--when the handlebar-fork assembly turns relative to the frame, nothing different happens from the Bicycle class' standpoint whether it's a suspended fork or not. Then again, maybe I need to do a bit more thinking on this, because the bike as a whole will respond differently over rough terrain (otherwise, what's the point of the suspended front end anyway?).

Hmmmm...