applying (rtos x 2 2) to a list...

[Lt Dan's legs]

I'm trying to convert this list

(0.33 0.5 0.75 1.0 1.01 1.25 1.5 1.51 2.0 2.25 2.5 3.0 3.01 3.02 3.25 3.5 3.9 4.0)

into

("0.33" "0.50" "0.75" "1.00" "1.01" "1.25" "1.50" "1.51" "2.00" "2.25" "2.50" "3.00" "3.01" "3.02" "3.25" "3.50" "3.90" "4.00")

 

this problem is driving me crazy!!!

[David Bethel]

Maybe this:

 

 [b][color=BLACK]([/color][/b]setvar [color=#2f4f4f]"DIMZIN"[/color] 0[b][color=BLACK])[/color][/b]
 [b][color=BLACK]([/color][/b]setq l1 '[b][color=FUCHSIA]([/color][/b]0.33 0.2 0.5 1.0 1.01 1.22[b][color=FUCHSIA])[/color][/b][b][color=BLACK])[/color][/b]
 [b][color=BLACK]([/color][/b]setq l2 [b][color=FUCHSIA]([/color][/b]mapcar '[b][color=NAVY]([/color][/b]lambda [b][color=MAROON]([/color][/b]s[b][color=MAROON])[/color][/b] [b][color=MAROON]([/color][/b]rtos s 2 2[b][color=MAROON])[/color][/b][b][color=NAVY])[/color][/b] l1[b][color=FUCHSIA])[/color][/b][b][color=BLACK])[/color][/b]
 [b][color=BLACK]([/color][/b]prin1 l2[b][color=BLACK])[/color][/b]

-David

[BlackBox]

Just something to consider...

 

There is no reason to set dimzin to zero, as (rtos 2 2) will do what the OP wants. However, if you do change dimzin, then (IMO) it *should* be changed back to it's original state when the routine is done. :wink:

 

Building on David's apt usage of mapcar + lambda...

 

(defun RM:ListReal->ListStr (l / l2)
 ;; © RenderMan
 ;; Example: (RM:ListReal->ListStr l1)
 ;; Where l1 =
 ;; (setq l1 (list 0.33 0.5 0.75 1.0 1.01 1.25 1.5 1.51 2.0 2.25 ;| etc |)
 (if (and l
          (= 'LIST (type l)))
   (setq l2 (mapcar (function (lambda (x) (rtos x 2 2))) l))))

 

 

Hope this helps!

[alanjt]

There is no reason to set dimzin to zero, as (rtos 2 2) will do what the OP wants. However, if you do change dimzin, then (IMO) it *should* be changed back to it's original state when the routine is done. :wink:

RToS will not override dimzin settings (removing leading/trailing zeros).

eg.

Enter new value for DIMZIN <12>:

Command: (rtos 0.1 2 2)
".1"

(defun RM:ListReal->ListStr (l / l2)
 ;; © RenderMan
 ;; Example: (RM:ListReal->ListStr l1)
 ;; Where l1 =
 ;; (setq l1 (list 0.33 0.5 0.75 1.0 1.01 1.25 1.5 1.51 2.0 2.25 ;| etc |)
 (if (and l
          (= 'LIST (type l)))
   (setq l2 (mapcar (function (lambda (x) (rtos x 2 2))) l))))

 

What if the list has sublists?

 

Food for thought...

(defun AT:RToSLst (lst unit prec)
 (mapcar
   (function (lambda (x)
               (cond
                 ((eq (type x) 'LIST) (AT:RToSLst x unit prec))
                 ((member (type x) (list 'INT 'REAL)) (rtos x unit prec))
                 (x)
               )
             )
   )
   lst
 )
)

eg.

(_rtoslst '(3.4 nil "A" (5)) 2 2)

Oh yeah, there's no need to use and to check if l is a valid variable before issuing type on it; type will work on nil. Also, you don't need to setq the second variable.

[BlackBox]

RToS will not override dimzin settings (removing leading/trailing zeros).

eg.

Enter new value for DIMZIN <12>:

Command: (rtos 0.1 2 2)
".1"

 

 

I appreciate the correction, Alan (and in turn, my apologies David! ).

 

Despite the educational correction, the latter part of my statement (changing Dimzin back) still holds true, no?

 

As always, I appreciate your sharing the knowledge. :wink:

[alanjt]

I appreciate the correction, Alan (and in turn, my apologies David! ).

 

Despite the educational correction, the latter part of my statement (changing Dimzin back) still holds true, no?

 

As always, I appreciate your sharing the knowledge. :wink:

Agreed and anytime.

Did you give my sub a look?

[Lee Mac]

What if the list has sublists?

 

Food for thought...

 

And if the list has dotted pairs?

 

More food for thought:

 

(defun LM:rtoslst ( l u p )
  
  (cond
    ( (member (type l) '(INT REAL)) (rtos l u p) )
    ( (atom l) l )
    ( (cons (LM:rtoslst (car l) u p) (LM:rtoslst (cdr l) u p)) )
  )

)

[alanjt]

And if the list has dotted pairs?

 

More food for thought:

 

(defun LM:rtoslst ( l u p )
  
  (cond
    ( (member (type l) '(INT REAL)) (rtos l u p) )
    ( (atom l) l )
    ( (cons (LM:rtoslst (car l) u p) (LM:rtoslst (cdr l) u p)) )
  )

)

 

ROFL

On my way home, I thought about dotted pairs (completely forgot about them) and just knew you would have responded with that very question by the time I got home.

[David Bethel]

Despite the educational correction, the latter part of my statement (changing Dimzin back) still holds true, no?

 

In most cases I would agree with that statement. In the case of DIMZIN, I think that any routine that uses ( rtos ) ( angtos ), that the routine should implicitly set DIMZIM to match the desired results. Resetting it would be a general housekeeping chore in a full robust routine.

 

 

 

As to the sublist, nils and none numberp atoms, I would lean toward an error. My thought is that initial need is to convert a list of reals to strings. If the atom isn't a number, something is screwed up and should be conveyed as such. My $0.02 -David

[BlackBox]

In most cases I would agree with that statement. In the case of DIMZIN, I think that any routine that uses ( rtos ) ( angtos ), that the routine should implicitly set DIMZIM to match the desired results. Resetting it would be a general housekeeping chore in a full robust routine.

 

As to the sublist, nils and none numberp atoms, I would lean toward an error. My thought is that initial need is to convert a list of reals to strings. If the atom isn't a number, something is screwed up and should be conveyed as such. My $0.02 -David

 

 

Those are great points.

 

It may only be $0.02 (USD) to you, but I've recently switched to the Zimbabwe Dollar... the other day I bought a Big Mac, and it cost me $980.75 (ZWD)! (Just kidding!)

 

I appreciate the clarification, David! :stein:

[Lee Mac]

As to the sublist, nils and none numberp atoms, I would lean toward an error. My thought is that initial need is to convert a list of reals to strings. If the atom isn't a number, something is screwed up and should be conveyed as such. My $0.02 -David

 

That methodology certainly makes mine a lot simpler

 

(defun LM:rtoslst ( l u p )
 (if l
   (if (atom l)
     (rtos l u p)
     (cons (LM:rtoslst (car l) u p) (LM:rtoslst (cdr l) u p))
   )
 )
)

[David Bethel]

Lee,

 

I think your's will hit the stack limit pretty quickly on large list. ( It crashed r12 with 1,000 atom list / A2k with 10,000)

 

Also I think that would be a fairly slow process. -David

[Se7en]

If the data was static (known) then i would use:

(mapcar (function (lambda ( x ) (rtos x 2 2))) )

 

If a little less static (some erroneous data maybe) I would still use something like:

(mapcar (function (lambda ( x ) (if (atom x) (rtos x 2 2) x))) )

 

If the data were totally unknown then i would employ a route similar to what Lee provided.

[David Bethel]

I think I'd lean more toward (numberp)

 

(atom (cadr '(1 nil 3))) returns T

 

[b][color=BLACK]([/color][/b]mapcar '[b][color=FUCHSIA]([/color][/b]lambda [b][color=NAVY]([/color][/b]s[b][color=NAVY])[/color][/b] [b][color=NAVY]([/color][/b]if [b][color=MAROON]([/color][/b]numberp s[b][color=MAROON])[/color][/b] [b][color=MAROON]([/color][/b]rtos s 2 2[b][color=MAROON])[/color][/b] [color=#2f4f4f]""[/color][b][color=NAVY])[/color][/b] l1[b][color=FUCHSIA])[/color][/b]

 

That would insure the length of lists be at least equal. -David

[Se7en]

sure; i cant argue. The concept is the same really.

 

It's always good to check and what-not but if the list becomes too unknown then most times I would just employ a method like what Lee provided and move on (take the performance hit and get back to coding).

 

If i have a mixed list like:

(setq l1 '(0.33 0.5 0.75 (1.0 (1.01) 1.25) 1.5 (1.51 . 2.0) 2.25 2.5 nil 3.0 3.01 3.02 3.25 3.5 3.9 4.0))

[Lee Mac]

Lee,

 

I think your's will hit the stack limit pretty quickly on large list. ( It crashed r12 with 1,000 atom list / A2k with 10,000)

 

Also I think that would be a fairly slow process. -David

 

Oh yes of course - for long lists there is a lot of information being added to the stack, my post was perhaps more conceptual. With such a large amount of data nested to an unknown level I would rethink an earlier stage of the program to avoid being in such a situation.