Re: Not quite a Swell FLOOP?
- To: mathgroup at smc.vnet.net
- Subject: [mg37441] Re: [mg37430] Not quite a Swell FLOOP?
- From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
- Date: Wed, 30 Oct 2002 00:50:37 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
I have no particular disagreements with anything in your interesting message. However, I do not see anything in it that, in my opinion, actually needs object oriented programming. In particular: > The > very statement that 'a tensor is a geometric object which remains > invariant > under coordinate trasfromations' screams OOP to me. That's really just a matter of choosing how you think about these things. I prefer to think of tensors without any reference to coordinate transformations, they are just multi-linear mappings. That makes it extremely easy to define and manipulate tensors in Mathematica. No need here to think of objects. However, the situation becomes different when you want to consider tensor algebras as objects in a wider class of of objects, like graded algebras, which in turn are a subclass of an even wider class of algebras etc. For considering such kind of hierarchical structures OOP is very useful and that is why programs designed for this purpose, (like Macaulay II) adopt a very much OOP approach. In some sense of course OOP is the opposite of functional programming (particularly when combined with pattern matching). The former emphasizes data and their hierarchies while the latter concentrates on functions and their hierarchies. The two programming style are very different. (As a programmer I much prefer functional programming but as a user of a ready made program I often find OOP preferable). There are of course languages which contain both, such as object oriented versions of Common Lisp. As I wrote earlier I would very much like to see a good OOP package for Mathematica, but I do not think I would like WRI to devote serious effort to develop such a functionality for Mathematica if it were to come at the expense of other things I am hoping to see in future versions. Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ On Tuesday, October 29, 2002, at 12:21 PM, Steven T. Hatton wrote: > 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." > > >