@JouleV Yes, must be getting old. Gave +1. (To be honest I didn't intend to answer this question. If you jam up the beamer slide like this, the audience may not appreciate it. Of course, that's the OP's problem. ;-)
@JouleV Yes, first try to understand things better and then focus on the relevant information. No one will grasp the information contained in such a large mind map in a talk.
@JouleV No, more seriously it is one of these huge conferences which is not really made to exchange information. Plus I am not very good at Alpine skiing. I prefer the Aspen summer workshops.
@UlrikeFischer Not quite. (What do you mathematicians learn in your studies?)
@CarLaTeX If we say about 'last summer', in Hanoi it reached 45 normally and even > 50 in peak hours. But I usually stay in the north during summer, where the weather is more convenient.
@CarLaTeX Well, I will have to familiarize myself a bit if I go to the Alps some day
@JosephWright it is expandable, currently only stuff like \token_if_eq_meaning_p:NN || or \token_if_eq_meaning_p:NN && would fail. Parenthesis aren't handled at all, they are left for \numexpr to evaluate. Currently trying to implement a reasonable NOT (which unfortunately needs to handle parenthesis).
@Skillmon yes sure as I say you'd need to re-arrange a bit going from || and && to + and * but using the arithmetic over F_2 is a well understood model of booleans but I'm not sure how you are using >
@DavidCarlisle yep, you'd have to normalize #1 in NOT, but I deleted the code anyway, the approach wouldn't be robust with parenthesis even if you'd normalize #1 for NOT.
@Skillmon but numexpr might be an interesting way to implement boolean logic if you use + as xor then parens do the right thing and all you need to test is the final number being odd....
@DavidCarlisle so you'd have to use \ifnum\numexpr#1>0 0\else1\fi for NOT instead (better than normalizing implementation wise).
@DavidCarlisle not sure why you still want to go for the \ifodd approach though, I like my >0 test with OR instead of XOR.
@DavidCarlisle still handling NOT correctly would be a mess, since it'd need to grab arguments in parenthesis and hence would be not robust against stuff like \token_if_eq_meaning_p:NN with a parenthesis as one of the tokens.
@Skillmon There's no way of dealing with ( in \bool_if:nTF and keeping expandablity and lazy evaluation: something has to give somewhere. I'd look to \bool_lazy_or:nnTF or similar if you want to re-code things
@Skillmon Like I said, send the code to LaTeX-L or the team list: it's quite possible it would work well (the existing approach likely goes back to before e-TeX was required, which may make a difference)
