@cfr Tnx!

@cfr More useful than the Turing machine reference? Cmon! ;-))))

@SašoŽivanović Look, it is a reference to WFF 'N PROOF, a game which uses Polish notation. So, yes!

@SašoŽivanović I think you may have but I didn't really get the implications. So my default mode of operation is to write what seems sensible and then worry about it if it doesn't work. My version works (that is, the output all looks right), so I'm not going to poke around to see if I need to add anything. I guess I think that number/size comparisons are likely going to be far more frequent than alphabetical ones in this context, so I think a default which uses the latter will mean many mystery bugs.

I appreciate it is TeX's fault....

@cfr Haven't heard about it before ... cool!!!

@cfr Out of default it is then!

@SašoŽivanović I tried to find the website, but either it is down or it is no more. A web search finds quite a bit of information, though. I used it with high school students. Though we had to make our own pieces because I was told my class had no budget. They even made us cut up sticky labels to use on the wooden cubes so they could take them off and reuse the cubes. But when I asked for more cubes (e.g. say I said I needed 60, they'd get me 12 or something), the cubes got smaller & I wrote on them.

I had one 'real' copy, but I didn't want to favour one group over the others, so they all got cubes.

Then I got told off because the kids were so excited when my boss visited unannounced that she considered the classroom too noisy. (I still think this criticism was ridiculous although I admit that my classroom at that moment probably didn't look very traditionally studious.)

But it gets used in universities, too.

@cfr Ahh, anything to suppress good ways of learning, ah? ;-(

@cfr Like.

@SašoŽivanović They really, really liked it ;). And they were absolutely learning logic, even if I didn't tell them that in that way ;).

@SašoŽivanović The only thing remarkable about the philosophers was that we both managed to argue with her before even arriving on campus, whereas the instructional staff for most subjects waited to actually meet her. (Good thing it was only a 3 week summer course.)

@SašoŽivanović No idea why I wrote all that. Sorry.

[Actually, I know why. I get outraged remembering it!]

@cfr I think it's good to let such stuff out!

@SašoŽivanović Well, possibly. But I don't see why other people should suffer! Wff 'n Proof is great though. (That boss's disapproval is probably endorsement enough!)

@SašoŽivanović I replaced cases where I use a single short step in a relative node name but I'm not sure how to replace multiple short steps in a relative node name. I tried the dumb approach of using !parent,parent rather than !uu and then changed them all back when I got errors.

I guess I need {} somewhere.

@cfr In some cases (depending on where precisely you are) you need !{parent,parent} -- just to protect the comma.

@cfr I tested an idea on speeding up .process. The current implementation modifies (TeX's) token registers a lot. This seems to be very slow once they grow. The "array" implementation is much faster, I think it's quadratic vs linear time complexity or some such. Back to the workbench ...

@SašoŽivanović Just because I understood some of it ;).

By the way, the file you sent me included this

% tempcounta=-10000, % don't know, really
            % for nodewalk={parent,sibling,descendants}{
            %   tempcounta/.process={O4w4+n R *2+2 nn>i}
            %     {level}{proof tree toing by}{proof tree toooing}{proof tree rhifo}
            %     {(##1+##2+##3)*##4}
            %     {tempcounta}
            % },

which I don't really know what to make of ;).

@cfr One of my crazier feats: a max. Just forget about it!

@cfr Oh, I almost forgot: there are now pgfless aggregate functions as well. So the above is really obsolete!

@SašoŽivanović OK. Thanks.

@SašoŽivanović Hmmm. I have enough trouble with the non-aggregates. I've been trying to use process things in split here and almost everything I've tried has failed. However, I'm never entirely sure I've got the right number of hashes, which doesn't help.

This works:

        for nodewalk/.wrap pgfmath arg={%
          {%
            draw tree processing order/.style={%
%               filter={tree breadth-first}{proof_tree_proof_line_no()>=####1}%
              filter'={tree breadth-first}{{_O<}{####1}{proof tree proof line no}}%
            }%
          }{}%
        }{tempcountb},

But I still need wrap pgfmath arg and I still need

          for nodewalk/.wrap 2 pgfmath args={%
            {%
              draw tree processing order/.style={%
                filter={tree breadth-first}{(proof_tree_proof_line_no()<=########1)&&(proof_tree_proof_line_no()>########2)}%
%                 filter'={tree breadth-first}{{_w+nO> _O< &}{########1}{################1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
              }%
            }{}%
          }{tempcounta}{tempcountb},

@cfr You certainly need the same number of hashes for both arguments. According to my test, the smaller number of hashes, 8. So:

for nodewalk/.wrap 2 pgfmath args={%
  {%
    draw tree processing order/.style={%
      %filter={tree breadth-first}{(proof_tree_proof_line_no()<=########1)&&(proof_tree_proof_line_no()>########2)}%
      filter'={tree breadth-first}{{_w+nO> _O< &}{########1}{########1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
    }%
  }{}%
}{tempcounta}{tempcountb},

And then, to .processify the remaining .wrap 2 pgfmath args:

for nodewalk/.process={RRw2}{tempcounta}{tempcountb}
  {%
    draw tree processing order/.style={%
      %filter={tree breadth-first}{(proof_tree_proof_line_no()<=########1)&&(proof_tree_proof_line_no()>########2)}%
      filter'={tree breadth-first}{{_w+nO> _O< &}{########1}{########1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
    }%
  }{}%

No change in the number of #. This should be true in general when converting from .wrap pgfmath arg to .process.

@SašoŽivanović This doesn't make sense to me. Isn't the first argument now redundant as the wrap doesn't use it?

@cfr Of course. Let me think again.

Can you see if this is ok --- it compiles and seems alright in the trace, but I don't have the application context ...

filter'={tree breadth-first}{{nO> _O< &}{########1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%

@cfr Starting to test the new implementation of .process. Keep your fingers crossed!

@SašoŽivanović Thanks. I was wondering about that but didn't have time to test it earlier. But it seems to work. Though I don't really understand why it doesn't work to use a wrap, even though this solution shows that to be unnecessary.

@SašoŽivanović Can I take that metaphorically? Makes typing awkward otherwise.

@cfr Deal!

@cfr I have no idea. But you know what? I'll pimp up debugging info on .process to show what's happening during the computation (not only args and result).

@SašoŽivanović This doesn't work, though. That is,

          for nodewalk/.wrap 2 pgfmath args={%
            {%
              draw tree processing order/.style={%
%                 filter'={tree breadth-first}{{_w+nO> _O< &}{########1}{################1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
                filter'={tree breadth-first}{{nO> _O< &}{########1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
              }%
            }{}%
          }{tempcounta}{tempcountb},

works but

          for nodewalk/.process={R2w2}{tempcounta}{tempcountb}{%
            draw tree processing order/.style={%
              %                 filter'={tree breadth-first}{{_w+nO> _O< &}{########1}{################1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
              filter'={tree breadth-first}{{nO> _O< &}{########1+1}{proof tree proof line no}{########2}{proof tree proof line no}}%
            }%
          }{}%

doesn't.

But substituting for .wrap pgfmath arg rather than .wrap pgfmath 2 args works:

        for nodewalk/.process={Rw}{tempcountb}{%
          draw tree processing order/.style={%
            filter'={tree breadth-first}{{_O<}{####1}{proof tree proof line no}}%
          }%
        }{},

'Doesn't work' here means that I get no error but the tree simply doesn't get drawn. I get just the text which is meant to be between the tree parts, but no parts.

@cfr Does this have something to do with hash doubling bug of wrap n pgfmath args? But you're using the rc version, right? So that should be fixed?

@SašoŽivanović I don't know. I'm using the 2.1 rc1 version you sent me. I must be else I couldn't be using the processing versions at all, could I?

@cfr Fair enough.

That is, I don't think I can be inadvertently using an earlier version....

@cfr Can you construct a sort of an MWE, with your newest prooftrees.sty, and send it over email?

@SašoŽivanović I didn't mean it to sound rude.

@cfr You didn't!

@SašoŽivanović It is not exactly minimal, but I have sent you something. Apologies for the non-minimalness. This is based on the code you posted for splitting forest trees but uses proof line numbers instead. It won't work with the published prooftrees as the updated version has been updated to give 'everything' (most things) proof tree proof line no s.

@SašoŽivanović I sounded rude to me when I read it back. I edited it and didn't appreciate the effect until after I'd posted it.

@cfr I'm taking a look. No need to apologize, it's obvious you cannot make a real MWE, we just need to work with the same stuff.

@cfr Btw, the new .process is progressing better than I believed it would!

@SašoŽivanović Excellent! Does that mean I need to remove all the numbers?

@cfr Yes! ;-)

@cfr Sorry: less hassle this way...

@SašoŽivanović Not for w, presumably.

But for O, R etc?

@cfr Nope. You have to add them there, actually, for w1.

@cfr Yes.

@SašoŽivanović It isn't much to change.

Spaces are still OK? No spaces are still OK?

@cfr And & and |take two args only. No more numbers there either.

@cfr Spaces are ok!

@cfr But I still didn't measure speed!

@SašoŽivanović Hmmm....

@cfr It's either that or type &2 always. It's optionality that's gone.

So actually ... please you decide!

I actually have both versions implemented ;-)

@SašoŽivanović Always give the number. That's more consistent with w, for example. And I think it is easier to use. I have e.g. {O! _O< O &3}. I guess I could write {O! _O< & O &} but I think that is harder to read than the version with the & at the end. But maybe that's an effect of WFF 'n Proof ;).

@cfr You've got it!

Otherwise, I want to write {O! _O< O & &} but I'm not sure that's allowed.

@cfr It is, actually.

That's why I even dared to propose a binary only version.

@SašoŽivanović Good. I'd still go for always writing the number for consistency with w but I'd be less bothered if I can still keep consistent notation. I just don't want to have to use something which is partly Polish notation and partly not!

@SašoŽivanović Actually, I don't know. Maybe && is better.

@cfr Consistent, we will be! ;-) My thought was: how many times do you actually use ternary (or more) conjunction?

It is more similar to the pgfmath stuff. So it will be easier for people to switch.

@cfr Binary version?

Oh, I see ... && ;-) aaa, but it doesn't mean the same !!! this might be confusing to people?

@SašoŽivanović Yes. I was originally thinking I'd otherwise need 'some connectives in the middle and some at the end' which I would find counterintuitive.

@SašoŽivanović Oh, that's true. I was thinking of the structural similarity. One && -> one &. I rather like the && for that reason: 2 && -> 2 &. There's potential confusion but anybody who's trying to do this is going to have to figure out the && -> & thing, so.... Oh, I don't know. What do you think?

@SašoŽivanović Probably not often. And requiring a number always will definitely make all the common cases harder to read.

prooftrees has 2 &3 and no |<number>.

@SašoŽivanović It is finding all the ws which is a pain!

@cfr Don't tell me you're fixing all this in advance? ---If so, you're brave. ;-)

@SašoŽivanović Not really. It is easy to change it back. Either by reverting the changes. Or searching for w1 is easy. Anyway, there's not that much of prooftrees.

And something like this will work, I assume. Even if I need numbers or not numbers or something.

@SašoŽivanović If you change your mind, I can just revert 4743.

@cfr I won't. I just manged to get through the old test file. Everything in there works now. Now to test the new stuff (ohh I forgot to tell you: "S"ave and "U"se!) and interaction with if', filter' etc. And then our real examples & docs! Iii!

@SašoŽivanović So binary & and w<number> ?

@SašoŽivanović ??

Is there a do until'?

@cfr Yes I think so.

@cfr Good point. Let it be.

"Sn" copies the last n results from the left into a special place (as Knuth would say:), comulatively. "U" then spits them out in the arg space (on the right). This way you can reuse the arguments as you wanted! ;-)

@SašoŽivanović I have no idea what 'comulatively' means, I'm afraid, but I'm sure it'll be good.

@cfr Like, you save one arg, and later another, and later yet another, and then dump them all together.

@SašoŽivanović Cumulatively? OK. The typo threw me. Sorry.

@SašoŽivanović .min dimexpr is faster than .min ?

@cfr Should be, but let's see ...

@cfr Sorry, fast typing, Slovene version ;-)

Still some errors. Think I'll call it a day.

@SašoŽivanović ;)

@SašoŽivanović No problem. I just thought it must be some technical term I didn't know.