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

Discussion in 'AutoCAD' started by Darren J. Young, Apr 23, 2004.

  1. Darren J. Young

    Owen Wengerd Guest

    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.
    :)
     
    Owen Wengerd, May 20, 2004
    #41
  2. Darren J. Young

    Owen Wengerd Guest

    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. :)
     
    Owen Wengerd, May 20, 2004
    #42
  3. 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 Tanzillo, May 20, 2004
    #43
  4. Darren J. Young

    Owen Wengerd Guest

    Tony:
    Did you look at my sample? There is no polymorphism or inheritance
    involved (at least not as far as Lisp is concerned). :)
     
    Owen Wengerd, May 20, 2004
    #44
  5. Darren J. Young

    John Uhden Guest

    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
     
    John Uhden, May 20, 2004
    #45
  6. Darren J. Young

    Doug Broad Guest

    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
     
    Doug Broad, May 20, 2004
    #46
  7. Darren J. Young

    Owen Wengerd Guest

    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. :)
     
    Owen Wengerd, May 20, 2004
    #47
  8. Darren J. Young

    Owen Wengerd Guest

    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. :)
     
    Owen Wengerd, May 20, 2004
    #48
  9. 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. :)
     
    Tony Tanzillo, May 20, 2004
    #49
  10. Darren J. Young

    Doug Broad Guest

    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 Broad, May 20, 2004
    #50
  11. Darren J. Young

    Owen Wengerd Guest

    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. :)
     
    Owen Wengerd, May 20, 2004
    #51
  12. Darren J. Young

    Owen Wengerd Guest

    Tony:
    I agree, it's a long shot that Autodesk will ever change it. :)
     
    Owen Wengerd, May 20, 2004
    #52
  13. Darren J. Young

    David Kozina Guest

    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
     
    David Kozina, May 20, 2004
    #53
  14. Darren J. Young

    Owen Wengerd Guest

    As I see it, Owen just wants us to make an informed decision with
    Well said David, thanks. :)
     
    Owen Wengerd, May 20, 2004
    #54
  15. Darren J. Young

    John Uhden Guest

    Okay. Thanks, Owen.
     
    John Uhden, May 21, 2004
    #55
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.