Matthias Apsel: Mathematik/Programmiertechnik zum Wochenende

0 42

Mathematik/Programmiertechnik zum Wochenende

Matthias Apsel
  • mathematik
  1. 0
    Rolf B
    1. 0
      Gunnar Bittersmann
      1. 0
        Rolf B
    2. 0
      Matthias Apsel
      1. 0
        Tabellenkalk
        1. 0
          Matthias Apsel
          1. 0
            Tabellenkalk
            1. 0
              Gunnar Bittersmann
              1. 0
                Tabellenkalk
                1. 0
                  Gunnar Bittersmann
                  1. 0
                    Rolf B
                    1. 0
                      Matthias Apsel
                      1. 0
                        Rolf B
                        1. 0
                          Matthias Apsel
  2. 0
    Gunnar Bittersmann
    1. 0
      Rolf B
      1. 0
        Gunnar Bittersmann
        1. 0
          JürgenB
          1. 0
            Rolf B
    2. 0
      Matthias Apsel
  3. 0
    Gunnar Bittersmann
  4. 0
    Tabellenkalk
    1. 0
      Rolf B
      1. 0
        Gunnar Bittersmann
        1. 1

          Mathematik/Programmiertechnik zum Wochenende – Lösung

          Gunnar Bittersmann
          1. 0
            Tabellenkalk
          2. 0
            Rolf B
  5. 0
    Gunnar Bittersmann
  6. 0
    Rolf B
    1. 0
      Gunnar Bittersmann
      1. 0
        Rolf B
  7. 0

    Mathematik/Programmiertechnik zum Wochenende – Lösung

    Gunnar Bittersmann
    • javascript
    • mathematik
    1. 0
      kai345
      • javascript
    2. 0
      Rolf B
    3. 0
      Gunnar Bittersmann
  8. 0

    Mathematik/Programmiertechnik zum Wochenende - Anzahl der n

    Rolf B
    1. 0
      Rolf B
      1. 0
        Rolf B
        1. 0
          Gunnar Bittersmann
    2. 0
      Gunnar Bittersmann
      • latex
      • zu diesem forum
      1. 0
        Christian Kruse

Hallo alle,

gegeben ist die Menge N, die diejenigen natürlichen Zahlen n enthält, bei der keine Ziffer mehr als neun Mal vorkommt.

Man ermittle die Mächtigkeit von N.

Aus den Zahlen n werden (höchstens zehnstellige) Zahlen z nach folgender Vorschrift gebildet:

Die k. Stelle von z ist die Anzahl der in n enthaltenen Ziffern k-1.

Für n = 2510102020 (25 Jahre SELFHTML am 10.10.2020) ist z = 4230100000.

Man ermittle alle Zahlen n, für die gilt n = z.

Bis demnächst
Matthias

