Wir haben in fast jeder Programmiersprache die builtin-Funktion pow(), meist mit syntaktischem Zucker.

In Python ist x hoch y einfach x ** y, in J ist das  x^y

In J und in APL gibt 0^0 1. In Python gibt 0**0 auch 1.

Eigentlich ist das alles falsch. 0 hoch 0 sollte eigentlich ne Exception schmeissen, oder wenigstens NaN liefern, das Resultat ist eindeutig undeterminiert.

Wie denkt ihr darueber?

Bevor ihr antwortet: Macht euch klar, dass eine Antwort darauf auch eine Antwort auf die Definition von 0 durch 0 impliziert. (das wirft in Python ne exception, in J ist das 0, in APL 1(WTF!))

Ich kann dir nur eine Antwort aus der Mathematik geben und da ist das einzige über das man sich bei 0^0 wirklich enig ist daß man sich nicht einig ist. Dennoch gibt es Fälle wo es tatsächlich Sinn macht zu sagen 0^0= 1, von daher halt ich das von Python und Java für berechtigt.

natuerlich 1. Aber ne compileroption fuer 0 wuerde ich zur not akzeptieren. jedenfalls fuer visual basic 6, waere genau so noobig wie arrays die mit index 1 anfangen.

> natuerlich 1

Warum natuerlich?

Sorry, aber das ist ueberhaupt nicht "natuerlich", sondern mathematisch einfach falsch.

Oft praktisch, ja. aber eigentlich sollte das - genau wie x / 0 fuer alle x incl. 0 - ne Exception oder wenigstens ne Warning schmeissen IMO.

Dass 0/0 undefiniert ist, ist relativ klar. Mathematisch sowieso, aber auch intuitiv:

Eine Frau kauft taeglich Aepfel frisch vom Markt. Sie bestimmt den Preis eines Apfels durch ihre Gesamtausgaben geteilt durch die Anzahl gekaufter Aepfel. Eines Tages ist sie krank, und geht deshalb nicht zum Markt. Natuerlich hatten Aepfel an diesem Tag auch einen Preis - aber sie hat keine Moeglichkeit, rauszufinden, welchen. "0 EUR/Stueck" ist offensichtlich falsch, "1 EUR/Stueck" ist auch eher unwahrscheinlich.
(ich hab grad den Namen und Urheber des Argumentes vergessen, sorry)

Analog ist auch 0^0 schlicht undefiniert. Eine Antwort auf das eine impliziert ueber Potenzgesetze auch die Antwort auf die andere Frage.

Es ist nicht so, dass 0^0 == 1 eine schlechte Konvention waere. De Facto habe ich die Definition sogar mal im Studium in Analysis benutzt. Es ergibt definiv Sinn, wenn man z.B. ueber |C redet. Und es vereinfacht viele Definitionen (allgemeine Polynomgleichungen, bspw.) - ABER: es induziert Widersprueche. "natuerlich" finde ich widerspruchsfreie Mathematik, nicht widerspruchsbehaftete.

0^0 = 1
<=>
0 ^1 * 0 ^ -1 = 1
<=>
0 * 0 ^ -1 = 1
<=>
0 = 1
WTF.

Die einzige Moeglichkeit, da rauszukommen, ist 0 * 0 ^ -1 aka 0 / 0 als 1 zu definieren. Das ist aber offensichtlich nicht definiert, s.o. Und selbst wenn wir das tuen, gibt es offensichtlich weitere Widersprueche.

Die Mathematik als ganzes kann garnicht widerspruchsfrei sein, denn du kannst KEIN Axiomensystem vollständig und widerspruchsfrei aus sich selbst beweisen ;)

Du hast Goedels Schlussfolgerunden zum Hilbertprogramm eindeutig NICHT verstanden.

Das sagt "nur", dass gewisse Dinge unentscheidbar sind.
Nicht, dass wir Widersprueche akzeptieren muessen. Das waer ja noch schoener. Denn aus einem Widerspruch hinaus laesst sich schliesslich alles beweisen.

