On Tuesday 29 October 2002 12:07 am, Andrzej Kozlowski wrote:
> 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
I once read a scientific paper describing a Hindu ascetic who had himself
sealed in an air-tight 'coffin' for several hours with a candle burning next
to him. He survived, and IIRC, the candle was still burning. *Need* is a
relative statement. ;-)
> 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.
Multi-linear mappings of what? I mistated the definition a bit. I should
have said that a tensor is a geometric object independent of any particular
coordinate system. The fact that it's invariant under coordinate
transformations, is a result of this refined definition. Nonetheless, the
concept of a tensor completely void of all coordinate systems is, to me, the
sound of one hand clapping.
> That
> makes it extremely easy to define and manipulate tensors in
> Mathematica. No need here to think of objects.
I believe this depends on what you are doing with the tensor. To soe extent,
I might agree with you. I believe a philosophical analysis would demonstrate
that the non-objective concept of a tensor is just a case of form defining
contour. I'm interested in the geometric nature of tensors, and more
specifically, in the geometric nature of the objects which tensors describe.
> 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.
This is a bit beyond my current understanding, but it sounds to me that you
are focusing on the algegraic nature of tensors. That's certainly an
interesting area, and for your purposes, objects may not be beneficial.
> 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.
Then of course, we have the possible view that functions are objects, which
seems to contradict the view that these are conflicting approaches.
> (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.
I read about this stuff many, many, many years ago. FLOOP means Functional
List Object Oriented Programming. See _Goedel, Escher, Bach_, by Hofstadter,
1979. I wasn't a programmer then, and my understanding of the topic bordered
on the mythical, at the time. I would really need to review the subject
before I could confidently address this.
> 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.
A place I believe OOP would naturally benefit Mathematica is in the area of
XML and particularly implementing the DOM IDL. There seem to be some
problems with Mathematica's XML implementation. I suspect a good OOP
approach might help in preventing some of these problems in the future. As
regards implementing the Document Object Model IDL, 'Object' is it's middle
name.
> 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."
--
STH
Hatton's Law:
"There is only One inviolable Law."