Sierpinski triangles with LISP code

[Anonymous]

I am trying to draw Sierpinski triangles using LISP code (recursive)  and LINE command. The code ran for order of 1 (m1 =1). But for higher order I am getting irregular pattern. Also, an error " error: bad function: 48 or 75 etc. etc." displayed on every run.

Here is my code:

;;;; Function for Sierpinski triangles

(defun drawtriangle1 (p1 p2 p3)
(command "line" p1 p2 p3 "c")
)

(defun sierpinski2 (t0 t1 t2 limit1)
(if (< 0 limit1)
(
(setq pax (/ (+ (car t0) (car t1)) 2))
(setq pay (/ (+ (cadr t0) (cadr t1)) 2))
(setq pbx (/ (+ (car t1) (car t2)) 2))
(setq pby (/ (+ (cadr t1) (cadr t2)) 2))
(setq pcx (/ (+ (car t2) (car t0)) 2))
(setq pcy (/ (+ (cadr t2) (cadr t0)) 2))
(setq pa (list pax pay))
(setq pb (list pbx pby))
(setq pc (list pcx pcy))
(sierpinski2 t0 pa pc (1- limit1))
(sierpinski2 pa t1 pb (1- limit1))
(sierpinski2 pc pb t2 (1- limit1))
);_end of if
(drawtriangle1 t0 t1 t2)
);_ end of if-else part
);_end of sierpinski2

;;;; Define the initial coordinates
(setq v0 (list 50 87))
(setq v1 (list 100 0))
(setq v2 (list 0 0))
(setq m1 2);_order of fractal

(defun c:st5 ()
(sierpinski2 v0 v1 v2 m1)
);_ end of st5 function

Regards,

Samim

[Kent1Cooper]

Without delving very deep, I notice something appears to be missing:

....

(if (< 0 limit1)
  (progn
    (setq pax (/ (+ (car t0) (car t1)) 2))
    (setq pay (/ (+ (cadr t0) (cadr t1)) 2))
    (setq pbx (/ (+ (car t1) (car t2)) 2))
    (setq pby (/ (+ (cadr t1) (cadr t2)) 2))
    (setq pcx (/ (+ (car t2) (car t0)) 2))
    (setq pcy (/ (+ (cadr t2) (cadr t0)) 2))
    (setq pa (list pax pay))
    (setq pb (list pbx pby))
    (setq pc (list pcx pcy))
    (sierpinski2 t0 pa pc (1- limit1))
    (sierpinski2 pa t1 pb (1- limit1))
    (sierpinski2 pc pb t2 (1- limit1))

  ); progn
);_end of if

[Anonymous]

Thanks for your quick reply.

Adding PROGN improves the output . It displayed the top correctly.  But next two subsections (pa t1 pb) and (pc pb t2) are not working properly.

[Kent1Cooper]

Or did I misunderstand where the end of the (progn) function should fall? Should it be:

(if (< 0 limit1)
  (progn ; then
    (setq pax (/ (+ (car t0) (car t1)) 2))
    .... all the stuff in between ....

    (sierpinski2 pc pb t2 (1- limit1))
  );_end of progn [then]
  (drawtriangle1 t0 t1 t2) ; else argument
);_ end of if-else part

Also, I wonder about those (sierpinski2) functions called from within the definition of the function itself.  Should those be (drawtriangle) functions instead?   [Never mind -- I think I see the recursive thing that's going on.]

[leeminardi · Accepted solution]

Another problem with your code is that it is doing integer math.  You want to do floating point math and not round to an integer value.  Change the statements such as 

(setq pax (/ (+ (car t0) (car t1)) 2))

to

(setq pax (/ (+ (car t0) (car t1)) 2.))

 Either the numerator or denominator must  be a real number to ensure a floating point calculations.

Check this link for a sophisticated vlisp implementation of Sierpinski's triangle.

[Kent1Cooper]

---

@leeminardi wrote:

Another problem with your code is that it is doing integer math.  You want to do floating point math and not round to an integer value.  Change the statements such as 

(setq pax (/ (+ (car t0) (car t1)) 2))

to

(setq pax (/ (+ (car t0) (car t1)) 2.))

 Either the numerator or denominator must  be a real number to ensure a floating point calculations.

....

---

That was in Reply to me, but I'm  not doing integer math -- @Anonymous is.  If in actual operation the starting triangle-defining points v0, v1 and v2 would come from something like (getpoint), or be extracted from something like entity data [e.g. Polyline vertices or something], then their coordinates would be real numbers, and the 2 [without decimal] would be fine.  They could also keep the 2 as an integer and make the coordinates of those points real numbers in (setq)ing them numerically, i.e.:

(setq v0 (list 50. 87.))
(setq v1 (list 100. 0.))
(setq v2 (list 0. 0.))

In any case, with values like these, the skewed-ness of their image wouldn't be explained only by that distinction, since the only incorrect result would be that (/ 87 2) yields 43, not 43.5 -- that would warp things only slightly.

[Later we can get into briefer ways to find the location midway between two others.]

[leeminardi]

@Kent1Cooper  my reply was intended for the OP.  I know you are experienced enough to understand the concepts of mixed mode math.  Back in the day we had to be acutely aware of it before programs like Excel let you be sloppy.  My apologies.   

I wasn't  trying to address the skewness of the results which indicate a more subtle coding problem.  The integer math problem does show the cause of the slight offset lines the program creates when all the coordinates of the points are integers.

[qnologi]

have you tried here?

https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/bd-p/130