c++ hochrechnen, negative dezimale werte



  • 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.


  • Mod

    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.


Anmelden zum Antworten