GOOGLE-Taschenrechner

Wen´s interessiert: Man kann http://www.google.de auch als Taschenrechner benutzen… ;o)

Und so funktioniert´s:

Um eine Rechenaufgabe von Google lösen zu lassen, gibt man diese einfach in das Suchformular ein. Man tippt die Aufgabe genauso in das Google-Suchformular wie in einen herkömmlichen Taschenrechner. Nach einem Klick auf „Google-Suche“ wird das Ergebnis präsentiert:

z.B. 17+4 -> Google Suche -> 21

Falls man nach Seiten suchen möchte, in denen die eingegebene Rechenaufgabe enthalten ist, klickt man auf die unterstrichene Formel am Ende des Satzes „Suchen nach Ergebnissen mit diesem Suchbegriff“.

Neben Subtraktion, Addition, Division und Multiplikation ist auch Prozentrechnung möglich. Um den Prozentwert eines bestimmten Grundwertes zu erhalten, multipliziert man den Grundwert mit dem Prozentsatz. Den Prozentsatz macht man dadurch kenntlich, dass direkt danach das Prozentzeichen ohne Leerzeichen eingegeben wird:

z.B. 1799*16% -> Google Suche -> 1799 * (16%) = 287.84

Zu beachten ist, dass auch bei Google Punkt- vor Strichrechnung geht… ;o)
Gegebenenfalls muss mit Klammern gearbeitet werden, um ein korrektes Ergebnis zu erzielen:

z.B. (134*1,15%)+26*(2,74+1,2) -> Google Suche -> (134 * (1,15%)) + (26 * (2,74 + 1,2)) = 103,98100

Google versteht sowohl das Hexadezimalsystem als auch das binäre Zahlensystem. Für Berechnungen im Hexadezimalsystem muss jeweils „0x“ vor die Hexadezimalzahlen gesetzt werden (Beispiel: „0xFF + 0xFF = 0x1FE“). Prozentrechnung ist ebenso möglich wie die Verwendung von Konstanten wie „pi“ (Beispiel: e^(i pi)+1).

Eigentlich braucht das kein Mensch – aber zu wissen, dass es geht und wie es geht und ein paar knikklige Aufgaben auszuprobieren macht trotzdem Spaß!

Veritas.

probier mal aus:
-0,2-0,1+0,2+0,1
in einem Schritt.
Das kommt sogar bei Mathematica so raus, ist ein typisches Problem

Weißt du auch, was die Ursache für dieses Problem ist? Würde mich nämlich mal interessieren.

Weißt du auch, was die Ursache für dieses Problem ist? Würde
mich nämlich mal interessieren.

Hallo,
diese Probleme entstehen beim Umrechnen der Zahlen in das jeweils benutzte Zahlenformat (abhängig vom verwendeten Programm bzw. Taschenrechner) durch dabei auftretende Rundungsfehler.
Gruß
Axel

Weißt du auch, was die Ursache für dieses Problem ist? Würde
mich nämlich mal interessieren.

Hallo,
diese Probleme entstehen beim Umrechnen der Zahlen in das
jeweils benutzte Zahlenformat (abhängig vom verwendeten
Programm bzw. Taschenrechner) durch dabei auftretende
Rundungsfehler.

Ich muss sagen, dass ich das verdammt schwach finde.
Excel hat so nen ähnlichen Bug, das verrechnet sich auch ständig im Nachkommabereich. Daher eigentlich nicht einsetzbar, wenn man mich frägt. Das aber Mathematica das auch nicht kann, schockt mich eigentlich. Wenn schon ein Mathe-Programm falsch rechnet, dann kann man es ja gleich auf den Müll werfen…

Mit Maple geht das übrigens einwandfrei :smile:

 |\^/| Maple 6 (SUN SPARC SOLARIS)
.\_|\| |/|\_. Copyright (c) 2000 by Waterloo Maple Inc.
 \ MAPLE / All rights reserved. Maple is a registered trademark of
 Waterloo Maple Inc.
 | Type ? for help.
\> -0.2-0.1+0.2+0.1;
 0.

mfg
deconstruct

Nicht schlecht, mit Maple. Hast Du das mit Mathematica bei Dir auch ausprobiert? Liegt wahrscheinlich an dem Rechner, den man benutzt.

Das Problem ist, dass es nur endlich viele Maschinenzahlen gibt, das heißt, unsere Eingabe wird erstmal auf Maschinenzahl gerundet, damit wird dann gerechnet. Dabei entstehen weitere (Rundungs-)Fehler. Und am Ende kommt dann was raus, was nicht stimmt. Ist aber eigentlich ziemlich übel, dass das schon bei so einfachen Zahlenwerten schlappmacht.

