Vorsicht Falle (Rechengenauigkeit)

Warum funktioniert ein bestimmtes Modul nicht so, wie man es sich vorstellt? Hier kann man Dampf ablassen.

Moderator: herw

Antworten
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

Manchmal stolpert man über Sachen, die glaubt man nicht:
Ganz harmlos habe ich mal nested loops in Max Zaglers partials framework ausprobiert:
nested loops 1.jpg
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?
nested loops 2.jpg
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!
nested loops 3.jpg
dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da die Summe ist kleiner als 4.6, also noch kein Abbruch!
nested loops 4.jpg
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:
nested loops 5.jpg
ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Thala
meister
Beiträge: 149
Registriert: 1. Oktober 2015, 14:36

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von Thala »

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 :(
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

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 :(
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:
Gleitkommazahlen.
ciao herw
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von Eventmanager »

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!
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

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!
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.
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:
mathematisches Runden.jpg
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.
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von Eventmanager »

Danke, hab nur R5 aber die Blaupause lässt sich ja im Handumdrehen nachbauen. Frage: Reden wir hier von dem gleichen round?
Bildschirmfoto 2017-06-17 um 11.50.45.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

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?
Bildschirmfoto 2017-06-17 um 11.50.45.jpg
ja, es besteht nur aus einem float-Eingang und einem integer-Ausgang und hat ansonsten innen nur eine direkte Verbindung.
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von Eventmanager »

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?)
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

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?)
partials framework ist in REAKTOR 5 entwickelt worden (und natürlich auch in R6 benutzbar).
Ich benutze hauptsächlich multiplexing und die standard library in core. Dort findest du auch im math-Ordner die verschiedenen Rundungsarten.
::kaffee::
bild 1.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von Eventmanager »

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...
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitrag von herw »

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...
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.
Als must-have ist es hier schon des öfteren erwähnt worden.
Antworten