Wo Maple falsch liegt - Gespräch mit dem Support!

Neue Frage »

Airblader Auf diesen Beitrag antworten »
Wo Maple falsch liegt - Gespräch mit dem Support!
Hi,

neulich im Forum kam die Frage auf, ob die Funktion



differenzierbar ist, speziell geht es um die potenziell kritische Stelle .
Maple will uns hier vorgaukeln, die Ableitung an dieser Stelle existierte nicht - tut sie aber (s.u.). Vom Support habe ich bestätigt bekommen, dass dies daran liegt, dass Maple die Produktregel anwendet und dann auf die Ableitung der Betragsfunktion stößt, die an dieser Stelle tatsächlich nicht definiert ist.

Inzwischen wurde meine Anfrage bis zu den Entwicklern durchgestellt, so dass ich nun folgende Antwort erhielt:

Zitat:
The function, D(f) (derivative of f), has a removable singularity at 0.
Simply evaluating a function with a removable singularity is not generally valid in mathematics, let alone in Maple.


Ich betone klar, dass ich das nicht so sehe!
Der Differenzquotient hat an dieser Stelle tatsächlich eine hebbare Singularität (s.u.), aber es geht nicht um den Wert des Differenzquotienten für x=0, sondern um den Grenzwert für x->0 .. und das ist ein Unterschied!

Für die Ableitung zählt nur, ob der Grenzwert existiert - und wenn er es tut, nennt man ihn die Ableitung an der Stelle.
Und hier nun die Begründung, dass er existiert und f damit differenzierbar ist:



Bei (*) wird die Singularität gekürzt, welche die Herren wohl meinen. Ich könnte diesen Grenzwert notfalls ja aber auch per -Definition nachweisen, statt mit kürzen - in meinen Augen aber völlig überflüssig.

Wie seht ihr das?
In meinen Augen produziert Maple hier schlicht einen Fehler. Okay, fair gesagt kommt in der Meldung nur, abs(x) sei für x=0 nicht differenzierbar - aber die Meldung müsste man dann schon sehr genau lesen.

air
system-agent Auf diesen Beitrag antworten »

Du hast jedenfalls recht.

Um den Grenzwert zu bilden spricht schliesslich auch niemand von , sondern man nimmt auch immer und dann ist kürzen unbedenklich und dein Limes OK.
Airblader Auf diesen Beitrag antworten »

Na Gott sei Dank. Wenn man gleich den Entwicklern gegenübersteht, denen ich ja eigentlich doch eine gewisse Ahnung unterstellen wollen würde, wird man durchaus auch bei solchen Dingen etwas unsicher und fragt nach.

Aber dann weiß ich ja jetzt bestärktermaßen, dass ich zurecht meine Ansicht davon vertrete.
Zum Glück ist der Maplesoft-Support supernett. Die gehen wirklich darauf ein (schreibe nun ja seit 2 Tagen mit denen).

air
jester. Auf diesen Beitrag antworten »

Na ja, ich denke, man muss bei Maple schon auf der Hut sein. Auch die Abfrage auf "continuous" funktioniert nicht so, wie man es erwarten würde...
Airblader Auf diesen Beitrag antworten »

@ jester

Kannst du da erläutern, was du meinst?
Ist das Problem bekannt bzw hast du es denen geschrieben? Wenn nicht, könnte ich es durchaus bei der nächsten Mail erwähnen.

Bisher habe ich Maple als ein Tool kennengelernt, das nicht immer leicht zu bedienen ist, aber sehr viel Macht besitzt und wenn ich bisher uneinig mit Maple war hat am Ende Maple gewonnen Big Laugh
Aber dieses Bild wurde nun doch etwas getrübt.

air
jester. Auf diesen Beitrag antworten »

Ich habe ja (noch) jede Woche Maple-Praktikum im Studium und da bin ich mal so frei aus einem aktuellen Übungsblatt zu zitieren:

Zitat:
MAPLE kennt zwar die Eigenschaft continuous, aber auf die Auswertungen sollte man sich nicht unbedingt verlassen. Das Thema ist nur sehr unvollständig implementiert.
> is(cos::continuous);

true

Hier sollte das Resultat eigentlich true lauten:
> is((x->cos(x))::continuous);

false

MAPLE: In dem folgenden Beispiel setzt Maple voraus, dass die noch nicht näher bestimmte Funktion f stetig ist:
>
> limit(f(1/n),n=infinity);

f(0)
 
 
Leopold Auf diesen Beitrag antworten »