Nicht schlecht, mit Maple. Hast Du das mit Mathematica bei Dir
auch ausprobiert? Liegt wahrscheinlich an dem Rechner, den man
benutzt.

Hmm, von Mathematica hatte ich nur mal ne Demo-Version. Und da es Maple bei uns an der Uni umsonst gibt, habe ich nie darüber nachgedacht, mir sowas wirklich zu kaufen :smile:
Daher kann ich über Mathematica auch nicht viel sagen.

Das Problem ist, dass es nur endlich viele Maschinenzahlen
gibt, das heißt, unsere Eingabe wird erstmal auf Maschinenzahl
gerundet, damit wird dann gerechnet.

Ja, das ist klar. Eine Wurzel, 1/3, oder PI kann man eben nicht genau als Maschinenzahl abbilden. Aber 0.1 und 0.2 lassen sich eben schon präzise darstellen, daher finde ich das schwach, dass Mathematica da schon versagt.

Dabei entstehen weitere
(Rundungs-)Fehler. Und am Ende kommt dann was raus, was nicht
stimmt. Ist aber eigentlich ziemlich übel, dass das schon bei
so einfachen Zahlenwerten schlappmacht.

Eben, wie gesagt, würden da irrationale Zahlen oder periodische Dezimalzahlen vorkommen, dann würde ich einen Rundungsfehler verstehen. Aber doch nicht bei rationalen, nichtperiodischen Zahlen…

Maple kann z.B. auch begrenzt mit periodischen Dezimalzahlen gut umgehen:

 |\^/| Maple 6 (SUN SPARC SOLARIS)
.\_|\| |/|\_. Copyright (c) 2000 by Waterloo Maple Inc.
 \ MAPLE / All rights reserved. Maple is a registered trademark of
 Waterloo Maple Inc.
 | Type ? for help.
\> 1/3 + 1.0 + 1/3 + 1/3;
 1.999999999

\> 1/3 + 1 + 1/3 + 1/3;
 2

Das erste Beispiel rechnet Maple dezimal, da eine Zahl vorkommt, die dezimal geschrieben ist, d.h. aus 1/3 wird eben 0.33333333, je nachdem wieviel Nachkommastellen man einstellt. Und dann kommts natürlich zu dem 1.999999.

Im zweiten Beispiel rechnet Maple nicht mit dezimal Zahlen, da keine vorkommt. Sie rechnet also wirklich mit 1/3 und nicht mit 0.333333333.

mfg
deconstruct

… Das ist noch kein Grund

Hallo,
diese Probleme entstehen beim Umrechnen der Zahlen in das
jeweils benutzte Zahlenformat (abhängig vom verwendeten
Programm bzw. Taschenrechner) durch dabei auftretende
Rundungsfehler.
Gruß
Axel

Genauigkeit gut und schön, aber auch bei 17 stellen (siehe google ergebnis), sollte wie bei jedem guten Taschenrechner auch mindestens 1 zusätzliche Stelle zum Runden vorhanden sein. Solche rechenergebnisse müssen nicht sein. Anders wäre das bei (Wurzel(2)^2), das ist eine klasse anspruchsvoller.

Gruß
achim

Hi,

Ja, das ist klar. Eine Wurzel, 1/3, oder PI kann man eben
nicht genau als Maschinenzahl abbilden. Aber 0.1 und 0.2 lassen
sich eben schon präzise darstellen,

Rundungsfehler verstehen. Aber doch nicht bei rationalen,
nichtperiodischen Zahlen…

Computer rechnen mit dualen Fließkommazahlen; in diesem Format dargestellt sind 0.1 und 0.2 periodisch! Alle rationalen Zahlen, deren Nenner nicht ausschließlich die 2 als Primfaktor enthält, sind periodisch (analog dazu sind beim Zehnersystem die Dezimalentwicklungen aller rationalen Zahlen periodisch, deren Nenner nicht nur die 2 und die 5 als Primfaktoren enthält). Bei der Konvertierung der Zeichenketten „0.1“ und „0.2“ in „floating point numbers“ muß der Computer also zwangsläufig schon runden und der Schlamassel nimmt seinen Lauf… :wink:.

Mit freundlichem Gruß
Martin

Computer-Algebra-Programm
Hallo Martin,

… Bei der Konvertierung der
Zeichenketten „0.1“ und „0.2“ in „floating point numbers“ muß
der Computer also zwangsläufig schon runden und der
Schlamassel nimmt seinen Lauf… :wink:.