Ich wollte auf deine WIDERSPRUCHSFREIE Mathematik hinaus die es so einfach nicht gibt, das vollständig und widerspruchsfrei aus sich selbst beweisen geht ja noch nichtmal in der Arithmetik. Willst du also nun ein widerspruchsfreies Axiomensystem schaffen brauchst du eben Aussagen die du einfach so annimmst. Und daß eben die Mathematik als Axiomensystem nicht vollständig aus sich selbst beweisbar ist, diese Tatsache müssen wir akzeptieren.

> Und daß eben die
> Mathematik als Axiomensystem nicht vollständig aus sich
> selbst beweisbar ist, diese Tatsache müssen wir
> akzeptieren.

Ja, das hat Goedel gezeigt. Trotzdem haben wir einen Anspruch an eine widerspruchsfreie Mathematik.
Sonst ist sie nutzlos, da man aus einem Widerspruch wie gesagt beliebiges "beweisen" kann.

Es hat schon einen Sinn, dass 0^0 = 1 nicht generell so definiert ist.

Du verwechselst Widerspruchsfreiheit mit Unvollständigkeit!

Ergibt sich übrigens bereits ohne großes Nachdenken aus dem Unvollständigkeitssatz selbst:

Jedes hinreichend mächtige formale System ist entweder widersprüchlich oder unvollständig.

Entweder ... oder ... ;-)

Einzelne mathematische Systeme sind durchaus widerspruchsfrei, nur lässt sich die Widerspruchsfreiheit nicht BEWEISEN innerhalb des Systems, sondern erfordert dann weitere Axiome. Die Widerspruchsfreiheit der Arithmetik ist zum Beispiel bewiesen seit 1936.

Ich weiß, du hast das mit dem zweiten Posting relativiert - aber wandkeks hat durchaus Recht mit seiner Forderung, dass das Subset der Mathematik, mit dem er arbeitet, seiner Meinung nach widerspruchsfrei sein sollte. Das ist sowohl eine legitime als auch erfüllbare Forderung, insofern bin ich mir eben nicht sicher, ob du das WIRKLICH in vollem Umfang verstanden hast: Nur weil etwas nicht "widerspruchsfrei beweisbar ist" ist (was ja so als Aussage auch nicht stimmt - Dinge lassen sich unter Rückgriff auf weitere Axiome durchaus beweisen, nur ist das neu entstandene System dann ebenfalls unvollständig und selbst nicht beweisbar), muss es nicht gleichzeitig an sich einen Widerspruch haben.

> Eigentlich ist das alles falsch. 0 hoch 0 sollte
> eigentlich ne Exception schmeissen, oder wenigstens NaN
> liefern, das Resultat ist eindeutig undeterminiert.
>
> Wie denkt ihr darueber?

Ich schließe mich an.
0⁰ sollte ne Exception/Error was auch immer auslösen und keinen Wert zurückliefern (oder notfalls halt sowas wie undef und Konsorten, wobei mir die Exception-Lösung lieber wäre).

Ich weiß auch gar nicht, warum in vielen Programmiersprachen da mit Kompromissen gearbeitet wird indem man irgend nen Wert zurückliefert. Macht man ja bei Division durch 0 auch nicht.

Kann ja sein, dass es bei bestimmten Szenarien nützlich ist, wenn es einen Wert wie 0 oder auch 1 zurückliefert, doch dann soll sich der Programmierer "zu Fuß" darum kümmern müssen.

Solche Fehlertoleranzen mögen zwar für den Programmierer ganz verlockend sein, aber schaffen sie auch Unschärfe. Da braucht man dann doch mal ein anderes Verhalten und dann fällt einem das vor die Füße oder führt zu schwer auffindbaren Bugs.

Gruß
MichaelK

Naja, jenachdem, aus welcher Sicht man das sieht. Nimmt man die Kürzungstheorie, wäre 0/0 = 1. Legen wir zu Grunde, dass der Nenner 0 ist, dann gilt natürlich undefiniert. Taschenrechner zeigen eher Undefiniert oder Divided by Zero an. Delphi (Pascal) wirft jedenfalls ne Exception.

MfG Blade

> Naja, jenachdem, aus welcher Sicht man das sieht. Nimmt
> man die Kürzungstheorie, wäre 0/0 = 1.

Sei 0 / 0 := 1

<=>

1 = 0/0 = (0+0) / 0 = 0/0 + 0/0 = 2

<=>

1 = 2

Unguenstig.