Maschinen sind halt Maschinen. Und auch wenn sie immer besser werden, bleiben es Maschinen. Vielleicht kannst du die Damen und Herren mit dem Hauptsatz der Differential- und Integralrechnung überzeugen, der besagt, daß die Integralfunktion einer stetigen Funktion immer differenzierbar ist mit dem Integranden als Ableitung:



und das für alle , wegen also auch für (in Worten: Null)!
Airblader Auf diesen Beitrag antworten »

@ Leopold

Danke - sollten sie immer noch nicht einsehen, dass sie falsch liegen, bringe ich auch dieses Argument!

@ jester.

Den Befehl kenne ich gar nicht. Muss ich mir mal anschauen.

air
Airblader Auf diesen Beitrag antworten »

Ich muss sagen, so zufrieden ich mit der Höflichkeit und der Tatsache, dass man sich um einen kümmert, des Supports bin, so unzufrieden bin ich mit den Ergebnissen.
Auch das Integralfunktion-Argument wurde gebracht und der Fehler wird, zumindest gewissermaßen, zugegeben. Den eigentlichen Punkt, den ich erreichen will, wollen sie aber nicht einsehen und weichen ständig aus:

Ist es denn so schwer, diesen Bug zu beheben? Und selbst wenn, es sollte getan werden.

Ich habe nun etlichere weitere eMails hin- und hergeschickt, Workarounds bekommen etc. aber das ist ja alles nicht das, was ich möchte.
Hier habe ich etwas berechnet, dessen Ergebnis ich kannte und dann kann ich einen Workaround anwenden. idR berechne ich ja aber etwas, weil ich das Ergebnis vorher eben nicht kenne.

Habe versucht, das nochmal ganz klar zu sagen und bin mal gespannt ob nun irgendwas bei rum kommt ...

air
Leopold Auf diesen Beitrag antworten »

Ich habe noch nie mit Maple gearbeitet, aber das Problem wird sein, daß die Produktregel formal angewendet wird und Maple bei



bezüglich der Stelle sagt: Das kann ich nicht, weil bei nicht differenzierbar ist. Falls Maple aus "ich kann es nicht" allerdings ein "nicht differenzierbar" macht, ist das natürlich ein mathematischer Trugschluß. Ich glaube, daß es prinzipiell nicht möglich ist, solche Dinge algorithmisch in den Griff zu kriegen. Natürlich kann eine neue Regel programmiert werden, nach der eine überall differenzierbare Funktion ist. Aber dann gibt es andere Funktionen, wo das Programm wieder versagt. Jedes Loch, das man schließt, reißt anderswo weitere Löcher auf.
Das Problem ist das "Unendlich-Kleine" in der Analysis, wie es beim Differenzenquotienten als "Unendlich-Klein durch Unendlich-Klein" in Erscheinung tritt. Man mag so etwas numerisch behandeln können, vielleicht sogar hervorragende Algorithmen finden, um Grenzwerte approximativ zu ermitteln, wenn man aber exakte Analysis treiben will, nutzt das alles nicht, man muß dann auf symbolische Differentiation ausweichen - und da wird es eben, wie ich einmal kühn behaupte, immer Lücken geben (Erster Leopoldscher Unvollständigkeitssatz).

Kann denn Maple Funktionen wie



differenzieren?
Airblader Auf diesen Beitrag antworten »

@ Leopold

Ja, Maple wendet die Produktregel an. Das war auch meine Vermutung und die wurde auch von Anfang an von Maplesoft bestätigt.
Natürlich ist es ein endloser Kreis. Das heißt aber nicht, dass man ihn nicht gehen muss. Denn dann wirds ja nie besser.

Zu den anderen Funktionen - zumindest das f kann es nicht ableiten, selbes Problem, nur mit Kettenregel. Bei der g weiß ich spontan nicht, wie ich sie eingeben kann.

air
Leopold Auf diesen Beitrag antworten »

Und das, obwohl !
Winni Auf diesen Beitrag antworten »
RE: Wo Maple falsch liegt - Gespräch mit dem Support!
Maple 14 bringt als Ableitung abs(x)+x*abs(1, x) .
Airblader Auf diesen Beitrag antworten »

Danke für den Hinweis. Eine kurze Google-Suche liefert aber:

Zitat:
The derivative of abs is denoted by abs(1, x). This is signum(x) for all non-0 real numbers, and is undefined otherwise.


Die Frage ist also nicht, was du bekommst, wenn du die Ableitung allgemein ausgibst, sondern was passiert, wenn du sie explizit an der Stelle Null berechnen willst. Kommt da nach wie vor die Fehlermeldung?

Da ich kein Maple 14 habe kann ichs leider nicht ausprobieren.

air
Neue Frage »
Antworten »



Verwandte Themen

Die Beliebtesten »
Die Größten »
Die Neuesten »