Re: 3DLDF

[Hans Aberg]

At 00:25 +0200 2004/08/13, Laurence Finston wrote:
>> On chapter 2: I am not sure how you avoid a polymorphic system when
>> developing a Bison parser. Given from what you write there, an obvious way
>> would be to derive all your geometric object classes from a root class
>> object_root, with a polymorphic calls object. The parser semantic value
>> then contains a
>>     object object_;
>> as I described earlier.
...
>I'm not trying to avoid a polymorphic system.  I think a program uses
>polymorphism when it accesses an object of a derived type through a variable
>of a base type and performs actions on it specific to the derived type.

Right.

>  I
>don't believe that polymorphism implies that the specific type of the object
>in question can only be known at run-time.

One can of course use a polymorphic system so that in effect the type of
the objects are statically known. But then one is not using the full
polymorphy. If you allow the typed of the derived object vary at runtime,
then it is not possible at compile time t know what it might be.

>  Therefore I believe that 3DLDF
>1.1.5.1, which is non-interactive, uses polymorphism.  However, I haven't had
>a chance to look up what Stroustrup says about it, so maybe I'm wrong.
>
>The geometric object classes are all derived from `class Shape', which is an
>abstract class.

If all your geometric object classes are derived from a common root class,
then you already have the polymorphy I have in my mind. Then it should be
easy to build a parser on top of that, building such objects directly.
I.e., instead of code like
    Point p(...);
    ...
for each graph, you build a single program with the capacity of building
any such object using constructs like
    Shape* pp = new Point();   // Preferably wrapped up in a object class.
invoked by the parser actions.

>> The Bison grammar then will contain things like:
>>   point:
>>     "(" coordinate "," coordinate "," coordinate ")" {
>>       $$ = new Point($1, $2, $3);
>>     }
>>   ;
>> if the syntax of a point in your program is (x_1, x_2, x_3). It is then
>> easy to add the different operations and types you have to your system.
>
>It's not that simple.  You can check the parser code in the CVS archive at
>Savannah if you want to see the syntax of `point expressions':
>
>http://savannah.gnu.org/cgi-bin/viewcvs/3dldf/3dldf/Group/CWEB/
>
>The parser code is in files with names of the pattern `p*.w', e.g.,
>`parser.w', `pldfdcl.w', etc.  `point_expressions' are in
>`ppntexpr.w'.

I will look more at it. I intended not to illustrate the syntax, but how
one can get the parser to polymorphicly create the needed objects. One
merely makes "closures", code that can be executed later. The finale will
be that one writes the object out.

>> (But I am not sure how your C++ code produces an output.)
>>
>
>Keep reading the manual and all will be revealed---well, almost all.  For the
>full story, you'd have to look at _3DLDF: The Program_.

I am not sure I will be able to work through all that :-), but to me it
looked as though you would only need to hook up the C++ components with a
polymorphic parser. I get the impression that your C++ code is similar in
structure to my underlying C++ program for my theorem prover.

>> >From what I have seen of what your program can do, you might decide to
>> invent your own syntax which the best expresses the things your program can
>> do.
>
>That's what I'm doing, while trying to stay as close to the Metafont language
>as possible.

I am inclined to think that you should skip all attempts to make it similar
to the MetaFont language, and merely make it efficient to describe
geometric shapes as you can see fit. Then you can use that geometric
language as object code of another language that might then be similar to
the MetaFont language if you so wish.

>> For n-D modelling (in n dimensions), I think one can use the higher
>> dimensional equivalent of Bezier (spline curves): maps
>>     f: sigma^n -> R^n
>> where sigma is the n-dimensional simplex, and where the coordinate
>> projection coordinates of f are degree 3 polynomials. These simplicies must
>> then be glued together at the lower dimensional subsimplicies, which then
>> also are parametrized by degree 3 polynomials.
>
>At the moment, I'm only concerned with 3D modelling.  I plan to implement
>NURBS, because the simpler spline curves aren't projectively affine.

Sorry, I do not know what NURBS is. And what do you mean by "projectively
affine"?

>Later, I would like to implement 4-dimensional and n-dimensional modelling so
>that I can make projections of Klein bottles, hypercubes, and other
>n-dimensional objects.  I'd also like to use 3DLDF to animations of a sphere
>inversion and similar things.

Sounds you have a lifetime project. :-)

>> (In section 1.4: You speak about real values, but probably mean floats
>> (floating point values).
>
>In 3DLDF, `real' is a synonym for `float' or `double' defined using `typedef'.

It clearly so that in some computer language paradigms, the word "real" is
used instead of the mathematically correct term "float". C/C++, however, do
it correctly.

  Hans Aberg