Das Problem ist, dass lim(ɛ1 / ɛ2) fuer ɛ1,2 -> 0 jeden beliebigen Wert annimmt (naemlich gerade den "Einschlagsvektor" ɛ1,2 auf 0, also die "Richtung").

> 1 = 0/0 = (0+0) / 0 = 0/0 + 0/0 = 2

Ich will auch nicht Mathe jetzt aufm Kopf stellen, aber rein Theoretisch macht auch die zwei Sinn. Schließlich hast du die Teiler zweimal :-D... Man ginge quasi gegen Unendlich bei dem Spielchen. Unendlich ist halt auch keine definierte Zahl mehr, die man ausschreiben kann. Ebenso macht ein Lim gegen 0 auch sinn. Ließe sich auch nicht definieren.

MfG Blade

> > 1 = 0/0 = (0+0) / 0 = 0/0 + 0/0 = 2
>
> Ich will auch nicht Mathe jetzt aufm Kopf stellen, aber
> rein Theoretisch macht auch die zwei Sinn.

Fuer 0/0? aber sicher doch, genau wie jede andere Zahl.
2 ist schliesslich der Grenzwert von 2x/x fuer x->0 :p

Das ist doch gerade, was ich schrob. Nur macht 1 = 2 halt definitiv keinen Sinn.

Ich weiß auch gar nicht, warum in vielen Programmiersprachen da mit Kompromissen gearbeitet wird indem man irgend nen Wert zurückliefert. Macht man ja bei Division durch 0 auch nicht.

Vmtl verlassen sich die programmiersprachen da auf cpu/fpu.
Bei debug 1/x oder 1^x muesste der compiler eine ueberpruefung einbauen, die flags nach dem rechenschritt pruefen oder auf eine exception hoffen. Oder halt weiterrechnen und zum schluss pruefen ob's NaN oder der gleichen ist (hab mit NaNs ned so erfahrung)?

> Vmtl verlassen sich die programmiersprachen da auf
> cpu/fpu.

Moeglich.
Weiss grad wer, was so ne x86-ALU bei 0/0 und pow(0,0) macht? Ist pow() ueberhaupt als IV implementiert?
Das ist alles viel zu lange her, dass ich das letzte mal ne ALU gebaut habe... ;)

Wenns wirklich daran liegt: warum signalt die ALU bei 0/0 einen error, bei pow(0,0) aber nicht?!

> > Vmtl verlassen sich die programmiersprachen da auf
> > cpu/fpu.

Moment mal: wir reden aber hier von Programmiersprachen mit builtin transparentem bigint-support. Die scheren sich erstmal nicht um die CPU-Builtins. Kann natuerlich sein, dass die das bei kleinen Zahlen aus optimierungsgruenden einfach durchreichen - dann sind die aber schon durch einen check durch, da koennte das dann auch gleich noch mit abgefangen werden.

> Weiss grad wer, was so ne x86-ALU bei 0/0 und pow(0,0)
> macht?

Bei Division durch Null gibts nen Interrupt.
(Ausnahme: FDIV beim Pentium ergibt nen gerundetes Ergebnis *zwinker*)

Potenz ist so direkt in der Form x^y weder bei x87 noch bei SSE direkt verfügbar, wenn mich nicht alles täuscht.

Gruß
MichaelK

> Bei Division durch Null gibts nen Interrupt.
> (Ausnahme: FDIV beim Pentium ergibt nen gerundetes
> Ergebnis *zwinker*)

Pentium 1, stepping irgendwas fruehes. Schreib das doch bitte dazu :p

> Potenz ist so direkt in der Form x^y weder bei x87 noch
> bei SSE direkt verfügbar, wenn mich nicht alles täuscht.

Wenn das stimmt, gibt es also nichtmal den "omg performance"- Grund, 0^0 keine exception schmeissen zu lassen.

> Ich weiß auch gar nicht, warum in vielen
> Programmiersprachen da mit Kompromissen gearbeitet wird
> indem man irgend nen Wert zurückliefert. Macht man ja bei
> Division durch 0 auch nicht.

"man" nicht. J schon. APL auch. J here:

   0%0
0
   1%0
_
   23%0
_

( "_" ist float("inf") (and is sad smiley here. zu recht, IMO.) "%" ist da ueberigens wirklich div, nicht mod.)