Calling all Math Wiz's - vlax-curve-getfirstderiv

That goes double in a non-object-oriented language where

I think you're missing the boat. It's true that non-OO languages are less
interested in dealing generically with classes of objects and their
derivatives, but that is not the main issue here. As a programmer of custom
objects, I want to be able to freely take advantage of the flexibility that
Autodesk's paramaterization API provides without worrying about other
programmers who have made assumptions about how I will relate my parameters
to points on the curve. I would assume that Autodesk wants the same
flexibility, otherwise they wouldn't have exposed a parameterized curve
model in the first place.

As the sample I attached to another message demonstrates, this problem
transcends the issues with lisp/VBA and derived classes. I think
limitations are bad, and relying on empirically determined parameter
relationships limits both the code that makes the assumptions (by making it
susceptible to failure) *and* developers who wish to add new capabilities to
e.g. polyline objects (because they have to worry about third party code
failing).

In any case, programmers can each decide whether they want to trade
stability for "practicality". My goal here is to ensure that they
understand the potential ramifications of the decision before they make it.

 

Doug:

I should add that although the sample I posted is contrived and simple,
I've actually designed and developed complex polyline objects in the past
that don't follow the "traditional" parameterization rules. I point that
out to counter the argument that one would never encounter the demonstrated
situation in the "real" world.

 

I disagree. That is the issue.

Also, I think you're missing the boat on one very simple
fact concerning OOP and LISP:

LISP applications have no concept or understanding of
polymorphism or inheritence. Not only is a LISP
application unable to determine an entity's ancestry,
the fact is that a LISP application has no legitmate
business even attempting to manipulate a custom entity
as if it were a concrete instance of one of its base
classes, in the absense of an explicit contract between
the implementor and the client.

And even if I were to agree to the use of polymorphism
in LISP, what is to suggest that an implementor of a
custom object cannot make the parameter contractual?

I see no legitimate reason why one cannot make emperical
assumptions about the parameter of native entities derived
from AcDbCurve. My opinion here is grounded in practicle
reality.

 

Tony:

Did you look at my sample? There is no polymorphism or inheritance
involved (at least not as far as Lisp is concerned).

 

Owen:

I get it. You *have* been polishing your crystal ball.

Dunno if this is right strand of the thread in which to respond, but the
examples I've read are dealing with LWPolylines, and you are cautioning about
curve types that as yet may not have been publicized. Not sure about others,
but a lot of my work is in between.

