Jump to content
Sign in to follow this  
Jon

AutoIt v3.3.9.13 Beta

Recommended Posts

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 by UEZ

Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites

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 by wraithdu

Share this post


Link to post
Share on other sites

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 by wraithdu

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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. :think:

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 by czardas

Share this post


Link to post
Share on other sites

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 by wraithdu

Share this post


Link to post
Share on other sites

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 by jaberwocky6669

Share this post


Link to post
Share on other sites

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 by czardas

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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 by jaberwocky6669

Share this post


Link to post
Share on other sites

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 by czardas

Share this post


Link to post
Share on other sites

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 by Mat

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...