Vorsicht Falle (Rechengenauigkeit)
Moderator: herw
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Vorsicht Falle (Rechengenauigkeit)
Manchmal stolpert man über Sachen, die glaubt man nicht:
Ganz harmlos habe ich mal nested loops in Max Zaglers partials framework ausprobiert: Die äußere Schleife läuft mit der Schrittweite 1 von n=2 bis 4. Die innere Schleife wiederholt den Wert n und fügt Additionen hinzu. Die Abbruchbedingung lautet, dass n+0.6 nicht erreicht werden soll.
Also erwarte ich 2 2 2.2 2.4 3 3 3.2 3.4 4 4 4.2 4.4.
Doch was muss ich erblicken? Es wird zusätzlich der Wert 4.6 angezeigt. Was soll das denn?
Nach langem Nachdenken und rumprobieren kam mir die Fundgrube in den Sinn: Dezimaldarstellung -> 32 bit Fließkommazahl.
Da war doch was mit der Rechengenauigkeit; also mal ein kleiner harmloser Test:
dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da, die Summe ist größer als 3.6, also Abbruch! dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da die Summe ist kleiner als 4.6, also noch kein Abbruch! arrggh! darauf muss man erstmal kommen. Was ist die Konsequenz: loops grundsätzlich mit integer-Werten und erst dann für die Ausgabe eine Umrechnung: ciao herw
Ganz harmlos habe ich mal nested loops in Max Zaglers partials framework ausprobiert: Die äußere Schleife läuft mit der Schrittweite 1 von n=2 bis 4. Die innere Schleife wiederholt den Wert n und fügt Additionen hinzu. Die Abbruchbedingung lautet, dass n+0.6 nicht erreicht werden soll.
Also erwarte ich 2 2 2.2 2.4 3 3 3.2 3.4 4 4 4.2 4.4.
Doch was muss ich erblicken? Es wird zusätzlich der Wert 4.6 angezeigt. Was soll das denn?
Nach langem Nachdenken und rumprobieren kam mir die Fundgrube in den Sinn: Dezimaldarstellung -> 32 bit Fließkommazahl.
Da war doch was mit der Rechengenauigkeit; also mal ein kleiner harmloser Test:
dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da, die Summe ist größer als 3.6, also Abbruch! dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da die Summe ist kleiner als 4.6, also noch kein Abbruch! arrggh! darauf muss man erstmal kommen. Was ist die Konsequenz: loops grundsätzlich mit integer-Werten und erst dann für die Ausgabe eine Umrechnung: ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- meister
- Beiträge: 149
- Registriert: 1. Oktober 2015, 14:36
Re: Vorsicht Falle (Rechengenauigkeit)
danke herw.
da ich gerne in core arbeite, bin ich auch schon ein paar mal ueber rechen ungenauigkeiten gestolpert.
und jedes mal kostet es stunden,
bis man sich erinnert:
da war doch was mit 64bit.
eigentlich ziemlich peinlich, wenn reaktor es mit 32bit nicht schafft 1 und 1 zusammen zu zaehlen. oder eine simple null als e hoch minus irgendwas darstellt. scheint wohl in der floating point natur zu liegen
da ich gerne in core arbeite, bin ich auch schon ein paar mal ueber rechen ungenauigkeiten gestolpert.
und jedes mal kostet es stunden,
bis man sich erinnert:
da war doch was mit 64bit.
eigentlich ziemlich peinlich, wenn reaktor es mit 32bit nicht schafft 1 und 1 zusammen zu zaehlen. oder eine simple null als e hoch minus irgendwas darstellt. scheint wohl in der floating point natur zu liegen
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Vorsicht Falle (Rechengenauigkeit)
ja klar,denn es werden nur wenige Stellen für die Mantisse benutzt. Unabhängig davon, nimmt die Dichte der Gleitkommazahlen mit deren Größe ab:Thala hat geschrieben:danke herw.
da ich gerne in core arbeite, bin ich auch schon ein paar mal ueber rechen ungenauigkeiten gestolpert.
und jedes mal kostet es stunden,
bis man sich erinnert:
da war doch was mit 64bit.
eigentlich ziemlich peinlich, wenn reaktor es mit 32bit nicht schafft 1 und 1 zusammen zu zaehlen. oder eine simple null als e hoch minus irgendwas darstellt. scheint wohl in der floating point natur zu liegen
Gleitkommazahlen.
ciao herw
-
- synth doctor
- Beiträge: 273
- Registriert: 25. Juni 2013, 15:26
Re: Vorsicht Falle (Rechengenauigkeit)
Ebenso blöd wie N,5 dass bei Quantizierung mal Auflösung zum nächsthöheren Wert, mal Abrundung bedeutet. Warum einigt man sich nicht endlich darauf, das n,5 in der Quantizierung unzulässig ist? 4:8 darf als Quantizierungs-Wert nicht 0.5 ergeben. Irgendwas unendlich nah dran, aber eben klar definiert zur 0.49999... - oder 0.50000...1 Seite, (dieser Offset wird hinterher selbstredend wieder da zu addiert, aber in den Q-Modulens selbst ist 0.5 nicht gestattet!.)
Man sollte doch wohl eine Lösung finden, die jenseits von Beliebigkeit, alle zu fFreiden stellt. Wreckmeisters wohltemperiertes 12-Ton-System ist auch nicht korrekt,a ebr wir haben uns drauf geeignigt und leben eigentlich ganz damit!
Wenn ich eben nur die Wahl zwischen Ungenauigkeit und Beliebigkeit habe, ziehe ich Ungenauigkeit vor!
Man sollte doch wohl eine Lösung finden, die jenseits von Beliebigkeit, alle zu fFreiden stellt. Wreckmeisters wohltemperiertes 12-Ton-System ist auch nicht korrekt,a ebr wir haben uns drauf geeignigt und leben eigentlich ganz damit!
Wenn ich eben nur die Wahl zwischen Ungenauigkeit und Beliebigkeit habe, ziehe ich Ungenauigkeit vor!
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Vorsicht Falle (Rechengenauigkeit)
oh da liegst du ganz falsch. Das Auf- und Abrunden bei n,5 ist genau geregelt: IEEE 754. Es wird immer abwechselnd mal auf- und abgerundet. Das ist eine Forderung von Donald E. Knuth, damit es bei längeren Rechnungen nicht zu einer statistischen Drift kommt.Eventmanager hat geschrieben:Ebenso blöd wie N,5 dass bei Quantizierung mal Auflösung zum nächsthöheren Wert, mal Abrundung bedeutet. Warum einigt man sich nicht endlich darauf, das n,5 in der Quantizierung unzulässig ist? 4:8 darf als Quantizierungs-Wert nicht 0.5 ergeben. Irgendwas unendlich nah dran, aber eben klar definiert zur 0.49999... - oder 0.50000...1 Seite, (dieser Offset wird hinterher selbstredend wieder da zu addiert, aber in den Q-Modulens selbst ist 0.5 nicht gestattet!.)
Man sollte doch wohl eine Lösung finden, die jenseits von Beliebigkeit, alle zu fFreiden stellt. Wreckmeisters wohltemperiertes 12-Ton-System ist auch nicht korrekt,a ebr wir haben uns drauf geeignigt und leben eigentlich ganz damit!
Wenn ich eben nur die Wahl zwischen Ungenauigkeit und Beliebigkeit habe, ziehe ich Ungenauigkeit vor!
Wenn du die mathematisch übliche Rundung suchst (immer bei n,5 aufrunden), dann schau mal im partials framework nach, bzw. du kannst auch mein Makro benutzen: Durch die Verdopplung am Anfang des Rechenweges bekommt man genau den Fall, dass aufgerundet wird. Zum Schluss muss wieder halbiert werden.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- synth doctor
- Beiträge: 273
- Registriert: 25. Juni 2013, 15:26
Re: Vorsicht Falle (Rechengenauigkeit)
Danke, hab nur R5 aber die Blaupause lässt sich ja im Handumdrehen nachbauen. Frage: Reden wir hier von dem gleichen round?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Vorsicht Falle (Rechengenauigkeit)
ja, es besteht nur aus einem float-Eingang und einem integer-Ausgang und hat ansonsten innen nur eine direkte Verbindung.Eventmanager hat geschrieben:Danke, hab nur R5 aber die Blaupause lässt sich ja im Handumdrehen nachbauen. Frage: Reden wir hier von dem gleichen round?
-
- synth doctor
- Beiträge: 273
- Registriert: 25. Juni 2013, 15:26
Re: Vorsicht Falle (Rechengenauigkeit)
Aha, also mein "integer-quantizer-"modul"" dass ich aufgrund Kompaktheit der Prim-Alternative vorziehe. Danke nochmal. Im Prinzip ist hier die Quantisierung in den Ein/Ausgang unsichtbar versteckt, oder? Einfach in den Properties den Out auf INT stellen, bedarf doch "intern" einiges mehr, als pures Durchschleifen... Wie überredet man ne Maschine dazu, statt Minuten, Stunden, Tage... nur die Kalenderwoche anzuzeigen?
Jut, grad nachgebaut und 20 mal test-knob auf 0.5 default springen lassen = IMMER 1 ))) Sehr schön! Wobei das prim-Quantize dass von haus aus auch schon macht (zumindest keine Abweichung in meine Versuchen. Hm, Zufall oder Implementation???).
Andre Frage: Das erwähnte Partial Framework... was sind hier deine besonderen Highlights (ausser eigentlich ALLES;-).
Ich suche vor allem so kleine, pfiffige Heinzelmännchen, wie eben der "bedingungslose Aufrunder" und so!
(und: gibts das auch für R5?)
Jut, grad nachgebaut und 20 mal test-knob auf 0.5 default springen lassen = IMMER 1 ))) Sehr schön! Wobei das prim-Quantize dass von haus aus auch schon macht (zumindest keine Abweichung in meine Versuchen. Hm, Zufall oder Implementation???).
Andre Frage: Das erwähnte Partial Framework... was sind hier deine besonderen Highlights (ausser eigentlich ALLES;-).
Ich suche vor allem so kleine, pfiffige Heinzelmännchen, wie eben der "bedingungslose Aufrunder" und so!
(und: gibts das auch für R5?)
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Vorsicht Falle (Rechengenauigkeit)
partials framework ist in REAKTOR 5 entwickelt worden (und natürlich auch in R6 benutzbar).Eventmanager hat geschrieben:Aha, also mein "integer-quantizer-"modul"" dass ich aufgrund Kompaktheit der Prim-Alternative vorziehe. Danke nochmal. Im Prinzip ist hier die Quantisierung in den Ein/Ausgang unsichtbar versteckt, oder? Einfach in den Properties den Out auf INT stellen, bedarf doch "intern" einiges mehr, als pures Durchschleifen... Wie überredet man ne Maschine dazu, statt Minuten, Stunden, Tage... nur die Kalenderwoche anzuzeigen?
Jut, grad nachgebaut und 20 mal test-knob auf 0.5 default springen lassen = IMMER 1 ))) Sehr schön! Wobei das prim-Quantize dass von haus aus auch schon macht (zumindest keine Abweichung in meine Versuchen. Hm, Zufall oder Implementation???).
Andre Frage: Das erwähnte Partial Framework... was sind hier deine besonderen Highlights (ausser eigentlich ALLES;-).
Ich suche vor allem so kleine, pfiffige Heinzelmännchen, wie eben der "bedingungslose Aufrunder" und so!
(und: gibts das auch für R5?)
Ich benutze hauptsächlich multiplexing und die standard library in core. Dort findest du auch im math-Ordner die verschiedenen Rundungsarten.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- synth doctor
- Beiträge: 273
- Registriert: 25. Juni 2013, 15:26
Re: Vorsicht Falle (Rechengenauigkeit)
Ah, danke! Sogar vom "Stephan" höchstselbst gebastelt;-)
Grad gesaugt, Dokumentationen (Plural) sind auch an Bord. So soll´s sein. Vielen Dank nochmal für den Tipp, viellleicht pinnst du den irgendwo als "Must-have", genau wie den ACEW, die FFT und quiitschboys init-tabelle und auch was du so an "universellen" Heinzelmänchen der Welt vermacht hast.... Mir fällt auch noch spontan Paul Rogats HSL/RGB tool, der Bupu-Mapper und so manches von Mike Dalliot ein... Es gibt auch son alles-zu-alles UMRECHNER, schneller und übersichtlicher als jeder OS-Rechner...den hab ich leider irgendwie verschlampt und finde den partout nicht mehr in der UL... /(falls irgendwer weiss was ich meine, bitte Link)
Alles absolut elementare Teile, die an prominenter Stelle in die Factory-Lib gehören...
Grad gesaugt, Dokumentationen (Plural) sind auch an Bord. So soll´s sein. Vielen Dank nochmal für den Tipp, viellleicht pinnst du den irgendwo als "Must-have", genau wie den ACEW, die FFT und quiitschboys init-tabelle und auch was du so an "universellen" Heinzelmänchen der Welt vermacht hast.... Mir fällt auch noch spontan Paul Rogats HSL/RGB tool, der Bupu-Mapper und so manches von Mike Dalliot ein... Es gibt auch son alles-zu-alles UMRECHNER, schneller und übersichtlicher als jeder OS-Rechner...den hab ich leider irgendwie verschlampt und finde den partout nicht mehr in der UL... /(falls irgendwer weiss was ich meine, bitte Link)
Alles absolut elementare Teile, die an prominenter Stelle in die Factory-Lib gehören...
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Vorsicht Falle (Rechengenauigkeit)
partials framework ist von Max Zagler! Stephan hat es unter seinem Namen veröffentlicht. In meiner library kannst du auch die Version 1.1 herunterladen, dort gibt es kleine Korrekturen.Eventmanager hat geschrieben:Ah, danke! Sogar vom "Stephan" höchstselbst gebastelt;-)
Grad gesaugt, Dokumentationen (Plural) sind auch an Bord. So soll´s sein. Vielen Dank nochmal für den Tipp, viellleicht pinnst du den irgendwo als "Must-have", genau wie den ACEW, die FFT und quiitschboys init-tabelle und auch was du so an "universellen" Heinzelmänchen der Welt vermacht hast.... Mir fällt auch noch spontan Paul Rogats HSL/RGB tool, der Bupu-Mapper und so manches von Mike Dalliot ein... Es gibt auch son alles-zu-alles UMRECHNER, schneller und übersichtlicher als jeder OS-Rechner...den hab ich leider irgendwie verschlampt und finde den partout nicht mehr in der UL... /(falls irgendwer weiss was ich meine, bitte Link)
Alles absolut elementare Teile, die an prominenter Stelle in die Factory-Lib gehören...
Als must-have ist es hier schon des öfteren erwähnt worden.