Das deutsche Python-Forum

Dennis89 hat geschrieben: Montag 22. September 2025, 19:53 Ich kann von mir erfahrungsgemäß sagen, dass ich mich da "immer" in die falsche Richtung verrenne und bitte euch daher wieder um Hilfe.

Du versuchst, zu viel auf einmal zu machen. Da sind mehr Fehler als nur der bei `split`; das sagt mir, dass du zu viel Code geschrieben hast, bevor du das erste Mal kompiliert/getestet hast. Also wäre mein Tipp, da kleinteiliger ranzugehen. Erstmal nur einen String splitten, und dabei darüber nachdenken, was die möglichen Eingabedaten sind (alle Strings) und wie dabei das Ergebnis aussieht (zum Beispiel, wenn man `"a: b: c: d"` an `':'` splittet) und was für ein Typ dementsprechend dabei rauskommt, der die Ergebnisdaten für alle Eingabedaten repräsentieren kann (warum kann es kein zweielementiges Tupel sein?). Und als kleiner Tipp noch ein Link auf die Doku von `str::split`. Vielleicht gibt es da ja noch andere (ähnliche?) Methoden, die besser zu dem Problem passen, das du lösen willst?

Dann das zweite Split an den Leerzeichen. Dann das beides in eine Funktion packen und die Funktion dann für jede Zeile aufrufen. Und so weiter... Und nach jedem kleinen Schritt zumindest kompilieren, damit du möglichst früh Typfehler findest und nicht in Folgefehler läufst.

Spoiler: So würde ich mit minimalen Änderungen deinen Code kompilierbar machen: https://godbolt.org/z/x5adcrKKM und so sieht meine Lösung von letztem Jahr aus (Tag 7?): https://godbolt.org/z/WWshvdP63

Ach und weil du von tuple unpacking schreibst: Das ist ein Python-Begriff, das gibt es so in Rust nicht. In Python kann man jedes Iterable unpacken und bekommt eine Exception, wenn die Länge nicht passt. In Rust gibt es Pattern Matching; und da muss der Typ des Patterns auf den Typ des Wertes passen. Mit einem Tuple-Pattern kann man also nur (von der Länge und von den Elementtypen passende) Tuples matchen. Und `let` macht Pattern Matching.

Guten Morgen,

