CAS: Gleichung mit Grenzwert ergibt eine leere Menge

tokmajigeorge shared this problem 4 years ago
Not a Problem

Wenn ich im CAS die folgenden Befehle eingebe:

f(x) := (x^(3)-8x^(2)+12x)/(x^(2)-9x+18)
Löse(LinksseitigerGrenzwert(f,x,z) != f(z), z)
erhalte ich stets eine leere Menge als Ergebnis, als wäre der Grenzwert überall gleich dem Funktionswert, was nicht stimmen kann, da die Funktion eine Lücke besitzt. Was mache ich falsch?

Comments (5)

photo
1

LimitBelow(f,x,z) != f(z)

gives


false

So you are effectively asking


Solve(false, z)

What are you trying to do exactly?

photo
1

Ich denke, dass das wesentliche Problem ist, das != "nur" eine logische Abfrage ist.

Man könnte mit

Nenner (Befehl)

denn Nenner-Termn bestimme und dann dessen Nullstellen bestimmen.

photo
1

Hi zusammen!


Hmm, also ich erhalte bei Deinen Befehlen eine zu erwartende Lösung.


Zunächst einmal lässt sich Dein Funktionsbeispiel ja im Zähler und Nenner faktorisieren (gibt ja auch praktischerweise den Befehl "Faktorisiere" dafür ;-) ):


(x^(3)-8x^(2)+12x)=x(x-2)(x-6)

(x^(2)-9x+18)=(x-6)(x-3)


Die Nullstellen des Nenners liegen also bei 3 und 6, allerdings handelt es sich bei 6 um eine hebbare Lücke, weil sich der Faktor (x-6) rauskürzen lässt.

Wenn Du Dir den von GeoGebra angegebenen Funktionsterm anschaust, dann erkennst Du, dass GeoGebra gerade diesen auch wegkürzt.

Die Stelle 3 ist nun eine wesentliche, nicht kürzbare Definitionslücke, was bedeutet, dass die original Funktion ebenso wie die gekürzte dort nicht definiert ist.

Und aus genau diesem Grunde erhalte ich dann das zu sehende Ergebnis - die Funktion ist halt überall auf ihrem Definitionsbereich gleich ihrem linksseitigen Grenzwert.


Wenn Du nicht möchtest, dass GeoGebra einen Funktionsausdruck automatisch kürzt, dann müsstest Du in der Ikonen-Leiste der CAS-Ansicht zuvor das dritte Symbol von links (sieht ein wenig aus wie ein Haken) aktivieren, der in den Modus "Behalte Eingabe" schaltet.

Allerdings werden dann Eingaben nicht ausgewertet und aus f(4) kommt z. B. als Ausgabe f(4) statt des berechneten Wertes. Deshalb also anschließend wieder auf das "Gleichheitszeichen" in der Ikonenleiste klicken.

Allerdings hat das hier wohl keine Auswirkungen, denn es gibt keine Sprungstellen und die Stelle 3 ist eine wesentliche Definitionslücke, d. h. es existiert gar ke sin f(3) welches ungleich seinem linksseitigen Grenzwert sein könnte, da die Prüfung der Ungleichung nur auf dem Definitionsbereich der Funktion selbst sinnvoll ist.


Man muss ja schon f(z) auswerten können. ;-)


Dennoch gibt es, so scheint es, einen Bug. Vielleicht kann da mal jemand genaueres zu sagen.

Ich hoffe, dass er aus der angehängten Datei ersichtlich ist.


Gruß

mire2

photo
1

Danke für deine Nachricht!

Der Versuch der Aktion war eigentlich, die "Arbeit", die Lücke herauszufinden, GeoGebra 100%ig zu überlassen (vielleicht hätte ich Grenzwert anstelle von LinksseitigerGrenzwert nehmen sollen, dann hätte es keine Polstellen detektiert, da sowohl Funktionswert als auch Grenzwert undefiniert sind). Gibt es also überhaupt keine Möglichkeit, das von mir bezweckte durchzuführen? (Ich weiß, wie ich es mit Faktorisiere(Nenner(f)) = 0 mache, aber das fällt für mich nicht ganz unter "automatisch" ;) )

photo
photo
1

Hi tokimajigeorge!

Wenn es Dir um das Auffinden der wesentlichen, also nicht-hebbaren Lücken, bei gebrochenrationalen Funktionen geht, dann wäre jetzt mein gedanklicher Schnellschuss der Befehl "Asymptote", ohne dass ich da jetzt intensiver drüber nachgedacht hätte.

Ich war von meiner Idee direkt so begeistert (also m. a. W.: Ich fand mich mal kurzzeitig einfach großartig :-D ), dass ich das auch gleich ausprobiert und mal drei Beispiele für die drei Möglichkeiten (Zählergrad > Nennergrad, Zählergrad = Nennergrad und Zählergrad < Nennergrad), die doch noch einigermaßen übersichtlich sind, in eine Beispieldatei gepackt habe.

Vermutlich habe ich was übersehen, aber so als erste "Arbeitshypothese" ist das zumindest nicht gänzlich untauglich.


Gruß

mire2


PS: Wenn ich evtl. altklug oder "klugscheißerhaft" rübergekommen sein sollte - Das lag natürlich nicht in meiner Absicht. :-)

© 2023 International GeoGebra Institute