Ganzzahlige Teilung von Float-Objekten

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 15. Mai 2008, 15:22

Goswin hat geschrieben:Tja, bedeutet das wohl, dass bei einer float-Division vielleicht doch keine unnötigen Rundungsfehler entstehen? Schön wäre es ja.
Vielleicht, vielleicht nicht. Das hängt von Deinen Zahlen ab. Siehe mein erster link, ganz oben.
BlackJack

Donnerstag 15. Mai 2008, 15:28

@Goswin: Wie CM schon sagte hängt das von den Zahlen ab. Mal als Beispiel:

Code: Alles auswählen

In [24]: 9999999999999999.0
Out[24]: 10000000000000000.0
Die Zahl ist noch ein ganzes Stück von der darstellbaren Obergrenze weg, aber schon nicht mehr verlustfrei darstellbar. Andererseits ist der Wert auch ein gutes Stück kleiner als der Wertebereich eines 64-Bit-Integers!
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Donnerstag 15. Mai 2008, 15:41

Ich verstehe Goswins Frage so: Gilt fuer drei reelle Zahlen a, b, c mit a + b = c folgendes: float(a) + float(b) = float(c)?

(und entsprechend fuer andere Grundrechenarten)
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 15. Mai 2008, 15:45

Kann man alle drei Zahlen exakt in eine Zahl mit Basis 2 überführen: Ja. Sonst: Nein.

edit: Nochmal nachgefragt: Goswin, was möchtest Du eigentlich machen? Gibt es vielleicht eine Lösung, die wir nicht diskutieren, weil wir gar nicht das eigentliche Problem kennen?
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Donnerstag 15. Mai 2008, 16:11

Stimmt, einfaches Gegenbeispiel:

Code: Alles auswählen

>>> 0.2 + 0.1
0.30000000000000004
>>> 0.3
0.29999999999999999
Sonst braeuchte man das oberste Gebot, Floats nie auf Gleichheit zu pruefen, auch nicht (so oft).
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Donnerstag 15. Mai 2008, 17:04

BlackJack hat geschrieben:@Goswin: Wie CM schon sagte hängt das von den Zahlen ab. Mal als Beispiel:

Code: Alles auswählen

In [24]: 9999999999999999.0
Out[24]: 10000000000000000.0
Die Zahl ist noch ein ganzes Stück von der darstellbaren Obergrenze weg, aber schon nicht mehr verlustfrei darstellbar.
Die Zahl mag zwar noch weit von der darstellbaren Obergrenze weg sein, aber du hast bei floats ca 6 Stellen Genauigkeit und bei doubles 15. Du hast da allerdings schon 16 zusammen. Nimm einige weniger und es funktioniert(womit auch gleich festgestellt wäre, dass float in python ein double ist ;)).

Code: Alles auswählen

In [15]: 999999999999999.0
Out[15]: 999999999999999.0
BlackJack

Donnerstag 15. Mai 2008, 19:35

Das ist mir alles klar, und nun schau Dir noch mal an bis in welche Grössenordnungen Goswin gerne genaue Zahlen hätte. Zumindest die Beispiele sind deutlich grösser.
Benutzeravatar
Goswin
User
Beiträge: 361
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen

Donnerstag 12. Juni 2008, 15:04

@CM: In bezug auf die float-Exaktheit sagtest du:
Kann man alle drei Zahlen exakt in eine Zahl mit Basis 2 überführen: Ja. Sonst: Nein.
Dieser Sachverhalt ist für meine Anwendung voll und ganz zufriedenstellend; ich arbeite nämlich mit ganzen Zahlen, und solange die klein genug sind, sind die ja alle exakt auf Basis 2 überführbar. Solltest du recht haben, dann kämen Rundungfehler nur vor, wenn diese Zahlen sehr groß sind.

Um auf deine konkrete Frage einzugehen: ich implementiere gerade ein Pivotverfahren (siehe deutsche Wikipedia, Stichwort Pivotverfahren) mit Array-Einträgen in Bruchzahlform (ich verwende Modul Numeric). In 90% der Fälle ist die float-Genauigkeit groß genug, um Zähler und Nenner exakt zu speichern; in diesen Fällen könnte ich auch int-Variablen benutzen. Ich bin aber nicht motiviert, für die verbleibenden 10% der Fälle ein anderes Programm zu schreiben, derselbe Code soll glatt durchlaufen, nur eben mit den bei diesen Fällen unvermeidlichen Rundungsfehlern. Long integers sind zu langsam.
Es geht mir also darum, zwei Fliegen auf einen Schlag zu treffen, und dabei den Code so einfach wie möglich zu halten.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Donnerstag 12. Juni 2008, 15:33

Goswin hat geschrieben:Dieser Sachverhalt ist für meine Anwendung voll und ganz zufriedenstellend; ich arbeite nämlich mit ganzen Zahlen, und solange die klein genug sind, sind die ja alle exakt auf Basis 2 überführbar. Solltest du recht haben, dann kämen Rundungfehler nur vor, wenn diese Zahlen sehr groß sind.
Vorsicht: Meine Antwort bezog sich auf Additionen nicht auf Divisionen! Wenn Du mit floats operierst, versucht Python (ab Vers. 3 gilt selbst diese Einschränkung nicht mehr) "präzise" zu arbeiten und rechnet auch mit floats, selbst, wenn diese ganze Zahlen repräsentieren sollen. Das erklärt locker die verbleibenden 10% Differenzen ...

Zu Deiner Frage: Was spricht gegen die Verwendung der scipy-Routinen? Ich nehme an "Genauigkeit". Aber die geht eben auf Kosten der Präzission. Wenn Du mit Deinem Kompromiss zufrieden bist, ist natürlich auch gut.

Besten Gruß,
Christian
Benutzeravatar
Goswin
User
Beiträge: 361
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen

Donnerstag 12. Juni 2008, 15:45

@CM: Es gibt keine 10% Differenzen im Sinne von Ungenauigkeit!
In 10% der Aufgaben ist die Dateneingabe so, dass mathematisch große Zahlen vorkommen und einfach nicht zu vermeiden sind!

Gruß und Dank für deine Bemerkungen. Vielleicht gilt deine Aussage ja trotzdem für Divisonen, anscheinend haben wir noch kein Gegenbeispiel mit ganzen und gleichzeitig nicht allzugroßen Zahlen.
Antworten