rem function problem

[shrinand_bhedasgaonkar]

(mapcar '(lambda (n) (rem n 0.25)) (getpoint "Select Point - "))

Above code is to check snap & grid points. Why "Y" axis value is showing wrong result? I think problem is in rem function, but not sure. Sample drawing attached. 

Your early help highly appreciated.

[Moshe-A]

@shrinand_bhedasgaonkar  hi,

---

@shrinand_bhedasgaonkar wrote:

(mapcar '(lambda (n) (rem n 0.25)) (getpoint "Select Point - "))

Above code is to check snap & grid points. Why "Y" axis value is showing wrong result? I think problem is in rem function, but not sure. Sample drawing attached. 

Your early help highly appreciated.

---

What the expression above does is to return a list of 3 reals which are the REMinder of a point XYZ.

this has nothing to do with AutoCAD Grid or Snap.

the questions is?

what are you trying to do? 

what is the result you are expecting?

Moshe

[ВeekeeCZ]

Pretty much for the same reason why the FIX returns 228. It's a known limitation of the double-precision format, see THIS.

You need to use a different algorithm that includes a FUZZ.

[komondormrex]

(mapcar '(lambda (n) (rem (atof (rtos n)) 0.25)) (getpoint "Select Point - "))

[Kent1Cooper]

When I pick the lower left corner, the return is (0.0 0.25 0.0).  That [the fact that the returned value shows as the same as the divisor] means that the Y coordinate of that corner is not exactly 229, but something like 228.99999999999937.  The displayed values are rounded down to your precision setting, but the (rem) function doesn't care about that -- it uses the actual value, all the way down to 16 significant figures.

You can force the vertices to fall on snap-increment positions exactly ["quantize" them] with several routines out there, for example >this<.  When I apply any of the commands defined there to your rectangle, and do your code line again, I get (0.0 0.0 0.0).

[komondormrex]

---

@Kent1Cooper wrote:

When I pick the lower left corner, the return is (0.0 0.25 0.0).  That [the fact that the returned value shows as the same as the divisor] means that the Y coordinate of that corner is not exactly 229, but something like 228.99999999999937.  The displayed values are rounded down to your precision setting, but the (rem) function doesn't care about that -- it uses the actual value, all the way down to 16 significant figures.

You can force the vertices to fall on snap-increment positions exactly ["quantize" them] with several routines out there, for example >this<.  When I apply any of the commands defined there to your rectangle, and do your code line again, I get (0.0 0.0 0.0).

---

while typically it is true in most cases, it is not for  this particular one. to ensure you might look at pline's vertices in saved dxf.

[Kent1Cooper]

---

@komondormrex wrote:

while typically it is true in most cases, it is not for  this particular one. to ensure you might look at pline's vertices in saved dxf.

---

When dividing something by 0.25 leaves a remainder [as displayed] of 0.25, and when quantizing eliminates the problem, there's no other possibility than a situation like what I described.

So the next question:  Is that tiny difference simply lost in exporting to DXF format?  If you then open that DXF file in AutoCAD, does their original code still give the same (0.0 0.25 0.0) result?

[CADaSchtroumpf]

For understand try this:

(mapcar '(lambda (n) (rtos (- n (fix n)) 2 16)) (getpoint "Select Point - "))

[komondormrex]

well, the answer to the next question is nope))) but dxf can show these out of order coordinates aamof imho.

[Kent1Cooper]

---

@komondormrex wrote:

... the answer to the next question is nope....

---

That can only mean that the DXF exporting has changed ["fixed", if you like] the value.

[komondormrex]

actually i do not like it both ways. something abnormal is in this, i think(

[CADaSchtroumpf]

If you use _DXFOUT (with FILEDIA = 0) and not choice binarie mode (default ASCII) you can only save with 16 digit max; the precision can be lost.

[komondormrex]

it is exactly what i meant( as for op dwg, the ordinates have differences to whole number with precision up to 16 digits and still dxf ate that, but however it would not to.

[shrinand_bhedasgaonkar]

I dont think values are rounded down. In attached drawing lower right corner has coordinates 412.0, 30.000000000467253 & LISP is showing remainder in scientific format like 4.67253e-10

[Moshe-A]

@shrinand_bhedasgaonkar ,

that's true

4.67253e-10 means 4.67253 power minus 10 (-10) which is a very small value and in this case this is the reminder from the Y value.

(rtos 4.67253e-10 2 16) = "0.000000000467253"

[shrinand_bhedasgaonkar]

Thanks, guys, for your time.

I changed your solution by providing mode & precision that is - 

(mapcar '(lambda (n) (rem (atof (rtos n 2 16)) 0.25)) (getpoint "Select Point - "))

Still LISP showing output with single decimal place (0.0 0.0 0.0)

[Moshe-A]

@shrinand_bhedasgaonkar ,

---

@shrinand_bhedasgaonkar wrote:

Thanks, guys, for your time.

I changed your solution by providing mode & precision that is - 

(mapcar '(lambda (n) (rem (atof (rtos n 2 16)) 0.25)) (getpoint "Select Point - "))

Still LISP showing output with single decimal place (0.0 0.0 0.0)

---

DIMZIN controls that, set it to 0 🤣

[marko_ribar]

Have a look at this topic : https://www.theswamp.org/index.php?topic=53061.0 

I think that custom (rem) function may solve the problem... I wrote my version also, just go and find it among other replies...