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."

**Combination/Permutation questions**

**Re: Print[] without linefeed?**

**Re: Not quite a Swell FLOOP?**

**Re: Not quite a Swell FLOOP?**