Mehrere Werte in eine Variable eingeben...

[Sone]

volkard schrieb:

Sone schrieb:

Du hast mich aber gerade auf eine Idee gebracht, die sich mit Boost.Gregorian schön lösen lässt: Jemand gibt sein Geburtsdatum an, und dann wird je nach aktuellem Datum angezeigt, wie alt der User in Jahren ist. Mit Fließkommazahl.

Wieviele Tage hat ein Jahr?

Kannst du deine kryptischen Suggestivfragen bitte unterlassen?

[SeppJ]

Sone schrieb:

Kannst du deine kryptischen Suggestivfragen bitte unterlassen?

Dann mache ich das in volkards Namen als Aufforderung: Nenn doch mal alle Möglichkeiten die bei einer tagesgenauen Zeitauflösung vorkommen können.

[Sone]

SeppJ schrieb:

Sone schrieb:

Kannst du deine kryptischen Suggestivfragen bitte unterlassen?

Dann mache ich das in volkards Namen als Aufforderung: Nenn doch mal alle Möglichkeiten die bei einer tagesgenauen Zeitauflösung vorkommen können.

Ich hab schon verstanden, worauf er hinaus will. Das mindert doch nicht im Geringsten den Spaß an der Sache.

[ca.]

volkard schrieb:

Wieviele Tage hat ein Jahr?

365,24

[Ein ehemaliger Benutzer]

So, hat alles geklappt! Danke für die Hilfe!
Hier der Code mit der Summe des Alters.

#include<iostream>
using namespace std;

float alter=0;
float summealter=0;
int eingabe;

int main()
{
	marke:;
	cout<<"1=Eingabe;Alles andere Ausgabe!\n";
	cin>>eingabe;

if(eingabe==1)
        {
do
	{
	cout<<"Bitte geben Sie Ihr Alter ein!\n";
	cin >> alter;
	summealter += alter;
	}

while   ( alterl <=0 );

	goto marke;
}

else

	cout<<alter<<"\n";
	cout<<summealter;
	system("pause");

}

[SeppJ]

Tu dir doch selbst einen Gefallen und versuch dieses Programm noch einmal zu schreiben. Dieses mal benutzt du kein goto^* und alle Variablen sind so lokal wie du sie nur irgendwie machen kannst.

^*: Zur besseren Übung versuch auch ohne break oder continue auszukommen.

[und]

wo ist jetzt das durchschnittsalter?

[berniebutt]

Im Sinne der gestellten Frage sind einige Antworten hier Schrott.
Eine Variable hat momentan jeweils nur einen Wert. Für solche Aufgaben verwendet man besser mehrere Variable: Eingabe, Anzahl der Eingaben, Summe, Ergebnis. Man probiert es oder liest ein Einsteigerbuch!
Ist das überhaupt ein Thema für C++ ? Wenn als Durchschnittsalter 2375 geliefert wird, könnte ein Fehler vorliegen. daddeldu! :p

[Ein ehemaliger Benutzer]

und schrieb:

wo ist jetzt das durchschnittsalter?

Natürlich nicht in dem Code
habe nur nach der Möglichkeit gesucht, mehrere Werte in einer Variablen einzugeben bspw für ein Durschnittsalter...

Ich gucke mal nach dem goto und probiere es zu ändern.
Das ist aber auch nicht das Hauptprogramm, hab nur kurz aus meinem code die einzelnen Schnipsel zusammengesucht

[volkard]

Sone schrieb:

volkard schrieb:

Sone schrieb:

Du hast mich aber gerade auf eine Idee gebracht, die sich mit Boost.Gregorian schön lösen lässt: Jemand gibt sein Geburtsdatum an, und dann wird je nach aktuellem Datum angezeigt, wie alt der User in Jahren ist. Mit Fließkommazahl.

Wieviele Tage hat ein Jahr?

Kannst du deine kryptischen Suggestivfragen bitte unterlassen?

Daran war nichts kryptisch. Du hast selber sofort erkannt, daß man die Anzahl der Tage pro Jahr kaum noch sinnvoll angeben kann (sonst hättest du einfach das Ergenis hinschreiben können) und insbesondere nicht von boost.gregorian verraten bekommt. Damit ist die Aussage, es ließe sich mit boost.gregorian schön lösen völlig fölsch.

[seldon]

Naja, da gibt es schon Mittel und Wege. Du musst halt nur sinnvoll definieren, wo die Jahresschnitte sind -- das wird hier wohl der Geburtstag sein. Die vollen Jahre am Anfang fallen aus der Rechnung wunderbar als Integer raus, und den Anteil am letzten Jahr misst man halt mit der Tageszahl, die zwischen dem letzten und dem nächsten Geburtstag liegt.

Ich denke mir das etwa so:

#include <boost/date_time.hpp>

#include <iostream>
#include <string>

int main() {
  using boost::gregorian::date;
  using boost::gregorian::days;
  using boost::gregorian::partial_date;
  using boost::gregorian::from_simple_string;
  using boost::gregorian::day_clock;

  std::string iso_date;

  std::cout << "Geburtsdatum (YYYY-mm-dd): " << std::flush;
  std::getline(std::cin, iso_date);

  date bday(from_simple_string(iso_date));

  // TODO: 29. Februar behandeln.
  partial_date bday_template(bday.day(), bday.month());
  date today = day_clock::local_day();

  date bday_this_year = bday_template.get_date(today.year());

  date bday_last;
  date bday_next;

  if(today < bday_this_year) {
    bday_last = bday_template.get_date(today.year() - 1);
    bday_next = bday_this_year;
  } else {
    bday_last = bday_this_year;
    bday_next = bday_template.get_date(today.year() + 1);
  }

  double lebenszeit = bday_last.year() - bday.year() + static_cast<double>((today - bday_last).days()) / (bday_next - bday_last).days();

  std::cout << lebenszeit << '\n';
}

[volkard]

seldon schrieb:

Naja, da gibt es schon Mittel und Wege. Du musst halt nur sinnvoll definieren, wo die Jahresschnitte sind -- das wird hier wohl der Geburtstag sein. Die vollen Jahre am Anfang fallen aus der Rechnung wunderbar als Integer raus, und den Anteil am letzten Jahr misst man halt mit der Tageszahl, die zwischen dem letzten und dem nächsten Geburtstag liegt.

Mit dem supi Erfolg, daß meine Jahreslänge anders ist als Deine Jahreslänge und man damit keinen Dreisatz mehr durchführen kann. Schlimmer noch, die Jahreslänge ist nicht nur von der Person abhängig, sondern auch davon, wie alt sie gerade ist und wechselt recht sprunghaft.
Die angebrochenen Jahre sollen mit so vielen Tagen gerechnet werden, wie die Gesamtzeit Tage pro Jahr hat. So langsam wird es zu einem interessanten Problem: Ist die Jahrestageanzahl dann überhaupt noch eindeutig?? Oder könnten zwei Lösungen (eine gerade mit dem 29.2. und eine gerade ohne) parallel beide korrekt sein? Ops, vier Lösungen natürlich. Oder drei? Wie alt muß jemand sein, damit vier Lösungen möglich sind? Wann habe ich Geburtstag und wie alt bin ich, wenn meine Jahre 365.247344562432298721 Tage lang sind? Aber im Sinne der ursprünglichen Aufgabenstellung kann das nicht mehr sein.

seldon schrieb:

Naja, da gibt es schon Mittel und Wege. Du musst halt nur sinnvoll definieren, wo die Jahresschnitte sind

sinnvoll! Da ist das Problem. Man kann das Problem auch direkt lösen. Da gibt es Mittel und Wege. Du musst halt nur sinnvoll definieren, wo die Jahresschnitte sindwas 0 geteilt durch 0 ergibt.

seldon schrieb:

-- das wird hier wohl der Geburtstag sein.

Wohl kaum. Warum? Und falls ja, warum doch nicht?

seldon schrieb:

Die vollen Jahre am Anfang fallen aus der Rechnung wunderbar als Integer raus, und den Anteil am letzten Jahr misst man halt mit der Tageszahl, die zwischen dem letzten und dem nächsten Geburtstag liegt.

Ich denke mir das etwa so:

Ich denke, Du hast Dich von der Implementierung leiten lassen und begründest sie im Nachhinein.

Sagen wir mal, daß der Ansatz mit der personenbezogenen Zeitgeschwindigkeit Mist ist. Aber was nehmen wir dann? Derzeit hat ein Jahr 365 Tage. Neulich waren es 366. Im 20. Jahrhundert hatte ein Jahr 365.25 Tage. Zur Zeit 365.24 Tage. Sollte man für einen Menschen genau so zwischen 365.25 und 365.24 annehmen, wie weit er ins 20. bez. 21. Jahrhundert eingetaucht ist? Vorsicht, wieder mehrere Lösungen. Oder die lange Periode nehmen, wo sich der Kalender wiederholt? Da würde ich mich aber ungerecht behandelt fühlen, weil ich finde, daß das eher für Leute im 1800 passt aber nicht und genau gar nicht für Leute um 2000.

Als Programmieraufgabe ist das nur halbwegs sinnvoll, wenn man dabei definiert, wieviele Tage ein Jahr hat und wenn man dazusagt, daß man genau weiß, daß die Aufgabe totaler Unfug ist und nicht als Übung verstanden werden sollte, die später in kommerzielle Software einfließt.

