APPLY function problem/strangeness...

[Anonymous]

Amigos,

I've come across the following AutoLISP strangeness/inconsistency in
R14.01 and ADT2, and I was wondering if any of you could
confirm/duplicate this behavior. Or perhaps clue me in as to if/where
this has been discussed before.

I noticed it whilst trying to program a check on a list of strings to
verify that no member is equivalent to "0" - but it seems that the
problem lies on a deeper level than that.

Here is a snip of my original function, which is supposed to take a
string like "FR10.0/15.0", split it up, then check to make sure it is
formatted correctly. [The function STD-STRTOK splits up a string (in
this case *FSM_STR*) based on a supplied delimeter (in this case the
"/"), and returns a list containing the substrings... IOW, (STD-STRTOK
"10.0/15.0" "/") -> ("10.0" "15.0")] :

(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR*
3) "/"))))))

Perhaps there is a much better way to do this, but my point is that
entire construct is throwing out some strange error messages...

IOW, given any list: , I can't get:

(apply 'not )

to work in either R14.01 or ADT2

However, if I use 'null, instead, as in:

(apply 'null )

this DOES work in R14.01 - but NOT in ADT2. (?!)

I thought that just in case the STDLIB functions might *possibly* have
something to do with this, I decided to try it without them loaded up.
As you can see below, this made no difference.

Here are two snips from my command line
(Tried immediately after starting fresh sessions of AutoCAD):

----------------------------------------------------------------
R14.01 Command Line output:

...

Command: ARX

?/Load/Unload/Commands/Options: ?

Loaded Runtime Extension Programs:

acadapp.arx
acmted.arx
autocell.arx
doslib14.arx
livetext.arx
oleaprot.arx
qpik14.arx
toolr14.arx

End of List.

Command: (apply 'NOT '(1 2 3 4 5))
error: too many arguments
(NOT (<> 1) (<> 2) (<> 3)
(<>
#28f3e40> 4) (<> 5))
(APPLY (QUOTE NOT) (QUOTE (1 2 3 4 5)))
*Cancel*

Command: (apply 'NOT (list 1 2 3 4 5))
error: too many arguments
(NOT (<> 1) (<> 2) (<> 3)
(<>
#28f3e40> 4) (<> 5))
(APPLY (QUOTE NOT) (LIST 1 2 3 4 5))
*Cancel*

Command: (apply 'NULL '(1 2 3 4 5))
nil

Command: (apply 'NULL '(nil nil nil nil nil))
T

Command: (apply 'AND '(1 2 3 4 5))
T

Command: (apply 'AND '(1 NIL 3 4 5))
nil

Command: (apply 'OR '(1 NIL 3 4 5))
T

Command: (apply 'OR '(NIL NIL NIL NIL NLI))
nil

----------------------------------------------------------------
ADT2 Command Line output:

...

Command: arx

Enter an option [?/Load/Unload/Commands/Options]: ?

Loaded Runtime Extension Programs:

acadapp.arx - MDI Aware.
acdim.arx - MDI Aware.
aceplotx.arx - MDI Aware.
acetutil.arx - MDI Aware.
achapi15.dbx - MDI Aware.
achlnkui.arx - MDI Aware.
aecstartup.arx - MDI Aware.
appload.arx - MDI Aware.
doslib2k.arx - MDI Aware.
modemacro.arx - MDI Aware.
oleaprot.arx - MDI Aware.
qpik15.arx - MDI Aware.
stdlib15.arx - MDI Aware.
vl.arx - MDI Aware.

End of List.

Command: arx

Enter an option [?/Load/Unload/Commands/Options]: u

Enter ARX/DBX file name to unload: stdlib15.arx

stdlib15.arx successfully unloaded.

Command: (apply 'NOT '(1 2 3 4 5))
; error: too many arguments

Command: (apply 'NOT (list 1 2 3 4 5))
; error: too many arguments

Command: (apply 'NULL '(1 2 3 4 5))
; error: too many arguments

Command: (apply 'NULL '(nil nil nil nil nil))
; error: too many arguments

Command: (apply 'AND '(1 2 3 4 5))
T

Command: (apply 'AND '(1 nil 3 4 5))
nil

Command: (apply 'OR '(1 nil 3 4 5))
T

Command: (apply 'OR '(nil nil nil nil nil))
nil

----------------------------------------------------------------

This is really weird; (apply 'and... , as well as (apply 'or... ,
both work as I would expect, but not (apply 'not... [as well as (apply
'null... in ADT2)]

BTW, my 'puter OS is WinNT4.0 SP4, FWIW, and I'm using a plenty good
machine w/ plenty o' memory for this paltry exercise.

So, first of all, can anyone duplicate/very this behavior?

Is it possible that the problem could be related to one of the other
third party programs I'm using?
(I truly hope that this isn't the case.) Perhaps NOT (and NULL) have
been setq redefined somehow/somewhere? [I'm 99.999% certain my own
programs have not done this.]

If this is indeed an AutoCAD/AutoLISP bug, does anyone have a good
simple workaround for this?

Sorry for the long post, but I hope I have explained this sufficiently
well.

Appreciative of any assistance/feedback tracking down this problemo,
David Kozina

[Anonymous]

You didn't get what you wanted for Christmas, did you? Anyone who can read
the help file knows that apply is used to process lists. While you (in your
typically negative manner) came up with the exception to the rule, the fact
remains that the reason Mr. Kozina's function failed was due to the fact
that NOT nor NULL mix very well with apply. Unless of course, you always
take the time to enclose single atoms in a list.

Good day to you, sir.

P.S. I'll see if they have any personalities left at the surplus store. What
size are you?

Tony Tanzillo wrote in message
news:38756918.5CA6EEB7@worldnet.att.net...
> Frank - It appears that you now think you are infallable.
>
> Well, I'm sorry to have to be the one to deliver this
> massive blow to your overblown ego, but here again are
> your own words:
>
> "Regardless of how you want to term it, apply will not
> operate correctly with NULL or NOT since they only accept
> one argument."
>
> You are wrong. I just got done showing that apply does
> operate correctly with NOT, contrary to your statement.
>
> You are wrong, got that Frank? As much as you may not
> like it, you are wrong.
>
> Frank Oquendo wrote:
> >
> > No one an ounce of common sense would feed a single member list to
apply.
> > Except maybe for someone trying to save face. Glad to have you back, Mr.
> > Tanzillo.
> >
> > Tony Tanzillo wrote in message
> > news:387536B8.7AD6D4C5@worldnet.att.net...
> > > Regardless of how you try to spin this, you are wrong.

[Anonymous]

Frank Oquendo wrote:
>
> Anyone who can read the help file knows that apply is used to process lists.

Which has absolutly nothing to do with the fact that
it works with NOT and NULL, in total contradiction to
what you have suggested.

Now what this has turned into is little more than
your overblown ego trying to wiggle out of having
to acknowledge that you were wrong, and you have
found yourself left with no recourse other than to
resort to personal attacks, only because you cannot
hack it on technical grounds.

You can attack me personally all you wish, but that
isn't going to change the facts, which is that you
simply cannot bring yourself to admit when you're
in error.

In the future, I will endeavour to teach you how
to admit when you are wrong.

--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/

[Anonymous]

What about the hat?

"Tony Tanzillo" wrote in message
news:38759D0B.5F104EF1@worldnet.att.net...
> Frank Oquendo wrote:
> >
> > Anyone who can read the help file knows that apply is used to process
lists.
>
> Which has absolutly nothing to do with the fact that
> it works with NOT and NULL, in total contradiction to
> what you have suggested.
>
> Now what this has turned into is little more than
> your overblown ego trying to wiggle out of having
> to acknowledge that you were wrong, and you have
> found yourself left with no recourse other than to
> resort to personal attacks, only because you cannot
> hack it on technical grounds.
>
> You can attack me personally all you wish, but that
> isn't going to change the facts, which is that you
> simply cannot bring yourself to admit when you're
> in error.
>
> In the future, I will endeavour to teach you how
> to admit when you are wrong.
>
> --
> /*********************************************************/
> /* Tony Tanzillo Design Automation Consulting */
> /* Programming & Customization for AutoCAD & Compatibles */
> /* ----------------------------------------------------- */
> /* tony.tanzillo@worldnet.att.net */
> /* http://ourworld.compuserve.com/homepages/tonyt */
> /*********************************************************/

[Anonymous]

It is doubtful that I could learn anything from such a spiteful person,
Tony. While you have a point that apply would work with a single element
list, you still have not, and cannot, demonstrate that the apply function
would work in the context of the original question. Remember my challenge to
you?

Prove that (apply ' not '(1 2 3)) works.
You ducked the question by responding with (apply 'not '(nil))

Who cares if you don't like my terminology? If you check the timestamps on
the posts, you'll note that I was the first to "incorrectly" identify the
source of Mr. Kozina's problem. I at least try to help people rather than
offend them. If you want to endeavor to do anything, try becoming a little
more social.

"Tony Tanzillo" wrote in message
news:38759D0B.5F104EF1@worldnet.att.net...
> Frank Oquendo wrote:
> >
> > Anyone who can read the help file knows that apply is used to process
lists.
>
> Which has absolutly nothing to do with the fact that
> it works with NOT and NULL, in total contradiction to
> what you have suggested.
>
> Now what this has turned into is little more than
> your overblown ego trying to wiggle out of having
> to acknowledge that you were wrong, and you have
> found yourself left with no recourse other than to
> resort to personal attacks, only because you cannot
> hack it on technical grounds.
>
> You can attack me personally all you wish, but that
> isn't going to change the facts, which is that you
> simply cannot bring yourself to admit when you're
> in error.
>
> In the future, I will endeavour to teach you how
> to admit when you are wrong.

[Anonymous]

Tony never met the challenge, hence the lack of hat eating. And he accuses
me of having an ego. Sheesh.

"Mike Leonard" wrote in message
news:854v59$g5017@adesknews2.autodesk.com...
> What about the hat?

[Anonymous]

BTW, my exact words were: "apply is not meant to work with unary operators."
I never said it did not work at all. As for the use of "unary operator", I
apologize if I have offended your sensibilities. NOT and NULL accept only
single arguments. In other languages, that could be called a unary operator.
Just to appease you, I'll retract that term and henceforth will type out the
excessively long phrase "functions that accept a single argument".

So let's recap, shall we? Apply is not meant to work with functions that
accept a single argument. I think you can hardly argue that the apply
function was not INTENDED (I'll use a synonym) for use with commands that
accept single arguments, since it feeds an entire list of arguments to the
specified function.

And I'm still waiting to see you make this one fly: (apply 'not '(1 2 3)).
Which was after all, my inital challenge to you. I'll admit I employed the
wrong semantics. Let's see if you can admit you're excessively belligerent.

[Anonymous]

David Kozina escribió en mensaje <85336p$bq235@adesknews2.autodesk.com>...
>Hola Eduardo,
>
>Well, it all depends on when where and what you're trying to do, I guess...
>In this case, in fact, the test happened to be part of a larger test all
tied together by an
>(and... statement so I needed a T or nil response for that particular test.

Why?

(and T T T) --> T

but then...

(and T 1 '(2 3)) --> T

so...

(and T (member 0 '(0 1 2))) -> T

Just trying to help 🙂

Eduardo Muñoz

[Anonymous]

Ooops!
Sorry, Eduardo, I was having a little trouble seeing the tree in there. 😉

When you originally said...

> but what about this?
>
> (while (member 0 '(1 2 3 0 ))
> (do_stuff)
> )

I was looking more at the (while ... (do_stuff)) part and not at the test you were actually trying
to point out. Thanks! That's yet another way to accomplish the type of test I was originally
looking for.

I would find it quite interesting to know how the different AutoLISP functions "stack up" against
each other in terms of "speed and efficiency" especially when performing similar tasks... sort of
like a "Function best when used in the following situations..." list or table of "pros and cons".
KWIM? Not necessarily that it would *matter* all that much in my own personal programs, or with
faster and faster computers, but I'd like to think I at least am *trying* to program about as well
as can be done in a given language - though I'm usually happy just to find something that *works*
[at which point I usually stop until I'm directed to an apparently better way]. Still, some general
guidelines would be quite useful. I've noticed some programmers like Vladimir Nesterovsky actually
take time to perform 'time-trials', so to speak, on with different subroutines doing the same
general problem, and then compare their performances.

As I've become well aware, there's often several ways to program something, some ways are much more
readable or easier than others, some ways are much more efficient speedwise, some ways are much more
efficient memory-wise, sometimes (or always?) repetitive things can be done using recursion (though
I don't really have a handle on that), but what way gives the most "bang for the buck"? What way is
more elegant? What way(s) is/are least likely to fail given large data structures? Still having a
hard time trying to figure things like that one out. Hope it comes with more experience. I guess
what I'd like is some "instant experience". That's where all of you folks come in... 🙂

So much to learn. So little time.

Best regards,
David Kozina

Eduardo Muñoz wrote in message news:855bb9$i5515@adesknews2.autodesk.com...

> (and T (member 0 '(0 1 2))) -> T
>
> Just trying to help 🙂

[Anonymous]

Frank Oquendo wrote in message
news:853m0p$drd30@adesknews2.autodesk.com...
> No one an ounce of common sense would feed a single member list to apply.

>
> Tony Tanzillo wrote in message
> news:387536B8.7AD6D4C5@worldnet.att.net...

> > (apply 'not '(nil)) ----------> T


Hello Frank,

PMFJI... I hope you won't think I'm trying to stir up trouble for saying this - and maybe it just
means I don't have an 'ounce of common sense', but I would just like to give a bit more background
as to my original post on this subject...

(It doesn't make too much difference now, since my questions regarding this have been pretty well
answered.)

In case you might not have caught it in my code snip I posted in regards to Eduardo's comment, I
came across this while trying to program a little routine to help fill out a Footing Schedule. At
our office, we mark our footings on plan like so...

"FC2.0" to denote a 2'-0" wide Continuous Footing,
"FS6.0" to denote a 6'-0" Square Spread (or Spot) Footing
"FR10.0/15.0" to denote a 10'-0" x 15'-0" Rectangular Spread (or Spot) Footing.

The Footing Schedule itself consists of 10 columns: Mark Name; Footing Width, Length, & Thickness;
Crosswise Reinf. Bar No., Size & Spacing; and Lengthwise Reinf. Bar No., Size, & Spacing. We just
use a small Mark Block with 10 attributes that we insert in the schedule as needed on each line. My
thought was that, given the Mark Name *alone*, several of the other attributes could be easily
derived as well providing guidance and direction for the any additional prompts needed to round out
the information.

Where I was running into difficulties was with checking for invalid input. In my original post, you
may not have noticed, but I mentioned the code I was trying...

(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/"))))))



(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/"))))

Now, **given my original situation**, this was what was really confusing me...

Say User has entered "FC2.0" for *FSM_STR* => [Valid]
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FC2.0" 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "2.0") "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof '("2.0")))) ->
(apply 'not (mapcar 'zerop '(2.0))) ->
(apply 'not '(nil)) ->
T
(TEST SUCCESSFUL!)

Say User has entered "FSW.0" for *FSM_STR* => [Invalid]
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FSW.0" 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "W.0") "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof '("W.0")))) ->
(apply 'not (mapcar 'zerop '(0.0))) ->
(apply 'not '(T)) ->
nil
(TEST SUCCESSFUL!)

Say User has entered "FR10.0/40.0" for *FSM_STR* => [Valid]
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FR10.0/40.0" 3) "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "10.0/40.0" "/")))) ->
(apply 'not (mapcar 'zerop (mapcar 'atof '("10.0" "40.0")))) ->
(apply 'not (mapcar 'zerop '(10.0 40.0))) ->
(apply 'not '(nil nil)) ->
error: too many arguments
(TEST UNSUCCESSFUL!?!?! What the...?)

Say User has entered "FR10.0/40.0" for *FSM_STR* => [Valid]
(apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3) "/")))) ->
(apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FR10.0/40.0" 3) "/")))) ->
(apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK "10.0/40.0" "/")))) ->
(apply 'null (mapcar 'zerop (mapcar 'atof '("10.0" "40.0")))) ->
(apply 'null (mapcar 'zerop '(10.0 40.0))) ->
(apply 'null '(nil nil)) ->
T
(TEST SUCCESSFUL! (in this *particular* case, anyway) - or so I thought 'til I later thought to pop
in something like "FR10.0/G", which returns T as well, which is wrong - but I didn't notice *that*
right away.)

But here's the really strange part...
As it turns out, we don't really use the "FR" mark too much in our drawings, probably less than 5%
of the time, which would mean that **the vast majority of the time**, my original test worked just I
felt it should! Strange - and maybe stupid, but true - believe it or not! But then I started
getting those inconsistent error messages with regards to 'not vss. 'null! What on earth is going
on here?! This was what prompted my original post to all of you here. If it wasn't for that ol'
"FR" mark, I wouldn't have even noticed the problem. Of course, if that were the case, I probably
would have just used something like:

(not (zerop (atof (substr *FSM_STR* 3))))

- which is *your* point, if I am understanding you correctly. But the "FR" mark involved an
additional string, so I decided to go with an apply test over a list of 1 or 2 strings that I hoped
would check for either case... I just was stumbling with regards to the right test.

Oh well, that's how I usually learn. Again, I'd like to thank you and everyone else who has
commented on this issue. Though I'm don't try to take sides or provoke an argument, I'm glad I
asked.

Best regards,
David Kozina

[Anonymous]

Mike Leonard wrote:
>
> What about the hat?

After he gets his foot out of there....
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/

[Anonymous]

Frank Oquendo wrote:
>
> It is doubtful that I could learn anything from such a spiteful person,
> Tony.

But you already have learned a lot from me - and your posts
clearly reflect it.

> While you have a point that apply would work with a single element
> list, you still have not, and cannot, demonstrate that the apply function
> would work in the context of the original question.

You're trying to make something out of nothing. I never said
that it would work in the context of the original question.

My comments were strictly limited to taking issue with:

A. Your proposed solution for determining if one or more
elements of a list are equal to NIL.

B. Your contention that apply does not work with functions
that expect/require a single argument.

I'm outta this thread.

--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/

[Anonymous]

That's it Frank - keep trying to spin this - but don't
think for a moment that most here can't see right through
you.

Frank Oquendo wrote:
>
> Tony never met the challenge, hence the lack of hat eating. And he accuses
> me of having an ego. Sheesh.
>
> "Mike Leonard" wrote in message
> news:854v59$g5017@adesknews2.autodesk.com...
> > What about the hat?

--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/

[Anonymous]

My only mistake was not backing you into a corner sooner.

Tony Tanzillo wrote in message
news:38769344.F7742A97@worldnet.att.net...
> Frank Oquendo wrote:
> >
> > It is doubtful that I could learn anything from such a spiteful person,
> > Tony.
>
> But you already have learned a lot from me - and your posts
> clearly reflect it.
>
> > While you have a point that apply would work with a single element
> > list, you still have not, and cannot, demonstrate that the apply
function
> > would work in the context of the original question.
>
> You're trying to make something out of nothing. I never said
> that it would work in the context of the original question.
>
> My comments were strictly limited to taking issue with:
>
> A. Your proposed solution for determining if one or more
> elements of a list are equal to NIL.
>
> B. Your contention that apply does not work with functions
> that expect/require a single argument.
>
> I'm outta this thread.
>
> --
> /*********************************************************/
> /* Tony Tanzillo Design Automation Consulting */
> /* Programming & Customization for AutoCAD & Compatibles */
> /* ----------------------------------------------------- */
> /* tony.tanzillo@worldnet.att.net */
> /* http://ourworld.compuserve.com/homepages/tonyt */
> /*********************************************************/

[Anonymous]

It's the only way to learn, David. I"m just glad we all got it figured out.
I felt right silly wondering why your test was malfunctioning. And I picked
up a few pointers on the use of logical functions to boot.

David Kozina wrote in message
news:855upo$k3p7@adesknews2.autodesk.com...
> Frank Oquendo wrote in message
> news:853m0p$drd30@adesknews2.autodesk.com...
> > No one an ounce of common sense would feed a single member list to
apply.
>
> >
> > Tony Tanzillo wrote in message
> > news:387536B8.7AD6D4C5@worldnet.att.net...
>
> > > (apply 'not '(nil)) ----------> T
>
>
>
> Hello Frank,
>
> PMFJI... I hope you won't think I'm trying to stir up trouble for saying
this - and maybe it just
> means I don't have an 'ounce of common sense', but I would just like to
give a bit more background
> as to my original post on this subject...
>
> (It doesn't make too much difference now, since my questions regarding
this have been pretty well
> answered.)
>
> In case you might not have caught it in my code snip I posted in regards
to Eduardo's comment, I
> came across this while trying to program a little routine to help fill out
a Footing Schedule. At
> our office, we mark our footings on plan like so...
>
> "FC2.0" to denote a 2'-0" wide Continuous Footing,
> "FS6.0" to denote a 6'-0" Square Spread (or Spot) Footing
> "FR10.0/15.0" to denote a 10'-0" x 15'-0" Rectangular Spread (or Spot)
Footing.
>
> The Footing Schedule itself consists of 10 columns: Mark Name; Footing
Width, Length, & Thickness;
> Crosswise Reinf. Bar No., Size & Spacing; and Lengthwise Reinf. Bar No.,
Size, & Spacing. We just
> use a small Mark Block with 10 attributes that we insert in the schedule
as needed on each line. My
> thought was that, given the Mark Name *alone*, several of the other
attributes could be easily
> derived as well providing guidance and direction for the any additional
prompts needed to round out
> the information.
>
> Where I was running into difficulties was with checking for invalid input.
In my original post, you
> may not have noticed, but I mentioned the code I was trying...
>
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/"))))))
>
>
> posted:>
>
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/"))))
>
>
> Now, **given my original situation**, this was what was really confusing
me...
>
> Say User has entered "FC2.0" for *FSM_STR* => [Valid]
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FC2.0" 3)
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "2.0") "/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof '("2.0")))) ->
> (apply 'not (mapcar 'zerop '(2.0))) ->
> (apply 'not '(nil)) ->
> T
> (TEST SUCCESSFUL!)
>
> Say User has entered "FSW.0" for *FSM_STR* => [Invalid]
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FSW.0" 3)
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "W.0") "/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof '("W.0")))) ->
> (apply 'not (mapcar 'zerop '(0.0))) ->
> (apply 'not '(T)) ->
> nil
> (TEST SUCCESSFUL!)
>
> Say User has entered "FR10.0/40.0" for *FSM_STR* => [Valid]
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr "FR10.0/40.0"
3) "/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof (STD-STRTOK "10.0/40.0"
"/")))) ->
> (apply 'not (mapcar 'zerop (mapcar 'atof '("10.0" "40.0")))) ->
> (apply 'not (mapcar 'zerop '(10.0 40.0))) ->
> (apply 'not '(nil nil)) ->
> error: too many arguments
> (TEST UNSUCCESSFUL!?!?! What the...?)
>
> Say User has entered "FR10.0/40.0" for *FSM_STR* => [Valid]
> (apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr *FSM_STR* 3)
"/")))) ->
> (apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK (substr
"FR10.0/40.0" 3) "/")))) ->
> (apply 'null (mapcar 'zerop (mapcar 'atof (STD-STRTOK "10.0/40.0"
"/")))) ->
> (apply 'null (mapcar 'zerop (mapcar 'atof '("10.0" "40.0")))) ->
> (apply 'null (mapcar 'zerop '(10.0 40.0))) ->
> (apply 'null '(nil nil)) ->
> T
> (TEST SUCCESSFUL! (in this *particular* case, anyway) - or so I thought
'til I later thought to pop
> in something like "FR10.0/G", which returns T as well, which is wrong -
but I didn't notice *that*
> right away.)
>
> But here's the really strange part...
> As it turns out, we don't really use the "FR" mark too much in our
drawings, probably less than 5%
> of the time, which would mean that **the vast majority of the time**, my
original test worked just I
> felt it should! Strange - and maybe stupid, but true - believe it or not!
But then I started
> getting those inconsistent error messages with regards to 'not vss. 'null!
What on earth is going
> on here?! This was what prompted my original post to all of you here. If
it wasn't for that ol'
> "FR" mark, I wouldn't have even noticed the problem. Of course, if that
were the case, I probably
> would have just used something like:
>
> (not (zerop (atof (substr *FSM_STR* 3))))
>
> - which is *your* point, if I am understanding you correctly. But the
"FR" mark involved an
> additional string, so I decided to go with an apply test over a list of 1
or 2 strings that I hoped
> would check for either case... I just was stumbling with regards to the
right test.
>
> Oh well, that's how I usually learn. Again, I'd like to thank you and
everyone else who has
> commented on this issue. Though I'm don't try to take sides or provoke an
argument, I'm glad I
> asked.
>
> Best regards,
> David Kozina
>
>

[Anonymous]

It's your self-aggrandizement at the expense of others that everyone clearly
sees, Tony P. If it weren't for the fact that you actually produce sound
code when your not busy attempting to humiliate others, I'm sure we would
have all filtered you out long ago.

Tony Tanzillo wrote in message
news:3876938A.D178EAE4@worldnet.att.net...
> That's it Frank - keep trying to spin this - but don't
> think for a moment that most here can't see right through
> you.
>
>
> Frank Oquendo wrote:
> >
> > Tony never met the challenge, hence the lack of hat eating. And he
accuses
> > me of having an ego. Sheesh.
> >
> > "Mike Leonard" wrote in message
> > news:854v59$g5017@adesknews2.autodesk.com...
> > > What about the hat?
>
> --
> /*********************************************************/
> /* Tony Tanzillo Design Automation Consulting */
> /* Programming & Customization for AutoCAD & Compatibles */
> /* ----------------------------------------------------- */
> /* tony.tanzillo@worldnet.att.net */
> /* http://ourworld.compuserve.com/homepages/tonyt */
> /*********************************************************/

[Anonymous]

Frank - I see you're going to continue to try to make
this look like something other than what it is.

It reminds me of the time you started begging me for
help on CreateWindow() via email, and then started
into a childlish little foot-stomping tirade, when
I refused to help.

You could not back me into a corner, if your very
life depended on it.

Frank Oquendo wrote:
>
> My only mistake was not backing you into a corner sooner.
>

--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/

[Anonymous]

Tony --

On Thu, 06 Jan 2000 17:44:45 -0500, Tony Tanzillo
wrote:

>There are no such thing as "operators" in LISP. The
>apply function cannot be used with special forms
>(functions that don't evaluate one or several of their
>arguments, such as defun, setq, if, and so on).

here's from A2K:

Command: (apply 'if '(1 1 2))
1

So it *does* work with at least 'if. The "cannot apply
special form" error is just a BUG, IMHO, precisely
because of the fact that it *can*:

Command: ((lambda(op)(apply op '(1 1 2))) 'if)
1
Command: ((lambda(op)(op 1 1 2)) if)
; error: cannot apply special form: IF

ALISP never distinguished between its SUBRs, be their
inner workings whatever different, and IF is just
the same ALISP SUBR as any other, or else why (type if)
would've being returning 'SUBR then?

The problem really arises when we're trying to use
functions receiving functional arguments -- the kind
of style LISP encourages us to use -- and suddenly
the old code that have always been working, breaks
because of this stupid new BUG. Or may be it's a
smart BUG, I don't know.

Cheers,

---
Vlad http://vnestr.tripod.com/

[Anonymous]

Frank ---

On Fri, 7 Jan 2000 10:02:10 -0600, "Frank Oquendo"
wrote:

> <...> Apply is not meant to work with functions that
>accept a single argument. I think you can hardly argue that the apply
>function was not INTENDED (I'll use a synonym) for use with commands that
>accept single arguments, since it feeds an entire list of arguments to the
>specified function.

Apply IS INTENDED for use with ANY function, even function that
takes NO arguments, like in (apply fn nil). The situation arises
when using functions that receive other functions as an argument,
and then try calling them. If your function expects to get its
functional argument as a quoted subr, then one way to call it is
via apply. Or maybe you're going to call the EXRXSUBR that can
accept variable number of arguments, and are building its arguments
list at run-time. Here too the way to call it would be via apply,
and your run-time list may well be empty, 1-argument long, or
anything else.

[Anonymous]

If it weren't for the profanity in your response, I would post that thread
in the take5 newsgroup but I'll spare Anne the trouble. Rather than endure
your odious presence any longer, I am going to take a fellow developer's
advice and filter you from my presence. I'd like to say it's been nice
knowing you; but it hasn't.

Tony Tanzillo wrote in message
news:38769D8B.C6270813@worldnet.att.net...
> Frank - I see you're going to continue to try to make
> this look like something other than what it is.
>
> It reminds me of the time you started begging me for
> help on CreateWindow() via email, and then started
> into a childlish little foot-stomping tirade, when
> I refused to help.
>
> You could not back me into a corner, if your very
> life depended on it.
>
> Frank Oquendo wrote:
> >
> > My only mistake was not backing you into a corner sooner.
> >
>
> --
> /*********************************************************/
> /* Tony Tanzillo Design Automation Consulting */
> /* Programming & Customization for AutoCAD & Compatibles */
> /* ----------------------------------------------------- */
> /* tony.tanzillo@worldnet.att.net */
> /* http://ourworld.compuserve.com/homepages/tonyt */
> /*********************************************************/

[Anonymous]

Vlad - Well - that's interesting. I don't believe
it was possible in earlier releases. However, for
most other 'special forms', it holds true that they
can't be applied.

The (apply) function passes the result of evaluating
the elements in the arguments list. If some arguments
are not supposed to be evaluated (as would be the case
with setq, for example) apply has no way to know this.

Vladimir Nesterovsky wrote:
>
> Tony --
>
> On Thu, 06 Jan 2000 17:44:45 -0500, Tony Tanzillo
> wrote:
>
> >There are no such thing as "operators" in LISP. The
> >apply function cannot be used with special forms
> >(functions that don't evaluate one or several of their
> >arguments, such as defun, setq, if, and so on).
>
> here's from A2K:
>
> Command: (apply 'if '(1 1 2))
> 1
>
> So it *does* work with at least 'if. The "cannot apply
> special form" error is just a BUG, IMHO, precisely
> because of the fact that it *can*:
>
> Command: ((lambda(op)(apply op '(1 1 2))) 'if)
> 1
> Command: ((lambda(op)(op 1 1 2)) if)
> ; error: cannot apply special form: IF
>
> ALISP never distinguished between its SUBRs, be their
> inner workings whatever different, and IF is just
> the same ALISP SUBR as any other, or else why (type if)
> would've being returning 'SUBR then?
>
> The problem really arises when we're trying to use
> functions receiving functional arguments -- the kind
> of style LISP encourages us to use -- and suddenly
> the old code that have always been working, breaks
> because of this stupid new BUG. Or may be it's a
> smart BUG, I don't know.
>
> Cheers,
>
> ---
> Vlad http://vnestr.tripod.com/

--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.tanzillo@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/