c++ hochrechnen, negative dezimale werte
-
Ich würde mit dem Thema mal ins Mathematik-Forum...
-
ruebe schrieb:
Definitionen werden benötigt um sicherzustellen das man über die gleiche Sache redet.
Stimmt, das ist aber nicht alles. Schließlich hat die Definition des Ergebnisses nichts mit unserem Verständnis der Sache zu tun. Sie können schlicht nützlich sein, etwa um die Behandlung von Sonderfällen unnötig zu machen. Und hierbei liegt das Problem:
Um den Fall als Sonderfall zu eliminieren, muss die Definition so erfolgen, dass sie sich in die bereits vorhandenen Gesetzmäßigkeiten einfügt. Das ist bei 0^0 nicht möglich. Wir haben u.a.
n^0 = 1 (für alle natürlichen n >= 1)
0^n = 0 (für alle natürlichen n >= 1)
Egal wie wir 0^0 definieren, nicht beide Gesetzmäßigkeiten können gleichzeitig auf diese Definition ausgedehnt werden. Es kann trotzdem sinnvoll sein, ein Ergebnis zu definieren: dann wenn wir aufgrund der Natur der Sache oder wegen unserer Herangehensweise nur beschränkten Gebrauch von Gesetzmäßigkeiten oder Regeln machen, und die Definition innerhalb dieses bechränkten Satzes an Gesetzmäßigkeiten auf natürliche Weise erfolgen kann. Das ist dann aber notwendig keine allgemeine Definition mehr, sondern eine, die nur eingeschränkt Gültigkeit hat.
-
ruebe schrieb:
...
Mich würde auch interessieren woher du weist, das es mehr Gründe gibt 0^0 undefiniert zu lassen als zu definieren?Ich argumentiere hier "inert" - d.h. ich gebe "fail detector" den von ihm selbst ins Spiel gebrachten Wiki-Artikel zu lesen.
Es ist also nicht "meine Meinung", die ich hier rechtfertigen müsste, sondern fails eigenes Argument, das ihm widerspricht....Gruß,
Simon2.
-
Simon2 schrieb:
Ich argumentiere hier "inert" - d.h. ich gebe "fail detector" den von ihm selbst ins Spiel gebrachten Wiki-Artikel zu lesen.
Es ist also nicht "meine Meinung", die ich hier rechtfertigen müsste, sondern fails eigenes Argument, das ihm widerspricht....Gruß,
Simon2.
wie camper schon gesagt hat gibt es so wohl bei "1 ist eine primzahl" als auch bei "0^0==1" jeweils regeln die sich widersprechen. bei beiden aussagen gibt es gründe die dafür und welche die dagegen sprechen. bei beiden aussagen geht man so vor, dass sie sich gut in gegebene gesetzmäßigkeiten einfügen. die drei beispiele für die gesetzmäßigkeiten, in die sich "0^0==1" einfügt, habe ich achon aus dem wikipedia artikel zitiert:
1.) der binomische Satz
2.) Potenzreihen wie beispielsweise für die Exponentialfunktion
3.) Summenformel für die geometrische Reiheursprünglich ging es mir darum, zu unterstreichen, dass es bei diesem thema eben doch diskussionsbedarf gibt und es keinesfalls eindeutig ist.
-
fail detector schrieb:
...
ursprünglich ging es mir darum, zu unterstreichen, dass es bei diesem thema eben doch diskussionsbedarf gibt und es keinesfalls eindeutig ist."Eindeutig" würde auch nicht zu "undefiniert" passen.
Aber der Wiki-Artikel klingt schon ziemlich danach, als sähe ein Großteil der Fachwelt keinen wirklichen Diskussionsbedarf mehr, sondern hat Konsens darüber, dass eine Definition nicht helfen würde.
Gruß,
Simon2.
-
Simon2 schrieb:
Aber der Wiki-Artikel klingt schon ziemlich danach, als sähe ein Großteil der Fachwelt keinen wirklichen Diskussionsbedarf mehr, sondern hat Konsens darüber, dass eine Definition nicht helfen würde.
Gruß,
Simon2.
für die informatik und die implementierung von numerischen algorithmen spielt es eine rolle, und man hat konsens darüber, dass die definition, z. bsp. im anhang F.9.4.4 des c99 standards, dabei hilft.
-
fail detector schrieb:
Simon2 schrieb:
Aber der Wiki-Artikel klingt schon ziemlich danach, als sähe ein Großteil der Fachwelt keinen wirklichen Diskussionsbedarf mehr, sondern hat Konsens darüber, dass eine Definition nicht helfen würde.
Gruß,
Simon2.
für die informatik und die implementierung von numerischen algorithmen spielt es eine rolle, und man hat konsens darüber, dass die definition, z. bsp. im anhang F.9.4.4 des c99 standards, dabei hilft.
Im C99 Standard herscht auch ein Konsens darüber, dass Float->Int Casts nicht mathematisch korrekt gerundet werden sondern dass der Nachkommateil abgeschnitten wird. Wo liegt die Aussagekraft in Deinem "Argument"?
-
die aussagekraft liegt darin, dass man dadurch weiß, ob man den fall 0^0 extra behandeln muss oder nicht, wenn man die genannten algorithmen implementiert.
-
Es mag cool sein 0^0 als NaN oder sonstwas zu definieren, aber alles was NaN liefert bedeutet daß man extra Code schreiben muss um den Fall abzufangen.
-
NixDa schrieb:
Es mag cool sein 0^0 als NaN oder sonstwas zu definieren, aber alles was NaN liefert bedeutet daß man extra Code schreiben muss um den Fall abzufangen.
Das muss man auch für alle Fälle, wo 0^0 1 Liefern würde, wo dies aber nicht korrekt ist. 0^0=1 ist nämlich nur in 3 Fällen von Vorteil. In vielen anderen Fällen führt das zu inkonsistenten Ergebnissen.
-
Aber diese "3" Fälle decken so ziemlich alles ab was man braucht. NaN ist immer furchtbar. 0 ist meistens furchtbar. 1 ist fast immer super.
-
NixDa schrieb:
Aber diese "3" Fälle decken so ziemlich alles ab was man braucht. NaN ist immer furchtbar. 0 ist meistens furchtbar. 1 ist fast immer super.
worauf willst du hinaus?
-
NixDa schrieb:
Aber diese "3" Fälle decken so ziemlich alles ab was man braucht. NaN ist immer furchtbar. 0 ist meistens furchtbar. 1 ist fast immer super.
Du willst ernsthaft behaupten, dass geometrische Reihen, Potenzreihen und der binomische Satz alles sind? Wieso versuchst Du überhaupt, hier mitzudiskutieren?
-
Weil die Praxis nunmal so aussieht.
Mit NaN kann man in Algorithmen nichts anfangen.
Es muss klare Definitionen geben und da ist jede Definition die kein NaN definiert besser als eine die ein NaN definiert.
-
NixDa schrieb:
Weil die Praxis nunmal so aussieht.
Mit NaN kann man in Algorithmen nichts anfangen.
Es muss klare Definitionen geben und da ist jede Definition die kein NaN definiert besser als eine die ein NaN definiert.
Alle außer den drei genannten Fällen gehen aber davon aus, daß 0^0 undefiniert ist. Für all diese Fälle müsste man dann bei e=b^n IMMER prüfen, ob sowohl die Basis als auch der Exponent 0 waren. Bei NaN reicht eine Prüfung des Ergebnisses auf e != e. Du kannst nicht eifach generell für jedes Problem 1 in für 0^0 einsetzen.
Ich sage nochmal: Wieso versuchst Du überhaupt, hier mitzudiskutieren?
-
so, ihr kleinen kinder
1 ist keine Primzahl, weil dann alle anderen natürlichen Zahlen > 1 keine Primzahlen mehr sein könnten, da sie ja dann 1 als PRIMfaktor hätten. Und 0^0=NaN halte ich auch für unsinnig. Zumindest für das, was ich mache.
was ich mache? Programmieren.
-
Heinzelotto schrieb:
so, ihr kleinen kinder
1 ist keine Primzahl, weil dann alle anderen natürlichen Zahlen > 1 keine Primzahlen mehr sein könnten, da sie ja dann 1 als PRIMfaktor hätten. Und 0^0=NaN halte ich auch für unsinnig. Zumindest für das, was ich mache.
was ich mache? Programmieren.Das ist ja mal ein Argument.
Abgesehen davon, dass wir uns bei den Primzahlen so ziemlich einig sind, bin ich auch der Meinung, geometrische Reihen, Potenzreihen und der binomische Satz werden eher nicht so oft in der Programmierung benötigt.