Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2002
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2002

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: Combination/Permutation questions
  • Next by Date: Re: Print[] without linefeed?
  • Previous by thread: Re: Not quite a Swell FLOOP?
  • Next by thread: Re: Not quite a Swell FLOOP?