Re: Not quite a Swell FLOOP?
- To: mathgroup at smc.vnet.net
- Subject: [mg37440] Re: [mg37430] Not quite a Swell FLOOP?
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Tue, 29 Oct 2002 00:09:46 -0500 (EST)
- References: <F1D47CB8-EA5F-11D6-B09D-00039311C1CC@tuins.ac.jp>
- Sender: owner-wri-mathgroup at wolfram.com
On Monday 28 October 2002 05:28 am, Andrzej Kozlowski wrote:
> Roman Maeder's package is meant for teaching computer science not for
> general use.
I haven't studied his package in *any* detail. It's possible that a lot of
what I /feel/ is missing, can be accomplished with a creative combination of
Dr. Mäder's package, and careful use of contexts. Scoping, in general, is a
subject which I have yet to get a grasp on in Mathematica. I had some rather
strange name collisions while working with objects created from his package.
It may have been the result of kernel clutter.
>Whether Mathematica would benefit from OO functionality
> has been a matter of some very heated debate, which you can find in
> this groups archives.
> Personally I am somewhere in the middle on this. I think it would be
> useful for developing packages for some very highly structured areas of
> mathematics (e.g. Algebraic Geometry). But for most applications in
> mathematics and physics the mixture of pattern based and functional
> programming offered by Mathematica is close to ideal and an additional
> programming paradigm would just get in the way. I don't think we need
> built in support for OOP in Mathematica but I am sure many would
> welcome a good AddOn package.
I have to plead virtually complete ignorance on pattern based programming. I
hope to read up on this topic soon. As far as objects and physics go. The
very statement that 'a tensor is a geometric object which remains invariant
under coordinate trasfromations' screams OOP to me.
I have already found Dr. Mäder's object paradigm useful in creating something
I have wanted for quite some time. My creation is certainly not as elegant
as I would like, but it works. I believe attempting the same thing without
an OO framework would have been far more difficult for me. I'm sure it can
be done, but I find OO helps me organize my thinking in a way that cleanly
separates different parts of a problem space.
The code I wrote simply draws three overlapping circles and a set of (more or
less) evenly distributed point-like objects I called pixels. Each pixel is
formed of four points. Each circle has a different color:
{1,0,0},{0,1,0},{0,0,1}. The circles are positioned relative to the center
of the diagram at equal radial displacements, and angles 2Pi/4, 2Pi/4 +
2Pi/3, 2Pi/4 + 2(2Pi/3) respectively.
The points forming the pixel arranged such that one point is positioned at the
location given for the entire pixel. The remaining points are displaced a
small distance from the pixel location, at angles congruent to those used to
position the circles. The point is given the color of the circle sharing its
displacement direction, but only if the pixel location falls within the
circle, else it is set to {0,0,0}. The center point of the pixel is given
the color representing the sum of the color vectors if its activated pixels.
In addition to all of the above, I created a filter mechanism which takes a
three variable boolean predicate as an argument. The predicate is used to
determine which pixels are actually added to the diagram.
The result of all this is a Ven diagram tool which takes an arbitrary logical
expression of three variables and produces the graphical representation of
the expression. It may be usefull to add a fourth variable for the 'world'.
Most of the code lives in a class I called a 'pointObj'. All other objects in
the diagram are subclasses of pointObj. All of the mechanisms for
determining whether a point is in a circle, moving the object, adding a point
to a pixel, creating the graphics primative, etc., are members of the
corresponding object. I have a mechanism to use either radial coordinates,
or cartesian coordinates to position the object, or to query the object for
its position. Of course I only need to maintain one pair of instance
variables to represent all four parameters since these are functionally
interdependant.
The generalization of this system to three dimensions shold be trival. I
already have a mechanism for determining the distance between two points. I
can easily add an instance variable for mass, charge, velocity, etc to the
pointObj class. Likewise, I can add member functions to determine the
'forces' contributed by all other objects in the diagram. It sholdn't be
too hard to turn this whole diagram into a topologically closed surface using
a wrap around where each edge is made functionally adjacent to its opposite.
Of course, I will have to limit recursive influences at some point. As a
first take, I could simply neglect all forces arrising from objects at a
distance greater than the radius of the mathematical object bounded by this
surface I have defined. That is, no object would produce a force felt by
itself at a distance.
In addition to all of the above, I could treat these objects as having a
finite volume, and thus having rotational parameters in addition to their
positional parameters. And the next obvious additon to the instance
variables after Euler angles, is ther derivative. Using a generalization of
the afore mentioned pixel structure and assigning mass to each pixel
component, I could introduce concepts such as moment of inertia and angular
momentum.
The real fun begins when we realize that we have all the components of the
momentum space as well as the configuration space. We could certainly
produce a corresponding diagram representing that space.
I have the sense this would produce a better animation in something like Java
3D, but the design phases is probably going to be easier in Mathematica. The
advantages that Java has are more complete OO support, and multi threading.
Now the one thing I haven't mentioned is the problem that there is no such
thing as immediate action at a distance. Oh, and there is that other
question of the metric nature of the space represented by the diagram, and
how the objects within the space affect that geometry. Introducing special
relativity into this model should be fairly easy. We simply assume the
computer screen to be absolute rest, and use Lorenz transformations in their
original sense.
The real problem is running the animation in a finite period. So after we get
objects, what we need is parallel computing to distribute the load.
Hmmmm.
Some day I'm going to have to actually finish a course in physics. At least
one. Physics 101?
> Andrzej Kozlowski
> Yokohama, Japan
> http://www.mimuw.edu.pl/~akoz/
> http://platon.c.u-tokyo.ac.jp/andrzej/
>
> On Monday, October 28, 2002, at 05:40 PM, Steven T. Hatton wrote:
> > I must admit, Mathematica looks a lot different to me after having
> > done some
> > real programming in Java, than it did a few years ago. I understand
> > it much
> > better, but I also find myself grasping for things that don't seem to
> > be
> > native to the product/language.
> >
> > There seems to be virtually no native support for OOP in Mathematica.
> > Am I
> > understanding things correctly? Dr. M�der (I'm being a bit stubborn
> > here -
> > use UTF-8) provides his own object package with his Computer Science
> > with
> > Mathematica. I haven't worked with yet, but by looking it over, it
> > seems a
> > bit kluged (
> > http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=kluge
> > ). I don't mean to upbraid Dr. M�der's attempt to add functionality
> > which
> > probably should be a native part of the Mathematica language. Perhaps
> > I'll
> > get used to the approach he has used, but for now, I must say, it seems
> > awkward. My guess is Dr. M�der did the best that could be expected
> > with the
> > constraints under which he was working.
> >
> > It is inconceivable to me that I am the first person to question the
> > lack of
> > native OO support in Mathematica. There must be a history of
> > discussion on
> > this topic. Is anybody aware of a record of such? Am I not
> > understanding
> > things correctly? Do others believe OO support is lacking in
> > Mathematica,
> > and really 'should' be here?
> > --
> > STH
> > Hatton's Law:
> > "There is only One inviolable Law."
--
STH
Hatton's Law:
"There is only One inviolable Law."