truth value of a variable containing an array is True, False, both, neither?

[SadBunny]

Hi there,

In another thread Nitekram had a function returning either a populated array or False. I was about to suggest you could still use that as a boolean, but I'm happy I tested that assumption just to be sure.

dim $a[1];
$a[0]="hello world";

if $a <> False then
    ConsoleWrite("it is something other than False" & @crlf)
EndIf

if $a then
    ConsoleWrite("it is true" & @crlf)
Else
    ConsoleWrite("it is not true" & @crlf)
EndIf

if not $a then
    ConsoleWrite("it is false" & @crlf)
Else
    ConsoleWrite("it is not false" & @crlf)
EndIf

Result:

it is something other than False
it is not true
it is false

Argh! What is the boolean truth value of a variable containing a perfectly fine array? Seemingly it's a meaningless question in AutoIt... Really??

Edited February 19, 2015 by SadBunny

[Spider001]

https://www.autoitscript.com/autoit3/docs/functions/IsArray.htm

[bogQ]

Argh! What is the boolean truth value of a variable containing a perfectly fine array?

i think your missing the point.

a variable doesnt containing a perfectly fine array

a array containing a perfectly fine array elements

so i googled this for you that i think it'll be satisfying for you

http://www.answers.com/Q/What_is_the_difference_between_an_array_and_variable

especialy

"it is true when the elements of the array are treated as individual entities"

and

"It is not generally right to distinguish between a variable and an array. You'd be comparing apples with pears."

Edited February 19, 2015 by bogQ

[SadBunny]

https://www.autoitscript.com/autoit3/docs/functions/IsArray.htm

 

I understand that I can check whether a variable points to an array with IsArray(), but that's not the point. I myself would consider a situation where you use a variable both as a boolean and a pointer to an array bad code. I would not run into this problem in my work I just think it's weird that AutoIt works this way.

 

i think your missing the point.

a variable doesnt containing a perfectly fine array

a array containing a perfectly fine array elements

 

Thanks for the link, but I think you're missing the point I did and would not confuse a variable with an array. For the purposes of this question, a variable is a handle to a certain data structure. Whether that be a boolean or an integer or an array (itself a collection of handles to yet other data structures) or an Audi sports car is not important. If I put it behind an if, I expect the engine to either draw an understandable boolean from it (meaning based on an understandable algorithm), or error out with "invalid truth expression" or whatever. Take awk, mine gives a clear error if I try to use a variable "holding" an array as the truth expression:

$ awk 'BEGIN {arr[1]=1; if (arr){print "yes";}}'
awk: cmd. line:1: fatal: attempt to use array `arr' in a scalar context

Or perl, which considers an empty array false and a non-empty array true, which also makes a lot of sence IMO:

$ perl -e "@arr = (); if (@arr) {print 'yes'}"

$ perl -e "@arr = (0,1,2); if (@arr) {print 'yes'}"
yes

AutoIt seems weird in this regard.

Edited February 19, 2015 by SadBunny

[czardas]

It's a bit confusing. If I create an array with one False value, it still exists. I would return True (not False because the array contains information). What if an array has zero elements or a mixture of True and False values?

Edited February 19, 2015 by czardas

[Melba23]

Hi,

It is well known that because of its lack of typing AutoIt can produce some apparently strange results when comparing variables - think of the number of times we have had to explain about the problems of comparing stings and numeric values. It seems to me that we have another case in point here - trying to compare arrays with Booleans is just not a sensible thing to do. The Help file does say for True/False:

 

These keywords should not be used in expressions as AutoIt will not detect this 'misuse' and the results will be unpredictable

which seems to sum up the results obtained here quite nicely.

It seems to me that the entire matter could have been avoided had the function to which the OP referred used a more sensible error return value than False allowing for a simple and logical comparison to detect the failure case - for instance returning an empty string, or indeed setting the @error macro which is designed for this very case.

M23

[SadBunny]

It's a bit confusing. If I create an array with one False value, it still exists. I would return True (not False because the array contains information). What if an array has zero elements or a mixture of True and False values?

 

If I had to choose, I'd agree with the Awk approach, and would prefer a language to throw some sort of type safety error, even a language without much of a type safety idea (which Awk also doesn't have). Perl is stupid anyway (apart from its stellar Regex support), but at least it's consistently stupid  Lacking a null or a strict boolean type in the language, I could also live with considering any variable pointing to an empty string ("") or integer 0 a False, and anything else (including an array, even an empty one) as True. But defending that still leads to arguments that feel like deductive contradictions, so it would still itch

 

Hi,

It is well known that because of its lack of typing AutoIt can produce some apparently strange results when comparing variables - think of the number of times we have had to explain about the problems of comparing stings and numeric values. It seems to me that we have another case in point here - trying to compare arrays with Booleans is just not a sensible thing to do. The Help file does say for True/False:

 

These keywords should not be used in expressions as AutoIt will not detect this 'misuse' and the results will be unpredictable

which seems to sum up the results obtained here quite nicely.

It seems to me that the entire matter could have been avoided had the function to which the OP referred used a more sensible error return value than False allowing for a simple and logical comparison to detect the failure case - for instance returning an empty string, or indeed setting the @error macro which is designed for this very case.

M23

 

 

All very True of course  (/edit: then again... what does True even mean given the subject matter of this thread?   ) And I understood that, and there are multiple ways to improve that function I referred to. Yours is fancy, my own quite oneliner-y suggestion in that thread probably came from 10 hours of awk'ing radiation at the black hole that was my work today. Still I think it's kind of strange that you can have something of which you are allowed to ask the truth value, but still get a boolean paradox. Any choice for a default algorithm in this case is better than a paradox, I would say?

Not that I am complaining here, mind you... I never ran into this situation, and I never would have if I wasn't inspired by someone else's code to deliberately test it  I'm just somewhat surprised it's a feature instead of a bug.

Edited February 19, 2015 by SadBunny

[czardas]

I don't understand this statement:

These keywords should not be used in expressions as AutoIt will not detect this 'misuse' and the results will be unpredictable.

 

Is the following not an expression?

Not ($bBoolean = True)
 

Edited February 19, 2015 by czardas

[Melba23]

czardas,

I read the statement to mean that you should not mix booleans with other datatypes in the same expression - so what you have there is perfectly valid as it is all boolean.

M23

[czardas]

Melba23: What you said there is more comprehensive than the help file. Perhaps stating that as a caution would be okay, since a certain amount of internal casting does take place when performing a comparison using the equals operator.

[Melba23]

czardas,

 

What you said there is more comprehensive than the help file

I should have made clear that the comment is a purely personal opinion. As I have no access to the internal AutoIt code, I can only base my comments on my own experiences of coding in AutoIt.

M23