1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus

Th69

Der rekursive Ansatz ist eleganter, aber ob @Luckyingmar den hinkriegt?

SeppJ

@Th69 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

@Schlangenmensch: Ja, genau.

Der rekursive Ansatz ist eleganter, aber ob @Luckyingmar den hinkriegt?

Ich würde sogar darauf wetten, dass es bei der Übungsaufgabe genau darum geht, Rekursion zu üben. Um was sollte es sonst gehen? Das Aufstellen einer kombinatorischen Formel wäre interessante Mathematik, aber man würde nichts über Programmierung lernen. Dann bliebe als Alternative noch das manuelle Abwickeln der Rekursion. Aber das wäre doch sehr anstrengend im Vergleich zur Rekursion, und damit wahrscheinlich nicht das Ziel.

also iterativ könnte man 4 (bzw. der anzahl der verschiedenen geldstücke entsprechend viele) for-schleifen über 0 bis zum maximalwert laufen lassen und den zähler immer dann erhöhen, wenn die gleichung erfüllt ist.

TGGC

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

also iterativ könnte man 4 (bzw. der anzahl der verschiedenen geldstücke entsprechend viele) for-schleifen über 0 bis zum maximalwert laufen lassen und den zähler immer dann erhöhen, wenn die gleichung erfüllt ist.

Das ist aber nicht nur kompliziert zu programmieren und warten sondern auch noch eine sehr aufwendige Art, wenn man nur die Anzahl braucht.

#include <stdio.h>
#include <time.h>

#define ival 1
#define jval 2
#define kval 5
#define lval 10

int main()
{
        int i;
        int j;
        int k;
        int l;

        struct timespec t1;
        struct timespec t2;

        int betrag;
        int moeglichkeiten;

        int maxi;
        int maxj;
        int maxk;
        int maxl;

        int anzahl = 0;

        printf("Betrag (ct): ");
        scanf("%d", &betrag);

        maxi = betrag / ival;
        maxj = betrag / jval;
        maxk = betrag / kval;
        maxl = betrag / lval;

        clock_gettime(CLOCK_REALTIME, &t1);

        for(i = 0; i <= maxi; i++)
        {
                for(j = 0; j <= maxj; j++)
                {
                        for(k = 0; k <= maxk; k++)
                        {
                                for(l = 0; l <= maxl; l++)
                                {
                                        if(i * ival + j * jval + k * kval + l * lval == betrag)
                                        {
                                                anzahl++;
                                        }
                                }
                        }
                }
        }

        clock_gettime(CLOCK_REALTIME, &t2);

        printf("Anzahl Kombinationen: %d\n", anzahl);
        printf("Benoetigte Zeit: %ld s %ld ns\n", t2.tv_sec - t1.tv_sec, t2.tv_nsec - t1.tv_nsec);

        return 0;
}

root@FreeBSD:/home/ralf # cc -O2 -o kombtest kombtest.c && ./kombtest
Betrag (ct): 1000
Anzahl Kombinationen: 1712051
Benoetigte Zeit: 10 s 55022303 ns
root@FreeBSD:/home/ralf # cc -O2 -o kombtest kombtest.c && ./kombtest
Betrag (ct): 100
Anzahl Kombinationen: 2156
Benoetigte Zeit: 0 s 2140391 ns

sie funktioniert aber. also die zeiten sind von meinem experimentier-board mit 1 GHz taktrate oder so. wenn man das ganze mit 4 GHz und parallelisiert betreiben würde, sähen die zeiten sicherlich anders aus. rekursion ist nach meinem wissen auch immer deutlich langsamer.

edit: ich hab die programmfehler mal korrigiert. natürlich <= maxi, maxj usw. und nicht < maxi, maxj, ...

Swordfish

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

sie funktioniert aber.

Es hat doch niemand gesagt, daß es nicht funktioniert. Es ist halt die naive Brute-Force-Lösung.

@Swordfish sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

sie funktioniert aber.

