change to logical operators

[ki77bot]

I haven't updated my daily build in a while (i've been using 8891), but now that I did, I noticed that something changed with the way logical operators are being processed.

this used to work:

	if (my_name() == "char1" || my_name() == "char2" && user_confirm("Are you sure?")){
	func1();	
	func2();
	}

So, if either char1 OR char2 used the script AND user-confirmed the functions would execute. But with the updates the functions would execute for char1 WITHOUT user-confirmation, but would still work OK for char2.

Yeah, I noticed there were some changes done with those operators, but i'm still not sure, how it will work the way it did before. Could someone help me out?

Cheers,
ki77bot

 

[Winterbay]

Without testing you could try:

if ( (my_name() == "char1" || my_name() == "char2") && user_confirm("Are you sure?")){
	func1();	
	func2();
	}

i.e. put the or-statement within a separate parenthesis.

 

[lostcalpolydude]

	if (my_name() == "char1" || ( my_name() == "char2" && user_confirm("Are you sure?") ) ){
	func1();	
	func2();
	}

Adding parentheses is the simplest way to apply operators in the order you want.

Edit: Winterbay beat me to it, and I misunderstood your question, but you can see how moving parentheses around gives you control over the logic rather than leaving it to the interpreter.

 

[Winterbay]

	if (my_name() == "char1" || ( my_name() == "char2" && user_confirm("Are you sure?") ) ){
	func1();	
	func2();
	}

Adding parentheses is the simplest way to apply operators in the order you want.

Wouldn't that make it execute if you are char1 OR if you are char2 AND approve? (i.e. no confirmation for char1)?

 

[ki77bot]

Sure, parentheses...could have thought of that myself.

Thanks a lot, guys, will check that tomorrow.

 

[lostcalpolydude]

Wouldn't that make it execute if you are char1 OR if you are char2 AND approve? (i.e. no confirmation for char1)?

My edit was a bit slow.

 

[Veracity]

When I added the arithmetic bitwise operators, I modified the operator precedence routine to make room for them. Apparently I adjusted/tweaked/changed && and || as well. ASH now has Java Operator Precedence, with a few additions and omissions.

14: (reserved for postfix ++ and --)
13: ! ~ contains remove (reserved for prefix ++ and --)
12: ** (and ^ until I make it into xor)
11: * / %
10: + -
9: << >> >>>
8: < > <= >=
7: == !=
6: &
5: (reserved for ^ as xor)
4: |
3: &&
2: ||
1: (reserved for ?: (ternary conditional))
0: (reserved for assignments)

This should be on the Wiki.

 

[StDoodle]

This should be on the Wiki.

It's a bit beyond me to fully understand what exactly some of it means, but here we go.

 

[Veracity]

Thank you! A few comments:

- The "few exceptions" are operators we have that ASH does not have, or vice versa. In all cases, when both Java and ASH have an operator, it has the same relative precedence.
- We don't have a ternary conditional yet., So, that should probably say (reserved for ternary conditional ?: ) (and I only have a space between the : and the ) there to make this forum not turn it into a smiley face.)

The comment on that page that "We also need to understand operator precedence. Statements inside a () pair are always evaluated first, then from right to left." is not quite right, since it doesn't explain "operator precedence". That sentence is correct if all of the operators have the same precedence. But, basically, operators with higher precedence hold their operands tighter and get evaluated before operators with lower precedence.

The issue in this thread had 2 operators - && and || - and three operands - call them a, b, and c

a || b && c

is the equivalent to

a || ( b && c )

because && has higher precedence than ||

a * b + c * d **e

is the equivalent of

(a * b) + (c * (d ** e))

because ** is higher than * is higher than +

 

[StDoodle]

Fixes made; I forgot I'd had that previous bit of precedence info in there (I think I just copy-pasta'd it from elsewhere, either here or an existing wiki page, can't recall).

What is there should be technically correct now, including the notes in the examples, though it may now be worthwhile to add another example or two to show what happens with equal precedence and such. I'll keep it in mind for later. Or, if you prefer, you can add any favorite examples. That's the beauty of using a wiki! (Of course the down side is that they have their own strange syntax rules...)

 

[Theraze]

Looking forwards to the eventual ternary conditionals. I keep attempting to use them every now and then to add efficiency, and realize (when it fails to run) that, "Oh yeah... can't use that here." Apparently, I need to rethink and add, "Yet." to that statement.

 

[Winterbay]

/me looks up ternary conditionals and goes "ewww"...
That looks very obfuscating

 

[StDoodle]

I find 'em very useful, or at least used to when I was doing lots of AutoLisp (don't ask).

 

[Theraze]

Winterbay, it does simplify things significantly, or can... as it means you can put an if/else statement anywhere you'd need it, including in the middle of a line. For example, if you're doing a check for moxie primestat, you could do it inside the print line, like this:

ashq print("Your primestat suggests using a " + (my_primestat() == $stat[Moxie] ? "ranged" : "melee") + " weapon.");

Currently, if I wanted to do that, I'd need to do one of these two following instead:

ashq string weapontype; if (my_primestat() == $stat[Moxie]) weapontype = "ranged"; else weapontype = "melee"; print("Your primestat suggests using a " + weapontype + " weapon.");

ashq if (my_primestat() == $stat[Moxie]) print("Your primestat suggests using a ranged weapon."); else print("Your primestat suggests using a melee weapon.");

Results of the 3 follow, with the 2nd and 3rd succeeding as expected, and the 1st failing.

> ashq string weapontype; if (my_primestat() == $stat[Moxie]) weapontype = "ranged"; else weapontype = "melee"; print("Your primestat suggests using a " + weapontype + " weapon.");

Your primestat suggests using a melee weapon.

> ashq if (my_primestat() == $stat[Moxie]) print("Your primestat suggests using a ranged weapon."); else print("Your primestat suggests using a melee weapon.");

Your primestat suggests using a melee weapon.

> ashq print("Your primestat suggests using a " + (my_primestat() == $stat[Moxie] ? "ranged" : "melee") + " weapon.");

Expected ), found ? ()

 

[Winterbay]

Yes, I don't doubt that they can be useful. I'm just saying that to me they obfuscate the code

 

[Theraze]

Definitely if you don't notice them.

 

[Theraze]

Whee!

> ashq print("Your primestat suggests using a " + (my_primestat() == $stat[Moxie] ? "ranged" : "melee") + " weapon.");

Your primestat suggests using a melee weapon.

Also fun, just converted:

mymax => ashq string maxstring; if (my_primestat() == $stat[Moxie]) maxstring = "2 moxie, ranged damage, .1 initiative, -melee, %%"; else maxstring = "2 muscle, weapon damage, .1 moxie, melee, %%"; CLI_Execute("maximize 4 item, 3 meat, " + maxstring);

to this:

mymax => ashq CLI_Execute("maximize 4 item, 3 meat, " + (my_primestat() == $stat[Moxie] ? "2 moxie, ranged damage, .1 initiative, -melee, " : "2 muscle, weapon damage, .1 moxie, melee, ") + "%%")

 

[zarqon]

WHEE!!! indeed. This is fabulous. I remember asking for this long ago, but didn't actually think it would ever make it high enough on the list to implement.

This is really like Christmas and my birthday. And Flag Day. All rolled into one.

 

[Winterbay]

Aaaand, I've now used that for the first time in my life (deciding which familiar equpiment to use in the modifier maximizer depending on availability or not of the hookah).
As I said I can see how it can be useful but it still looks obfuscated