@UlrikeFischer ooh Bären

@UlrikeFischer No need to be concerned, it is totally a bärable situation!

\pgfmathsetlengthmacro\yShift{%
\n==0 ? 0pt : (
\deckarray[\no]==\choosearray[0] || \deckarray[\no]==\choosearray[1]
 || \deckarray[\no]==\choosearray[2] || \deckarray[\no]==\choosearray[3]
 || \deckarray[\no]==\choosearray[4]  || \deckarray[\no]==\choosearray[5]
? -0.5*\cardheight : (
\deckarray[\no]==\choosearray[6] || \deckarray[\no]==\choosearray[7]
  || \deckarray[\no]==\choosearray[8] || \deckarray[\no]==\choosearray[9]
  || \deckarray[\no]==\choosearray[10]  || \deckarray[\no]==\choosearray[11]

The \yShift is shown here:

@PauloCereda ooh, German.

@cis What does \choosearray[11] mean? Maybe you can move the test somewhere before this code so that you just test for single Boolean here?

@JasperHabicht most likely a PGF array/list accessor.

Or maybe write a function that outputs -1 for \choosearray[0] to [5] and 1 for \chooserray[6] to [11]?

@Skillmon Yeah, I would need to look at the code to make more sense of this, I think

@cis what do you mean by runtime problem, if you get an error what error?

@DavidCarlisle I guess he means performance, not runtime.

@JasperHabicht well it's inside a \pgfmathparse and that would be standard PGF syntax...

@Skillmon same as last time then, remove the pgf accessors by L3 ones?

@Skillmon But it compares against these values in the array. Maybe it is easier to do the comparison in another way … my question was, what do these values look like

Booleans, integers …

Maybe you can calculate some kind of hash and compare :)

@cis well at the very least you are evaluating \deckarray[\no] 12 times so that could be 12 times faster

@DavidCarlisle Mmmhh.... I have no idea to implement an or-method better.

can't you \edef\foo{\deckarray[\no]} then use \foo ?

@DavidCarlisle Sure, why not. Mmmh, I will test.

@cis but depending on how pgf [] is implemented it looks a slow way of determining the shift as each \choosearray[] probably has to iterate over the array to access the nth item. You could make a single iteration over the array and just set the shift if you see \deckarray[\no]

@DavidCarlisle Mmmhhh, seems to be a bit faster with that:

%% Choosed DeckA and DeckB ===================
\pgfmathtruncatemacro\DA{\deckarray[\no]}
%
\pgfmathtruncatemacro\I{\choosearray[0]}
\pgfmathtruncatemacro\II{\choosearray[1]}
\pgfmathtruncatemacro\III{\choosearray[2]}
\pgfmathtruncatemacro\IV{\choosearray[3]}
\pgfmathtruncatemacro\V{\choosearray[4]}
\pgfmathtruncatemacro\VI{\choosearray[5]}
\pgfmathtruncatemacro\VII{\choosearray[6]}
\pgfmathtruncatemacro\VIII{\choosearray[7]}
\pgfmathtruncatemacro\IX{\choosearray[8]}
\pgfmathtruncatemacro\X{\choosearray[9]}

yes but still probably to evaluate \pgfmathtruncatemacro\XII{\choosearray[11]} you have iterate through the full array to find the 11th element so that means you have done that 12 times. I would remove the entire || construct and all the definitions except DA and then iterate one through the choosearray list setting the shift if the current item = \DA

@JasperHabicht in that case I just misunderstood your last message, sorry :) Yes, one can most definitely improve this... But I agree we need more information to do so.

@cis how is your \choosearray and \deckarray initialised? Which functionality do you need? Are their lengths static? Most likely you can be magnitudes faster by using intarrays if they indeed have static length.

@cis you could show me your entire code with a bit of explanatory comments if you want and I can speed it up...

@Skillmon When you are done with it the cards will fly out of the screen/window...

\documentclass[margin=4pt, varwidth]{standalone}

\usepackage{amsmath}
\usepackage{tikz}

\usepackage{multirow}

\usepackage{fontspec}
\newfontfamily\cardfont{60deckDE.ttf}

% Input ============================
\pgfmathtruncatemacro\Nchoose{12}% choose \Ncoose
\pgfmathtruncatemacro\Nmax{60}%  from \Nmax
\pgfmathtruncatemacro\TargetCard{26}% 26=Jack of hearts, 1=Ace of Pique
%
\pgfmathtruncatemacro\M{3}% No. of Experiments (if 0 only meshed deck)
% ==================================
%
% Show Settings =========================

Inspired by the Dante meeting being held in Goethe museum in Weimar, I got myself a novel based on the life of Goethe's wife for the train journey home. The train journey went more smoothly than anticipated, so I didn't actually finish the book then and it took a cold and rainy Sunday afternoon to get back to it. Funny surprise on the last page: the company to which prepared the novel as an ebook was le-tex. A full tex circle :)

