Replace the rtd in polar commands

Hopefully the heading has caught your attention, often we see, me to in code when doing (polar pt1 (dtr 45) 25) the use of the polar function repeated all the time for standard type angles 45 90 180 etc. I tend to define these early on in code as (setq ang90 (/ pi 2.0) ) with the correct value or use the direct conversion (/ pi 2)

So I thought why not just make variables on the fly for the most common angles and use those in any polar function. Hence this lisp.

; simple make angles as a variable for use in polar's
; By Alan H May 2018
; change the angs list to suit

(defun AHANGS ( / ang angs )
(setq angs (list 22.5 30.0 45.0 60.0 90.0 135.0 180.0 225.0 270.0))
(foreach ang angs 
(set (read (strcat "A" (rtos ang 2 0)) ) (* pi (/ ang 180.0)) )
)
)

(ahangs)

; a couple of examples
(if (not ahangs)(load "AHANGS")) ; put at start etc so makes the angles

(setq pt2 (polar pt1 a45 25))
(setq pt3 (polar pt2 a225 25))

Hopefully the heading has caught your attention, often we see, me to in code when doing (polar pt1 (dtr 45) 25) the use of the polar function repeated all the time for standard type angles 45 90 180 etc. I tend to define these early on in code as (setq ang90 (/ pi 2.0) ) with the correct value or use the direct conversion (/ pi 2)

 

So I thought why not just make variables on the fly for the most common angles and use those in any polar function. Hence this lisp.

 

; simple make angles as a variable for use in polar's
; By Alan H May 2018
; change the angs list to suit

(defun AHANGS ( / ang angs )
(setq angs (list 22.5 30.0 45.0 60.0 90.0 135.0 180.0 225.0 270.0))
(foreach ang angs 
(set (read (strcat "A" (rtos ang 2 0)) ) (* pi (/ ang 180.0)) )
)
)

(ahangs)

 

; a couple of examples
(if (not ahangs)(load "AHANGS")) ; put at start etc so makes the angles

(setq pt2 (polar pt1 a45 25))
(setq pt3 (polar pt2 a225 25))

Something like the properties in the VBA reference like the color property acRed , acGreen... it could certainly be handy when using lots of (polar) angles and it can make your routines easier to read. Nice technique Bigal

Hi BIGAL,

Just sharing my opinion:

I'd avoid your approach because defining too many global variables might mess up one/few of the hundreds lisp codes you use.

Say somewhere you already have (defun C:*** ( / .. a90 ...) ...) where 'a90' has a different meaning, or even worse - if its global.

Unless you keep up with very good standartization for your variable names and .lsp codes, to define your own enumerables.

For short it would be hard to maintain the future .lsp codes that use such 'library' variables.

On the other hand, I'd use a 'library / global' subfunction like this:

; _$ (_polar '(0. 0. 0.) 45 100) >> (70.7107 70.7107 0.0)
; _$ (_polar '(0. 0. 0.) 0 100) >> (100.0 0.0 0.0)
(defun-q _polar ( pt ang dst )
 "This subfunction acts like polar, but expects angle in degrees"
 (polar pt (* PI (/ ang 180.)) dst)
)

And try to keep the 'variables' always local, so they could be associated under the context of the certain subfunction:

(defun MakeSquares ( pt n / ang dst )
 
 ; ...
 (defun MakeSingleSquare ( pt / ang dst )
   ; ...
 )
 
 (defun MakeColumnOfSquares ( pt n / ang dist )
   ; ...
 )
 
 (repeat n 
   (MakeColumnOfSquares pt++ i++)
 )
)

Defun-q, not defun - why?

One day you might forget the purpose of that subfoo, so just do this in VLIDE:

_$ _polar
((PT ANG DST) "This subfunction acts like polar, but expects angle in degrees" (POLAR PT (* PI (/ ANG 180.0)) DST))

But usually I would define that subfoo under the context of my main program, so I probably won't require such description.

Nice idea Grr I did think about doing a direct polar defun like you posted, I think its more about how happy are you about using lots of little defuns in code and understanding how they work. As an example one "Package" has 95 lisps these are very integrated with a serious amount of library calling, so you are right if suddenly I use a90 it could screw something else. I have not had to do a suite lately but the stuff at work now has a lot more library routines in them or (if (nots, rather than repeating code nor just loading code that you may not use, they use a hopefully unique naming. Looking back now will probably next time I do lots of polars use your defun. If its one or two just use the direct pi conversion.

Just to elaborate its all because of the variable-defining complexity.

Say when you define a 300 row subfunction, with some custom name, the chance to redefine it would be alot less than a custom variable:

(setq LM:GetBoundingBox (getdist "\nSpecify the box: ")) ; low chance to redefine
(setq a90 '((name "Alan")(amount "90"))) ; high chance to redefine, because it was angle of 90 degrees

That said, still means that not all main functions (C:***) are self-dependent and require defined subfunctions in order to work properly.

But thats alot easier than requiring custom global variables.

In my lisps, when a subfunction requires another subfunction or more I put a comment like this:

; Required subfunctions: LM:GetBoundingBox ShiftNths DrawSquare
(defun MyAwesomeFunction ( / ) ...)

Although if you have a new 1000+ rows code I would define these angles just like you did, with a22.5 ; a45 ; a90 ...

but the difference would be that they would stay local under the context of my huge program.

Yeah keeping local makes lots of sense, it was originally about saving a bit of typing time and just repeating the dtr function.

Whatever technique works best for you is up to you just try to be consistent. For my 'tiny lisp' section my goal is to create one-liners so every character I can do without is a victory:celebrate: but all variables are local.

If my program is large (and most of the time they are cause I never can stop adding extra options) I try to create long and self descriptive (but still always local) variable names. So in this case a pimped polar function would probably make more sense than a globar var.

i prefer localize variable, but sometimes naming defun is important due to it's also set globally, try as unique as possible to avoid conflict, or longer symbol...

because we don't know other pc may have same function/command call?

using prefix e.g: XXX:MATH_COSINE , FUNC_MATRIX_TRANPOSE , XXX:MYFUNCTION, LM:Uniquefuzz etc..