Es hat doch niemand gesagt, daß es nicht funktioniert. Es ist halt die naive Brute-Force-Lösung.

die reicht doch für den anfang, oder? also wenn ich irgendetwas berechnen muss und vor allem an dem ergebnis interessiert bin, ist es ja eigentlich egal, ob dieses ergebnis sofort oder nach einigen stunden auftaucht, oder? also optimieren kann man ja immer noch.

SeppJ

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

die reicht doch für den anfang, oder? also wenn ich irgendetwas berechnen muss und vor allem an dem ergebnis interessiert bin, ist es ja eigentlich egal, ob dieses ergebnis sofort oder nach einigen stunden auftaucht, oder? also optimieren kann man ja immer noch.

Das hier ist offensichtlich eine Programmierübungsaufgabe. Da geht es nicht um das Ergebnis, sondern um die möglichst optimale Umsetzung. Dazu gehört natürlich auch eine Diskussion verschiedener Möglichkeiten.

TGGC

@Wade1234

Also wenn die simple Lösung nur 3 Zeilen hat und auch die Variante mit allen 8 Münzen in Sekundenbruchteilen löst, frag ich mich schon wo der Sinn ist deine Variante überhaupt einzutippen? Optimiert ist das von mir beschriebene noch gar nicht, denn dabei würde man die Zwischenschritte in einer Matrix cashen.

@SeppJ sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

die reicht doch für den anfang, oder? also wenn ich irgendetwas berechnen muss und vor allem an dem ergebnis interessiert bin, ist es ja eigentlich egal, ob dieses ergebnis sofort oder nach einigen stunden auftaucht, oder? also optimieren kann man ja immer noch.

Das hier ist offensichtlich eine Programmierübungsaufgabe. Da geht es nicht um das Ergebnis, sondern um die möglichst optimale Umsetzung. Dazu gehört natürlich auch eine Diskussion verschiedener Möglichkeiten.

da hast du natürlich recht. ich habe halt schon einmal die erste funktionierende möglichkeit geliefert. also wenn man irgendwann einmal in die situation gerät, irgendetwas derartiges zu berechnen, dann bekommt man das schon einmal hin.

schöner wäre vielleicht der aufruf entsprechender funktionen, um das ganze noch weiter zu verallgemeinern und sie summierung von zwischenergebnissen und der abbruch der berechnung bei überschreitung der gesamtsumme.

@TGGC sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

@Wade1234

Also wenn die simple Lösung nur 3 Zeilen hat und auch die Variante mit allen 8 Münzen in Sekundenbruchteilen löst, frag ich mich schon wo der Sinn ist deine Variante überhaupt einzutippen? Optimiert ist das von mir beschriebene noch gar nicht, denn dabei würde man die Zwischenschritte in einer Matrix cashen.

wie sähe die simple lösung mit 3 zeilen denn aus?

Swordfish

@Wade1234 sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

wie sähe die simple lösung mit 3 zeilen denn aus?

template<typename T>
int count_solutions(int amount, T const &coins, typename T::size_type index = 0)
{
	if (amount == 0) return 1;	
	if (amount < 0 || coins.size() == index) return 0;
	return count_solutions(amount - coins[index], coins, index) + count_solutions(amount, coins, index + 1);
}

Schlangenmensch

Und in C

Swordfish

@Schlangenmensch Keine Ahnung? Analog?

TGGC

@Schlangenmensch
int calc(int s, int l, int* c)
{
if (l < 2) return s % c[l] ? 0 : 1;
if (s < c[l] ) return calc(s,l-1, c);
return calc(s,l-1,c) + calc(s-c[l],l,c);
}

Luckyingmar

Vielen Dank für die fleißigen Antworten!
Bei der Aufgabe ist es egal, ob sie iterativ oder rekursiv gelöst wird...
Da ich bisher viele Aufgaben iterativ gelöst habe, freue ich mich über rekursive Ansätze für meine Aufgabe.

Luckyingmar

Das sind unsere heutigen Ansätze:

#include <stdio.h>
#include <stdlib.h>