danke für die Erklärung und Hilfe.
Das `split` kann kein zweiteiliger Tuple sein, weil `split` jeden beliebigen String annimmt und der mehr als in nur zwei Teile gesplittet werden kann. Dabei liefert die Methode auch den Typ `Split<'_, &str>` im Vergleich zu `split_once`, das mir den Typ `Option<(&str, &str)>` liefert. Das ist natürlich viel mehr das, was ich auch will, denn wenn ich dann über die `lines` iteriere bekomme ich folgende Tuple `(&str, &str)'. Im Vergleich dazu bekomme ich mit `split` "nur" ein `&str`. Das war hilfreich, sich mal anzuschauen, was da eigentlich kommt.

Ja genau, Tag 7 stimmt. Genau so wie deine Lösung aussiehst, hatte ich mir das zu Beginn vorgestellt. Was man da alles so in der geschweiften Klammer machen kann, war bei mir ehrlich gesagt dann mehr raten und weil das nicht zielführend ist, dann der Umstieg auf die Schleife.

Dann schaue ich jetzt mal, wie ich mit dem Rest weiter komme. Falls meine Interpretation oben nicht ganz stimmen sollte, wäre es nett wenn ihr mich berichtigt.

Grüße
Dennis

Ich habe gerade deine Lösung auch noch versucht und `try_collect` ist noch nicht in der stabilen Version.

Code: Alles auswählen

error[E0658]: use of unstable library feature `iterator_try_collect`
  --> src/main.rs:15:18
   |
15 |                 .try_collect()?;
   |                  ^^^^^^^^^^^
   |
   = note: see issue #94047 <https://github.com/rust-lang/rust/issues/94047> for more information

Gibt es da eine Alternative dazu?

Dennis89 hat geschrieben: Dienstag 23. September 2025, 09:01 Im Vergleich dazu bekomme ich mit `split` "nur" ein `&str`.

Fast. Du bekommst einen Iterator, der dir `&str` liefert. Also beliebig viele `&str`.

`try_collect` macht aus einem `Iterator<Item = Result<T, E>>` ein `Result<Vec<T>, E>`. Das gleiche geht auch immer mit `collect`, aber da muss man in der Regel mehr Typannotationen schreiben, und da war ich zu faul für. Also `.collect::<Result<Vec<_>, _>>()?` in diesem Fall.

Vielleicht als kleine Übungsaufgabe, wenn du dir Generics und Traits anguckst: `collect` kennst du wahrscheinlich als Methode, die aus einem `Iterator<Item = T>` ein `Vec<T>` macht. `collect` ist allerdings wesentlich flexibler als das, z. B. der Fall hier mit dem `Iterator` von `Result`s nach `Result` von `Vec`. Wie funktioniert das? Welche Typen kann `collect` noch erzeugen? Wo ist das sinnvoll?

Für mich stellt sich hier beim Mitlesen die Frage, warum jemand freiwillig Rust benutzen möchte. Ich habe grundsätzlich nichts gegen Typangaben, finde sie sogar ganz praktisch. Aber hier grenzt es doch schon fast an Masochismus. Wieso macht es einem diese Sprache so kompliziert? Oder findet man das als Rust-Programmierer toll, dass man so viele komplexe Angaben machen muss, um etwas zu erreichen? Nichts gegen Vec<T> und ähnlichem, aber `.collect::<Result<Vec<_>, _>>()?` finde ich schon hart...

Ich bin mir nicht ganz sicher, ob ich deine Frage richtig verstanden habe. Das letzte `collect` wandelt in den Datentyp, der als Rückgabewert angegeben ist. Dass ist das gleiche Prinzip, wie wenn ich sowas wie `let name: String = (…).collect()` schreibe, da wird das, was auch immer in der Klammer steht zu einem String. Das wäre auch eine Antwort auf die zweit letzte Frage. `collect` kann alle Typen erzeugen, in denen man Daten „speichern/sammeln“ kann und daraus würde ich schließen, dass `collect` in alle Typen wandeln kann über die man iterieren kann.(?)`
`try_collect` bzw. die Typenangabe finde ich noch etwas verwirrend. Ich finde in der Doku von `map` und `split` beides mal nicht, dass da ein `Result`-Objekt zurück gegeben wird und im Code ist das einzige `Result`-Objekt das, das vom letzten `collect`benutzt wird. Ich hätte eher etwas wie `collect::>Vec<_>>()` an dieser Stelle erwartet.

Wo `collect` im Allgemeinen noch sinnvoll ist, kann ich nur raten bzw. es liegt nahe, dass es bei wandeln von Datentypen sinnvoll ist?

@snafu Ich wollte neben einer Interpretersprache noch eine weitere lernen und ich kann es auch nicht genau begründen, aber C++ war mir nicht sympathisch und Rust dagegen schon. Da es auch eine recht neue Sprache ist und ich neue „Sachen“ mag, habe ich mich dafür entschieden. Dass das mit den Typenangaben sehr aufwendig sein kann, hatte @__deets__ mal erwähnt. Da ich nicht weiß wie das bei anderen Sprachen ist, ist das für mich dann eher „normal“ zu lernen. Achja, das Logo von Rust ist auch toll

Danke undGrüße
Dennis

Nachtrag, das `Result`-Objekt kommt wegen des `?`. Je nach dem ob ein Fehler geworfen wird, gibt es den zurück oder es wird das Ergebnis verarbeitet, falls das Ok ist.

Code: Alles auswählen

