Get the points selected by mouse of the stretch for pathSeg

Leo,

I think I misinterpreted your previous post. I think you want this:

selectedPoints=foreach(mapcan (sel pt) geGetSelSetFigPoint(shapeId) list(shapeId~>beginPt shapeId~>endPt) sel && list(pt))

That will be a list of whichever points were selected (so if only one end is selected, it will be a list of one point)

Andrew

Hi Andrew,

Yes That's what I wanted. Thanks!

Also, below is copied sequentially from CIW window : 

nth(0 a)
(1.8115 1.013)
nth(0 b)
(1.8115 1.013)
nth(0 a)==nth(0 b)
nil

Why the last 1 is getting returned nil, it should be t.

I tried using car also but the last command is giving me nil output, i don't know why could this be happening.

Regards,

Leo

This almost certainly depends on where a  and b came from. You've probably got some small floating point rounding error in a computation somewhere. If the numbers both came out of the database, they should match. If you do:

xy1=car(a)
xy2=car(b)
xCoord(xy1)-xCoord(xy2) ; what does this output?
yCoord(xy1)-yCoord(xy2) ; what does this output?

Performing == checks on floating point numbers is dangerous (see gazillions of issues related to this all over the internet in any programming language that uses IEEE floating point representation, such as C, python, SKILL, etc etc)...

Andrew

Hi Andrew,

a and b both are list of coordinates formed from either bBoxes or beginPt and endPt of many pathSeg.

xCoord(xy1)-xCoord(xy2) gives me 0.0

yCoord(xy1)-yCoord(xy2) gives me 0.0

Leo

So xCoord(xy1)==xCoord(xy2) and yCoord(xy1)==yCoord(xy2) should both be t, and hence I would expect xy1==xy2 to be t as well. Is that what you see?

Andrew

Yes. They are true, but the lists which I am working with, are made up of several floating point numbers(upto 4 decimal places), even though I see their car(a) is same as car(b), but when I compare them with ==, it gives me nil, and because of this my next if loop is not starting.
So how should I compare these floating point numbers.

Leo

If they genuinely all came from beginPt and endPt, then they should be identical, because the database itself is really integer - and gets consistently converted to floating point by dividing by the DBUPerUU value for the database.

In general, floating point numbers should be compared with a tolerance - here's an example (there are many more on this forum)

If they genuinely all came from beginPt and endPt, then they should be identical, because the database itself is really integer - and gets consistently converted to floating point by dividing by the DBUPerUU value for the database.

In general, floating point numbers should be compared with a tolerance - here's an example (there are many more on this forum)

Hi Andrew,

In some place when I am subtracting the two car, the result is 2.220446e-16. So can I use this approximation : (y1-y2)<0.0001 approximation if I have 2000DBUperUU? I think the difference is not felt upto 15th decimal place, then I would go for (y1-y2)<0.00001 (upto 5th decimal place to be safe).

Actually Why this difference is coming I have to understand, one list is of bbox and other list is of beginPt/endPt. Even though they look equal, but still getting a difference of 2.220446e-16 in someplaces not all.

Leo

Leonardo Vinci said:

So can I use this approximation : (y1-y2)<0.0001 approximation if I have 2000DBUperUU?

Yes, that's reasonable. nearlyEqual is another possibility as Lawrence suggested, but you still really need to think about the right tolerances to use then. Note that the difference is not about decimal places, it's about significant digits. So you don't want to go for too small a tolerance because then you might hit the limit at the upper end, but practically you're not going to hit that since the maximum coordinate with 2000DBUPerUU is just over 1 metre. So either 0.0001 or 0.00001 would be fine.

Andrew

Many thanks Andrew Beckett and skillUser this solved my problem. :-)