int arra[]= {1, 2, 5, 10};
int muenzwert(int betrag)
{
int zahler =0;
int i =0;
    
    if(betrag<=0)
    {
        return 1;
    }
    else
    {

        while(i<4)
        {
            zahler+=muenzwert(betrag-arra[i]);
            i++;
        }
        return zahler;
        printf("%d", zahler);
    }
    return 0;

}

int main()
{
    int eingabe;
    scanf("%i", &eingabe);
    printf("%i", muenzwert(eingabe));


    return 0;
}

oder

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int muenzwert(int c1=1, int c2=2, int c5=5, int c10=10)
    if(betrag<=0)
    {
        return 1;
    }
    else
    {
        c1*1+c2*2+c5*5+c10*10=betrag;
    }
    return 0;

int main(void)
{
    int betrag;
    printf("Geben Sie einen Centbetrag zwischen 1 und 100 ein: ");
    scanf("%i", &betrag);

    printf("\n\nFuer %i Cent gibt es %i Moeglichkeiten der Bezahlung.", betrag, zaehler);

    return 0;
}

funktionieren nur noch nicht richtig.

SeppJ

So allgemein, fiel mir schon bei deiner ersten Frage auf, dass du dies lesen solltest: https://www.c-plusplus.net/forum/topic/200753/du-brauchst-hilfe
Besonders den Abschnitt darüber, wie man Probleme nachvollziehbar macht und wie man Fragen richtig stellt.

Du klatscht hier Code hin, der teilweise nicht einmal compilierbar ist, und sagst bloß "geht nicht". Was soll dir da jemand helfen?

Luckyingmar

@SeppJ
Der obere funktioniert er rechnet lange und kommt zu einem nicht richtigen Ergebnis. Im Debugger ist erkennbar das er immer wieder in die erste if hineingeht, dass ist für mich unverständlich warum er das macht.
Den zweiten Code hat meine Studienkollegin geschrieben, mit der ich mich immer austausche.

TGGC

Euch fehlen Grundlagen und ihr werdet daher dieses Problem nicht lösen, wenn ihr die nicht nachholt. Ihr werdet maximal irgendwas zusammenkopieren, was zufällig den richtigen Wert berechnet und nicht verstehen warum.

SeppJ

@Luckyingmar sagte in 1 bis 100 Centbeträge Möglichkeiten/Kombinationen Algorithmus:

@SeppJ
Der obere funktioniert er rechnet lange und kommt zu einem nicht richtigen Ergebnis. Im Debugger ist erkennbar das er immer wieder in die erste if hineingeht, dass ist für mich unverständlich warum er das macht.
Den zweiten Code hat meine Studienkollegin geschrieben, mit der ich mich immer austausche.

Beim ersten Code: Das ist schon korrekt, dass er oft (aber nicht immer!) in den ersten Fall läuft. Die Bedingung <= 0 umfasst schließlich auch all die Fälle, die nicht aufgehen und das sind halt ziemlich viele. Da ist aber auch gleich einer der Fehler: Du zählst all diese Fälle, wo es nicht passt, als 1. Kein Wunder, dass das viel zu viele sind. Du brauchst eine Unterscheidung nach

Es passt nicht und zählt dann als nichts
Es geht genau auf und zählt als 1
Es ist noch nicht fertig und wir müssen weiter machen, bis wir bei 1 oder 2 sind.

Selbst wenn du das korrigierst, werden es aber trotzdem zu viele Möglichkeiten sein. Wenn du bei deinem Programm 4 Cent aufteilen wolltest, würdest du nämlich folgende Möglichkeiten zählen:
1+1+1+1
2+2
2+1+1
1+2+1
1+1+2
Was aber auch zu viele sind, da die Reihenfolge bei der Fragestellung egal sein sollte. Das zu lösen, überlasse ich dir. Oder lies den Rest des Threads aufmerksam, es wurde schon alles gesagt was zur Lösung nötig ist.

Der zweite Code ist indiskutabler Schrott.