--
Du kannst das Projekt SELFHTML unterstützen,
indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
  1. Hallo Matthias,

    das ist leider unsauber und auch widersprüchlich.

    1. Ist 007 ∈ N? Wenn nicht, was ist dann mit Punkt 2...
    2. Welches z gehört zu n=345? 000111? Ist das eine natürliche Zahl? Was ist mit 0001110, oder 00011100 oder 000111000 oder 0001110000? Die Bildungsregel liefert mehr als ein z.

    Aber man kann es säubern, denke ich.

    Sei $$h_i: \mathbb N \rightarrow \mathbb N, i \in [0..9]$$ die Funktion, die die Häufigkeit der Ziffer $$i$$ in der Zahl $$n$$ angibt.

    Sei $$N := \{ n | n \in \mathbb{N} $$ und $$(\forall_{i=[0..9]}(h_i(n)<10) \}$$ ,

    Sei $$\displaystyle z: N \rightarrow \mathbb{N}, z(n) = \sum_{i=0}^n h_i(n)\cdot 10^i $$

    Auf diese Weise ist die Bildungsregel für z eindeutig und kann auch eine fehlende 0 in n darstellen.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. @@Rolf B

      das ist leider unsauber und auch widersprüchlich.

      1. Ist 007 ∈ N? Wenn nicht, was ist dann mit Punkt 2...

      Gute Frage. Vermutlich sind führende Nullen nicht erlaubt.

      1. Welches z gehört zu n=345? 000111?

      Wie ich die Aufgabe verstanden habe: 00011100000, also 11100000. Ohne führende Nullen stimmt dann aber „Die k. Stelle von z ist die Anzahl der in n enthaltenen Ziffern k-1“ nicht mehr.

      Sei $$\displaystyle z: N \rightarrow \mathbb{N}, z(n) = \sum_{i=0}^n h_i(n)\cdot 10^i $$

      Das wäre aber eine andere Aufgabe. Da ist die Häufigkeit der Neunen vorne und die der Nullen hinten. Es sollte doch aber andersrum sein:
      $$\displaystyle z: N \rightarrow \mathbb{N}, z(n) = \sum_{i=0}^9 h_i(n)\cdot 10^{\left(9-i\right)} $$

      (Die obere Grenze des Index hab ich gleich mal mit korrigiert.)

      🖖 Stay hard! Stay hungry! Stay alive! Stay home!

      --
      Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
      1. Hallo Gunnar,

        Da ist die Häufigkeit der Neunen vorne und die der Nullen hinten

        Ja, ich hielt das für unumgänglich, weil ich zu sehr an der "die n-te Stelle beschreibt die Häufigkeit der Ziffer n" klebte, und habe beim Aufschreiben einfach nur "n-te Stelle von hinten" im Kopf gehabt.

        Aber du hast recht, die Definition erlaubt auch die ursprüngliche Reihenfolge. 111000 würde dann 456, 465, 546, 564, 645 und 654 beschreiben.

        Rolf

        --
        sumpsi - posui - obstruxi
    2. Hallo Rolf B,

      1. Ist 007 ∈ N?

      Nein.

      1. Welches z gehört zu n=345? 000111? Ist das eine natürliche Zahl? Was ist mit 0001110, oder 00011100 oder 000111000 oder 0001110000? Die Bildungsregel liefert mehr als ein z.

      00011100000 ⇒ 1110000

      Führende Nullen sind weder für n noch für z erlaubt.

      Bis demnächst
      Matthias

      --
      Du kannst das Projekt SELFHTML unterstützen,
      indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
      1. Hallo,

        Führende Nullen sind weder für n noch für z erlaubt.

        Also muss n mindestens eine 0 enthalten?

        Gruß
        Kalk

        1. Hallo Tabellenkalk,

          Führende Nullen sind weder für n noch für z erlaubt.

          Also muss n mindestens eine 0 enthalten?

          Nein. Warum? (die Zahl Null besitzt keine führende Null)

          n z
          0 1.000.000.000
          1 100.000.000
          2 10.000.000
          3 1.000.000
          9 1
          10 1.100.000.000
          11 200.000.000

          Bis demnächst
          Matthias

          --
          Du kannst das Projekt SELFHTML unterstützen,
          indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
          1. Hallo,

            Nein. Warum?

            Weil

            Die k. Stelle von z ist die Anzahl der in n enthaltenen Ziffern k-1.

            Wie zählst du k?

            n z
            0 1.000.000.000
            1 100.000.000
            2 10.000.000
            3 1.000.000
            9 1
            10 1.100.000.000
            11 200.000.000

            Offensichtlich nicht so wie ich…

            Gruß
            Kalk

            1. @@Tabellenkalk

              Wie zählst du k?

              n z
              0 1.000.000.000
              1 100.000.000
              2 10.000.000
              3 1.000.000
              9 1
              10 1.100.000.000
              11 200.000.000

              Offensichtlich nicht so wie ich…

              Gruß
              Kalk

              hᵢ: Häufigkeit des Auftretens der Ziffer i in n

              n h h h h h h h h h h z
              0 1 0 0 0 0 0 0 0 0 0 1.000.000.000
              1 0 1 0 0 0 0 0 0 0 0 100.000.000
              2 0 0 1 0 0 0 0 0 0 0 10.000.000
              3 0 0 0 1 0 0 0 0 0 0 1.000.000
              9 0 0 0 0 0 0 0 0 0 1 1
              10 1 1 0 0 0 0 0 0 0 0 1.100.000.000
              11 0 2 0 0 0 0 0 0 0 0 200.000.000

              Jetzt klarer?

              🖖 Stay hard! Stay hungry! Stay alive! Stay home!

              --
              Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
              1. Hallo,

                Jetzt klarer?

                ich fragte nach k in z, du kommst mit h0 bis h9 in n.

                Gruß
                Kalk

                1. @@Tabellenkalk

                  ich fragte nach k in z, du kommst mit h0 bis h9 in n.

                  Dass das mit dem k in z ohne die führenden Nullen dann nicht mehr hinhaut, hatte ich doch auch schon festgestellt.

                  🖖 Stay hard! Stay hungry! Stay alive! Stay home!

                  --
                  Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
                  1. Hallo Gunnar,

                    ja, aber Matthias muss das auch noch einsehen.

                    Rolf

                    --
                    sumpsi - posui - obstruxi
                    1. Hallo Rolf B,

                      ja, aber Matthias muss das auch noch einsehen.

                      Du kannst auch einfach sagen, wenn du keine solchen Aufgaben mehr sehen möchtest. Dann gibt es von mir keine mehr.

                      Bis demnächst
                      Matthias

                      --
                      Du kannst das Projekt SELFHTML unterstützen,
                      indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
                      1. Hallo Matthias,

                        wenn Du auf Rückfragen so patzig reagierst, musst Du Dich nicht wundern, wenn deine Aufgaben liegen bleiben. Auch wenn sie interessant sind. Wie diese eigentlich.

                        Deine Definition von z funktioniert nicht, das versuche ich Dir klar zu machen.

                        An einer Stelle hatte ich unrecht: dass die Zahl der abschließenden Nullen von z nicht wohldefiniert sei. Das ist ein Irrtum gewesen.

                        Aber trotzdem funktioniert sie nicht.

                        Die k. Stelle von z ist die Anzahl der in n enthaltenen Ziffern k-1.

                        Du sagst, dass zu n=345 ein z=1110000 gehört. Okay. Vier Nullen am Ende, passend zu "keine 6, keine 7, keine 8 und keine 9". Demzufolge zählst Du die Stellen erwartungsgemäß von links nach rechts. In z=1110000 ist die erste Stelle 1. Die erste Stelle bezeichnet die Häufigkeit der Ziffer 0. In n=345 ist aber keine 0. Ein n, das keine 0 enthält, kannst Du mit deiner Definition nicht darstellen.

                        Deswegen die Summendefinition für z, die ich aufstellte und die Gunnar weiterentwickelt hat. Anders bekommt man es wohl nicht hin, und ich werde auf dieser Basis arbeiten.

                        Wenn Du der Meinung bist, dass ich die Aufgabe grundsätzlich falsch verstehe und nur deshalb mit deiner Definition nicht klarkomme, bitte ich um einen Hinweis.

                        Rolf

                        --
                        sumpsi - posui - obstruxi
                        1. Hallo Rolf B,

                          wenn Du auf Rückfragen so patzig reagierst,

                          In „ja, aber Matthias muss das auch noch einsehen.“ kann ich keine Rückfrage entdecken.

                          Aber trotzdem funktioniert sie nicht.

                          Ja, sie war unsauber formuliert.

                          Die k. Stelle von z ist die Anzahl der in n enthaltenen Ziffern k-1.

                          • Anschließend sind führende Nullen zu streichen.

                          Deswegen die Summendefinition für z, die ich aufstellte und die Gunnar weiterentwickelt hat. Anders bekommt man es wohl nicht hin, und ich werde auf dieser Basis arbeiten.

                          Diese Summendefinition ist meiner Meinung nach identisch mit den Beispielen in der Tabelle (und beschreibt die Bildungsvorschrift von z wie von mir intendiert).

                          Wenn Du der Meinung bist, dass ich die Aufgabe grundsätzlich falsch verstehe und nur deshalb mit deiner Definition nicht klarkomme, bitte ich um einen Hinweis.

                          Ich denke nicht, dass du die Aufgabe grundsätzlich falsch verstehst.

                          Bis demnächst
                          Matthias

                          --
                          Du kannst das Projekt SELFHTML unterstützen,
                          indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
  2. @@Matthias Apsel

    Man ermittle alle Zahlen n, für die gilt n = z.

    for (i = 1; i <= 999999999888888888777777777666666666555555555444444444333333333222222222111111111; i++)
    

    Ich miete dann mal Rechenzeit auf einem Supercomputer … 😉

    🖖 Stay hard! Stay hungry! Stay alive! Stay home!

    --
    Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
    1. Hallo Gunnar,

      999999999888888888777777777666666666555555555444444444333333333222222222111111111
      

      Wenn Du für diese Obergrenze einen Supercomputer brauchst, dann brauchst Du für Matthias Aufgabe eine Milliarde Supercomputer!

      Rolf

      --
      sumpsi - posui - obstruxi
      1. @@Rolf B

        999999999888888888777777777666666666555555555444444444333333333222222222111111111
        

        Wenn Du für diese Obergrenze einen Supercomputer brauchst, dann brauchst Du für Matthias Aufgabe eine Milliarde Supercomputer!

        Naja, die Obergrenze zu finden, bis zu der man untersuchen muss, ist ja schon Teil der Lösung. 😉

        Und die ist immer noch zu groß, um die Schleife in JavaScript laufen zu lassen, ohne dass der Browser immer wieder nachfragt, ob er das Script weiter ausführen soll.

        Meh, da muss man wohl doch überlegen anstatt mit brute force ranzugehen.

        🖖 Stay hard! Stay hungry! Stay alive! Stay home!

        --
        Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
        1. Hallo Gunnar,

          Und die ist immer noch zu groß, um die Schleife in JavaScript laufen zu lassen, ohne dass der Browser immer wieder nachfragt, ob er das Script weiter ausführen soll.

          Powerschleifen lässt man mit setTimeout laufen, oder vielleicht doch im Worker, oder auf der Grafikkarte. 😉

          Gruß
          Jürgen

          1. Hallo JürgenB,

            jedenfalls nicht mit JavaScript. Mit C# läuft meine Zählerei locker 10x so schnell. Erstaunlich eigentlich, dass es nicht mehr ist, aber mein C++ ist zu rostig geworden...

            Rolf

            --
            sumpsi - posui - obstruxi
    2. Hallo Gunnar Bittersmann,

      for (i = 1; i <= 999999999888888888777777777666666666555555555444444444333333333222222222111111111; i++)
      

      Ich miete dann mal Rechenzeit auf einem Supercomputer … 😉

      Genau. Zumal noch 000000000 fehlt.

      Bis demnächst
      Matthias

      --
      Du kannst das Projekt SELFHTML unterstützen,
      indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
  3. @@Matthias Apsel

    Für n = 2510102020 (25 Jahre SELFHTML am 10.10.2020) ist z = 4230100000.

    War kurz am Zweifeln, ob ich ich ’nen Bug ich meiner Funktion habe, die 4230010000 herausbekam. 😄

    🖖 Stay hard! Stay hungry! Stay alive! Stay home!

    --
    Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
  4. Hallo,

    Man ermittle alle Zahlen n, für die gilt n = z.

    Die Quersummen der Zahlen, auf die das zutrifft, ist 10. Man kann also die Suche auf solche Zahlen einschränken.

    Gruß
    Kalk

    1. Hallo Tabellenkalk,

      Die Quersummen der Zahlen, auf die das zutrifft, ist 10.

      ich glaube, dass diese Aussage falsch ist. Die Quersumme sollte kleiner oder gleich 10 sein.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. @@Rolf B

        Man ermittle alle Zahlen n, für die gilt n = z.

        Die Quersummen der Zahlen, auf die das zutrifft, ist 10.

        ich glaube, dass diese Aussage falsch ist. Die Quersumme sollte kleiner oder gleich 10 sein.

        Die Quersumme der 10stelligen Zahlen, auf die das zutrifft, ist 10.
        Die Quersumme der 9stelligen Zahlen, auf die das zutrifft, ist 9.
        Die Quersumme der 8stelligen Zahlen, auf die das zutrifft, ist 8.

        Die Quersumme der 1stelligen Zahlen, auf die das zutrifft, ist 1.

        Eine k-stellige Zahl n mit k ≤ 9, für die n = z gilt, darf keine Nullen enthalten, sonst wäre z zehnstellig. Wegen der Quersumme besteht n aus k Einsen. Damit ist z = k00000000 ≠ n.

        Es gibt also keine 9-oder-weniger-stelligen Zahlen mit n = z. Wenn es solche Zahlen n gibt, dann müssen sie 10stellig sein.

        Somit hatte @Tabellenkalk also doch recht. 😉

        🖖 Stay hard! Stay hungry! Stay alive! Stay home!

        --
        Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
        1. @@Gunnar Bittersmann

          Die Quersumme der 10stelligen Zahlen, auf die das zutrifft, ist 10.
          … Wenn es solche Zahlen n gibt, dann müssen sie 10stellig sein.

          An der Stelle machen wir doch mal weiter. Wir zerlegen die Quersumme 10 in 10 Summanden sᵢ ∈ {0, 1, 2, …, 9} (was denn die Ziffen von n sind).

          Permutationen außerachtgelassen (für z ist die Reihenfolge der Ziffern ja egal) gibt’s dafür gar nicht so viele Möglichkeiten. Für jede werden die Vorkommen der Nullen, Einsen, …, Neunen gezählt.

          Zerlegung h h h h h h h h h h
          9 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 8 1 0 0 0 0 0 0 0 1
          8 + 2 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 8 0 1 0 0 0 0 0 1 0
          8 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 2 0 0 0 0 0 0 1 0
          7 + 3 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 8 0 0 1 0 0 0 1 0 0
          7 + 2 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 1 1 0 0 0 0 1 0 0
          7 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 3 0 0 0 0 0 1 0 0
          6 + 4 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 8 0 0 0 1 0 1 0 0 0
          6 + 3 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 1 0 1 0 0 1 0 0 0
          6 + 2 + 2 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 0 2 0 0 0 1 0 0 0
          6 + 2 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 2 1 0 0 0 1 0 0 0 🌞🌞🌞
          6 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 5 4 0 0 0 0 1 0 0 0
          5 + 5 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 8 0 0 0 0 2 0 0 0 0
          5 + 4 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 1 0 0 1 1 0 0 0 0
          5 + 3 + 2 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 0 1 1 0 1 0 0 0 0
          5 + 3 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 2 0 1 0 1 0 0 0 0
          5 + 2 + 2 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 1 2 0 0 1 0 0 0 0
          5 + 2 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 5 3 1 0 0 1 0 0 0 0
          5 + 1 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 4 5 0 0 0 1 0 0 0 0
          4 + 4 + 2 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 0 1 0 2 0 0 0 0 0
          4 + 4 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 2 0 0 2 0 0 0 0 0
          4 + 3 + 3 + 0 + 0 + 0 + 0 + 0 + 0 + 0 7 0 0 2 1 0 0 0 0 0
          4 + 3 + 2 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 1 1 1 1 0 0 0 0 0
          4 + 3 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 5 3 0 1 1 0 0 0 0 0
          4 + 2 + 2 + 2 + 0 + 0 + 0 + 0 + 0 + 0 6 0 3 0 1 0 0 0 0 0
          4 + 2 + 2 + 1 + 1 + 0 + 0 + 0 + 0 + 0 5 2 2 0 1 0 0 0 0 0
          4 + 2 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 4 4 1 0 1 0 0 0 0 0
          4 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 0 + 0 3 6 0 0 1 0 0 0 0 0
          3 + 3 + 3 + 1 + 0 + 0 + 0 + 0 + 0 + 0 6 1 0 3 0 0 0 0 0 0
          3 + 3 + 2 + 2 + 0 + 0 + 0 + 0 + 0 + 0 6 0 2 2 0 0 0 0 0 0
          3 + 3 + 2 + 1 + 1 + 0 + 0 + 0 + 0 + 0 5 2 1 2 0 0 0 0 0 0
          3 + 3 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 4 4 0 2 0 0 0 0 0 0
          3 + 2 + 2 + 2 + 1 + 0 + 0 + 0 + 0 + 0 5 1 3 1 0 0 0 0 0 0
          3 + 2 + 2 + 1 + 1 + 1 + 0 + 0 + 0 + 0 4 3 2 1 0 0 0 0 0 0
          3 + 2 + 1 + 1 + 1 + 1 + 1 + 0 + 0 + 0 3 5 1 1 0 0 0 0 0 0
          3 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 0 2 7 0 1 0 0 0 0 0 0
          2 + 2 + 2 + 2 + 2 + 0 + 0 + 0 + 0 + 0 5 0 5 0 0 0 0 0 0 0
          2 + 2 + 2 + 2 + 1 + 1 + 0 + 0 + 0 + 0 4 2 4 0 0 0 0 0 0 0
          2 + 2 + 2 + 1 + 1 + 1 + 1 + 0 + 0 + 0 3 4 3 0 0 0 0 0 0 0
          2 + 2 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 0 2 6 2 0 0 0 0 0 0 0
          2 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 1 8 1 0 0 0 0 0 0 0
          1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 0 10 0 0 0 0 0 0 0 0

          (Die letzte Zerlegung entfällt wegen h₁ > 9.)

          Es gibt nur eine Übereinstimmung der Zahlen bei Summanden und Häufigkeiten (ohne Beachtung der Reihenfolge) in der gekennzeichneten Zeile.

          Es gibt also nur eine solche Zahl, für die n = z gilt: 6210001000.

          Na bitte, geht doch ohne Computer! Der @Matthias Apsel wollte uns mit „Programmiertechnik“ im Titel nur in die Irre führen.

          🖖 Stay hard! Stay hungry! Stay alive! Stay home!

          --
          Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
          1. Hallo,

            Permutationen außerachtgelassen (für z ist die Reihenfolge der Ziffern ja egal) gibt’s dafür gar nicht so viele Möglichkeiten. Für jede werden die Vorkommen der Nullen, Einsen, …, Neunen gezählt.

            Zerlegung [...]

            Applaus! So in der Art waren auch meine Gedanken, aber da ich davon ausging, dass das ausartet, wollte ich mir dafür einen Algorithmus überlegen. Aber dann kamen andere Dinge dazwischen…

            Gruß
            Kalk

          2. Hallo Gunnar,

            Cleverle!

            Rolf

            --
            sumpsi - posui - obstruxi
  5. @@Matthias Apsel

    Man ermittle alle Zahlen n, für die gilt n = z.

    Nicht dass ich eine solche Zahl gefunden hätte; dafür aber ein Zahlenpaar (ab), für das a = z(b) und b = z(a) gilt.

    Oder anders gesagt: Ich habe zwei Zahlen gefunden, für die n = z(z(n)) gilt.

    🖖 Stay hard! Stay hungry! Stay alive! Stay home!

    --
    Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
  6. Hallo,

    ich hätte zwei Checkpoints.

    1. Für $$z=1234567890$$ gibt es $$6.374 \cdot 10^{34}$$ Werte für n.

    2. $$10^{82} < |N| < 10^{83}$$

    Sieht das jemand anders?

    Rolf

    --
    sumpsi - posui - obstruxi
    1. @@Rolf B

      2. $$10^{82} < |N| < 10^{83}$$

      Sieht das jemand anders?

      Ich bin mir nicht sicher, ob’s wirklich weniger als 10⁸³ sind, evtl. sind’s auch ein paar drüber.

      Ich würde jetzt schätzen 0.9 × 10⁸³ < |N| < 1.2 × 10⁸³.

      🖖 Stay hard! Stay hungry! Stay alive! Stay home!

      --
      Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
      1. Hallo Gunnar,

        oh. Ich habe gerechnet, nicht geschätzt, aber ich mag ja auch einen falschen Ansatz haben. Ich bin gespannt auf die Lösungsdiskussion.

        Jedenfalls bin ich, was die untere Schranke angeht, ebenfalls deiner Ansicht.

        Rolf

        --
        sumpsi - posui - obstruxi
  7. @@Matthias Apsel

    Man ermittle alle Zahlen n, für die gilt n = z.

    Aus der Bildungsvorschrift von z ergibt sich, dass z maximal 10stellig sein kann. Damit können auch die gesuchten mit z übereinstimmenden n maximal 10stellig sein.

    Auf die Suche!

    Eine Methode, um die Vorkommen eines Zeichens (einer Zeichenkette) in einem String zu zählen:

    String.prototype.occurrences = function (character) {
    	return this.match(new RegExp(character, 'g'))?.length || 0;
    };
    

    Ist es eigentlich eine gute oder eine blöde Idee, Basisobjekte prototypisch zu erweitern? (Ernsthafte Frage.)

    Damit erhält man z(n):

    function z(n) {
    	const nString = n.toString();
    	let zString = '';
    	for (let digit = 0; digit <= 9; digit++) {
    		zString += nString.occurrences(digit);
    	}
    	return Number.parseInt(zString, 10);
    };
    

    Jetzt braucht man nur noch alle maximal 10stelligen Zahlen untersuchen:

    for (let n = 0; n < 1e10; n++) {
    	if (n == z(n)) {
    		console.log(n);
    	}
    }
    

    (Die nicht in N einthalten Zahlen 1111111111 (zehn Einsen), 2222222222, …, 9999999999 würde man einfach ignorieren, sollten sie Treffer sein.)

    Das Problem daran: Das Script läuft eeeeeeeeeewig. Bzw.: Es tut es nicht; der Browser fragt immer wieder nach, ob er es weiter ausführen soll. Es läuft durch bis 10⁶; mit wiederholten Aufforderungen weiterzumachen kommt man auch bei 10⁷ zum Ende. Aber bis 10¹⁰ sind’s noch Größenordnungen …

    Andere Implementierungen mögen schneller sein und keine Nachfrage erzeugen; 10¹⁰ Schleifendurchläufe sind auch dann kaum praktikabel. (Bei nur einer Zehntelmillisekunde pro Durchlauf würde das Script 10⁶ Sekunden laufen; das sind über 11½ Tage.)

    Aber wir wissen schon mal, dass es keine Zahl n = z(n) gibt, die 7 oder weniger Stellen hat.

    Das muss anders gehen als mit brute force; Gewalt ist keine Lösung.


    Ich hatte mich schon gefragt, ob ich mit „Ich habe zwei Zahlen gefunden, für die n = z(z(n)) gilt“ nicht schon zu viel vom Lösungsweg verraten hatte …

    Lassen wir uns doch mal z(n) ausgeben:

    function check(n) {
    	console.log(n, n == z(n) ? '🌞🌞🌞' : z(n));
    }
    

    Für 0:

    check(0); // 0 1000000000
    

    Und jetzt setzen wir das Ergebnis wieder ein:

    check(1000000000); // 1000000000 9100000000
    

    Und wieder und wieder:

    check(9100000000); // 9100000000 8100000001
    
    check(8100000001); // 8100000001 7200000010
    
    check(7200000010); // 7200000010 7110000100
    
    check(7110000100); // 7110000100 6300000100
    
    check(6300000100); // 6300000100 7101001000
    
    check(7101001000); // 7101001000 6300000100
    

    Wir landen im Zyklus 6300000100 ↔︎ 7101001000.

    Und dasselbe passiert auch für den Startwert 1, 2, 3, …, 98765, …

    Das legt die Vermutung nahe, dass das für alle Startwerte so ist, d.h. dass es keine Zahl gibt, für die n = z(n) gilt.

    An der Stelle kommt @Matthias Apsel ins Spiel, der mir zuflüsterte, dass es doch eine solche Zahl gibt. Dann heißt’s wohl, die Nadel im Heuhaufen zu suchen …


    Und dafür eine Funktion geschrieben, die z(z(z(…))) berechnet, bis sie in den Zyklus läuft oder nach einigen Durchläufen abbricht. (Wie wir gesehen hatten, kommt man recht schnell in den Zyklus; 10 Schleifen sollten reichen.)

    function attractor(n) {
    	for (let i = 0; i < 10; i++) {
    		if (n == 7101001000) {
    			return n;
    		}
    		else {
    			n = z(n);
    		}
    	}
    	return null;
    };
    
    console.log(attractor(0)); // 7101001000
    

    Voller Verzweiflung hab ich dann wahllos auf der Tastatur rumgeklimpert (ich schwör’s, so war’s):

    console.log(attractor(42189658268)); // null
    

    Nanu? Reichen 10 Schleifen doch nicht? Auf 100 erhöht, 1000, 10000 – selbes Ergebnis.

    Huch, was’n da los?

    check(42189658268); // 42189658268 120112031
    
    check(120112031); // 120112031 2421000000
    
    check(2421000000); // 2421000000 6120100000
    
    check(6120100000); // 6120100000 6210001000
    
    check(6210001000); // 6210001000 "🌞🌞🌞"
    

    Punker Maria, du ich hab die Nadel gefunden! (Didi)

    Es gibt sie wirklich: 6210001000 ist so eine gesuchte Zahl mit n = z(n).


    Jetzt stellt sich die Frage, ob ich einfach nur wahnsinnig viel Glück hatte oder ob es viele Startwerte gibt, die nicht in den Zyklus 6300000100 ↔︎ 7101001000, sondern zu 6210001000 führen.

    Die Funktion abgewandelt zu

    function attractor(n) {
    	const attractors = [
    		6210001000,
    		7101001000,
    	];
    
    	for (let i = 0; i < 10; i++) {
    		if (attractors.includes(n)) {
    			return n;
    		}
    		else {
    			n = z(n);
    		}
    	}
    	return null;
    };
    

    und mit 10000 Zufallszahlen aus dem Bereich [0, 10¹⁰[ geprüft ergibt: Etwa 34½ % der Zahlen führen zu 6210001000; 65½ % zum Zylus 7101001000 ↔︎ 6300000100. Es war keine Zahl dabei, die nicht zu einem der beiden führt.

    Das ist ein Indiz, aber kein Beweis dafür, dass es nicht noch weitere Zyklen gibt; womöglich gar welche der Länge 1, d.h. weitere Zahlen mit der Eigenschaft n = z(n).

    Um das auszuschließen, fiele mir jetzt wieder nur brute force ein …

    Es war also doch nicht die Nadel, die ich im Heuhaufen gefunden hab; es gibt viele davon. Warum ich anfangs keine gefunden hatte: es gibt keine Nadeln < 10⁶. Die kleinste Zahl, die zu 6210001000 führt, ist 1000123.

    Hier noch der Link zu meiner Spielwiese.

    🖖 Stay hard! Stay hungry! Stay alive! Stay home!

    --
    Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
    1. Eine Methode, um die Vorkommen eines Zeichens (einer Zeichenkette) in einem String zu zählen:

      String.prototype.occurrences = function (character) {
      	return this.match(new RegExp(character, 'g'))?.length || 0;
      };
      

      Ist es eigentlich eine gute oder eine blöde Idee, Basisobjekte prototypisch zu erweitern? (Ernsthafte Frage.)

      Ja. Nein. Vielleicht. Keine Ahnung.

      Object ist selbstverständlich wegen der Vererbung tabu, String, Number, Array hingegen halte ich nicht wirklich für problemantisch. [1]

      Es ist aber anzuraten, bezüglich eventueller zukünftiger JS-Erweiterungen eine Namenskonvention zu verwenden, die bei (in)offiziellen Benamungen nicht verwendet werden wird, z.B. ein/zwei führende Unterstriche String.prototype.__occurrences() (oder irgendetwas anderes; bspw. ein Prefix), um zu vermeiden, dass potentielle Funktionen durch Namens-Kollisionen überschrieben werden.

      /K

      --
      Stur lächeln und winken, Männer!

      1. Natürlich wird die prototypische Erweiterung auch da in speziellen Fällen versagen, z.B. wenn genau 99 Hexen in der Walpurgisnacht bei Vollmond gegen den Uhrzeigersinn auf ihren Besen pesen ↩︎

    2. Hallo Gunnar,

      ich habe eine effizientere Implementierung gefunden und sie darüber hinaus nicht mit JavaScript, sondern mit C# laufen lassen. Mein C++ war zu rostig, damit wär's sicherlich noch mal schneller gewesen.

      Nach 4 Minuten habe ich gewusst, dass 6210001000 die einzige Zahl n ist, für die z(n)=n gilt.

      Rückkopplung habe ich nicht ausprobiert; ich denke auch, dass eine erschöpfende Suche aller Startwerte der Rückkopplungsschleife deutlich länger dauert.

      Die analytische Vorgehensweise ist zu ineffizient. Mein erster Ansatz war eine Zerlegung der Zahl n in Ziffern, indem ich durch 10 geteilt habe und dann Quotient und Rest separiert habe. Ein Überrest davon findet sich noch im Konstruktor meiner Digits Klasse:

          struct Digits
          {
              public byte d0, d1, d2, d3, d4, d5, d6, d7, d8, d9;
              public int quersumme;
      
              public Digits(long z)
              {
                  z = (z - (d9 = (byte)(z % 10))) / 10;
                  z = (z - (d8 = (byte)(z % 10))) / 10;
                  z = (z - (d7 = (byte)(z % 10))) / 10;
                  z = (z - (d6 = (byte)(z % 10))) / 10;
                  z = (z - (d5 = (byte)(z % 10))) / 10;
                  z = (z - (d4 = (byte)(z % 10))) / 10;
                  z = (z - (d3 = (byte)(z % 10))) / 10;
                  z = (z - (d2 = (byte)(z % 10))) / 10;
                  z = (z - (d1 = (byte)(z % 10))) / 10;
                  d0 = (byte)z;
      
                  quersumme = d0 + d1 + d2 + d3 + d4 + d5 + d6 + d7 + d8 + d9;
              }
          }
      

      Ich verwende ganz bewusst einzelne Variablen und kein Array, und ich lasse keine Schleife laufen (wobei ich den Zeitgewinn nicht gemessen habe, vermutlich sind's nur 2-3 Prozent). Lästig ist, dass jede Zeile den z-Wert der vorherigen braucht, was die Prozessorpipeline vermutlich ausbremst. Da gäbe es vermutlich noch Optimierungspotenzial. Die Quersumme brauche ich für die Berechnung der Anzahl n und berechne sie darum gleich mit. Eine solche Additionskette flutscht eigentlich ganz glatt durch die execution pipeline.

      Aber es sind 20 Divisionen und 9 Subtraktionen, das ist aufwändig. Mittels Math.DivRem hätte man die Divisionen halbieren können, und man hätte den Code pipelinefreundlicher gestalten können, aber das habe ich nicht verfolgt. Ich habe etwas anderes gemacht.

      Eine brute-force Suche muss ja der Reihe nach Zahlen durchgehen. Ich muss also gar nicht beliebige Zahlen in Ziffern zerlegen, es reicht völlig, wenn ich einen effizienten Schritt von n nach n+1 habe. Gedacht, getippt:

              public void Increment()
              {
                  if (d9<9) { d9++; quersumme++; return; } else { d9=0; quersumme-=9; }
                  if (d8<9) { d8++; quersumme++; return; } else { d8=0; quersumme-=9; }
                  if (d7<9) { d7++; quersumme++; return; } else { d7=0; quersumme-=9; }
                  if (d6<9) { d6++; quersumme++; return; } else { d6=0; quersumme-=9; }
                  if (d5<9) { d5++; quersumme++; return; } else { d5=0; quersumme-=9; }
                  if (d4<9) { d4++; quersumme++; return; } else { d4=0; quersumme-=9; }
                  if (d3<9) { d3++; quersumme++; return; } else { d3=0; quersumme-=9; }
                  if (d2<9) { d2++; quersumme++; return; } else { d2=0; quersumme-=9; }
                  if (d1<9) { d1++; quersumme++; return; } else { d1=0; quersumme-=9; }
                  if (d0<9) { d0++; quersumme++; return; } else { d0=0; quersumme-=9; }
              }
      

      Dieser Code ist lange nicht so aufwändig wie er aussieht, denn in 90% aller Fälle endet er im ersten Then-Teil. In 99% aller Fälle läuft er bis zum zweiten Then-Teil. In 99,9% bis zum dritten.

      Man muss dann auch noch das z zum n berechnen können, das von dieser Ziffernfolge dargestellt wird. Dabei muss man aufpassen, man möchte ja nicht, dass z(1)=9100000000 liefert. Das Montieren der Ziffern zu z geht bei mir in der gezeigten Weise am schnellsten, ich habe ein paar Varianten probiert. C# ist nicht nahe genug am Blech, dass man hier mit Variationen der Ausführungsreihenfolge die Pipeline-Nutzung optimieren könnte (oder der .net JIT macht das schon selbst).

              public long ZValue
              {
                  get
                  {
                      byte[] z = new byte[10];
                      byte zq;
                      // Ziffern nur zählen wenn es keine führenden Nullen sind
                      if ((zq  = d0) > 0) z[d0]++;
                      if ((zq += d1) > 0) z[d1]++;
                      if ((zq += d2) > 0) z[d2]++;
                      if ((zq += d3) > 0) z[d3]++;
                      if ((zq += d4) > 0) z[d4]++;
                      if ((zq += d5) > 0) z[d5]++;
                      if ((zq += d6) > 0) z[d6]++;
                      if ((zq += d7) > 0) z[d7]++;
                      if ((zq += d8) > 0) z[d8]++;
                      if ((zq += d9) > 0) z[d9]++;
      
                      return ((((((((z[0] * 10 + z[1]) * 10 + z[2]) * 10 + z[3]) * 10 + z[4]) * 10 
                                  + z[5]) * 10 + z[6]) * 10 + z[7]) * 10 + z[8]) * 10L + z[9];
                  }
              }
      
      

      Diese Schleife läuft auf meinem etwas altertümlichen PC (Core i5-3470 CPU mit 3.20GHz) dann in unter 4 Minuten durch und meldet 6210001000 als einziges n mit n == d.ZValue.

      Digits d = new Digits(1);
      for (long i=1; i<10000000000; i++) {
         if (n == d.ZValue)
            Console.WriteLine("Match: {0}", n);
         d.Increment();
      }
      

      Rolf

      --
      sumpsi - posui - obstruxi
    3. @@Gunnar Bittersmann

      Das ist ein Indiz, aber kein Beweis dafür, dass es nicht noch weitere Zyklen gibt; womöglich gar welche der Länge 1, d.h. weitere Zahlen mit der Eigenschaft n = z(n).

      Um das auszuschließen, fiele mir jetzt wieder nur brute force ein …

      Man sollte ausschließen, sich in die Irre führen zu lassen. Dann geht’s auch ohne brute force. Sogar ohne Schleife. Sogar ohne Computer.

      🖖 Stay hard! Stay hungry! Stay alive! Stay home!

      --
      Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
  8. Hallo,

    für die Antwort auf Frage 1 habe ich nicht versucht, alle n zu bilden und ihr z zu berechnen. Das dauert mutmaßlich länger, als unsere Sonne brennt.

    Statt dessen schaue ich mir alle möglichen z an, das sind ja nur 9999999999, und bereche für jedes z die möglichen n. Das ist gar nicht so schwer.

    Sei im Folgenden $$h_i : \mathrm N \rightarrow \mathbb N$$ die Funktion, die die Häufigkeit der Ziffer i in der der Zahl $$n \in \mathrm N$$ angibt. Dann definiere ich z in der Gunnar-Variante als

    $$\displaystyle z: \mathrm N \rightarrow \mathbb N, z(n) = \sum_{i=0}^9 h_i(n)10^{9-i}$$

    Sei darüberhinaus $$q: \mathbb N \rightarrow \mathbb N$$ die Funktion, die zu einer Zahl ihre Quersumme liefert, und $$z_i$$ die Stelle einer Zahl z, die die Ziffernhäufkeit der Ziffer i angibt.

    Der naive Ansatz wäre, bei gegebenem z für die Anzahl der möglichen n mit z(n)=z den einfachen kombinatorischen Ansatz zu wählen:

    $$\displaystyle | \left\{ n | n \in \mathrm N, z(n)=z \right\} | = \frac{q(z)!}{z_0!z_1!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}$$

    Für Ziffern, die in n nicht vorkommen, ist $$z_i!=1$$, da muss man also nicht besonders aufpassen. Aber das Ergebnis ist trotzdem falsch, weil es n mit führenden Nullen mitzählt, die in n nicht erlaubt sind.

    Deshalb muss man es mühsamer machen. Für jede Ziffer von 1-9, die mindestens einmal vorkommt, muss man ermitteln, wie sich die übrigen Ziffern dahinter kombinieren lassen. Beispielsweise für die 1 (start(n) bezeiche die erste Ziffer von n):

    $$\displaystyle N_{z,1} := \left\{ n | n \in \mathrm N, \mathrm{start}(n)=1, z(n)=z \right\}, | N_{z,1} | = \frac{(q(z)-1)!}{z_0!(z_1-1)!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}$$

    Das macht man für die Ziffern von 1-9 und addiert auf. Fertig. Irgendwann 😟. Das geht doch bestimmt besser!

    Das $$(z_i-1)!$$ im Nenner ist extrem unhandlich für n die die Ziffer i nicht enthalten, das muss mal als erstes weg. Wenn man den Bruch für $$|N_{z,1}|$$ mit $$z_1$$ erweitert, dann bekommt man

    $$\displaystyle | N_{z,1} | = \frac{z_1 \cdot (q(z)-1)!}{z_0!z_1(z_1-1)!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}= \frac{z_1 \cdot (q(z)-1)!}{z_0!z_1!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}$$

    und das ist eine Erleuchtung, denn bis auf das $$z_i$$ im Zähler ist dieser Bruch für alle Ziffern gleich. Und für Ziffern, die in n nicht vorkommen, liefert der Term brav den Wert 0. Eine Fallunterscheidung, ob Ziffern vorkommen oder nicht, entfällt damit. Nach Aufaddieren und Ausklammern des Fakultätenhaufens ist die Anzahl aller n zu einem z:

    $$\displaystyle | N_z | = \frac{(z_1+z_2+z_3+z_4+z_5+z_6+z_7+z_8+z_9) \cdot (q(z)-1)!}{z_0!z_1!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}$$
    $$\displaystyle = \frac{(q(z)-z_0) \cdot (q(z)-1)!}{z_0!z_1!z_2!z_3!z_4!z_5!z_6!z_7!z_8!z_9!}$$

    (wieso funktionieren \align-Umgebungen nicht mehr⁉️)

    Die Fakultäten der Zahlen von 0-90 kann man noch vorausberechnen und in einem Array ablegen, so dass man sie nur noch abrufen muss statt für jedes z neu berechnen. Das sieht in C# dann so aus:

       double[] fakTab = new double[91];
       for (int i = 0; i <= 90; i++)
          fakTab[i] = fakultät(i);
    
       double allCombs = 0;
       Digits d = new Digits(z1);
       for (long z = 1; z < 10000000000; z++)
       {
          double combs = (fakTab[d.quersumme - 1] * (d.quersumme - d.d0))
                       / (fakTab[d.d0] * fakTab[d.d1] * fakTab[d.d2] * fakTab[d.d3]
                        * fakTab[d.d4] * fakTab[d.d5] * fakTab[d.d6] * fakTab[d.d7] 
                        * fakTab[d.d8] * fakTab[d.d9])
                            ;
          allCombs += combs;
          d.Increment();
       }
       Console.WriteLine("{0} Kombinationen", allCombs);
    

    Diese Schleife läuft bei mir in ca 2 Minuten durch und ermittelt 9,626183655 E+82 mögliche n. Ich hätte es aber auch schneller haben können. Alle z, deren Quersumme unter 50 liegt, haben eine Quersumme, deren Fakultät die um viele Größenordnungen kleiner ist als die Fakultät der maximalen Quersumme 90 (10^73). Bei 70 ist es noch 10^38, aber es kommt auch der Effekt des kleineren Nenners hinzu, darum sieht man da schon erste Abweichungen:

            9999999999 z gerechnet: 9,62618365528156E+82 - 125s
    q > 50, 2750633666 z gerechnet: 9,62618365528156E+82 -  63s
    q > 70,   19106230 z gerechnet: 9,62618365528149E+82 -  41s
    q > 75,    1951246 z gerechnet: 9,62618365316412E+82 -  38s 
    q > 80,      92378 z gerechnet: 9,62615856375375E+82 -  37,6s
    q > 99,       nichts gerechnet:                      -  37,5s
    

    Unter 37 komme ich nicht, das ist der Anteil der Increment-Methode.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. Update: Verzichtet man auf die Digits-Struktur und inlined ihre Eigenschaften und die Increment-Methode, kommt man für q>50 auf 49s und für q>70 auf 26s Laufzeit. Das ist dann wieder die Größenordnung für den Increment und das beste, was mein PC single-threaded hergibt

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Update: C++ ist so schlecht gar nicht; ich habe mir den C++ Compiler (Microsoft) jetzt nachinstalliert. Mit inline-Increment und q>50 läuft das C++ Programm in 32 Sekunden durch

        Rolf

        --
        sumpsi - posui - obstruxi
        1. @@Rolf B

          … läuft das C++ Programm in 32 Sekunden durch

          Wozu braucht Gott ein Raumschiff Programm? 😏

          🖖 Stay hard! Stay hungry! Stay alive! Stay home!

          --
          Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
    2. @@Rolf B

      (wieso funktionieren \align-Umgebungen nicht mehr⁉️)

      Ja, dieses LaTeX-Dingens mit eingeschränktem Funktionsumfang, was jetzt im CForum 5 am Start ist, finde ich auch nicht gut. Das macht mindestens ein Dutzend Postings von mir im Archiv unleserlich.

      Lässt sich da was machen, @Christian Kruse?

      🖖 Stay hard! Stay hungry! Stay alive! Stay home!

      --
      Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
      1. Hallo Gunnar,

        Lässt sich da was machen, @Christian Kruse?

        Das hier ist die Mathjax-Konfiguration:

        window.MathJax = {
          displayAlign: "left",
          messageStyle: "none",
          showMathMenu: false,
          menuSettings: { CHTMLpreview: false },
          tex2jax: {
            inlineMath: [['$$', '$$']],
            displayMath: [],
            preview: "none",
            processEscapes: true
          }
        };
        

        Ich bin offen für Vorschläge.

        Freundliche Grüße,
        Christian Kruse