Jump to content

Why is zero not a valid parameter value for a function?


Recommended Posts

Why doesn't this work as I expect it to?

Test ()   ;This should produce "Parameter Not Provided"
Test (0) ;This should produce "Parameter is 0"  - BUT it DOESN'T
Test (1) ;This should produce "Parameter is 1"


Func Test ( $foo = "bar" )
    If $foo = "bar" Then
        MsgBox ( "", "", "Parameter Not Provided" )
    Else
        MsgBox ( "", "", "Parameter is " & $foo )
    EndIf
EndFunc

Is this a bug? Mathematically, zero is certainly a valid number. Linguistically, it is a valid symbol. Logically, it is a valid parameter!

Param = 0 should NOT be functionally equal to Param = "" but it seems to be the case.

Is there a reason for this?

What say you folks that know better than me... bug?

Cheers.

LD

Link to comment
Share on other sites

Hey, right on thanks.

That worked. Now, if only I understood WHY it worked :)

I'll be happy to spend some time searching the help files, but I don't know how to search for "==" :) If you could tell me, It'd be appreciated!

Thanks again.

LD

Link to comment
Share on other sites

I found the entry in the help file... so now I wonder if it is a small bug. Because according to that, they are functionally the same when used with non-strings.

= Tests if two values are equal (case insensitive if used with strings). e.g. If $var= 5 Then (true if $var equals 5)

== Tests if two values are equal (case sensitive if used with strings)

I'm going to submit it as a bug. Either = needs to be changed, or more simply the help file should be updated.

LD

Edited by LondonNDIB
Link to comment
Share on other sites

I found the entry in the help file... so now I wonder if it is a small bug. Because according to that, they are functionally the same when used with non-strings.

I'm going to submit it as a bug. Either = needs to be changed, or more simply the help file should be updated.

LD

It's not a bug. Including a numeric value make it a mathematic compare. Any non-numeric string is equivalent to 0 for mathematic compares.

-1 < "abc"

0 = "abc"

"abc" < 1

AutoIt does do some conversion of purely numeric strings for you:

-1 > "-2"

-1 < "0"

Don't routinely mix numeric and string operands in compare operations. If you wish to code for the possibility of numeric or string parameters, test them with IsNum() or IsString() and then handle accordingly.

:)

Edited by PsaltyDS
Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law
Link to comment
Share on other sites

So do i have to change all the = signs in my script that compare thigns to ==?

Only for Case Sensitive string compares.

It doesn't mean anything different from '=' for mathematic compares, and you should not be comparing numbers and strings (It can be done, but you have to be very aware of the rules, better to avoid it).

:)

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law
Link to comment
Share on other sites

Why doesn't this work as I expect it to?

Is this a bug? Mathematically, zero is certainly a valid number. Linguistically, it is a valid symbol. Logically, it is a valid parameter!

Param = 0 should NOT be functionally equal to Param = "" but it seems to be the case.

Is there a reason for this?

What say you folks that know better than me... bug?

Cheers.

LD

In some other languages, you would get a mistype error. Comparing an Integer directly to a string is illogical.

If you do this...

If 123 == "123" Then MsgBox(0, 'Same characters', 'ok')

== compares it as a case sensitive string (character by character). You may say that is handy to use == by default then. Answer is no, as you lose the identification of the value being an integer. So, if you are not checking the data type of the variable 1st, then you are possibly creating illogical code. This is why we have the type conversion functions such as Int() or the type checking functions such as IsInt(). Also StringIs...() functions can be used on strings to valid the type of characters with the string.

:)

Link to comment
Share on other sites

Some of you are thinking too much like programmers in other languages.

In AutoIT, as explained in the Help File, a "variable" can be of any type at any time. There's nothing illogical about comparing a number to a string.

0 does not = "hello" in any case, shape or form. 1* "hello" does equal zero.

I did report it as a bug, and there has been an acknowlegement that either the functionality has to change (unlikely) or the help file needs to be updated (more likely) because as written, = and == are the same. But they clearly are not in practice.

0 = "hello" is true

0 == "hello" is false

According to how the help file is written right now, they should both be true.

LD

Link to comment
Share on other sites

...According to how the help file is written right now, they should both be true...

For the sake of those not following both threads on this topic - here is the link to the bug report:

http://www.autoitscript.com/forum/index.ph...showtopic=47388

Keep in mind that it was reported as a bug in the code or a "bug" in the help file. (A very good way to report it in my mind, not dogmatic or arrogant by any means.) I agree with the OP that the summary table named Language Reference - Operators seems to indicate that = and == are the same. However, I had the advantage of knowing that the help file had more to say on the topic, I just had to find it. [see Language Reference - Datatypes. Perhaps a link to the Language Reference - Datatypes page in the Language Reference - Operators table cell for == would help some people.]

To all of those in the forum that have had formal programming training - thanks for putting up with those of us who have not (and probably never will). I know that it must be frustrating at times. And remember, just because we seem to "understand it" today, does not mean that we will "understand" the same issue tomorrow. We don't do this sort of thing often enough for it to become ingrained.

-MSP-

[size="1"][font="Arial"].[u].[/u][/font][/size]

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...