AutoIt v3.3.9.13 Beta

[UEZ]

Well, but the result without using gfx elements show the same relativ result: 3.3.8.1 is slighty faster than the beta.

When I run the benchmark and have a look to the GPU I can see it is in usage but for sure it have some influences. The idea was to compare same benchmark on same system to see the differences between the autoit versions not to compare computers with each other.

The difference in Text to Bezier Intro benchmark is not so high.

 

Br,

UEZ

Edited July 30, 2013 by UEZ

[jaberwacky]

 

A non-empty string is always True.

Then should't Case 1 execute in this:

Local Const $test2 = '0'

; If a non empty string is always true then why does
; Case 0, '' execute?

Switch $test2
  Case 1
    ConsoleWrite(True & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
  Case 0, ''
    ConsoleWrite(False & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
EndSwitch

[Ascend4nt]

The idea was to compare same benchmark on same system to see the differences between the autoit versions not to compare computers with each other.

 

 

I understand that, but as you can see by my results, with the graphics drawing left on, the script performance is far too dependent on the GPU.

[wraithdu]

Then should't Case 1 execute in this:

No. A non-empty string on its own is True, ie in a ternary expression. But you are comparing values in a Switch, so look at the conversion. You're comparing string '0' to int 1. Doesn't really matter which gets converted to which: '0' <> '1' and 0 <> 1.

Edited July 30, 2013 by wraithdu

[wraithdu]

More fun:

ConsoleWrite((True = "") & @CRLF) ; false
ConsoleWrite(("" = True) & @CRLF) ; false
ConsoleWrite((True = "0") & @CRLF) ; true
ConsoleWrite(("0" = True) & @CRLF) ; true
ConsoleWrite((True = 0) & @CRLF) ; false
ConsoleWrite((0 = True) & @CRLF) ; false

Switch '0'
    Case True
        ConsoleWrite("True" & @CRLF)
    Case False
        ConsoleWrite("False" & @CRLF)
EndSwitch
; prints True

Bottom line, know what you're comparing and make sure it makes sense.

Edited July 30, 2013 by wraithdu

[czardas]

Perhaps this modification may help to clarify things.

Local Const $test2 = '0'

Switch $test2
    Case 1, True
        ConsoleWrite(True & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
    Case 0, '', False
        ConsoleWrite(False & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
EndSwitch

[jaberwacky]

I guess I assumed that 1 would stand in for True.  But I guess that's not, ... 1.

YYYYYYEEEEEEAAAAAAAHHHHHHHHHH!!!!!!!!!!

[wraithdu]

 

Perhaps this modification may help to clarify things.

 

Yikes no. '0' <> 1, but '0' = True. You have conflicting comparisons in the same Case. Have fun debugging that in a script.

[czardas]

Yikes no. '0' <> 1, but '0' = True. You have conflicting comparisons in the same Case. Have fun debugging that in a script.

 

Yikes indeed! The order of comparisons makes all the difference. Scrap the False comparison if it makes you feel better. Hmm maybe not. There's nothing wrong with it (not a conflict) - well only one thing.

It was simply to demonstrate the reason that Case 1 returned False in the given example, and is not how I would write code, but you're right to point it out. Quite funny though.

Edited July 30, 2013 by czardas

[wraithdu]

I guess I assumed that 1 would stand in for True.  But I guess that's not, ... 1.

 

Again, you have to consider the circumstance. Yes, 1 equates True when taken as a boolean expression, ie 'If 1 Then ...', but only because any non-empty string and any non-zero integer are True. But when used in a comparison, 'If 1 = ... Then ...' it behaves differently, the same as True would behave differently.

This is one of the reasons Valik always used to say if a function is documented as returning a non-zero value, then the test should be 'If $return Then ...' to treat it as a boolean expression.

Edited July 30, 2013 by wraithdu

[jaberwacky]

One final thing then I'm out.  Shouldn't neither of these cases execute?  If a non-empty string is always true then why does Case 0, '' execute?  It shouldn't really.  Right?

Local Const $test2 = '0'

Switch $test2
  Case 1
    ConsoleWrite(True & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
  Case 0, ''
    ConsoleWrite(False & @TAB & $test2 & @TAB & VarGetType($test2) & @CRLF)
EndSwitch

Edit: Oh ok, because the string is converted to an integer?  Why?  Seems kinda weird that a switch is not a boolean test.

Edit: I still say these two should then display the same result. But wait, I think they might shoudl after all.  if '0' is an expression that returns true then why doesn't it return true in the switch statement?  Is it to accomadate for the fact that switch deals with ranges?

Switch '0'
  Case 1
    ConsoleWrite(True & @CRLF)
  Case 0, ''
    ConsoleWrite(False & @CRLF)
EndSwitch

ConsoleWrite(('0' ? True : False) & @CRLF)

Final edit: If finally clicked.  Thank you.

Edited July 30, 2013 by jaberwocky6669

[czardas]

If a non-empty string is always true then why does Case 0, '' execute?  It shouldn't really.  Right?

 

Something trancexx told me a while back.

Type coercion is prefered over erroring-out on "wrong" input.

 

The comments of experienced programmers here is very valuable.

Edited July 30, 2013 by czardas

[Ascend4nt]

..and the award for the most edits in 15 minutes goes to... jaberworky6669!! hahaha

[jaberwacky]

Ok, I have edited my last post a hundred times already.  YOu might want to go back and re read it.

[jaberwacky]

..and the award for the most edits in 15 minutes goes to... jaberworky6669!! hahaha

More like 2 minutes actually

[jaberwacky]

Something trancexx told me a while back.

"Type coercion is prefered over erroring-out on "wrong" input."

The comments of experienced programmers here is very valuable.

 

 

I defintiely don't intend to disregard the comments of knowledgeable people.  I'm just so thoroughly confused.

Edit: Well I was but I understand now, I think.

Edited July 30, 2013 by jaberwocky6669

[czardas]

I don't see the confusion. The case statement makes a comparison. I imagine something like this:

ConsoleWrite (("5" == 2 + 3) & @LF)

The string "5" is converted to a number  >It's the other way around the expression 2 + 3 is evaluated and converted to a string for the comparison only.

Edited July 31, 2013 by czardas

[Mat]

Basically, make sure you are always comparing the correct types. If you are getting a string input, and want to compare it to numbers, then call Number() first. It's explicit and very clear what you intend to do. 

 

Trying to figure out how to coerce variants in a way that satisfies all the criteria for normal comparisons (i.e. if a = b and b = c then a = c) is impossible I think.

 

You may be interested in this python testing I did quickly:

>>> bool("1")
True
>>> bool("0")
True
>>> bool("")
False
>>> "1" == True
False
>>> "1" == False
False
>>> "0" == True
False
>>> "0" == False
False
>>> "" == True
False
>>> "" == False
False
>>> "True" if "1" else "False"
'True'
>>> "True" if "0" else "False"
'True'
>>> "True" if "" else "False"
'False'
>>> "1" == 1
False
>>> "0" == 0
False

Edited July 30, 2013 by Mat

[jaberwacky]

Thanks mat, that is enlightening.

[FaridAgl]

I don't see the confusion. The case statement makes a comparison. I imagine something like this:

ConsoleWrite (("5" == 2 + 3) & @LF)

The string "5" is converted to a number for the comparison only.

 

 

The string "5" is converted to a number for the comparison only.

 

Incorrect,

Actually the number 2 + 3 (5) will be converted to a string for the comparison.

That's because of == operator:

==: Tests if two strings are equal. Case sensitive. The left and right values are converted to strings if they are not strings already. This operator should only be used for string comparisons that need to be case sensitive.