fn parse_lines<'a>(
    lines: impl Iterator<Item = &'a str>,
) -> Result<Vec<(i32, Vec<i32>)>, Box<dyn Error>> {
    lines
        .map(|line| {
            let (target, operands) = line.split_once(": ").ok_or("No colon in line")?;
            let operands = operands
                .split(' ')
                .map(|operand| operand.parse())
                .collect::<Result<Vec<_>, _>>()?;
            Ok((target.parse()?, operands))
        })
        .collect()
}

fn main() {
    let input =
        read_to_string("/home/dennis/PycharmProjects/AdventofCode/2024/Day07/input07.txt").unwrap();
    let calibrations = parse_lines(input.lines());
    println!("{}", calibrations.is_ok());
}

Gibt allerdings

Code: Alles auswählen

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.26s
     Running `target/debug/day07`
false

aus. Wie gehe ich hier denn jetzt auf Fehlersuche? Ich habe hier absolut kein Hinweis bekommen und auch wenn ich `RUST_BACKTRACE=full` setze, bekomme ich nichts weiter.

Danke und Grüße
Dennis

Dennis89 hat geschrieben: Dienstag 23. September 2025, 21:10 @snafu Ich wollte neben einer Interpretersprache noch eine weitere lernen und ich kann es auch nicht genau begründen, aber C++ war mir nicht sympathisch und Rust dagegen schon.

Du hast IMHO eine seltsame Vorstellung von "sympathischen" Programmiersprachen, aber ist ja Ansichtssache. Ich würde da wohl eher zu Go tendieren, das kommt mir deutlich verständlicher vor und orientiert sich ganz grob an C und C++.

Guten Morgen,

zur oben angesprochenen Fehlersuche, "meine" Funktion hatte `i32` und nicht `u64` wie @narpfel. Habe dann nachgeschaut und die größte Zahl in den Puzzel-Daten ist größer als die max. größte darstellbare Zahl mit 32 Bit, auch `unsigned`.
Wie geht man da grundsätzlich, unabhängig von Advent of Code, vor? Weiß man im realen Programmierleben immer dass beispielsweise 32 Bit reichen? Ob vorzeichenbehaftet oder nicht, das kann ich mir vorstellen, dass man die Einschränkung kennt. Wählt ihr "zur Sicherheit" auch lieber einen größeren Wert oder wird das vor dem programmieren wirklich so spezifiziert, das man sicher 32 Bit wählen kann?

Durch dass das ich keine Fehlermeldung bekam tendiere ich schon dazu immer 64 Bit zu wählen, nur das ist ja nicht der Sinn.

Danke und Grüße
Dennis

@Dennis89: Man schaut ob und wo man Laufzeitprüfung auf Wertebereiche aktivieren kann. Soweit ich weis prüft Rust das bei „dev“ Builds, aber nicht mehr bei „release“ Builds.

Ansonsten hat Rust da ja einen ganzen Zoo von Methoden neben den Operatoren. Also sowas wie `wrapping_add()`, `carrying_add()`, `checked_add()`, … wenn man sicher sein will was da genau passiert.

Danke für die Antwort.
Das von mir war ein `dev`-Build:

Code: Alles auswählen

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.26s
     Running `target/debug/day07`
false

Wie mir die Methoden bei der Fehlersuche helfen sollen verstehe ich noch nicht. Ich habe die Daten gelesen und weil ich den falschen Datentyp angegeben habe, war das wandeln der Daten nicht erfolgreich und dazu gab es keine Fehlermeldung. Unabhängig davon würde mich interessieren, wie ihr euch auf die Datentypen festlegt? Hier habe ich alle Eingabedaten und könnte prüfen, ob 32 Bit für alle reichen, aber das wird im echten Leben ja nicht so sein.

Grüße
Dennis

Dennis89 hat geschrieben: Samstag 27. September 2025, 13:07 und dazu gab es keine Fehlermeldung.

Doch, du bekommst eine Fehlermeldung. Du ignorierst sie nur explizit.