If we follow your suggestion not to derive empirical relationships about
parameters, then one might be stimied dealing with complex polylines, eg. an
AcDb3dPolyline that has been spline-fitted (Type 2)...
(vlax-get Object 'Coordinates) will return only the control points (say it's 6).
(vlax-curve-getendparam Object) will return the highest parameter (say 24.0)
But (vlax-get-property Object 'Coordinate 13.0) returns "; error: Automation
Error. Invalid index" because it's higher than number of control points.

So one has to rely on the evidence that each whole parameter represents a real
vertex (such as one would find via an endpoint snap), if one wants to find say
the segment selected via (entsel). Now in the old days (as yet still present)
one could use (nentselp) and retrieve the vertex entity and its information via
(entget) and (entnext) etc., and even modify any vertex using (entmod). Not so
with ActiveX, and maybe that's part of what you are preaching... that 4th party
hackers shouldn't be modifying extra vertices. Yet we might want to alter the
elevation (Z) in our own way while maintaining the stock 2D geometry.

Another example is changing the bulge of a 2D curve-fitted polyline segment.
Once again, we can't rely on the 'Coordinate property to find an extra vertex,
but must rely on the "evident" parameters. Again, maybe we're not supposed to
change a 2D polyline's bulge, even though we have been able to by
(entget)-(entmod) means and/or trusting the "evident" ActiveX parameters.

Now if they fixed the 'Coordinate property indexing to include the full range of
parameters returned by GetEndParam, then this argument is moot. So maybe I'm
ranting over ActiveX limitations that one doesn't experience with ARX.

Confusedly yours, John

 

Owen,
Thanks. An interesting demonstration which proves your
point.

Now I'm even more curious. What advantage would a third
party have in changing the parameters of a polyline in that manner.
What does or could the polyline do better? It doesn't appear
to affect anything observably.

Apparently the parametrization changes are eliminated if
pedit is used to fit curve and then decurve the object.

Thanks again.

Regards,
Doug

 

John:

Given the limitations of the ActiveX interface that you described (and it
is just the ActiveX interface -- no such limitations exist in ObjectARX) I
would use the (entget)/(entmod) approach where necessary.

I realized from reading your reply that my previous reply made it sound
like I was dissing (entget)/(entmod). I didn't mean to imply that those
should no longer be used. I meant that just because parameters are opaque
doesn't mean they aren't useful or should be avoided.

 

Doug:

That's exactly right: it *shouldn't* affect anything observably. The
parameters should only be meaningful to the code behind the object, and they
should only be incidental when used by client code. The relationship of the
parameters to the graphic representation of the object should in theory be
selected by the implementor so as to make the implementation efficient
internally, either mathematically or programmatically, whichever is most
important to the design goal.

For example, imagine an application where polylines are used to represent
the path that the tip of the cutting tool on a multi-axis milling machine
will cut along to machine a part. In that application, it might be more
efficient for the parameters to be related to a point on the milling machine
head somewhere other than the tip of the cutting tool. Furthermore, while
the visual representation of the path would be delineated by vertices, the
real path might not be. Imagine that the application needs to generate a
tool path from the polylines, but the tool path is defined by the location
of the base of the cutting tool rather than the tip (which is related to the
base in calculatable but unorthodox ways that depend on the exact
orientation of the cutting tool as it travels along the path). The math for
generating tool paths would be much simpler internally if the polyline's
parameters were related to the base of the tool rather than the tip that is
represented by the displayed polyline.

My point is that we should leave that decision to the implementor, and not
tie her down with needless assumptions. We can't possibly imagine all the
cases where using a different parameterization relationship could be
beneficial to the specific application, but surely we can recognize that if
the potential exists then someone somewhere will utilize it.

 

Did you look at my previous reply? Specifically:

We're comparing apples and oranges. I'm referring to the
emperical meaning of built-in entities, not custom entities.

I maintain that for all practicle purposes, there is
absolutely nothing wrong with making assumptions about
the parameter of an AcDbPolyline. We will all be dead
and buried or barbequed before its meaning changes.

 

Nice explanation Owen. Thank you very much
That makes sense.

Of course, now I'm curious about what the parameters
would actually look like for such an application. Since
the parameter can only be a single number(right?) and since,
as far as I can imagine, it is related to the distance along
the curve, would the tool be ahead or behind the tool path?

What are your capabilities for adjusting the parameters?
Is it only a scaling factor? Can the parameterization be offset
so that a curve starts at parameter 1 rather than 0? Can you
impose a mathematical function? Can parameters be placed
on the curve at specific distances along the path? Can they
have different spacings for each type of segment(arc or
straight)? Can they represent points off the curve? If so how
with only one number?....

If you don't have time to get into it, perhaps give a link to
where parameterization rules and applications are discussed.

Thanks again!

Regards,
Doug

 

Doug:

The concept of parameterized curves has been explained in the past better
than I can explain it. I did a quick google search and found this:
http://groups.google.com/groups?hl=...?q=parameterized+curve+Autocad&ie=UTF-8&hl=en.
If we're lucky, one of the math wizzes (Jon Fleming, where are you?) will
jump in and explain.

Parameters *are* mathematical functions, and they can be *anything* so
long they maintain a one-to-one relationship between parameters and points
on the curve. In the example I posted before they do indeed represent
points off the curve. Look at the spline or ellipse objects in AutoCAD if
you want to see parameterization functions that are not linear like those of
lines and arcs.

 

Tony:

I agree, it's a long shot that Autodesk will ever change it.

 

Luis,

I think one of Owen's points is that maybe *you* *won't* ever do/make
something like that.

But one day you might get a drawing from a client that has objects like that
in it.

For whatever reason, you start copying the object here and there (CAD
entities propagate faster than rabbits, you know). Then, all of a sudden,
your routines that used to work (based on empirical/evident relationships
suddenly start having problems - and you will be hardpressed to know/figure
out why.

Think about the difficulties people have had with the educational plot
stamp.

As I see it, Owen just wants us to make an informed decision with respects
to these things, and be aware of the possible consequences, slim though they
may be at present.

Best regards,
David Kozina

 

As I see it, Owen just wants us to make an informed decision with

Well said David, thanks.

 

Okay. Thanks, Owen.