[Push] Project notes

[William Tozier]

On Jan 22, 2006, at 5:12 AM, Maarten wrote:

> I've just added push-3.1.0 to the download section of sourceforge.  
> This one
> should compile on g++-4.0 out of the box. This version has a  
> completely
> revamped implementation of the push 'names'. Names are no longer  
> part of the
> environment and are garbage collected.
>
> Hope no big bugs have been overlooked,

Thanks both Maarten and Jon for your efforts! I've got what looks  
like a sound compile here now [I was just re-training myself to use  
CVS for Jon's update when Maarten's release came over the transom],  
and have poked around enough to know that both the main run_push and  
example executables work. [A wee Bus Error or Segmentation Fault here  
or there are things that I'll play with in a little while.]

As I've told Lee and Maarten already off-list, my planned project is  
somewhat odd, and definitely very far outside my paltry C++ skills.  
First I'm going to take some days to familiarize myself with push 3.1  
as it exists now, and try to weigh the costs and benefits of forking  
push substantially to create the extensions we need, as opposed to re- 
implementing a modified push language in a slower but more familiar  
wrapper like Mma or Python. It may be that the best course under the  
circumstances of the project timetable and collaboration environment  
here will be to create a dialect of push in a language I know better  
than C++.

I've chosen push (or a flavor) because of the open-endedness of the  
domain I'm working in: mathematical programming and computational  
geometry. The project sketch is to add at least three major types to  
the language, all of which will have a nonstandard stack behavior,  
and leading to some sort of "PushGeometry" variant.

The goals of the project are to use GP to search for linear and  
integer programming, convex hull, domination, distance, and other  
mathematical programming algorithms.

At present I think the minimal set of new types will represent  
points, matrices, and half-spaces.

All of these will be lists, wrapped in special notation. We need to  
be able to represent points, lines, matrices, hyperplanes, and half- 
spaces in arbitrary dimension, To avoid a kludgy duplication of  
stacks, I think I'll be implementing these stacks with a kind of  
"selective transparency": function calls will pull the topmost entry  
off the stack that preserves mathematical validity. So a proposed  
POINT.+, for instance, would pop the topmost POINT from the stack,  
determine its dimensionality, and then yank the next POINT down that  
has the same dimension. As with the Push language generally, if there  
are not two matching objects, the function will fail.

Type interconversion functions between these types and the basic  
types seem to be pretty straightforward: POINTS can be made from and  
unpacked into REALs; MATRICES and HALF-SPACEs can be built from  
points, and shifted one into the other. Geometric functions like  
distances, directions, whether a point lies in a half-space, &c. will  
simply pop (with selective transparency) the items of the right  
dimension from the respective stacks. Matrix operations, again, will  
depend on the first parameter: MATRIX.* would pop the top entry, and  
then the next one down that makes sense, and push the result. And so  
forth.

But as I indicated, I'm pretty worried about not knowing C++ well  
enough to unit test the code we write. So I'm tempted to move, at  
least for prototyping. Or I'll have to recruit an undergraduate  
colleague or two here at U-M to give me a hand.

I'd like to hear advice, one way or the other.
-----
Bill Tozier
http://williamtozier.com/slurry

"Be anything you want to be, but don't be dull."
   -- Frank Robinson