Topic: Null vs empty?

[ronjonp]

Looks good to me? You gave it a 1 and it said NO not all empty strings?

According to you guys, it is supposed to fail.

OK .. maybe I'm missing something. My argument is that data that is passed should be checked before using this function as to not be 'superfluous' as Lee stated. My benchmark shows that there is definitely a performance hit if you don't check the data prior.

[ronjonp]

And the numbers are in

    (TEST-STR-3 L)...........1344 / 2.86 <fastest>
    (TEST-STR-2 L)...........1703 / 2.26
    (TEST-STR L).............1735 / 2.22
    (TEST-STR-4 L)...........3172 / 1.21
    (_ALLEMPTYSTRINGS L).....3844 / 1.00 <slowest>

Doh, recursion is slow no matter what :geek:

BTW I think if you externally define '_chk' (outside of _allemptystrings) it should perform drastically faster, since it wont redefine the subfoo each time.

Pretty similar:

_$


("" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "")
TEST-STR
TEST-STR-2
TEST-STR-3
TEST-STR-4
_CHK
_ALLEMPTYSTRINGS Benchmarking ...................Elapsed milliseconds / relative speed for 65536 iteration(s):


    (TEST-STR-3 L)...........1360 / 2.81 <fastest>
    (TEST-STR-2 L)...........1719 / 2.23
    (TEST-STR L).............1750 / 2.19
    (TEST-STR-4 L)...........3203 / 1.20
    (_ALLEMPTYSTRINGS L).....3828 / 1.00 <slowest>

[MP]

[Mark]

[JohnK]

OK .. maybe I'm missing something. My argument is that data that is passed should be checked before using this function as to not be 'superfluous' as Lee stated. My benchmark shows that there is definitely a performance hit if you don't check the data prior.

The scope keeps changing; you guys talk among'st yourselves and come to a consensus. ...I can't really keep up but as far as I can keep straight, = should work just fine for you guys.

Code: [Select]

(= "" "" "")
I'm out of here.

[ronjonp]

OK .. maybe I'm missing something. My argument is that data that is passed should be checked before using this function as to not be 'superfluous' as Lee stated. My benchmark shows that there is definitely a performance hit if you don't check the data prior.

The scope keeps changing; you guys talk among'st yourselves and come to a consensus. ...I can't really keep up but as far as I can keep straight, = should work just fine for you guys.

Code: [Select]

(= "" "" "")
I'm out of here.

Sure .. but the data is in a list .. and I'm outta here too .

[JohnK]

Ah, well that would be a simple fix but after some "huge contemplation" *eye-roll* EQ will not fail so I quickly penned two alternates (#6 & #7) which should fail ungracefully (per spec).

Code - Auto/Visual Lisp: [Select]

1. (defun test-str-5 ( aList ) (apply '= aList))
2. (defun test-str-6 ( aList )
3.   (zerop (apply '+ (mapcar '(lambda (x) (ascii x)) aList))) )
4. (defun test-str-7 ( aList ) (foreach x aList (zerop (ascii x))) )
5.  

[Lee Mac]

It is the same as:

Code - C++: [Select]

1. if (n <= 0) {
2.         printf("The number should be positive.\n");
3. } else {
4.         for (int i = 1; i <= n; ++i) {

Are [you] honestly telling me this is not "correct". -i.e. in this code the program exits (falls out of the IF statement) if the number isnt postive; are [you] telling me the programmer should have just "preformed math" or "entered a loop" or "launched N rockets" on/with a negative number?

Why are you not checking that 'n' is a numerical data type first?

[MP]

Because trees.

[Lee Mac]

You are mearly[sic] accepting data (from a source you may not have control of--user or text file for example)

On this point, could you provide an AutoLISP example in which a user or file can supply a function with data of an unknown data type? Perhaps I'm overlooking something obvious, but reading a file in AutoLISP can only ever return strings, and obtaining input from a user is restricted by the various getXXX/entsel/ssget/grread functions which return known data types.

[JohnK]

> n is numerical
Because C based languages work differently. I do that in my argument list (I specify that I only accept INT values for example). -e.g. "int FOO ( int PARAMETER )", the compiler helps enforce stuff like this. And this is where Owens comment about API stuff comes into play (we have stuff like destructors).

> sterile list
So then back up.
Given: (setq aList '("" ""))
Why
(= "" (apply 'strcat aList))
and not just
(apply '= aList)
or being more specific (and compairing the list to a "key")
(apply '= (cons "" aList))
?

-i.e. If this list is sterile then why concatenate for comparison? And, if it's not sterile (the assumption I was under caused by multiple statements so far and/like: the OP said they were in the process of iterating this list(s)) then why are you passing it through "extra stuff" without "type checking" (and how is a hard stop failure with concatenate--and unverified data--better then failing, with a return, via a generic comparison)?

[JohnK]

Because trees.

Mean.

[kdub_nz]

That's the issue with travelling ... I missed all the exciting discussion

[JohnK]

Exciting? More like one sided, vague, confusing, and mean from this perspective.

Did you have a good trip?

[Marc'Antonio Alessi]

Another (slower):

Code: [Select]

(defun test-str-9 (l) (eq (1+ (strlen (vl-string-trim "()" (vl-princ-to-string l)))) (length l)))