Ich würde den Problemfall gerne auf den Punkt bringen mit der Frage "Wieviele Tage hat ein Jahr?".

[seldon]

volkard schrieb:

Mit dem supi Erfolg, daß meine Jahreslänge anders ist als Deine Jahreslänge und man damit keinen Dreisatz mehr durchführen kann. Schlimmer noch, die Jahreslänge ist nicht nur von der Person abhängig, sondern auch davon, wie alt sie gerade ist und wechselt recht sprunghaft.

Dass die Länge eines Lebensjahres vom Geburtstag der Person abhängt, liegt in der Natur der Sache. Und dass mein jetztiges Lebensjahr sich in der Länge von deinem unterscheiden kann, auch. (Fußnote 1)

volkard schrieb:

Die angebrochenen Jahre sollen mit so vielen Tagen gerechnet werden, wie die Gesamtzeit Tage pro Jahr hat.

Das macht aus meiner Sicht keinen Sinn. Wenn du auf die Art vorgehst, sind die selben Kalendertage zweier aufeinander folgender Jahre nur in Sonderfällen genau ein Jahr voneinander entfernt. Jahre sind in Tagen nicht gleich lang, also kannst du Tage und Jahre nicht einfach linear aufeinander mappen.

volkard schrieb:

seldon schrieb:

-- das wird hier wohl der Geburtstag sein.

Wohl kaum. Warum? Und falls ja, warum doch nicht?

Weil es sich um Lebensjahre handelt. Die beginnen halt am Geburtstag.

volkard schrieb:

Als Programmieraufgabe ist das nur halbwegs sinnvoll, wenn man dabei definiert, wieviele Tage ein Jahr hat und wenn man dazusagt, daß man genau weiß, daß die Aufgabe totaler Unfug ist und nicht als Übung verstanden werden sollte, die später in kommerzielle Software einfließt.

Das ist ein Standpunkt, den du mal mir der ICMA (oder wahlweise deiner Bank) besprechen solltest. Die wären sehr daran interessiert, dass act/act totaler Unfug ist und nicht kommerziell verwendet werden sollte.

volkard schrieb:

Ich würde den Problemfall gerne auf den Punkt bringen mit der Frage "Wieviele Tage hat ein Jahr?".

Wenn ein Schalttag im Jahr liegt 366, sonst 365.

Aber eigentlich ist die Frage eher: wieviele Jahre ist ein Tag lang? Das ist entsprechend 1/366 oder 1/365, und damit läuft es letztendlich darauf hinaus, wo man die Jahre anfangen und enden lässt. Bei Lebensjahren halte ich, wie gesagt, den Geburtstag für die natürliche Wahl.

(Fußnote 1): Wenn die Zeitspanne auf ein einheitliches Raster gelegt werden soll, um besser vergleichen zu können (und es nicht möglich/sinnvoll ist, mit Tagen zu rechnen), kann das Verfahren angepasst werden, indem man einen einheitlichen Rasterpunkt festlegt (sinnvollerweise vermutlich den Beginn des Kalenderjahres; so macht das jedenfalls die ISDA). Die Berechnung wird dadurch insofern etwas komplizierter, als dass nicht nur der gebrochene Teil am Ende, sondern analog auch der am Anfang erfasst werden muss, aber das ist beherrschbar.

[volkard]

seldon schrieb:

Das ist ein Standpunkt, den du mal mir der ICMA (oder wahlweise deiner Bank) besprechen solltest. Die wären sehr daran interessiert, dass act/act totaler Unfug ist und nicht kommerziell verwendet werden sollte.

Offensichtlich ist act/act keine soo natürliche Wahl, sonst gäbe es wohl dieses Chaos da nicht.

seldon schrieb:

Aber eigentlich ist die Frage eher: wieviele Jahre ist ein Tag lang?

Scherzkeks.

seldon schrieb:

Das ist entsprechend 1/366 oder 1/365, und damit läuft es letztendlich darauf hinaus, wo man die Jahre anfangen und enden lässt. Bei Lebensjahren halte ich, wie gesagt, den Geburtstag für die natürliche Wahl.

Mit dem Effekt, daß der ältere Bruder 25,27391 während sein jüngerer Bruder 25,27397 Jahre alt ist.
Ach nöö.

[seldon]

volkard schrieb:

Offensichtlich ist act/act keine soo natürliche Wahl, sonst gäbe es wohl dieses Chaos da nicht.

Das ist nicht ganz von der Hand zu weisen, obwohl sich da vieles daraus erklärt, dass man ganz früher mit Bleistift und Papier gerechnet hat (30 Tage pro Monat, 360 Tage pro Jahr ist auch mit Taschenrechner noch deutlich einfacher zu bewältigen) oder sich in dem Bereich, um den es geht, nur um Tage kümmert und die Jahre einem echt egal sind (so erklärt sich act/360). Heute, wo die alle Computer haben, ist act/act aber in den meisten Bereichen Standard.