Du meinst sicherlich, dass ich im Code irgendwo etwas stehen habe, dass die Meldung unterdrückt? Denn ich komme beim besten Willen nicht drauf, was du meinst.

Danke und Grüße
Dennis

@Dennis89: Du fragst am Ende ob das Ergebnis okay ist, das ist es nicht. Mehr machst Du ja nicht. Du fragst weder den konkreten Fehler ab, noch versuchst Du das Ergebnis abzufragen, wo dann ja der Fehler den Programmabbruch mit Fehlermeldung zur Folge hätte.

Achsooo, ich hätte das Result-Objekt richtig behandeln sollen, so zum Beispiel:

Code: Alles auswählen

fn main() {
    let input =
        read_to_string("/home/dennis/PycharmProjects/AdventofCode/2024/Day07/input07.txt").unwrap();
    let calibrations_result = parse_lines(input.lines());
    let calibration = match calibrations_result {
        Ok(values) => values,
        Err(error) => panic!("Error: {error:?}"),
    };

Dann erhalte ich mit 32 Bit, folgende Meldung:

Code: Alles auswählen

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.91s
     Running `target/debug/day07`

thread 'main' panicked at src/main.rs:68:23:
Error: ParseIntError { kind: PosOverflow }
stack backtrace:
   0:     0x55ce5b4a2e82 - std::backtrace_rs::backtrace::libunwind::trace::h2d45396358f41939
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
   1:     0x55ce5b4a2e82 - std::backtrace_rs::backtrace::trace_unsynchronized::hffcefc0b67f1d6e2
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14
   2:     0x55ce5b4a2e82 - std::sys::backtrace::_print_fmt::hd72f71d23b436b92
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/sys/backtrace.rs:66:9
   3:     0x55ce5b4a2e82 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hdcfcb6d4c8489523
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/sys/backtrace.rs:39:26
   4:     0x55ce5b4bea03 - core::fmt::rt::Argument::fmt::h2c56b3114963061a
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/fmt/rt.rs:173:76
   5:     0x55ce5b4bea03 - core::fmt::write::h8a494366950f23bb
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/fmt/mod.rs:1468:25
   6:     0x55ce5b4a0b93 - std::io::default_write_fmt::ha27fbccbc65eb6fa
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/io/mod.rs:639:11
   7:     0x55ce5b4a0b93 - std::io::Write::write_fmt::h6556609fca33d0b1
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/io/mod.rs:1954:13
   8:     0x55ce5b4a2cd2 - std::sys::backtrace::BacktraceLock::print::hb2a626a81e06b2dc
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/sys/backtrace.rs:42:9
   9:     0x55ce5b4a3d63 - std::panicking::default_hook::{{closure}}::h4f78485264f12d10
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:300:27
  10:     0x55ce5b4a3b45 - std::panicking::default_hook::h2c66fc99e962531d
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:327:9
  11:     0x55ce5b4a4635 - std::panicking::rust_panic_with_hook::h33ac55f64bbd807d
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:833:13
  12:     0x55ce5b4a44ca - std::panicking::begin_panic_handler::{{closure}}::h30e7cb89678a57fe
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:706:13
  13:     0x55ce5b4a3379 - std::sys::backtrace::__rust_end_short_backtrace::hed60f27456c16ced
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/sys/backtrace.rs:174:18
  14:     0x55ce5b4a415d - __rustc[de2ca18b4c54d5b8]::rust_begin_unwind
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:697:5
  15:     0x55ce5b4bdcd0 - core::panicking::panic_fmt::h62f63d096dd276af
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/panicking.rs:75:14
  16:     0x55ce5b48131b - day07::main::hf1888efda1a1dd69
                               at /home/dennis/PycharmProjects/AdventofCode/2024/Day07/Rust/src/main.rs:68:23
  17:     0x55ce5b47e4bb - core::ops::function::FnOnce::call_once::he51c071a6ec35ef4
                               at /home/dennis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:253:5
  18:     0x55ce5b47fd8e - std::sys::backtrace::__rust_begin_short_backtrace::h8bbe765f3ddc2e71
                               at /home/dennis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:158:18
  19:     0x55ce5b47dcd1 - std::rt::lang_start::{{closure}}::hae39c16b771680fe
                               at /home/dennis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:206:18
  20:     0x55ce5b49e080 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h638295a043b40957
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/ops/function.rs:290:21
  21:     0x55ce5b49e080 - std::panicking::catch_unwind::do_call::hbd68098bdea1ca50
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:589:40
  22:     0x55ce5b49e080 - std::panicking::catch_unwind::h50591d85bf847c7c
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:552:19
  23:     0x55ce5b49e080 - std::panic::catch_unwind::h2487b4c4f2ae22c6
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panic.rs:359:14
  24:     0x55ce5b49e080 - std::rt::lang_start_internal::{{closure}}::h61f0945cc6c9a811
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/rt.rs:175:24
  25:     0x55ce5b49e080 - std::panicking::catch_unwind::do_call::h34b9c3722acd6bd1
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:589:40
  26:     0x55ce5b49e080 - std::panicking::catch_unwind::hf9a822ea043fb0d6
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:552:19
  27:     0x55ce5b49e080 - std::panic::catch_unwind::h5b3cac802237ed89
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panic.rs:359:14
  28:     0x55ce5b49e080 - std::rt::lang_start_internal::h34f9328d113fd60a
                               at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/rt.rs:171:5
  29:     0x55ce5b47dcb7 - std::rt::lang_start::h78fc075c575dcb43
                               at /home/dennis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:205:5
  30:     0x55ce5b48135e - main
  31:     0x7efe70553088 - __libc_start_call_main
  32:     0x7efe7055314b - __libc_start_main@GLIBC_2.2.5
  33:     0x55ce5b4790c5 - _start
  34:                0x0 - <unknown>

Den Teil am Anfang:

Code: Alles auswählen

Error: ParseIntError { kind: PosOverflow }

muss ich dann als Speicherfehler interpretieren und daraus auf dem Datentyp schließen, weil dass ja mein einziger Einfluss in dem Fall ist?
Aus dem Rest kann ich nichts rauslesen.

Danke und Grüße
Dennis

Ich weiss nicht ob ich das einen Speicherfehler nennen würde. Da kann etwas nicht als Int geparsed werden, weil es zu gross für ein Int ist.

Guten Morgen,

ich habe im Gesamten wohl noch einen Fehler, den ich nicht finde. Folgender Code funktioniert mit den Beispieldaten, aber mit dem individuellen Puzzel-Input bleibt er ununterbrochen bei dieser Eingabe hängen:
``15644706: 5 7 8 1 7 9 3 6 621 3 9 6``

Aus irgendeinem Grund endet die Schleife mit diesen Eingaben nicht. Was mich wundert, weil es mit den Beispieldaten funktioniert und auch mit richtigem Ergebnis.
Die Idee hinter der Lösungsfindung ist übrigens nicht von mir, hab das munter von @__blackjack__ abgeschaut.

Code: Alles auswählen

use itertools::Itertools;
use std::error::Error;
use std::fs::read_to_string;

fn add(a: &u64, b: &u64) -> u64 {
    a + b
}

fn multiply(a: &u64, b: &u64) -> u64 {
    a * b
}

fn parse_lines<'a>(
    lines: impl Iterator<Item = &'a str>,
) -> Result<Vec<(u64, Vec<u64>)>, Box<dyn Error>> {
    lines
        .map(|line| {
            let (target, operands) = line.split_once(": ").ok_or("No colon in line")?;
            let operands = operands
                .split(' ')
                .map(|operand| operand.parse())
                .collect::<Result<Vec<_>, _>>()?;
            Ok((target.parse()?, operands))
        })
        .collect()
}

