calculate a point between two other points

[Anonymous]

Hello group,

Using LISP, how would one calc a point (p3), between two other points (p1
and p2), a given distance (dist) from p1?
Example:

p1 = (2.0 2.5 0.0)
p2 = (6.5 2.2 1.0)
dist = 1.5
p3 = ?

I'm sure there is a simple formula, however, I failed 3rd grade math five
times.
--
Eric S. eschneider@jensenprecast.com

[Anonymous]

Absolute genius! The brilliant minds on this NG never cease to amaze me.
Jadranko for coming up with an engenius quick sub, and Tony for being able
to envision and explain to a layman like me, the incredibly complex concepts
both now and in other threads.

My thanks goes out to all the great minds who share their talents here.
--
Eric S. eschneider@jensenprecast.com

[Anonymous]

Tony,

I completely agree with your previous post.
If we could calculate the total time spent on discussion about efficiency in
this thread it would be surely huge compared to the performance difference
between discussed functions. We should process vast number of
points-on-lines in order to pay off such a bad investment of time.
On the other hand, faster function is not the only gain of this discussion.
I learned about undocumented sysvar "millisecs" (which I was completely
unaware of) from two sides: You and R. Robert Bell.

Anyway, risking the possibility to be called meticulous, I have to comment
part of your previous post.

You developed optimized version of point-on-line function and compared its
results with previous functions:

>
>My results are as follows:
>
>Command: TEST
>Points-on-line-1 (Tony): 2.3530
>Points-on-line-2 (Jadranko): 1.3420
>Points-on-line-3 (optimized): 0.4110
>

Furthermore you explained the performance difference by avoiding function
call overhead:

>Both examples are inefficient ways to go about using
>the code in (point-on-line) iteratively, because of
>the overhead of having to make a seperate function
>call (to point-on-line) for each iteration.
>
>Reason: Making calls to a user-defined function has
>a fixed amount of overhead associated with it, and
>in this case, it can be completely avoided by not
>making numerous calls to a version of (point-on-line)
>that's designed to handle only one point on one line.
>
>Instead, you should encapsulate the iteration into
>another version of (point-on-line) that takes either
>many lines, or many distances, and does not have to
>call another user-defined function once for each item
>it processes, in order to get the job done.

In my opinion, this statement could be misleading. The reason of such a big
performance difference between optimized and non-optimized versions is not
the pure function call overhead. Optimized version calculates multiple
points on the same line, which allows the function to calculate all the line
depending constants once for all the iterations, instead of calculating them
again and again in each call of nonoptimized function. Efficiency increase
caused by avoiding pure function call overhead is very very small compared
to increase caused by avoiding recalculation of the same constants again and
again.
In other words optimized function took advantage of special case of multiple
points on a single line. Similar optimization cannot be done in a more
general (and not less probable) case when you need to calculate many points
on different distances on different lines (one point on each line). I tried
to find similar optimized solution for the other special case you mentioned
(equal distance on multiple lines), without success.
When I tried to optimize my function by mere avoiding the pure function call
overhead I increased performance between 1.2% for VLX and 6.2% for
interpreted LSP. The figures for your function are probably even smaller as
it takes more time for processing while the overhead time is, as you said,
fixed.
If you compare this result to the performance difference between your and my
nonoptimized function (50% according to my measurements, and even 75%
according to yours on a rather small number of iterations) it doesn't look
so splendid as in your special case scenario, even if we forget less
readable code and other tradeoffs.

I have to agree once more with you, that it's questionable weather
performance gains we are talking about are worthy the time we wasted in this
discussion.
However I still think that it pays off to think once more over finished
function to see if a slight change in code could gain 50% in performance or
to think once again before you spend 50% more development time for a slight
performance gain.

Thanks again for your effort in this newsgroup, and specially for
"millisecs" sysvar from this thread.

Jadranko

[Anonymous]

Jadranko Stjepanovic wrote:
>
> Tony,
>
> I completely agree with your previous post.
> If we could calculate the total time spent on discussion about efficiency in
> this thread it would be surely huge compared to the performance difference
> between discussed functions. We should process vast number of
> points-on-lines in order to pay off such a bad investment of time.
> On the other hand, faster function is not the only gain of this discussion.
> I learned about undocumented sysvar "millisecs" (which I was completely
> unaware of) from two sides: You and R. Robert Bell.
>
> Anyway, risking the possibility to be called meticulous, I have to comment
> part of your previous post.
>
> You developed optimized version of point-on-line function and compared its
> results with previous functions:
>
> >
> >My results are as follows:
> >
> >Command: TEST
> >Points-on-line-1 (Tony): 2.3530
> >Points-on-line-2 (Jadranko): 1.3420
> >Points-on-line-3 (optimized): 0.4110
> >
>
> Furthermore you explained the performance difference by avoiding function
> call overhead:
>
> In my opinion, this statement could be misleading.
> The reason of such a big
> performance difference between optimized and non-optimized versions is not
> the pure function call overhead. Optimized version calculates multiple
> points on the same line, which allows the function to calculate all the line
> depending constants once for all the iterations, instead of calculating them
> again and again in each call of nonoptimized function. Efficiency increase
> caused by avoiding pure function call overhead is very very small compared
> to increase caused by avoiding recalculation of the same constants again and
> again.

You are right. The function call overhead is not entirely
responsible for the difference, as my original response
to your post with the improved version of (points-on-line)
clearly says:

> ......in a scenario where you
> would be calling the code many times, to find multiple
> points on the same line, the code should be optimized
> to eliminate all redundant expressions whose results
> are constant for the line (e.g., the distance between
> the endpoints and the delta).

> In other words optimized function took advantage of
> special case of multiple points on a single line.

This is not a 'special case', it is overwhelmingly the
most common case involving any iterative application
of this code.

> Similar optimization cannot be done in a more general
> (and not less probable)

I'm sorry, I don't agree with your characterization
of the 'multiple points on multiple lines at the same
or different distance' case as being more general and
'not less probable'. That is simply not the case. I've
used the optimized code I posted numerous times, to
find multiple points on the same line. On the other
hand, I've *never* had a scenario where I needed to
use the 'not less probable' case you cite.

In any case, even the highly-uncommon special case you
cite (many lines) can be optimzed further as well. For
example, if they are LINE entities, you can just use
(vlax-curve-getPointAtDist).

And, while we're discussing effeciency, I should also
note that using C++ would make the whole issue of
trying to optimize LISP code for this task, somewhat
moot. If optimization is *that* important, then you
should consider using C++ for the critical parts of
an application.

The basic point I was trying to make, was that there
was little benefit to optimizing the (point-on-line)
function I orignally posted, given the nature of its
parameters (which makes it completely inappropriate
for iterative use). And that optimization of any code,
has a lot to do with the context in which the code is
used, rather than a more general context typical of
a library function.

However, none of that was intended to belittle your
suggested improvement to the code.

Your point is well taken.

--

Checkout the AcadX(tm) ActiveX Extension Library at:

http://www.caddzone.com/acadx/acadx.htm

/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://www.caddzone.com */
/*********************************************************/