[variable] wiki clarification

[Pentarctagon]

Reading the wiki on [variable], there are two things I'm not completely clear on:

1) equals and not_equals are specified as being string comparisons, however greater_than/less_than/greater_than_equal_to/less_than_equal_to do not specify a type. Am I correct in assuming they are only intended to function with numeric values? They do not give the correct result when used with string values, in any case.

2) equals and not_equals are stated as being better performing compared to their numeric and boolean counterparts. Is this performance difference at all noticeable? It just seems odd to have this called out specifically here, especially since it would seem to be a micro-optimization at best.

[gfgtdf]

Reading the wiki on [variable], there are two things I'm not completely clear on:

1) equals and not_equals are specified as being string comparisons, however greater_than/less_than/greater_than_equal_to/less_than_equal_to do not specify a type. Am I correct in assuming they are only intended to function with numeric values? They do not give the correct result when used with string values, in any case.

Yes the comparision operator onyl apply to numerical values.

2) equals and not_equals are stated as being better performing compared to their numeric and boolean counterparts. Is this performance difference at all noticeable? It just seems odd to have this called out specifically here, especially since it would seem to be a micro-optimization at best.

Not sure but i doubt that. Actuall I'm not even sure that it is acually faster since the wml object stores integers already as integer internally, not as strings. If you want performance use lua i'd say.

[Iris]

Regarding point 2, I’d bet my posterior bits that the page in question was written well before WML value type coercion was implemented (i.e. before version 1.9.0, released in August 2010), so back then it was most likely 100% positively faster to use string-based comparisons since all WML values were internally stored as strings. Nowadays it would certainly be slower. Performance issues aside, if someone’s handing you a screwdriver (integer/boolean comparisons) and it seems to be the most elegant tool for the job, then you don’t need the hammer (string comparisons).

Nevertheless, if you’re working with a special case where micro-optimizations make a significant contribution to your code’s performance then you should consider either using Lua or not using Wesnoth.

[Pentarctagon]

Yeah, I'm not asking #2 because it matters to anything I'm doing, I just thought it was an odd thing to include. If it's actually wrong though, I'll remove it from the wiki.

[doofus-01]

1) equals and not_equals are specified as being string comparisons, however greater_than/less_than/greater_than_equal_to/less_than_equal_to do not specify a type. Am I correct in assuming they are only intended to function with numeric values? They do not give the correct result when used with string values, in any case.

I'm curious what that comparison would even mean for strings. String length?

[Iris]

If you were programming in a general-purpose language like C++ or C that would be the lexicographical order function result. For example, “abc” < “abcdef” could yield true, “ABC” >= “ABC” would always yield true*, and “01234” < “#####” could yield false, depending on the exact locale and collation method used.

* As long as you don’t bring alternate Unicode representations and zero-width characters into the equation, anyway.

[Pentarctagon]

Performance issues aside, if someone’s handing you a screwdriver (integer/boolean comparisons) and it seems to be the most elegant tool for the job, then you don’t need the hammer (string comparisons).

Also due to a bit of a quirk with boolean/string types, this comparison just plain doesn't work:

Code: Select all

[event]
  name="start"
  
  {VARIABLE test "true"}
  
  [if]
    [variable]
      name="test"
      equals="true"
    [/variable]
    [then]
      [message]
        message="hi"
      [/message]
    [/then]
  [/if]
  
  [message]
    message="$test"
  [/message]
  
[/event]

The "hi" message doesn't get displayed at all, and the "$test" message displays the text "yes".

[Ravana]

I have used this when I explicitly want strings

Code: Select all

#define ORM_BOOLEAN_FORMAT VAR
	[if]
		[variable]
			name={VAR}
			boolean_equals=true
		[/variable]
		[then]
			{VARIABLE {VAR} ORM_bool_true}
		[/then]
		[else]
			{VARIABLE {VAR} ORM_bool_false}
		[/else]
	[/if]
#enddef

[gfgtdf]

The "hi" message doesn't get displayed at all, and the "$test" message displays the text "yes".

Yes that's becasue in 1.13 the [set_variable] implementation was moved to lua,a dn when a wml table is moves to lua both "true" and "yes" get mapped to the lua boolean value true whihc gets mapped to "yes" when its converted back to wml.

I have used this when I explicitly want strings

Just wondering: when would you actuall want want such strings instead of bools ?

[Ravana]

I wanted to use [switch], which is implemented so that it needs string.

[Pentarctagon]

The "hi" message doesn't get displayed at all, and the "$test" message displays the text "yes".

Yes that's becasue in 1.13 the [set_variable] implementation was moved to lua,a dn when a wml table is moves to lua both "true" and "yes" get mapped to the lua boolean value true whihc gets mapped to "yes" when its converted back to wml.

I figured it was something like that. I just brought it up since it's pretty counter-intuitive just from looking at it, and did actually break something in my add-on.