fn check_calibration(target: &u64, values: &[u64]) -> bool {
    let mut multible_operations: Vec<_> = Vec::new();
    let length = values.len() - 1;
    for _ in 0..length {
        for operation in [add, multiply] {
            multible_operations.push(operation);
        }
    }
    for operations in multible_operations
        .iter()
        .combinations_with_replacement(length)
    {
        let mut values = values.iter();
        let mut result: u64 = *values.next().unwrap();
        for (operation, value) in operations.iter().zip(values) {
            let result_: u64 = operation(&result, value);
            result = result_;
        }
        if result == *target {
            return true;
        }
    }
    false
}

fn sum_solvable_calibrations(calibrations: &Vec<(u64, Vec<u64>)>) -> u64 {
    let mut solvable: Vec<u64> = Vec::new();
    for (target, values) in calibrations {
        if check_calibration(target, values) {
            solvable.push(*target);
        };
    }
    solvable.iter().sum()
}

fn main() {
    let input =
        read_to_string("/home/dennis/PycharmProjects/AdventofCode/2024/Day07/input07.txt").unwrap();
    let calibrations_result = parse_lines(input.lines());
    let calibrations = match calibrations_result {
        Ok(values) => values,
        Err(error) => panic!("Error: {error:?}"),
    };
    let sum_ = sum_solvable_calibrations(&calibrations);
    println!("{:?}", sum_)
}