du nimmst also an, dass Maple mit „floating point numbers“ rechnet? Stimmt nicht unbedingt. Soweit es geht, versucht nämlich Maple tatsächlich algebraisch und nicht numerisch zu rechnen. Mit Mathematica kenne ich mich nicht so gut aus, aber auch dies ist genau wie Maple ein Computer-Algebraprogramm, das mathematische Strukturen möglichst in symbolischer Weise erfasst und bearbeitet. Wenn Maple zum Beispiel sqrt(2)*sqrt(2) ausrechnen soll, so wird nicht die Wurzel aus 2 als Fließkommazahl dargestellt und dann eine Fließkommaoperation durchgeführt, sondern das Programm erkennt, dass sqrt(2)*sqrt(2)=sqrt(2*2) ist, und zwar ohne sqrt(2) ausgerechnet zu haben. Anschließend wendet Maple die Definition der Wurzel an und erhält exakt 2 als Ergebnis. Ebensogut hätte man auch sqrt(z)*sqrt(z) hinschreiben können, dann hätte Maple halt als Ergebnis z ausgegeben. Nun erklär mir mal, wie Maple das mittels „floating point numbers“ bewerkstelligen soll?

Es grüßt
Jens

Hallo Jans,

… Bei der Konvertierung der
Zeichenketten „0.1“ und „0.2“ in „floating point numbers“ muß
der Computer also zwangsläufig schon runden und der
Schlamassel nimmt seinen Lauf… :wink:.

du nimmst also an, dass Maple mit „floating point numbers“
rechnet?

über Maple habe ich doch gar keine Aussage gemacht!? Insbesondere habe ich nirgendwo behauptet, daß es ausschließlich mit floating point numbers rechnet!?!? Ich habe deconstruct darauf hingewiesen, daß die Zahlen 0.1 und 0.2 in dualer Fließkommazahl-Darstellung periodisch sind und deshalb schon bei der Konvertierung Rundungsfehler auftreten, und das ist korrekt. Wie und warum ein CAS anders/besser rechnen kann, steht doch auf einem ganz anderen Blatt!?!?!?

Mit freundlichem Gruß
Martin

Hi,

Ja, das ist klar. Eine Wurzel, 1/3, oder PI kann man eben
nicht genau als Maschinenzahl abbilden. Aber 0.1 und 0.2 lassen
sich eben schon präzise darstellen,

Rundungsfehler verstehen. Aber doch nicht bei rationalen,
nichtperiodischen Zahlen…

Computer rechnen mit dualen Fließkommazahlen; in diesem
Format dargestellt sind 0.1 und 0.2 periodisch! Alle
rationalen Zahlen, deren Nenner nicht ausschließlich die 2 als
Primfaktor enthält, sind periodisch (analog dazu sind beim
Zehnersystem die Dezimalentwicklungen aller rationalen Zahlen
periodisch, deren Nenner nicht nur die 2 und die 5 als
Primfaktoren enthält). Bei der Konvertierung der
Zeichenketten „0.1“ und „0.2“ in „floating point numbers“ muß
der Computer also zwangsläufig schon runden und der
Schlamassel nimmt seinen Lauf… :wink:.

Das ist mir schon klar, aber dazu rechnest du eben so einen wert wie 0.1 nicht direkt ins Binär-System um, sondern abstrahierst das ganze durch Datenklassen. und dadurch sparst du dir die meisten (alle?) Rundungs-Probleme, die durch das Binär-System auftauchen. Bleiben dann noch die Rundungs-Fehler aufgrund Irrationalität usw.

mfg
deconstruct

Mit freundlichem Gruß
Martin

Hallo Martin,

über Maple habe ich doch gar keine Aussage gemacht!?

da hast du wohl recht. Ich hatte das irgendwie so interpretiert, als seiest du der Meinung, dass ein Computer solche Rundungsdfehler grundsaetzlich nicht vermeiden koenne.

Herzliche Gruesse
Jens

Hallo deconstruct,

Das ist mir schon klar, aber dazu rechnest du eben so einen
wert wie 0.1 nicht direkt ins Binär-System um, sondern
abstrahierst das ganze durch Datenklassen. und dadurch sparst
du dir die meisten (alle?) Rundungs-Probleme, die durch das
Binär-System auftauchen.

Sicher? das wäre ein irrer Aufwand, den auch vermutlich keine Hardware unterstützt. Ich denke nicht, dass es ein anderes als das Binärsystem (und die zugehörige fix- und fließpunktdarstellung etc.) in einem realen PC gibt.

Decimal-Nachkommastellen:
1/10tel, 1/100tel, 1/1000tel …

Binär-Nachkommastellen:
1/2, 1/4tel, 1/8tel, 1/16tel…

also: kein gemeinsamer „Nenner“ der beiden Systeme,
also: Spezielle Dezimal-Hardware oder Rechnungen ohne Hardwareunterstützung notwendig.