volkard schrieb:

seldon schrieb:

Aber eigentlich ist die Frage eher: wieviele Jahre ist ein Tag lang?

Scherzkeks.

Das ist nicht das selbe, auch wenn's auf den ersten Blick so aussieht. Oder, alternative Formulierung: Wenn du wissen willst, wie viele Tage ein Jahr lang ist, muss erst geklärt werden, was du mit "Jahr" meinst.

volkard schrieb:

Mit dem Effekt, daß der ältere Bruder 25,27391 während sein jüngerer Bruder 25,27397 Jahre alt ist.
Ach nöö.

Ich nehme an, du meinst 25,27322 und 25,27397 (25 Jahre und 100 Tage). Das ist aber halt so, wenn im 26. Lebensjahr des älteren Bruders ein Schalttag liegt und in dem des jüngeren nicht. Sonst wäre der ältere Bruder ja an seinem 26. Geburtstag 26,0027397 Jahre alt.

[volkard]

seldon schrieb:

volkard schrieb:

Mit dem Effekt, daß der ältere Bruder 25,27391 während sein jüngerer Bruder 25,27397 Jahre alt ist.
Ach nöö.

Ich nehme an, du meinst 25,27322 und 25,27397 (25 Jahre und 100 Tage).

Nein. Ich meine
25+100.25/366=25.27391 < 25+100/365=25,27397
Aber ich meine nicht das Alter zweier jetzt lebende Brüder, sondern rechne ihre Lebenszeit aus, damit die End-Zeitpunkte in verschiedenen Jahren landen können.

Der der mehr Stunden gelebt hat, hat zugleich weniger Jahre gelebt nach Deiner Rechnung.

seldon schrieb:

Das ist aber halt so,

Eben nicht.
Da stimmt irgendwas nicht.

seldon schrieb:

Sonst wäre der ältere Bruder ja an seinem 26. Geburtstag 26,0027397 Jahre alt.

Jo, ein Problem. Eins, das ich nicht zufriedenstellend lösen kann. Ich kann nur Mumpitz definieren und dann die Definition befolgen. Oder eine Mumpitzdefinition, die von verschiedenen Institutionen empfohlen wird, nachschlagen.
Fast immer nehme ich 365.2425 Tage.

(Auch klar, daß ein Astronom nicht immer act/act verwendet.)

[seldon]

volkard schrieb:

Nein. Ich meine
25+100.25/366=25.27391 < 25+100/365=25,27397
Aber ich meine nicht das Alter zweier jetzt lebende Brüder, sondern rechne ihre Lebenszeit aus, damit die End-Zeitpunkte in verschiedenen Jahren landen können.

Der der mehr Stunden gelebt hat, hat zugleich weniger Jahre gelebt nach Deiner Rechnung.

Jahre sind halt stumpf nicht alle gleich lang. Ich halte das Ergebnis daher nicht für problematisch.

Dass Astronomen anders rechnen, ist klar. Die kümmern sich bei ihren Berechnungen aber auch nicht um Geburtstage und Lebensjahre (und haben auch keine Entsprechungen). Und auch die können Tage nicht linear auf Jahre hochrechnen, weil die Erddrehung sich im Laufe der $lange_zeit verlangsamt, sie sich eh nicht gleichmäßig dreht und die Erde sich zu allem Übel auch noch ungleichmäßig um die Sonne bewegt. Das Universum ist ziemlich schlampig entworfen, wenn du mich fragst.

Da wir aber bei Geburtstagen sind, lass uns bei Kalenderjahren bleiben und froh sein, dass wir keinen Mond- bzw. lunisolaren Kalender haben.

[volkard]

seldon schrieb:

Da wir aber bei Geburtstagen sind, lass uns bei Kalenderjahren bleiben und froh sein, dass wir keinen Mond- bzw. lunisolaren Kalender haben.

Und bei ganzen Zahlen bitte. So ist es auch üblich.

Die gebrochenen Jahre nur bei Zinsrechnung als Zwischenergebnis, das nicht nach außen getragen wird.

[MultiStrikeAUT]

Benutze doch vectoren z.b.:

vector<int> vecint;

und dann:
int tmp;
cin >> tmp;
vecint.push_back(tmp);

[volkard]

MultiStrikeAUT schrieb:

Benutze doch vectoren z.b.:

vector<int> vecint;

und dann:
int tmp;
cin >> tmp;
vecint.push_back(tmp);

Das Aufsummieren löst es doch viel direkter.
Bei vector müßte er danach auch aufsummieren. Erst zu speichern ist nicht zwingend.