Grüße
Dennis

Zur Frage wie man sich auf die Datentypen festlegt: Das hängt von den Eingabedaten, der Programmiersprache, dem Zielsystem, und wie wichtig Optimierung ist, ab. Also erst einmal muss der Datentyp natürlich den Wertebereich der Eingabedaten abdecken, sonst kann das Programm nicht alle möglichen Eingabedaten korrekt verarbeiten. Alles andere ist erst einmal nachrangig, solange es nicht direkt den Programmablauf verhindert.

Was das hängenbleiben betrifft: Geduld! Im schlechtesten Fall müssen bei 12 Operanden, 129.024.480 Operatorkombinationen durchprobiert werden. Also müssen natürlich nicht, aber Dein Code macht das. `combinations_with_replacement()` macht keinen Sinn, habe ich ich ja auch nicht verwendet. Du probierst da einen Haufen Kombinationen mehrfach. Das sieht man schon wenn man nur drei Operanden, also zwei Operationen hat:

Code: Alles auswählen

In [41]: list(itertools.combinations_with_replacement("+*" * 2, 2))
Out[41]: 
[('+', '+'),
 ('+', '*'),
 ('+', '+'),
 ('+', '*'),
 ('*', '*'),
 ('*', '+'),
 ('*', '*'),
 ('+', '+'),
 ('+', '*'),
 ('*', '*')]

In [42]: list(itertools.product("+*", repeat=2))
Out[42]: [('+', '+'), ('+', '*'), ('*', '+'), ('*', '*')]

Bei den 10 Kombinationen bei [41] sind 6 mehr als einmal dabei. Bei den 129.024.480 Kombinationen für den Fall mit den 11 Operatoren gibt es nur 2.048 unterschiedliche die man eigentlich nur prüfen müsste.

Danke für die Antwort.

Itertools für Rust hat kein `product` zumindest habe ich keins gefunden und mir schien `combinations_with_replacemet` als relativ ähnlich, daher das.
`product` selbst zu schreiben habe ich mir kurz überlegt und wäre evtl. auch ne gute Übung was Datentypen angeht und mal selbst einen Iterator zu erstellen, wollte aber erst mal das Problem lösen.

Dann lasse ich den Code einfach mal laufen und schaue was passiert.

Grüße
Dennis

Geduld ist schön ausgedrückt, habe die Laufzeit gemessen:

Code: Alles auswählen

10989.60064s runtime

Das deutsche Python-Forum

[Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten

Re: [Rust]Summe eines Vec mit Wahrheitswerten