@samcarter powered by xmltex then possibly:-)

@DavidCarlisle who would ever use that?

:)

@Skillmon not me, for sure.

@DavidCarlisle very possible :)

@DavidCarlisle ooh today is the foundation day of Rome

@PauloCereda @egreg was there

@PauloCereda Coquam anatem ad celebramus

@DavidCarlisle ooh fortasse notabat spatia spuria in textibus

@DavidCarlisle oh no

@cis what of that should be "package" code and what is just document code that need not get optimised? Honestly, everything between \begin{document} and \end{document} looks messy to me...

@Skillmon Rabbits are very good at messing around...

@mickep but rabbits have code-formatting-ocd

@PauloCereda And I was on the right side of the pomerium, unlike Remus.

@DavidCarlisle “ad celebrandum”, I'd say

@Skillmon oh no

@DavidCarlisle Oh no, small test examples.

@mickep to be fair, David doesn't use LaTeX for documents, either...

@Skillmon Oh no!

@egreg ooh

@mickep \bye

@DavidCarlisle Very small, indeed.

@Skillmon no I use it for parsing xml documents of course

@DavidCarlisle :D

@Skillmon <3

@cis well, the question is, is this a one-off document? In that case optimising isn't worth it. Or should any of that functionality you use in your document be reusable code for other people, in which case optimising is indeed worthwhile.

@cis now you have the cards in a font and are not drawing them with tikz I doubt you need pgf or tikz at all in this document, perhaps just for the blue boxes, but not for any of the calculations or layout

@PauloCereda we could suggest fixing the overfull box by eating some of its contents. tex.stackexchange.com/q/716103/1090

@DavidCarlisle Sometimes you have good ideas.

@mickep I try

@DavidCarlisle No need to eat them. Just use a carriage (return):

@JasperHabicht :-)

@PauloCereda @DavidCarlisle twitter.com/SoVeryBritish/status/1781962615784169605

@yo' OH NO

@DavidCarlisle oh no

@JasperHabicht ooh

@cis sounds like something that can be calculated exactly and nothing you have to run simulations on (not that you shouldn't if you're interested in it).

But nothing that's worth spending an hour to optimise... (I optimised two of the base functions though)

Faster \cardcolor:

\newcommand\cardcolor[1]% 60deck .............
  {%
    % reduce median number of comparisons via bisectioning
    \ifnum#1<31
      \ifnum#1<16
        \ifnum#1=\z@ cardframecolor\else spadecolor\fi
      \else heartcolor%
      \fi
    \else
      \ifnum#1<46 diamondcolor%
      \else\ifnum#1=61 cardbackcolor\else clubcolor\fi
      \fi
    \fi
  }

Faster \createlist:

\ExplSyntaxOn
\cs_generate_variant:Nn  \cs_set:Npn {Npe,Npo} % old latex
\cs_generate_variant:Nn  \seq_set_from_clist:Nn {Ne} % old latex

\cs_new:Npn \cis_comma_tmp:n #1 {,~#1}
\cs_new:Npn \cis_comma_tmp:nn #1#2
  {
    #2
    \if_int_compare:w #1 = \l_tmpa_int \seq_map_break:n \fi:
    ,~
  }

\NewDocumentCommand\createlist{mmm}
  {
    \int_set:Nn \l_tmpa_int {#3}
    \int_compare:nNnTF \l_tmpa_int > \c_zero_int
      {
        \seq_set_from_clist:Ne \l_tmpa_seq
          { \int_step_function:nN {#2} \cis_comma_tmp:n }